From nobody Mon Feb 1 06:20:58 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218BB1A913F for ; Mon, 1 Feb 2016 06:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xmo-8NQQQRC7 for ; Mon, 1 Feb 2016 06:20:54 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1801A914B for ; Mon, 1 Feb 2016 06:20:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 09A2FD930B; Mon, 1 Feb 2016 15:20:51 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0lNP-UstngvO; Mon, 1 Feb 2016 15:20:50 +0100 (MET) Received: from [192.168.178.33] (x4d02d484.dyn.telefonica.de [77.2.212.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 3E893D9309; Mon, 1 Feb 2016 15:20:50 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA41521DED@ESESSMB205.ericsson.se> Date: Mon, 1 Feb 2016 15:20:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8201C9AF-01C6-424D-87C4-23F4B6128A54@tik.ee.ethz.ch> References: <81564C0D7D4D2A4B9A86C8C7404A13DA41521DED@ESESSMB205.ericsson.se> To: Ingemar Johansson S X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "rmcat WG \(rmcat@ietf.org\)" , "rmcat-chairs@tools.ietf.org" Subject: Re: [rmcat] SCReAM : Question on confusing terminology, OWD vs queueing delay X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 14:20:56 -0000 Hi Ingemar, 2 seems to be the right solution for me as well. Mirja > Am 21.01.2016 um 09:41 schrieb Ingemar Johansson S = : >=20 > Hi > =20 > Xiaoqing Zhu noted that I have mixed up the terms OWD (One way delay) = and queueing delay in the SCReAM draft. RFC6817 (LEDBAT) use the term = queuing delay to denote the extra delay caused by queuing in the = network. The SCReAM draft use the term OWD, it was argued that this can = become confusing for the reader. > There are two ways to solve this : > 1) State clearly in the SCReAM draft that OWD is the estimated = queueing delay > 2) Change to the term queuing delay (queueing_delay or qdelay) in = the SCReAM draft. > =20 > I lean towards alternative 2 as I fear that there will be objections = also in WG last call and later reviews > =20 > Comments/objections ? > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > Ingemar Johansson M.Sc. > Senior Researcher > =20 > Ericsson AB > Wireless Access Networks > Labratoriegr=C3=A4nd 11 > 971 28, Lule=C3=A5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > =20 > =E2=80=9CWe can be heroes, > just for one day=E2=80=9D > David Bowie=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Wed Feb 3 08:12:29 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DF11AD333 for ; Wed, 3 Feb 2016 08:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0q5Sv67AO-oT for ; Wed, 3 Feb 2016 08:12:22 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15D3D1AD2F6 for ; Wed, 3 Feb 2016 08:12:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8E21BD930C; Wed, 3 Feb 2016 17:12:20 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cpBAldLSqtyD; Wed, 3 Feb 2016 17:12:20 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 2FABDD9309; Wed, 3 Feb 2016 17:12:20 +0100 (MET) To: "rmcat@ietf.org" From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <56B226DF.80905@tik.ee.ethz.ch> Date: Wed, 3 Feb 2016 17:12:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Karen Elisabeth Egede Nielsen , =?UTF-8?Q?Anna_Brunstr=c3=b6m?= Subject: [rmcat] Please send agenda requests! X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 16:12:24 -0000 Hi all, we started the planning for our next meeting. We believe there are enough things we need to discuss as a group that we will be able to fill our usual 2.5h slot. However, please send agenda requests now, such that we are able to better plan the meeting! Further, we would like to get a impression who is planning to participate the meeting (in person or remotely), as we assume that there might be less people that usually. Please reply to this mail, or just to the chairs directly, and let us know if you are planning to come or if you know for sure that you will not be there! Thanks, Mirja, Anna and Karen From nobody Thu Feb 4 12:14:34 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C821ACEEF for ; Thu, 4 Feb 2016 12:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkhAdtpifTPf for ; Thu, 4 Feb 2016 12:14:30 -0800 (PST) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55911A87EB for ; Thu, 4 Feb 2016 12:14:29 -0800 (PST) X-Spam-Processed: mail.kau.se, Thu, 04 Feb 2016 21:14:10 +0100 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 213.113.181.50 X-MDArrival-Date: Thu, 04 Feb 2016 21:14:10 +0100 X-Authenticated-Sender: anna.brunstrom@kau.se X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: rmcat@ietf.org To: "rmcat@ietf.org" From: Anna Brunstrom Message-ID: <56B3B11C.9030706@kau.se> Date: Thu, 4 Feb 2016 21:14:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [rmcat] Reminder for reviews X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 20:14:32 -0000 Hi all, We are missing a number of the reviews people signed up for in Yokohama. The original deadlines have passed, but please try to provide your reviews by February 28. Thanks in advance! Anna, Mirja & Karen PS. And thanks to those who have sent in their reviews of course! From nobody Sun Feb 7 03:12:08 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABB81B38F0 for ; Sun, 7 Feb 2016 03:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.52 X-Spam-Level: X-Spam-Status: No, score=0.52 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3f0TloDjcs0 for ; Sun, 7 Feb 2016 03:12:05 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4491B38ED for ; Sun, 7 Feb 2016 03:12:04 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id 9so171059950iom.1 for ; Sun, 07 Feb 2016 03:12:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=/LfoABsFlKn/0/JIpQMbKRdB9J63F0RDa/sHaEBoKR4=; b=fADaA+sgpMKxSpTJlxssRS8CwgYSgnxTevLc7eKXXFqmaw12jI1USV4rZkKQ+I1RtI fMrZAdCKvgwVLlY4rdvtegPu3IZ13ihop8y40Likk7AhDvMwaU6lI32zttgocMn52nkU Do5XKa/n5fQqWfWk+vETT7r9cB8IFZCYqAwQB21OZna+ZLLZcpjPzyuTSKks4AKuK3pr pUgewr9B2HTwG1nqc0KWtbgC8wYWFoSzHyCdt/RGr4x4rCmj9XCm+bx7ITYh5S0XgTjL ria6Qiy5sD0IDmTVU430cLztdi1WT7ADF0kY7PTgRr64y6AzxTMUeurHcnqGetwf7GzB xVqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=/LfoABsFlKn/0/JIpQMbKRdB9J63F0RDa/sHaEBoKR4=; b=aXPztT8pBRY4bHzrQiNbwMYCVDocHzUlMUhhQkE+dZ6yPxjAUiMCp2tRENp55Wbrmu JMpM3d5WZGYOrYhJIlJa1j3hAl3bFL4JuxhDMzFNwQTDpxhE2zecbj5uz4QxKd+KqQkQ i5w5MR/Ah1jfREBNRXciS7lRxGCSatFeNxOouasIFtQ+23hH9OmNSHjiuoY1eQclqvhQ 7rCTPcC36bLU0a8ihzuiEgMQTFnle87KUkGXAOcBkdryY5LcfdGwnN74WhjBvzd6i024 tr8LKG5lzKFYRXRcmv3NZDQ/h/rr4/in2F9WWIm7UMqbLFp9V6+8Vb2RdNSGCKWcSdho ckuw== X-Gm-Message-State: AG10YOSIdzEMgKaxlrcI6pwpgvK23jP8j0Wo7PE1daP+4y+P7HncyjhKjSjawDU9rNKvKR3fAPgOb2Fm+J3SEMMG X-Received: by 10.107.185.8 with SMTP id j8mr20717006iof.94.1454843524011; Sun, 07 Feb 2016 03:12:04 -0800 (PST) MIME-Version: 1.0 From: Stefan Holmer Date: Sun, 07 Feb 2016 11:11:54 +0000 Message-ID: To: rmcat WG , "Mo Zanaty (mzanaty)" , Zaheduzzaman Sarker , "Suhas Nandakumar (snandaku)" , Varun Singh Content-Type: multipart/alternative; boundary=94eb2c076a6a741939052b2c2756 Archived-At: Subject: [rmcat] Review of cc-codec-interactions-01 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 11:12:06 -0000 --94eb2c076a6a741939052b2c2756 Content-Type: text/plain; charset=UTF-8 Hi, Sorry for missing the deadline for reviewing this document. Here are my comments: General observations: - Overall this document seems to be in a good state. - I think we should mention the possibility of having a single CC for the case when several streams are multiplexed over the same port, and maybe mention the possibility of having an Allowed Rate Allocator which splits the Allowed Rate between the different codecs, possibly according to priority/weight. - The definition of Codec feels a bit vague to me, and there are some sections which are talking about Codec interactions where I don't feel Codec is the right component. For instance, I don't understand how the Codec would have an opinion on delay tolerance. Would it be better to define interactions between delay tolerance and App? I can see the connection to loss tolerance though, but that also would fit as an interaction between CC and App. All my raw comments: *Section 5* Startup Ramp (CC-Codec): Initial rate (or number of packets in window-based CC proposals) and strategy for increasing the rate (or window) during media startup, similar to TCP intial congestion window and slow start. See Section 5.4.3 for details. Comments: - It's not entirely clear to me why the Codec would be interested in telling the CC how to ramp up. I see that as possibly something the user/App may want to specify, and the Codec will be notified through changes in the Allowed Rate. - "initial" misspelled. Priority / Weight (Config-CC-UDP): If the application has multiple media flows, and can configure relative priority or weight among them, the config can interact with shared state if coupled CC is used (Section 5.7), or interact directly with a CC designed with intrinsic distributed weighted fairness such as NADA. Priority can also interact with the underlying network stack if it supports layer 2/3 prioritization (Section 5.6). Comments: - I don't think this document should refer to the candidate drafts. I rather see the candidates referring to this doc. *Section 5.1* The primary interactions between the config and the codec that are relevant to congestion control are the multiplexing of media streams [I-D.ietf-mmusic-sdp-bundle-negotiation] and RTP/RTCP [RFC5761] on the same UDP port. Comments: - - How is this a codec interaction? Should it not also mention how it affects CC? In my mind, if we do multiplexing of media streams, a single CC instance could be recommended for that set of streams (see general comments). *Section 5.3* Packetization of codec frames into RTP packets can be an important interaction. Some network interfaces may benefit from small packet sizes well below the MTU, while others may benefit from large packets approaching the MTU. Equalizing packet sizes of a frame may also be beneficial in some cases, rather than a combination of large and small packets. For example, in some FEC schemes, the FEC bandwidth overhead depends on the largest source packet size. Equalizing the source packet sizes can yield lower overhead than a combination of large and small packets. Comments: - Are the last two sentences about FEC really relevant for to CC? *Section 5.4.5* Note this is unrecoverable post-repair loss after retransmission or forward error correction. Comments: - "Note that this" --94eb2c076a6a741939052b2c2756 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Sorry for missing the deadline for = reviewing this document. Here are my comments:

Gen= eral observations:
  • Overall this document seems to be in a= good state.
  • I think we should mention the possibility of having a = single CC for the case when several streams are multiplexed over the same p= ort, and maybe mention the possibility of having an Allowed Rate Allocator = which splits the Allowed Rate between the different codecs, possibly accord= ing to priority/weight.
  • The definition of Codec feels a bit vague t= o me, and there are some sections which are talking about Codec interaction= s where I don't feel Codec is the right component. For instance, I don&= #39;t understand how the Codec would have an opinion on delay tolerance. Wo= uld it be better to define interactions between delay tolerance and App? I = can see the connection to loss tolerance though, but that also would fit as= an interaction between CC and App.

All = my raw comments:
Section 5
=C2=A0Startup Ra= mp (CC-Codec): Initial rate (or number of packets in
=C2=A0 =C2= =A0 =C2=A0 window-based CC proposals) and strategy for increasing the rate<= /div>
=C2=A0 =C2=A0 =C2=A0 (or window) during media startup, similar to= TCP intial congestion
=C2=A0 =C2=A0 =C2=A0 window and slow start= .=C2=A0 See Section 5.4.3 for details.

Comme= nts:
  • It's not entirely clear to me why the Codec woul= d be interested in telling the CC how to ramp up. I see that as possibly so= mething the user/App may want to specify, and the Codec will be notified th= rough changes in the Allowed Rate.
  • "initial" misspell= ed.

Priority / Weight (Config-CC-UD= P): If the application has multiple
=C2=A0 =C2=A0 =C2=A0 media fl= ows, and can configure relative priority or weight among
=C2=A0 = =C2=A0 =C2=A0 them, the config can interact with shared state if coupled CC= is
=C2=A0 =C2=A0 =C2=A0 used (Section 5.7), or interact directly= with a CC designed with
=C2=A0 =C2=A0 =C2=A0 intrinsic distribut= ed weighted fairness such as NADA.=C2=A0 Priority
=C2=A0 =C2=A0 = =C2=A0 can also interact with the underlying network stack if it supports
=C2=A0 =C2=A0 =C2=A0 layer 2/3 prioritization (Section 5.6).
=

Comments:
  • I don't think thi= s document should refer to the candidate drafts. I rather see the candidate= s referring to this doc.
Section 5.1
<= b>
=C2=A0 =C2=A0The primary interactions between the= config and the codec that are
=C2=A0 =C2=A0relevant to congestio= n control are the multiplexing of media streams
=C2=A0 =C2=A0[I-D= .ietf-mmusic-sdp-bundle-negotiation] and RTP/RTCP [RFC5761] on
= =C2=A0 =C2=A0the same UDP port.

Comments:
  • How is this a codec interaction? Should it not als= o mention how it affects CC? In my mind, if we do multiplexing of media str= eams, a single CC instance could be recommended for that set of streams (se= e general comments).

Section 5.3
<= b>
=C2=A0 =C2=A0Packetization of codec frames into R= TP packets can be an important
=C2=A0 =C2=A0interaction.=C2=A0 So= me network interfaces may benefit from small packet
=C2=A0 =C2=A0= sizes well below the MTU, while others may benefit from large packets
=
=C2=A0 =C2=A0approaching the MTU.=C2=A0 Equalizing packet sizes of a f= rame may also be
=C2=A0 =C2=A0beneficial in some cases, rather th= an a combination of large and
=C2=A0 =C2=A0small packets.=C2=A0 F= or example, in some FEC schemes, the FEC bandwidth
=C2=A0 =C2=A0o= verhead depends on the largest source packet size.=C2=A0 Equalizing the
=C2=A0 =C2=A0source packet sizes can yield lower overhead than a com= bination of
=C2=A0 =C2=A0large and small packets.

Comments:
  • Are the last two sentences abou= t FEC really relevant for to CC?

Sect= ion 5.4.5

Note this is unrecoverable post= -repair loss after
=C2=A0 =C2=A0retransmission or forward error c= orrection.

Comments:
  • "= ;Note that this"
--94eb2c076a6a741939052b2c2756-- From nobody Sun Feb 7 04:05:18 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD731B39A1 for ; Sun, 7 Feb 2016 04:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.52 X-Spam-Level: X-Spam-Status: No, score=0.52 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1cv7pOCv4N3 for ; Sun, 7 Feb 2016 04:05:13 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF021B39A0 for ; Sun, 7 Feb 2016 04:05:13 -0800 (PST) Received: by mail-ig0-x232.google.com with SMTP id hb3so40309484igb.0 for ; Sun, 07 Feb 2016 04:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=qM6XC3zEsdheyqplXkddTNMw3V+nglo3hhAYpxjao5Q=; b=hRr6bwkrtrs0b1aN+1+/5E1vPlp4M/SEelzT8xZWQo9GPYpjjbz5I5n2+94u7jeXPp b2hK5YACaSCuQfujoNaaqGUhJZXP1asGnR/Nmd5X59C+/RLdoLZISuzOyzwYRmU5Itv/ 4JqpCKG8x9t9e2gwHUiXtrIKlICvMRWfriwOVajjwzi1d4X2FVDZpBGbi6rUsaAfiglv pvJf77fnLyDwej3+OZNC9A9qj+E835RN06HrqjGbZgjPN8NvWygsb+rcUtxgG31GoJSQ /wHijjGGpnOym4/U98jJznfqS9fdkMiUC/HTtXE6b02vGKh6roHrRjVXh79ZDOflq23w jhHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=qM6XC3zEsdheyqplXkddTNMw3V+nglo3hhAYpxjao5Q=; b=ZZBeil+ymWUhKGr2KXvxOsBir9j2fw8wNPBwQ/qlg4mmBF8UGp+Helv7dbF8KC9ZiU +Tpuh1r92yAhPLASqmA+jFpt5j9iLLhxp9DZHlxrJkScB/4MTVg0lRTFvO8a/vGJPydk hxbW0jry9FCSX713yLKmAHFEEd/+yQCAieRNNKN+APX/xl/BFg0UB+UX8e/3zkKhvYAF rJkNTeJmh7vMz8DKkL82RSXf532cBKbsEFGq+fIDC3BYmeoggrc3EMtPVxnLCI7gy8fg ZBlUDuPA6ZjWDhVK0fL7DuW/t0IY4HIMm9C8H7hiXxtn+/xNIbOR/te92EcreSKCZqtZ k/yg== X-Gm-Message-State: AG10YORzdBCsS+wYHGM0xIPJ+e1ln5VKTJiKeh72zhGtQeLIbiLd9xMazOKbaJP1cNzc+YY5vwIgngd3DNdhh17q X-Received: by 10.50.79.136 with SMTP id j8mr7092119igx.54.1454846712339; Sun, 07 Feb 2016 04:05:12 -0800 (PST) MIME-Version: 1.0 From: Stefan Holmer Date: Sun, 07 Feb 2016 12:05:02 +0000 Message-ID: To: rmcat WG , "Michael Ramalho (mramalho)" , "Xiaoqing Zhu (xiaoqzhu)" , Varun Singh , Zaheduzzaman Sarker Content-Type: multipart/alternative; boundary=089e013a110a7e4f23052b2ce516 Archived-At: Subject: [rmcat] Review on draft-ietf-rmcat-eval-test-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 12:05:16 -0000 --089e013a110a7e4f23052b2ce516 Content-Type: text/plain; charset=UTF-8 Hi, Sorry for being late with this review, here are my comments: *General comments:* - We consider audio and video content, but should we also consider slide shows and/or screen content? In my experience those often sources are widely different in their rate characteristics, and may be very bursty. I think it could be interesting to see how different candidates handle the case where they are source limited most of the time (static image, encoder produces < 50 kbps), and every now and then there's a slide change. - Each video stream is often accompanied by a constant bitrate audio stream in these test cases, but it's not clear to me why? I think we need to clarify how the audio stream is going to be evaluated. Are we going to look at end-to-end latency and jitter? - It's suggested that video resolution should be specified in the test cases, but we don't seem to suggest that video quality should be evaluated (PSNR/SSIM). How are we then expecting that video resolution will matter in these tests? Do we allow the encoder to internally scale down the resolution depending on the available bandwidth? In that case, will be really be evaluating CC candidates or are we starting to lean towards comparing full RTC systems? *Raw comments:* 4.1. Evaluation metircs . . . . . . . . . . . . . . . . . . . 7 Comments: - metrics *Section 3* It should be noted that depending on the test cases it is possible to have different path characteristics in of the either directions. Comments: - "in either of the directions" - There is a bullet which looks misplaced after this. In a testbed environment laboratory there may exist a significant amount of traffic on portions of the network path between the endpoints that is not desired for the purposes of these RMCAT tests. Comments: - I think we should define what a testbed environment laboratory is somewhere. Is it a LAN with some network emulator, or is it a fully simulated network? + Bottleneck queue size: defines size of queue in terms of queuing time when the queue is full (in milliseconds). Comments: - "the size of the queue" * Application-related: defines the traffic source behaviour for implementing the test case Comments: - In this section we mention Video/Voice as media types. Should we also consider screen content/slide shows? See general comments. - Under adaptability we mention resolution as being an option of adaptation. It's not clear to me how we should evaluate something like that without comparing the visual quality in some way. See general comments. *Section 4.3* Also it is possible that the media traffic generator used in a particular simulator or testbed if not capable of generating higher bitrate. Hence we have selected a suitable bitrate range Comments: - Spelling errors: - "testbed is not" - "bit rate" *Section 5.1* maximum Media Bit Rate is Greater than Link Capacity. In this case, the application will attempt to ramp up to its maximum bit rate, since the link capacity is limited to a value lower, the congestion control scheme is expected to stabilize the sending bit rate close to the available bottleneck capacity. This situation can occur when the endpoints are connected via thin long networks even though the advertised capacity of the access network may be higher. Comments: - I don't understand the last sentence here. Isn't it simpler to refer to e.g. cable/adsl links where the uplink may be in the order of 256 - 1024 kbps. It should be noted that the exact variation in available capacity due to any of the above depends on the under-lying technologies. Hence, we describe a set of known factors, which may be extended to devise a more specific test case targeting certain behaviour in a certain network environment. Expected behavior: the candidate algorithm is expected to detect the path capacity constraint, converges to bottleneck link's capacity and Comments: - "underlying" - "targeting* a* certain" - "converges to *the* bottleneck link's capacity" o Path characteristics: as described in Section 4.2 Comments: - I don't think there is a point in mentioning that we are using the defaults. * This test uses the following one way propagation delays of 50 ms and 100 ms. Comments: - "This test uses one way propagation delays of 50 ms and 100 ms" - Is this referring to two instances of the test, or to forward and backward delays? *Section 5.2* Expected behavior: the candidate algorithms is expected to detect the variation in available capacity and adapt the media stream(s) accordingly. The flows stabilize around their maximum bitrate as the as the maximum link capacity is large enough to accommodate the flows. When the available capacity drops, the flow(s) adapts by decreasing its sending bit rate, and when congestion disappears, the flow(s) are again expected to ramp up. Comments: - spelling error "maximum bitrate as the maximum link capacity" - Rewrite last sentence as plural. *Section 5.3* It is expected that the candidate algorithms is able to cope with the lack of feedback information and adapt to minimize the performance degradation of media flows in the forward channel. It should be noted that for this test case: logs are compared with the reference case, i.e, when the backward channel has no impairments Comments: - "algorithms *are* able" - End last sentence with ". - I think the test duration should be longer since this is a fairly complicated scenario. What about 300 s? *Section 5.4* In this test case, more than one RMCAT media flow shares the bottleneck link and each of them uses the same congestion control algorithm. This is a typical scenario where a real-time interactive application sends more than one media flows to the same destination and these flows are multiplexed over the same port. Comments: - - I don't think multiplexing is a good example here. There is no reason why they would actually fight for bandwidth between each other if they are multiplexed over the same port, as they may as well run a single CC and allocate the available bandwidth between them. Better to take an example of two or more different endpoints in the same office calling two or more endpoints in another office, or similar. - misspelled: "one media flows" should be "one media flow" Testbed topology: Three media sources S1, S2, S3 are connected to respective R1, R2, R3. Comments: - Should probably be "are connected to R1, R2 and R3 respectively". +---------+------------+------------+----------+ | Flow IF | Media type | Start time | End time | +---------+------------+------------+----------+ Comments: - Flow ID *Section 5.1* * Path capacity ratio: 1.0 Comments: - Not necessary to mention as I think it is the default? Also mentioned in other places. + Congestion control: Default TCP congestion control. Comments: - Should we suggest what the default TCP CC could be? New reno, Cubic? *Section 5.8* In this test case, more than one real-time interactive media flows share the link bandwidth and all flows reach to a steady state by utilizing the link capacity in an optimum way. At these stage one of the media flow is paused for a moment. This event will result in more available bandwidth for the rest of the flows and as they are on a shared link. When the paused media flow will resume it would no longer have the same bandwidth share on the link. It has to make it's way through the other existing flows in the link to achieve a fair share of the link capacity. This test case is important specially for real-time interactive media which consists of more than one media flows and can pause/resume media flow at any point of time during the session. This test case directly addresses the requirement number 5 in [I-D.ietf-rmcat-cc-requirements]. One can think it as a variation of test case defined in Section 5.4. However, it is different as the candidate algorithms can use different strategies to increase its efficiency, for example the fairness, convergence time, reduce oscillation etc, by capitalizing the fact that they have previous information of the link. Comments: - Several spelling errors: - "At *this* stage one of the media *flows* is paused for a moment." - - "This event will result in more available bandwidth for the rest of the flows *(and)* as they are on a shared link. When the paused media flow *resumes* it *will* no longer have the same bandwidth share on the link." - - " ... one media flows and can pause/resume media *flows* at any point of time during the session." - - "However, it is different as the candidate algorithms can use different strategies to increase *their* efficiency, for example *(the)* fairness" *Section 6* It has been noticed that there are other interesting test cases besides the basis test cases listed above. Comments: - "base" *Section 6.2* Testbed attributes: o Test duration: 120s o Path characteristics: * Reference bottleneck capacity between A and B = 2Mbps. ... * One-Way propagation delay: 1. Between S1 and R1: 100ms 2. Between S2 and R2: 40ms 3. Between S3 and R3: 40ms Comments: - Duration should probably be at least 300s given the complexity of this setup. - Does the reference bottleneck capacity apply to all links or only A and B? If only A and B, what's the reference for the other links? - In my opinion this test case is complex enough without different one-way propagation delays on the links. *Section 7* Additional wireless network (both cellular network and WiFi network) specific test cases are define in [I-D.ietf-rmcat-wireless-tests] Comments: - "defined in" --089e013a110a7e4f23052b2ce516 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Sorry for being late with this revi= ew, here are my comments:

General comments:=
  • We consider audio and video content, but should we also = consider slide shows and/or screen content? In my experience those often so= urces are widely different in their rate characteristics, and may be very b= ursty. I think it could be interesting to see how different candidates hand= le the case where they are source limited most of the time (static image, e= ncoder produces < 50 kbps), and every now and then there's a slide c= hange.
  • Each video stream is often accompanied by a constant bitrate= audio stream in these test cases, but it's not clear to me why? I thin= k we need to clarify how the audio stream is going to be evaluated. Are we = going to look at end-to-end latency and jitter?
  • It's suggested = that video resolution should be specified in the test cases, but we don'= ;t seem to suggest that video quality should be evaluated (PSNR/SSIM). How = are we then expecting that video resolution will matter in these tests? Do = we allow the encoder to internally scale down the resolution depending on t= he available bandwidth? In that case, will be really be evaluating CC candi= dates or are we starting to lean towards comparing full RTC systems?

Raw comments:

=
=C2=A0 =C2=A0 =C2=A04.1.=C2=A0 Evaluation metircs =C2=A0. . . . . . . = . . . . . . . . . . . . =C2=A0 7
Comments:
    metrics

Section 3
=
It should be noted that
=C2=A0 =C2=A0 =C2= =A0 depending on the test cases it is possible to have different path
=
=C2=A0 =C2=A0 =C2=A0 characteristics in of the either directions.

Comments:
  • "in either of t= he directions"
  • There is a bullet which looks misplaced after t= his.

In a =C2=A0testbed environment laboratory= there may exist a significant
=C2=A0 =C2=A0 =C2=A0 amount of tra= ffic on portions of the network path between the
=C2=A0 =C2=A0 = =C2=A0 endpoints that is not desired for the purposes of these RMCAT
<= div>=C2=A0 =C2=A0 =C2=A0 tests.

Comments:
  • I think we should define what a testbed environment laborat= ory is somewhere. Is it a LAN with some network emulator, or is it a fully = simulated network?

=C2=A0 + =C2=A0Bottlene= ck queue size: defines size of queue in terms of
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 queuing time when the queue is full (in millise= conds).

Comments:
  • "th= e size of the queue"

=C2=A0 = =C2=A0 =C2=A0 * =C2=A0Application-related: defines the traffic source behav= iour for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementing the test = case

Comments:
  • In this sec= tion we mention Video/Voice as media types. Should we also consider screen = content/slide shows? See general comments.
  • Under adaptability we me= ntion resolution as being an option of adaptation. It's not clear to me= how we should evaluate something like that without comparing the visual qu= ality in some way. See general comments.

Se= ction 4.3

Also it is possible
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that the media= traffic generator used in a particular
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0simulator or testbed if not capable of gener= ating higher
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0bitrate.=C2=A0 Hence we have selected a suitable bitrate range

Comments:
  • Spelling errors:
    • "testbed is not"
    • "bit rate"
    =
Section 5.1

maxi= mum Media Bit Rate is Greater than Link Capacity.=C2=A0 In this
= =C2=A0 =C2=A0 =C2=A0 case, the application will attempt to ramp up to its m= aximum bit
=C2=A0 =C2=A0 =C2=A0 rate, since the link capacity is = limited to a value lower, the
=C2=A0 =C2=A0 =C2=A0 congestion con= trol scheme is expected to stabilize the sending bit
=C2=A0 =C2= =A0 =C2=A0 rate close to the available bottleneck capacity.=C2=A0 This situ= ation
=C2=A0 =C2=A0 =C2=A0 can occur when the endpoints are conne= cted via thin long networks
=C2=A0 =C2=A0 =C2=A0 even though the = advertised capacity of the access network may be
=C2=A0 =C2=A0 = =C2=A0 higher.

Comments:
  • I don't understand the last sentence here. Isn't it simpler to= refer to e.g. cable/adsl links where the uplink may be in the order of 256= - 1024 kbps.

    • =C2=A0 =C2= =A0It should be noted that the exact variation in available capacity due
    =C2=A0 =C2=A0to any of the above depends on the under-lying technol= ogies.=C2=A0 Hence,
    =C2=A0 =C2=A0we describe a set of known facto= rs, which may be extended to devise a
    =C2=A0 =C2=A0more specific = test case targeting certain behaviour in a certain
    =C2=A0 =C2=A0n= etwork environment.

    Expected behavior: = the candidate algorithm is expected to detect the
    =C2=A0 =C2=A0pa= th capacity constraint, converges to bottleneck link's capacity and

    Comments:
    • "underlying&qu= ot;
    • "targeting a certain"
    • "converges = to the bottleneck link's capacity"

    =
    =C2=A0 =C2=A0o =C2=A0Path characteristics: as described in Section 4.2=

    Comments:
    • I don't think= there is a point in mentioning that we are using the defaults.
    =C2=A0 =C2=A0 =C2=A0 * =C2=A0This test uses the following one way p= ropagation delays of 50
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ms and = 100 ms.

    Comments:
    • &q= uot;This test uses one way propagation delays of 50 ms and 100 ms"
    • Is this referring to two instances of the test, or to forward and back= ward delays?

    Section 5.2

    =C2=A0 =C2=A0Expected behavior: the candidate = algorithms is expected to detect the
    =C2=A0 =C2=A0variation in av= ailable capacity and adapt the media stream(s)
    =C2=A0 =C2=A0accor= dingly.=C2=A0 The flows stabilize around their maximum bitrate as the
    =
    =C2=A0 =C2=A0as the maximum link capacity is large enough to accommoda= te the
    =C2=A0 =C2=A0flows.=C2=A0 When the available capacity drop= s, the flow(s) adapts by
    =C2=A0 =C2=A0decreasing its sending bit = rate, and when congestion disappears, the
    =C2=A0 =C2=A0flow(s) ar= e again expected to ramp up.

    Comments:
    • spelling error "maximum bitrat= e as the=C2=A0maximum link capacity"
    • Rewrite last sentence as = plural.

    Section 5.3
    =
    =C2=A0 =C2=A0It is expected that the candidate algo= rithms is able to cope with the
    =C2=A0 =C2=A0lack of feedback inf= ormation and adapt to minimize the performance
    =C2=A0 =C2=A0degra= dation of media flows in the forward channel.

    =C2= =A0 =C2=A0It should be noted that for this test case: logs are compared wit= h
    =C2=A0 =C2=A0the reference case, i.e, when the backward channel= has no impairments

    Comments:
      =
    • "algorithms are able"
    • End last sentence with &= quot;.
    • I think the test duration should be longer since this is a f= airly complicated scenario. What about 300 s?

    Section 5.4

    =C2=A0 =C2=A0I= n this test case, more than one RMCAT media flow shares the
    =C2= =A0 =C2=A0bottleneck link and each of them uses the same congestion control=
    =C2=A0 =C2=A0algorithm.=C2=A0 This is a typical scenario where a= real-time interactive
    =C2=A0 =C2=A0application sends more than o= ne media flows to the same destination
    =C2=A0 =C2=A0and these flo= ws are multiplexed over the same port.=C2=A0

    Comments:
    • I don't think multiplexing is a g= ood example here. There is no reason why they would actually fight for band= width between each other if they are multiplexed over the same port, as the= y may as well run a single CC and allocate the available bandwidth between = them. Better to take an example of two or more different endpoints in the s= ame office calling two or more endpoints in another office, or similar.
    • misspelled: "one media flows" should be "one media flow= "

    =C2=A0 =C2=A0Testbed topology: Three me= dia sources S1, S2, S3 are connected to
    =C2=A0 =C2=A0respective R= 1, R2, R3.=C2=A0

    Comments:
      Should probably be "are connected to R1, R2 and R3 respectively"= .


    =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------+------------+------------+-------= ---+
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Flow IF | = Media type | Start time | End time |
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+---------+------------+------------+----------+
    <= /div>

    Comments:
    • Flow ID

    <= /div>
    Section 5.1

    =C2=A0 =C2=A0 =C2=A0 = * =C2=A0Path capacity ratio: 1.0
    Comments:
    • Not = necessary to mention as I think it is the default? Also mentioned in other = places.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2=A0Conge= stion control: Default TCP congestion control.
    Comments:
    • Should we suggest what the default TCP CC could be? New reno,= Cubic?
    Section 5.8

    <= div>
    =C2=A0 =C2=A0In this test case, more than one real-time interactiv= e media flows
    =C2=A0 =C2=A0share the link bandwidth and all flows= reach to a steady state by
    =C2=A0 =C2=A0utilizing the link capac= ity in an optimum way.=C2=A0 At these stage one of
    =C2=A0 =C2=A0t= he media flow is paused for a moment.=C2=A0 This event will result in
    =
    =C2=A0 =C2=A0more available bandwidth for the rest of the flows and as= they are on
    =C2=A0 =C2=A0a shared link.=C2=A0 When the paused me= dia flow will resume it would no
    =C2=A0 =C2=A0longer have the sam= e bandwidth share on the link.=C2=A0 It has to make
    =C2=A0 =C2=A0= it's way through the other existing flows in the link to achieve a
    =C2=A0 =C2=A0fair share of the link capacity.=C2=A0 This test case is= important
    =C2=A0 =C2=A0specially for real-time interactive media= which consists of more than
    =C2=A0 =C2=A0one media flows and can= pause/resume media flow at any point of time
    =C2=A0 =C2=A0during= the session.=C2=A0 This test case directly addresses the
    =C2=A0 = =C2=A0requirement number 5 in [I-D.ietf-rmcat-cc-requirements].=C2=A0 One c= an
    =C2=A0 =C2=A0think it as a variation of test case defined in S= ection 5.4.
    =C2=A0 =C2=A0However, it is different as the candidat= e algorithms can use
    =C2=A0 =C2=A0different strategies to increas= e its efficiency, for example the
    =C2=A0 =C2=A0fairness, converge= nce time, reduce oscillation etc, by capitalizing
    =C2=A0 =C2=A0th= e fact that they have previous information of the link.
    Comments:
    • Several spelling errors:
        • "At this stage one of =C2=A0the media flows is paused = for a moment."
      • "This event will result in more a= vailable bandwidth for the rest of the flows (and)=C2=A0as they are = on a shared link.=C2=A0 When the paused=C2=A0media flow resumes it <= b>will no longer have the same bandwidth share on the link."
        • <= li>
      • " ... one media flows and can pause/resume media flows<= /b> at any point of time during the session."
      • "H= owever, it is different as the candidate algorithms can use different strat= egies to increase their efficiency, for example (the) fairnes= s"

    Section 6
    =C2=A0= It has been noticed that there are other interesting test cases
    = =C2=A0 =C2=A0besides the basis test cases listed above.
    Comments:
    • "base"
    S= ection 6.2
    =C2=A0 =C2=A0Testbed attributes:
    <= div>
    =C2=A0 =C2=A0o =C2=A0Test duration: 120s

    <= /div>
    =C2=A0 =C2=A0o =C2=A0Path characteristics:

    =C2=A0 =C2=A0 =C2=A0 * =C2=A0Reference bottleneck capacity between A and= B =3D 2Mbps.
    ...

    =C2=A0 =C2= =A0 =C2=A0 * =C2=A0One-Way propagation delay:

    =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01.=C2=A0 Between S1 and R1: 100ms
    =
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02.=C2=A0 Between S2 and R2= : 40ms

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03.=C2=A0 = Between S3 and R3: 40ms

    Comments:
    =
    • Duration should probably be at least 300s given the complexity of t= his setup.
    • Does the reference bottleneck capacity apply to all link= s or only A and B? If only A and B, what's the reference for the other = links?
    • In my opinion this test case is complex enough without diffe= rent one-way propagation delays on the links.
    Section 7
    =C2=A0 =C2=A0Additional wireless network (both cellular ne= twork and WiFi network)
    =C2=A0 =C2=A0specific test cases are defi= ne in [I-D.ietf-rmcat-wireless-tests]

    Commen= ts:
    • "defined in"

    =

    --089e013a110a7e4f23052b2ce516-- From nobody Mon Feb 8 05:28:19 2016 Return-Path: X-Original-To: rmcat@ietf.org Delivered-To: rmcat@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C62C71B2AE1; Mon, 8 Feb 2016 05:28:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160208132817.28179.49983.idtracker@ietfa.amsl.com> Date: Mon, 08 Feb 2016 05:28:17 -0800 Archived-At: Cc: rmcat@ietf.org Subject: [rmcat] I-D Action: draft-ietf-rmcat-scream-cc-03.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 13:28:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RTP Media Congestion Avoidance Techniques of the IETF. Title : Self-Clocked Rate Adaptation for Multimedia Authors : Ingemar Johansson Zaheduzzaman Sarker Filename : draft-ietf-rmcat-scream-cc-03.txt Pages : 34 Date : 2016-02-08 Abstract: This memo describes a rate adaptation algorithm for conversational media services such as video. The solution conforms to the packet conservation principle and uses a hybrid loss and delay based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a LTE (Long Term Evolution) system simulator and is shown to achieve both low latency and high video throughput in these scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-scream-cc/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rmcat-scream-cc-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-scream-cc-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 8 05:44:24 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1301B2B45 for ; Mon, 8 Feb 2016 05:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bLyBfDzCqtJ for ; Mon, 8 Feb 2016 05:44:21 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C921B2B37 for ; Mon, 8 Feb 2016 05:44:20 -0800 (PST) X-AuditID: c1b4fb2d-f78fe6d00000163a-32-56b89bb2c9c4 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 14.61.05690.2BB98B65; Mon, 8 Feb 2016 14:44:18 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.36]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Mon, 8 Feb 2016 14:44:17 +0100 From: Ingemar Johansson S To: "rmcat WG (rmcat@ietf.org)" Thread-Topic: New Version Notification for draft-ietf-rmcat-scream-cc-03.txt Thread-Index: AQHRYnSTIQxsMyb/4kaUHJC4JWpxXp8iJy0Q Date: Mon, 8 Feb 2016 13:44:16 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA41547BDE@ESESSMB205.ericsson.se> References: <20160208132818.28179.45629.idtracker@ietfa.amsl.com> In-Reply-To: <20160208132818.28179.45629.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbE9UHfT7B1hBo9+81t0/G1hsVh98wOb A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJVxdPdO1oIf4hWT9vxnbWBcId7FyMkhIWAi sefCbWYIW0ziwr31bF2MXBxCAocZJTZP+MQI4SxilFjReJMFpIpNwEZi5aHvQAkODhEBA4mb vaYgYWYBe4kH7Z/BBgkLeEvc6FoOZosI+Ejsv3OAHcI2kri3+yBYnEVARaJjchMriM0r4Csx ecdBRhBbSMBR4kznS7A4p4CTxJaVS9hAbEYBWYn73++xQOwSl7j1ZD4TxNECEkv2nId6QFTi 5eN/rCCnSQgoSUzbmgZiMgtoSqzfpQ/RqSgxpfshO8RWQYmTM5+wTGAUm4Vk6CyEjllIOmYh 6VjAyLKKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzByDm75rbuDcfVrx0OMAhyMSjy8BlO2 hwmxJpYVV+YeYpTgYFYS4d3RuyNMiDclsbIqtSg/vqg0J7X4EKM0B4uSOO8a5/VhQgLpiSWp 2ampBalFMFkmDk6pBkaBpW+6p+5YUp34o/fQq5oFmkvZt7OZ8yxSKT7ifzR4wVaz8/Of1GbY yzVJauXOPMtYwcnhfDq+c/bHdc+8f16e0PD83cGUmVttS6ROurjXrz77ZvWhGd0TpvFdOphc y2wcpZV88Eua3fTDx8X+mZ77ZiN7ruT1gvy4iRuORvdZ+2p++JL0i0lKiaU4I9FQi7moOBEA Mw3T3pgCAAA= Archived-At: Cc: "rmcat-chairs@tools.ietf.org" Subject: [rmcat] FW: New Version Notification for draft-ietf-rmcat-scream-cc-03.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 13:44:22 -0000 SGkNCg0KVGhlIFNDUmVBTSBkcmFmdCBpcyBub3cgdXBkYXRlZCwgdGhhbmtzIHRvIFN0ZWZhbiBh bmQgIFhpYW9xaW5nIGZvciB0aGUgcmV2aWV3IGFuZCBjb21tZW50cy4gSSBob3BlIEkgaGF2ZSBt YW5hZ2VkIHRvIGFkZHJlc3MgYWxsIHRoZSBjb21tZW50cy4gDQpUaGUgbWFpbiBjaGFuZ2VzIGFy ZToNCisgT1dEIGNoYW5nZWQgdG8gcWRlbGF5IGZvciBjbGFyaXR5LiANCisgQWRkZWQgYXBwZW5k aXggIHNlY3Rpb24gd2l0aCBSVENQIGZlZWRiYWNrIHJlcXVpcmVtZW50cywgaW5jbHVkaW5nIGEg c3VnZ2VzdGVkDQogICAgICBiYXNpYyBmZWVkYmFjayBmb3JtYXQgYmFzZWQgTG9zcyBSTEUgcmVw b3J0IGJsb2NrIGFuZCB0aGUgUGFja2V0DQogICAgICBSZWNlaXB0IFRpbWVzIGJsb2NrcyBpbiBb UkZDMzYxMV0uICANCisgTG9zcyBkZXRlY3Rpb24gYWRkZWQgYXMgYSAgc2VjdGlvbi4gIA0KKyBU cmFuc21pc3Npb24gc2NoZWR1bGluZyBhbmQgcGFja2V0IHBhY2luZyBleHBsYWluZWQgaW4gICBh cHBlbmRpeC4gIA0KKyBTb3VyY2UgcXVlbmNoIHNlbWFudGljcyBhZGRlZCB0byBhcHBlbmRpeC4g DQoNCi9JbmdlbWFyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2Vu dDogZGVuIDggZmVicnVhcmkgMjAxNiAxNDoyOA0KVG86IFphaGVkdXp6YW1hbiBTYXJrZXI7IFph aGVkdXp6YW1hbiBTYXJrZXI7IEluZ2VtYXIgSm9oYW5zc29uIFMNClN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1ybWNhdC1zY3JlYW0tY2MtMDMudHh0DQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtcm1jYXQtc2NyZWFtLWNjLTAzLnR4 dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEluZ2VtYXIgSm9oYW5zc29uIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYtcm1j YXQtc2NyZWFtLWNjDQpSZXZpc2lvbjoJMDMNClRpdGxlOgkJU2VsZi1DbG9ja2VkIFJhdGUgQWRh cHRhdGlvbiBmb3IgTXVsdGltZWRpYQ0KRG9jdW1lbnQgZGF0ZToJMjAxNi0wMi0wOA0KR3JvdXA6 CQlybWNhdA0KUGFnZXM6CQkzNA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXJtY2F0LXNjcmVhbS1jYy0wMy50eHQNClN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJt Y2F0LXNjcmVhbS1jYy8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1ybWNhdC1zY3JlYW0tY2MtMDMNCkRpZmY6ICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1ybWNhdC1zY3JlYW0tY2MtMDMN Cg0KQWJzdHJhY3Q6DQogICBUaGlzIG1lbW8gZGVzY3JpYmVzIGEgcmF0ZSBhZGFwdGF0aW9uIGFs Z29yaXRobSBmb3IgY29udmVyc2F0aW9uYWwNCiAgIG1lZGlhIHNlcnZpY2VzIHN1Y2ggYXMgdmlk ZW8uICBUaGUgc29sdXRpb24gY29uZm9ybXMgdG8gdGhlIHBhY2tldA0KICAgY29uc2VydmF0aW9u IHByaW5jaXBsZSBhbmQgdXNlcyBhIGh5YnJpZCBsb3NzIGFuZCBkZWxheSBiYXNlZA0KICAgY29u Z2VzdGlvbiBjb250cm9sIGFsZ29yaXRobS4gIFRoZSBhbGdvcml0aG0gaXMgZXZhbHVhdGVkIG92 ZXIgYm90aA0KICAgc2ltdWxhdGVkIEludGVybmV0IGJvdHRsZW5lY2sgc2NlbmFyaW9zIGFzIHdl bGwgYXMgaW4gYSBMVEUgKExvbmcNCiAgIFRlcm0gRXZvbHV0aW9uKSBzeXN0ZW0gc2ltdWxhdG9y IGFuZCBpcyBzaG93biB0byBhY2hpZXZlIGJvdGggbG93DQogICBsYXRlbmN5IGFuZCBoaWdoIHZp ZGVvIHRocm91Z2hwdXQgaW4gdGhlc2Ugc2NlbmFyaW9zLg0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdA0KDQo= From nobody Mon Feb 8 19:01:53 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD47E1A008E for ; Mon, 8 Feb 2016 19:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-3gHNTZXB3V for ; Mon, 8 Feb 2016 19:01:51 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CCF1A008A for ; Mon, 8 Feb 2016 19:01:51 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id q190so117894200ywd.3 for ; Mon, 08 Feb 2016 19:01:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=BtRTU/c4+1PIyZnz0kT8yxzRT/S/ocHIU3nX0SBHsSw=; b=lJBQf+drL1XzZZzk0jKjlvb0uQFFFgoinmN0uFapLNPBH9i1IG2UT5Uvg6+FMc/FFW dur1WoA1A//P63GRe/MplpGa/wMZ4wvN8zin+QnAn4P37XR0zjujZCC0gClkDGek1MXl 5ZdXKOyOg3lo3KYDnuDN9GUyml3PKXPTSFWEOI562fX7THDy4vpIsFcQOo2Cup0uXejB 0+HLMf3zA1Ib4PhZAPcXUzRD88m7OrjtGYUj5c93xBkXFXDUtbCg4s8cY4Vw2Vhq+Fbt Yu/5K6wqtYcMrRCi0QPj2HC2U+24UOpasy/HrtaIqjZQUqeg59+7eNDV0McaXZlqHM69 RIJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=BtRTU/c4+1PIyZnz0kT8yxzRT/S/ocHIU3nX0SBHsSw=; b=ZQi32ChjhnzYHqah2qNQtwYvbyIFIu3n3h6FtcA0QE0q7tmhY0Ip4yZ0WhMzw7MDuv 93mjqyOsQulV8jdCv8FJAAv4gMZpcCa5hf3CZHz0qnsxdhx8RPMcZnnAxOUjd2BFca/r DCrooCXa1v3Ppd4Ese2i+85L8Oezqwbm3fKQ4Ey1N242gQRJ99aYHv4WRoQfZO4eGF4V Fy/LfCdrcI/KieDccY7cUy8enbkPzdig6Oy0F+dOwaXPy9TAPIDjydFhQAw8Fekv7L5R m68qepfg1jJqEIbV++SR0s0AfWyLNzM4ZygWHtwwjyd7S22rh0tEebbyw3ga27vMbzIS Y4iw== X-Gm-Message-State: AG10YOTCXyHKA7l+PtezBYU8p8ENm7SyhVV8NHotYpJHNyX44HAQQU8Xlb2PCP+BtsVHZivjt0MN7xXmdd91UQ== MIME-Version: 1.0 X-Received: by 10.129.72.78 with SMTP id v75mr17230426ywa.78.1454986910951; Mon, 08 Feb 2016 19:01:50 -0800 (PST) Received: by 10.37.99.65 with HTTP; Mon, 8 Feb 2016 19:01:50 -0800 (PST) Date: Mon, 8 Feb 2016 21:01:50 -0600 Message-ID: From: Spencer Dawkins at IETF To: "rmcat@ietf.org" Content-Type: multipart/alternative; boundary=001a114dcb02faf002052b4d89d9 Archived-At: Cc: rmcat-ads@tools.ietf.org Subject: [rmcat] Karen Nielsen stepping down as RMCAT co-chair X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 03:01:53 -0000 --001a114dcb02faf002052b4d89d9 Content-Type: text/plain; charset=UTF-8 Dear RMCATers, I wanted to let the working group know that Karen has stepped down as co-chair for RMCAT. Karen has done great work with Mirja and Lars, and I'd like to thank her for that. Spencer --001a114dcb02faf002052b4d89d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Dear RMCATers,

    I wanted to let the work= ing group know that Karen has stepped down as co-chair for RMCAT.

    Karen has done great work with Mirja and Lars, and I'd = like to thank her for that.

    Spencer
    --001a114dcb02faf002052b4d89d9-- From nobody Tue Feb 9 01:58:57 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B3F1A87C1 for ; Tue, 9 Feb 2016 01:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63viCM-M15ab for ; Tue, 9 Feb 2016 01:58:54 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 856F11A87A4 for ; Tue, 9 Feb 2016 01:58:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1356AD9305; Tue, 9 Feb 2016 10:58:53 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HvDhIaUePvyj; Tue, 9 Feb 2016 10:58:52 +0100 (MET) Received: from [10.2.116.140] (public-docking-etx-1162.ethz.ch [10.2.116.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id B9A3BD9303; Tue, 9 Feb 2016 10:58:52 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Tue, 9 Feb 2016 10:58:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "rmcat@ietf.org" , rmcat-ads@tools.ietf.org Subject: Re: [rmcat] Karen Nielsen stepping down as RMCAT co-chair X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 09:58:56 -0000 Thanks a lot, Karen! Was a great joy to work with you! Mirja > Am 09.02.2016 um 04:01 schrieb Spencer Dawkins at IETF = : >=20 > Dear RMCATers, >=20 > I wanted to let the working group know that Karen has stepped down as = co-chair for RMCAT. >=20 > Karen has done great work with Mirja and Lars, and I'd like to thank = her for that. >=20 > Spencer From nobody Tue Feb 9 06:51:07 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8F11A90B4 for ; Tue, 9 Feb 2016 06:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygz5QwpJbMUC for ; Tue, 9 Feb 2016 06:51:02 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E381A90B0 for ; Tue, 9 Feb 2016 06:51:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 18D69D9305; Tue, 9 Feb 2016 15:51:01 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id V8-q0fkdC74D; Tue, 9 Feb 2016 15:51:00 +0100 (MET) Received: from [10.2.116.140] (public-docking-etx-1162.ethz.ch [10.2.116.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AF8ECD9303; Tue, 9 Feb 2016 15:51:00 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <56AA17AD.8060806@ericsson.com> Date: Tue, 9 Feb 2016 15:51:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <170F0EA5-EAB0-4B01-A8DF-56A0B2923A9A@ifi.uio.no> <56AA17AD.8060806@ericsson.com> To: Zaheduzzaman Sarker X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Safiqul Islam , "rmcat@ietf.org" , "mramalho@cisco.com" , =?utf-8?Q?Anna_Brunstr=C3=B6m?= , Varun Singh , Xiaoqing Zhu Subject: [rmcat] test cases for coupled cc [was: Re: Review of draft-ietf-rmcat-eval-test-02] X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 14:51:07 -0000 Hi Zahed, see below. > Am 28.01.2016 um 14:29 schrieb Zaheduzzaman Sarker = : >=20 >> * I would like to suggest the following two additional test-cases >> under section 6 (other potential test cases). >=20 > The test cases in the draft were designed for end-point adaptation = algorithm without coupled congestion control in mind i.e. no need for = shared bottleneck detection and flow priority. In the last IETF meeting = we talked about the possibility of extending the test cases to include = coupled congestion control algorithm. I believe we decided already at the last meeting that we need to adapt = this draft to include uses cases for coupled congestion (and that=E2=80=99= s why we asked Safiqul to propose some). >=20 > Now if we extend the test cases then I don't think only adding the two = proposed test cases will be sufficient. Yes, that might be true but adding these use cases below would probably = be a good starting point. > We will need to identify all the test cases those are suitable for = running with coupled congestion control. Not sure, if you only have one flow that test case is simply not = suitable and that=E2=80=99s fine. > Like 5.2 can be run with priority per flow. By doing this we can = mention (in each test case or in one place in the document) that one can = run tests with flow priority and perhaps give some means to evaluate the = available capacity distribution with some equation like the one = mentioned here in the proposed test case 6.3. Yes. > However, then this document also needs to include description for = shared bottleneck detection. Why? > In the simplest form, we can perhaps assume that the identified test = cases have single bottleneck point. Yes. >=20 > I think we need to discuss what is best possible way to extend the = test cases if we agreed to do that. As I said I think we agreed already. Please following with Safiqul on = this! >=20 > But before that I would like to know if the WG is OK with extending = the test cases for coupled congestion control. Any further feedback on this from the group is of course welcome! Please = speak up now! >=20 > And will it be a compulsory (candidate algorithms MUST present = results) or optional (candidate algorithms MAY present results) part of = the test case. I guess only candidates that use coupled cc..? Mirja >=20 >>=20 >> 6.3 Prioritization test >>=20 >> In this test case, three RMCAT media flows started out with a = priority >> of 1 each. At around 50 s, the priorities of flow 2 and flow 3 were >> decreased to 1/3 and 2/3. A flow i is assigned the available = capacity >> based on its priority p_{i} as follows: >>=20 >> b_{i} =3D (p_{i} / Sum(p_{k}) ) * BW ; k =3D {1.. 3} >>=20 >> This test case ensures that flows are getting their assigned portions = of >> the available capacity based on their assigned priorities. It can be >> useful for [I-D.ietf-rmcat-coupled-cc]. It addresses the requirement = 3A >> in [I-D.ietf-rmcat-cc-requirements] >>=20 >> Testbed topology: Same as test case defined in section 5.4 >>=20 >> Testbed Attribute: >>=20 >> The general description of the testbed parameters is same as Section = 5.4 >> with changes in the test specific setup as below- >>=20 >> o Other test specific setup: >>=20 >> * RMCAT media flow timeline: >>=20 >> + Flow ID: One (1) >>=20 >> + Start time: 0s >>=20 >> + Flow duration: 119s >>=20 >> + Priority: no change >>=20 >> * RMCAT media flow timeline: >>=20 >> + Flow ID: Two (2) >>=20 >> + Start time: 0s >>=20 >> + Flow duration: 119s >>=20 >> + Priority: change to 1/3 after 50s >>=20 >> * RMCAT media flow timeline: >>=20 >> + Flow ID: Three (3) >>=20 >> + Start time: 0s >>=20 >> + Flow duration: 119s >>=20 >> + Priority: change to 2/3 after 50s >>=20 >>=20 >> 6.4 RMCAT flows competing with one or more long TCP flows >>=20 >> This test case is an extension of the test case defined in section = 5.6. >> It is important for [I-D.ietf-rmcat-coupled-cc], where it requires = more >> than one RMCAT flows in order to couple them. >>=20 >> The general description of the testbed parameters is same as section = 5.6. From nobody Tue Feb 9 07:34:34 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696BF1A92B4 for ; Tue, 9 Feb 2016 07:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.202 X-Spam-Level: X-Spam-Status: No, score=-14.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5xTqDuay1m0 for ; Tue, 9 Feb 2016 07:34:32 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9E71A92AB for ; Tue, 9 Feb 2016 07:34:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=784; q=dns/txt; s=iport; t=1455032072; x=1456241672; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6CcH/ht/FcIjrt+EeNY9CLCkG6Cmy55fs8j25puJB9w=; b=GvvtAWyVmjpjnKef5JVZwak6pt2oXTTPnEEEIuxZlfPSPPGyCIuhp+83 UluJ1r4U1uXXT7yGpnVaQMsL5cPQibmgzswDnAbHEWj+BSeHpN49Arpab EQxm1jnLhMrJHO+Ygx0SzkKE470M6EtJWLPr09OSipmPTmagNU94wsuDg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRBQDLBbpW/4gNJK1egzqBPwaIVq8Jg?= =?us-ascii?q?iGBZoYNAoE0ORMBAQEBAQEBgQqEQgEBBHkQAgEIRiERJQIEAQ0FiAYDEroyDYR?= =?us-ascii?q?PAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYShDeCN4Y1AQSNX4kZAYtcgXOBW40Yh?= =?us-ascii?q?n6Db4NRASIBP4NkagGHVnwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,421,1449532800"; d="scan'208";a="235086826" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2016 15:34:31 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u19FYVfQ025976 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Feb 2016 15:34:31 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 9 Feb 2016 09:34:29 -0600 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1104.009; Tue, 9 Feb 2016 09:34:29 -0600 From: "Xiaoqing Zhu (xiaoqzhu)" To: =?iso-8859-1?Q?Mirja_K=FChlewind?= , Karen Elisabeth Egede Nielsen Thread-Topic: [rmcat] Karen Nielsen stepping down as RMCAT co-chair Thread-Index: AQHRYuY9IsVLQtrzo06XVM98MDZIxp8j374A///5MIA= Date: Tue, 9 Feb 2016 15:34:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.198.216] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <46B14F53F78D8E41919C9BF06A8C750E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rmcat@ietf.org" , "rmcat-ads@tools.ietf.org" Subject: Re: [rmcat] Karen Nielsen stepping down as RMCAT co-chair X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 15:34:33 -0000 +1=20 Thanks to Karen for your great work at RMCAT. I greatly appreciate many of the good advice & suggestions you provided in helping my drafts, either as chair or as reviewer/individual contributor. Xiaoqing On 2/9/16, 3:58 AM, "rmcat on behalf of Mirja K=FChlewind" wrote: >Thanks a lot, Karen! Was a great joy to work with you! > >Mirja > > >> Am 09.02.2016 um 04:01 schrieb Spencer Dawkins at IETF >>: >>=20 >> Dear RMCATers, >>=20 >> I wanted to let the working group know that Karen has stepped down as >>co-chair for RMCAT. >>=20 >> Karen has done great work with Mirja and Lars, and I'd like to thank >>her for that. >>=20 >> Spencer > From nobody Tue Feb 9 07:36:47 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C331A92DE; Tue, 9 Feb 2016 07:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9NJUHeK7gjq; Tue, 9 Feb 2016 07:36:41 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CECBB1A92DC; Tue, 9 Feb 2016 07:36:40 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-92-56ba07862148 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C5.FD.02707.6870AB65; Tue, 9 Feb 2016 16:36:39 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.248.2; Tue, 9 Feb 2016 16:36:38 +0100 References: <20160209150104.21383.43407.idtracker@ietfa.amsl.com> To: , From: Magnus Westerlund Message-ID: <56BA0785.2080802@ericsson.com> Date: Tue, 9 Feb 2016 16:36:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160209150104.21383.43407.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM2K7h247+64wg+udHBYve1ayW6y++YHN gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZb9+2sBYck6tY8WoaUwPjIokuRk4OCQETia53E5kh bDGJC/fWs3UxcnEICRxmlOjddIsJwlnGKPFi8g92kCphAXeJM3N+gtlCAo4S6582gXWLCKhI HDxwnRXEZhOwkLj5o5ENxOYV0JbYu/sjmM0CVLPx6VGwXlGBGImLnUeYIGoEJU7OfMICYnMK OEm0PN0JVMPBwSxgL/FgaxlImFlAXqJ562xmiLXaEg1NHawTGAVmIemehdAxC0nHAkbmVYyi xanFSbnpRkZ6qUWZycXF+Xl6eaklmxiBoXhwy2+DHYwvnzseYhTgYFTi4f0guzNMiDWxrLgy 9xCjBAezkgiv3BugEG9KYmVValF+fFFpTmrxIUZpDhYlcd7VzuvDhATSE0tSs1NTC1KLYLJM HJxSDYztNdfWRW7SLNu0YpfQG0U9w6vMTR+aueKS6udlONxmqT9quPKa6p1LwT6TSg3DD3vU cHU+cypOcd+W083SOM9cripkVeHmWUt+f1aU6Z3Ttz5D5YP2e/n6qpCmr01rrTnfVdR/+srm ZFEc5dvPeOzVJiFT6yg9n7dW917KsT1K1Fn9YdODo0osxRmJhlrMRcWJALYzekFBAgAA Archived-At: Subject: Re: [rmcat] I-D Action: draft-ietf-avtcore-rtp-circuit-breakers-12.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 15:36:44 -0000 AVTCORE and RMCAT, I have in my role as document shepherd reviewed the changes. They are almost all clarifications. There is on added SHOULD NOT in the text. This is that one SHOULD NOT turn off the RTP circuit breaker due to missing RTCP implementation unless a non-RTP/RTCP based circuit breaker is available with reference to the TSVWG circuit breaker. I don't consider this a major changes, and will proceed with producing my publication request and related write-up. The WG will have a week or so to react to the changes before I submit the publication request. Cheers Magnus Westerlund AVTCORE chair Den 2016-02-09 kl. 16:01, skrev internet-drafts@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance of the IETF. > > Title : Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions > Authors : Colin Perkins > Varun Singh > Filename : draft-ietf-avtcore-rtp-circuit-breakers-12.txt > Pages : 24 > Date : 2016-02-09 > > Abstract: > The Real-time Transport Protocol (RTP) is widely used in telephony, > video conferencing, and telepresence applications. Such applications > are often run on best-effort UDP/IP networks. If congestion control > is not implemented in the applications, then network congestion will > deteriorate the user's multimedia experience. This acts as a safety > measure to prevent starvation of network resources denying other > flows from access to the Internet, such measures are essential for an > Internet that is heterogeneous and for traffic that is hard to > predict in advance. This document does not propose a congestion > control algorithm; instead, it defines a minimal set of RTP circuit- > breakers. Circuit-breakers are conditions under which an RTP sender > needs to stop transmitting media data in order to protect the network > from excessive congestion. It is expected that, in the absence of > severe congestion, all RTP applications running on best-effort IP > networks will be able to run without triggering these circuit > breakers. Any future RTP congestion control specification will be > expected to operate within the constraints defined by these circuit > breakers. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-circuit-breakers-12 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Feb 9 07:39:00 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E33F1A92E5 for ; Tue, 9 Feb 2016 07:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-Bg5ftxwTDW for ; Tue, 9 Feb 2016 07:38:58 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E941A92E3 for ; Tue, 9 Feb 2016 07:38:58 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id xg9so79638187igb.1 for ; Tue, 09 Feb 2016 07:38:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=webrtc-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=j5NsSKihwPZJWC7SHmRzSN0gvQO1kvFOeHcJAs8lsTM=; b=R8HoiwAPoMwjf4Efh2rKFytP6YCFitBuUnMsNAyaR+R6wkQ/JQRndINlS8QJZ4c6h9 AQ1VB39weyJh8CnHb+08a2Z1LCaSjSkYgYS3snJnYc8bqILIU3RdAP1rRD2z02X+PVlK hsqkVKTVfoaEVfkVukrjUco3yNsVMTjti5Aul3ul99minvxBdt06Jm+HWC+PSnqtQZgy 0eKV7u6BLi/NPMBBsOslJIg/ZNXG5ZloXxTGjrNG+zwv1WuTEWwOKGJg0RP7ECd8faMg t7bMsDTKvaqyTu4D3GnyOHrSypHaowAwAhkccWQoB1qvehXU4COP8NRII5cQSgrk/1fc uiAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=j5NsSKihwPZJWC7SHmRzSN0gvQO1kvFOeHcJAs8lsTM=; b=lCtx7Ls3UiHKM89Lioaz8dPDPX1pInz4vvYHtZdiJwABY6Szp3jHY4s9UIFSZkKObI cu5V0NxuQ5lnAhFBFD7ISkiUgzB6lFQ7sl0tHT89Om7uME3GYBCO8BajlUkUFz8mdCDg LSehSulDsZ0vCUjFw4Zx1rOYfAcJaE/BSgxPiDqy+OTn7RIZBuq1MxHNusCXrd8of3GX KFc6C5tn+1Rx4V4p7XWpuf63hG+xMe6B2kE3a694DAZhBIzrvd7W6e11QloLDsOcXf7S 0e8ZgHU/O2ue1j47wD0Tt2wC+fI/kxbrkG74GrmbFmvLmnynr56GLtqr00lqSiB0lReK kXrg== X-Gm-Message-State: AG10YOSr/2dXqeU82jpImYcmKMvvCCnDyWKB+Ii3q0P428P/NNqfC+OwSvQPPy4lKqNXCIPhbRfW6GFQ+h06wFxp X-Received: by 10.50.87.7 with SMTP id t7mr5152387igz.65.1455032337454; Tue, 09 Feb 2016 07:38:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Stefan Holmer Date: Tue, 09 Feb 2016 15:38:47 +0000 Message-ID: To: "Xiaoqing Zhu (xiaoqzhu)" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Karen Elisabeth Egede Nielsen Content-Type: multipart/alternative; boundary=047d7bf0c28e9cbdb3052b581d8d Archived-At: Cc: "rmcat@ietf.org" , "rmcat-ads@tools.ietf.org" Subject: Re: [rmcat] Karen Nielsen stepping down as RMCAT co-chair X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 15:38:59 -0000 --047d7bf0c28e9cbdb3052b581d8d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for all your hard work, Karen! On Tue, Feb 9, 2016, 16:34 Xiaoqing Zhu (xiaoqzhu) wrote: > +1 > > Thanks to Karen for your great work at RMCAT. > > I greatly appreciate many of the good advice & suggestions you provided i= n > helping my drafts, either as chair or as reviewer/individual contributor. > > Xiaoqing > > > On 2/9/16, 3:58 AM, "rmcat on behalf of Mirja K=C3=BChlewind" > > wrote: > > >Thanks a lot, Karen! Was a great joy to work with you! > > > >Mirja > > > > > >> Am 09.02.2016 um 04:01 schrieb Spencer Dawkins at IETF > >>: > >> > >> Dear RMCATers, > >> > >> I wanted to let the working group know that Karen has stepped down as > >>co-chair for RMCAT. > >> > >> Karen has done great work with Mirja and Lars, and I'd like to thank > >>her for that. > >> > >> Spencer > > > > --047d7bf0c28e9cbdb3052b581d8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    Thanks for all your hard work, Karen!


    On Tue, Feb 9, 2016, 16:34= =C2=A0Xiaoqing Zhu (xiaoqzhu) <xia= oqzhu@cisco.com> wrote:
    +1
    Thanks to Karen for your great work at RMCAT.

    I greatly appreciate many of the good advice & suggestions you provided= in
    helping my drafts, either as chair or as reviewer/individual contributor.
    Xiaoqing


    On 2/9/16, 3:58 AM, "rmcat on behalf of Mirja K=C3=BChlewind"
    <rmcat-bounc= es@ietf.org on behalf of mirja.kuehlewind@tik.ee.ethz.ch>
    wrote:

    >Thanks a lot, Karen! Was a great joy to work with you!
    >
    >Mirja
    >
    >
    >> Am 09.02.2016 um 04:01 schrieb Spencer Dawkins at IETF
    >><spencerdawkins.ietf@gmail.com>:
    >>
    >> Dear RMCATers,
    >>
    >> I wanted to let the working group know that Karen has stepped down= as
    >>co-chair for RMCAT.
    >>
    >> Karen has done great work with Mirja and Lars, and I'd like to= thank
    >>her for that.
    >>
    >> Spencer
    >

    --047d7bf0c28e9cbdb3052b581d8d-- From nobody Tue Feb 9 07:50:25 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00911AC39A for ; Tue, 9 Feb 2016 07:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.202 X-Spam-Level: X-Spam-Status: No, score=-14.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRuu0nDsxWhY for ; Tue, 9 Feb 2016 07:50:22 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB2501AC398 for ; Tue, 9 Feb 2016 07:50:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1139; q=dns/txt; s=iport; t=1455033022; x=1456242622; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jknDxhcCUTjuUzkhepKp7vMEs6tisnOVtTlEq6BwvxE=; b=hZkRFGvN7JeRVNcpQOQKxLoCsd2mECVG24OQB6ykfzvNWT22GCdENrqp A5ir5OUF97a32f1DExiFEG9tHTu99LC7s5sqBl39KfB8XF0+abPKwF9fB Dl6fGQ+lFawAkv+JDBara8NQJBldOMoizkURrCvWltW1WLdE+AIOHe/A6 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgAtCrpW/5BdJa1egzqBPwaIVq8Jg?= =?us-ascii?q?hMBDYFmhg0CgTQ4FAEBAQEBAQGBCoRBAQEBBHkMBAIBCBEEAQEoByERFAkIAgQ?= =?us-ascii?q?BDQUIh34DErokDYQ7AQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYSAYQ2gjeGNQWNX?= =?us-ascii?q?4kZAYtcgWyBYo0Yhn6Db4NRAR4BAUKDZGoBh1Z8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,421,1449532800"; d="scan'208";a="74414270" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Feb 2016 15:50:21 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u19FoL5H024151 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Feb 2016 15:50:21 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 9 Feb 2016 09:50:21 -0600 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1104.009; Tue, 9 Feb 2016 09:50:21 -0600 From: "Michael Ramalho (mramalho)" To: "Xiaoqing Zhu (xiaoqzhu)" , =?iso-8859-1?Q?Mirja_K=FChlewind?= , "Karen Elisabeth Egede Nielsen" Thread-Topic: [rmcat] Karen Nielsen stepping down as RMCAT co-chair Thread-Index: AQHRYuY9eD0rwR+pTkOHMoSH69vX/58j374AgABdxYD//5/DEA== Date: Tue, 9 Feb 2016 15:50:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.240.243] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rmcat@ietf.org" , "rmcat-ads@tools.ietf.org" Subject: Re: [rmcat] Karen Nielsen stepping down as RMCAT co-chair X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 15:50:24 -0000 +1 ... Thanks Karen! -----Original Message----- From: rmcat [mailto:rmcat-bounces@ietf.org] On Behalf Of Xiaoqing Zhu (xiao= qzhu) Sent: Tuesday, February 09, 2016 10:34 AM To: Mirja K=FChlewind; Karen Elisabeth Egede Nielsen Cc: rmcat@ietf.org; rmcat-ads@tools.ietf.org Subject: Re: [rmcat] Karen Nielsen stepping down as RMCAT co-chair +1 Thanks to Karen for your great work at RMCAT. I greatly appreciate many of the good advice & suggestions you provided in = helping my drafts, either as chair or as reviewer/individual contributor. Xiaoqing On 2/9/16, 3:58 AM, "rmcat on behalf of Mirja K=FChlewind" wrote: >Thanks a lot, Karen! Was a great joy to work with you! > >Mirja > > >> Am 09.02.2016 um 04:01 schrieb Spencer Dawkins at IETF >>: >>=20 >> Dear RMCATers, >>=20 >> I wanted to let the working group know that Karen has stepped down as=20 >>co-chair for RMCAT. >>=20 >> Karen has done great work with Mirja and Lars, and I'd like to thank=20 >>her for that. >>=20 >> Spencer > From nobody Tue Feb 9 08:30:15 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E221AC44D for ; Tue, 9 Feb 2016 08:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sw8sLrI6PTOd for ; Tue, 9 Feb 2016 08:30:12 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4DCE1AC44C for ; Tue, 9 Feb 2016 08:30:11 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aTBAz-0000x7-8w; Tue, 09 Feb 2016 17:30:05 +0100 Received: from mail-ex12.exprod.uio.no ([129.240.120.74]) by mail-mx1.uio.no with esmtps (TLSv1.2:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1aTBAy-0006ju-G7; Tue, 09 Feb 2016 17:30:05 +0100 Received: from mail-ex04.exprod.uio.no (2001:700:100:52::7) by mail-ex12.exprod.uio.no (2001:700:100:120::74) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 9 Feb 2016 17:30:02 +0100 Received: from mail-ex04.exprod.uio.no ([fe80::5da2:f347:6a4b:effc]) by mail-ex04.exprod.uio.no ([fe80::5da2:f347:6a4b:effc%19]) with mapi id 15.00.1130.005; Tue, 9 Feb 2016 17:30:02 +0100 From: Safiqul Islam To: Karen Elisabeth Egede Nielsen Thread-Topic: [rmcat] Karen Nielsen stepping down as RMCAT co-chair Thread-Index: AQHRYuY+oYKlEg9CWEmk9UQUKy76np8jamUAgABdxYCAAARvgIAACxWA Date: Tue, 9 Feb 2016 16:30:01 +0000 Message-ID: <59A6EE09-6F12-4BDE-A2AF-A2AEF47F4F5F@ifi.uio.no> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [129.240.169.59] Content-Type: multipart/alternative; boundary="_000_59A6EE096F124BDEA2AFA2AEF47F4F5Fifiuiono_" MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 1 sum rcpts/h 6 sum msgs/h 1 total rcpts 2620 max rcpts/h 24 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 535F0EA21B2886C2F6C0CD9AACF1761A6DD07E9A X-UiO-SPAM-Test: remote_host: 129.240.120.74 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 72 total 1281440 max/h 1434 blacklist 0 greylist 0 ratelimit 0 X-UiOonly: A9764E8E67493E6AFC742A78ABFE1931002B0336 Archived-At: Cc: "rmcat@ietf.org" , "Michael Ramalho \(mramalho\)" , =?iso-8859-1?Q?Mirja_K=FChlewind?= , "rmcat-ads@tools.ietf.org" , "Xiaoqing Zhu \(xiaoqzhu\)" Subject: Re: [rmcat] Karen Nielsen stepping down as RMCAT co-chair X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 16:30:14 -0000 --_000_59A6EE096F124BDEA2AFA2AEF47F4F5Fifiuiono_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 Thanks Karen for the encouragement and feedback. /Safiqul On 9. feb. 2016, at 16.50, Michael Ramalho (mramalho) > wrote: +1 ... Thanks Karen! -----Original Message----- From: rmcat [mailto:rmcat-bounces@ietf.org] On Behalf Of Xiaoqing Zhu (xiao= qzhu) Sent: Tuesday, February 09, 2016 10:34 AM To: Mirja K=FChlewind; Karen Elisabeth Egede Nielsen Cc: rmcat@ietf.org; rmcat-ads@tools.ietf.org Subject: Re: [rmcat] Karen Nielsen stepping down as RMCAT co-chair +1 Thanks to Karen for your great work at RMCAT. I greatly appreciate many of the good advice & suggestions you provided in = helping my drafts, either as chair or as reviewer/individual contributor. Xiaoqing On 2/9/16, 3:58 AM, "rmcat on behalf of Mirja K=FChlewind" on behalf of mirja.k= uehlewind@tik.ee.ethz.ch> wrote: Thanks a lot, Karen! Was a great joy to work with you! Mirja Am 09.02.2016 um 04:01 schrieb Spencer Dawkins at IETF >: Dear RMCATers, I wanted to let the working group know that Karen has stepped down as co-chair for RMCAT. Karen has done great work with Mirja and Lars, and I'd like to thank her for that. Spencer --_000_59A6EE096F124BDEA2AFA2AEF47F4F5Fifiuiono_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <40AC3F12BDFAAD428D3C3CAD382C541F@mail.uio.no> Content-Transfer-Encoding: quoted-printable +1

    Thanks Karen for the encouragement and feedback.

    /Safiqul


    On 9. feb. 2016, at 16.50, Michael Ramalho (mramalho) <<= a href=3D"mailto:mramalho@cisco.com" class=3D"">mramalho@cisco.com> = wrote:

    +1 ... Thanks Karen!

    -----Original Message-----
    From: rmcat [mailto:rm= cat-bounces@ietf.org] On Behalf Of Xiaoqing Zhu (xiaoqzhu)
    Sent: Tuesday, February 09, 2016 10:34 AM
    To: Mirja K=FChlewind; Karen Elisabeth Egede Nielsen
    Cc: rmcat@ietf.org; rmcat-ads@tools.ietf.org
    Subject: Re: [rmcat] Karen Nielsen stepping down as RMCAT co-chair

    +1

    Thanks to Karen for your great work at RMCAT.

    I greatly appreciate many of the good advice & suggestions you provided= in helping my drafts, either as chair or as reviewer/individual contributo= r.

    Xiaoqing


    On 2/9/16, 3:58 AM, "rmcat on behalf of Mirja K=FChlewind"
    <rmcat-bounces@ietf= .org on behalf of mirja.kuehlew= ind@tik.ee.ethz.ch>
    wrote:

    Thanks a lot, Karen! Was a great joy t= o work with you!

    Mirja


    Am 09.02.2016 um 04:01 schrieb Spencer= Dawkins at IETF
    <spencerdawk= ins.ietf@gmail.com>:

    Dear RMCATers,

    I wanted to let the working group know that Karen has stepped down as
    co-chair for RMCAT.

    Karen has done great work with Mirja and Lars, and I'd like to thank
    her for that.

    Spencer



    --_000_59A6EE096F124BDEA2AFA2AEF47F4F5Fifiuiono_-- From nobody Wed Feb 10 01:24:47 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078781A03A3 for ; Wed, 10 Feb 2016 01:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzdQ12NzYRE6 for ; Wed, 10 Feb 2016 01:24:44 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62F71A03A1 for ; Wed, 10 Feb 2016 01:24:43 -0800 (PST) X-AuditID: c1b4fb25-f797e6d000007600-11-56bb01d9e387 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 21.03.30208.9D10BB65; Wed, 10 Feb 2016 10:24:41 +0100 (CET) Received: from [150.132.141.74] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.248.2; Wed, 10 Feb 2016 10:24:37 +0100 To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <170F0EA5-EAB0-4B01-A8DF-56A0B2923A9A@ifi.uio.no> <56AA17AD.8060806@ericsson.com> From: Zaheduzzaman Sarker Organization: Ericsson AB Message-ID: <56BB01D5.5040902@ericsson.com> Date: Wed, 10 Feb 2016 10:24:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM2K7me5Nxt1hBr9ui1ic+HGZ2WLD6iks Fu8/81usvvmBzeJWyxlGi71N/havW5YxObB7TPm9kdVj56y77B5Llvxk8li9+iGzx98LrWwe xz58ZQtgi+KySUnNySxLLdK3S+DK6N+1kKngjVTF9e42lgbGaaJdjJwcEgImEosvtLNA2GIS F+6tZ+ti5OIQEjjMKHF/xmYmCGcNo0T7hItsIFXCAskS33bcAOsQEXCTmLdqPSuILSQwnVHi yDMFkAZmgT+MEks2TWPsYuTgYBOwkXi82A+khl9AUmJDw25mkDCvgLbExJ1JIGEWAVWJ3W9m MoPYogIxEhc7jzCB2LwCghInZz4BW8Up4CRxbOkvdhCbWcBCYub884wQtrxE89bZYCOFBHQl ul7GTWAUmoWkexaSjllIOhYwMq9iFC1OLU7KTTcy1kstykwuLs7P08tLLdnECIyNg1t+q+5g vPzG8RCjAAejEg+vgfmuMCHWxLLiytxDjBIczEoivAI/gEK8KYmVValF+fFFpTmpxYcYpTlY lMR51zivDxMSSE8sSc1OTS1ILYLJMnFwSjUwRus4Lknkm/ZR67m71M7ZjF0Ki0r2sD7KMnRi E38X/61906S/ix/dk5i9pFC8X3gZ79dvKxfN2pX9z9VmWeWyk/3FdpPKj76bcCz81E+b6MaX izP6yqpKdsjvNMuyne3+cOGRkC7xnbkhwesWsZxPLirtOR6gxtf5ZEOJ3JzdLDXfzcSrpjir KbEUZyQaajEXFScCAHhc6KSJAgAA Archived-At: Cc: Safiqul Islam , "rmcat@ietf.org" , "mramalho@cisco.com" , =?UTF-8?Q?Anna_Brunstr=c3=b6m?= , Varun Singh , Xiaoqing Zhu Subject: Re: [rmcat] test cases for coupled cc [was: Re: Review of draft-ietf-rmcat-eval-test-02] X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 09:24:46 -0000 Hi Mirja, please see inline.... On 2016-02-09 15:51, Mirja Kühlewind wrote: >> >> The test cases in the draft were designed for end-point adaptation >> algorithm without coupled congestion control in mind i.e. no need >> for shared bottleneck detection and flow priority. In the last IETF >> meeting we talked about the possibility of extending the test cases >> to include coupled congestion control algorithm. > > I believe we decided already at the last meeting that we need to > adapt this draft to include uses cases for coupled congestion (and > that’s why we asked Safiqul to propose some). That is what I can also recall but didn't see anything in the meeting minutes so was not sure what we agreed on. May be missed it in the meeting minutes. > >> >> Now if we extend the test cases then I don't think only adding the >> two proposed test cases will be sufficient. > > Yes, that might be true but adding these use cases below would > probably be a good starting point. If I understand shafiqul's last mail, it is fine with only having test results with priority for 5.4 test case. > >> We will need to identify all the test cases those are suitable for >> running with coupled congestion control. > > Not sure, if you only have one flow that test case is simply not > suitable and that’s fine. Yes, that is one identification criteria. But may be we dont need results for all the test cases who has more than one flow. see my previous comment. > >> Like 5.2 can be run with priority per flow. By doing this we can >> mention (in each test case or in one place in the document) that >> one can run tests with flow priority and perhaps give some means to >> evaluate the available capacity distribution with some equation >> like the one mentioned here in the proposed test case 6.3. > > Yes. > >> However, then this document also needs to include description for >> shared bottleneck detection. > > Why? Bcos I dont think the document now even mention "shared bottleneck" and to me coupled congestion control does not make sense without shared bottleneck. > >> In the simplest form, we can perhaps assume that the identified >> test cases have single bottleneck point. > > Yes. > >> >> I think we need to discuss what is best possible way to extend the >> test cases if we agreed to do that. > > As I said I think we agreed already. Please following with Safiqul on > this! > >> >> But before that I would like to know if the WG is OK with extending >> the test cases for coupled congestion control. > > Any further feedback on this from the group is of course welcome! > Please speak up now! > >> >> And will it be a compulsory (candidate algorithms MUST present >> results) or optional (candidate algorithms MAY present results) >> part of the test case. > > I guess only candidates that use coupled cc..? hmm... I am a bit confused now. Are we talking about test case(s) to evaluate the Coupled CC or the use of Coupled CC in the candidate CC? BR -- Zahed ================================================== ANM ZAHEDUZZAMAN SARKER Ericsson AB Services, Media and Network Features Laboratoriegränd 11 97128 Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ================================================== From nobody Wed Feb 10 06:36:25 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775FB1B2B72 for ; Wed, 10 Feb 2016 06:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-fMOT3ZYGJx for ; Wed, 10 Feb 2016 06:36:15 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E78E1B2B66 for ; Wed, 10 Feb 2016 06:36:14 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aTVsJ-0005aM-94; Wed, 10 Feb 2016 15:36:11 +0100 Received: from mail-ex03.exprod.uio.no ([129.240.52.6]) by mail-mx2.uio.no with esmtps (TLSv1.2:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1aTVsI-0006Ym-Fa; Wed, 10 Feb 2016 15:36:11 +0100 Received: from mail-ex04.exprod.uio.no (2001:700:100:52::7) by mail-ex03.exprod.uio.no (2001:700:100:52::6) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 10 Feb 2016 15:36:08 +0100 Received: from mail-ex04.exprod.uio.no ([fe80::5da2:f347:6a4b:effc]) by mail-ex04.exprod.uio.no ([fe80::5da2:f347:6a4b:effc%19]) with mapi id 15.00.1130.005; Wed, 10 Feb 2016 15:36:08 +0100 From: Safiqul Islam To: Zaheduzzaman Sarker Thread-Topic: test cases for coupled cc [was: Re: [rmcat] Review of draft-ietf-rmcat-eval-test-02] Thread-Index: AQHRY0lM+VftAzSKGkKCCoBjW8PXq58k8mKAgABXC4A= Date: Wed, 10 Feb 2016 14:36:08 +0000 Message-ID: References: <170F0EA5-EAB0-4B01-A8DF-56A0B2923A9A@ifi.uio.no> <56AA17AD.8060806@ericsson.com> <56BB01D5.5040902@ericsson.com> In-Reply-To: <56BB01D5.5040902@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [129.240.169.59] Content-Type: multipart/alternative; boundary="_000_FA953D2237A146458F2056C79A4B2806ifiuiono_" MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 1 sum rcpts/h 10 sum msgs/h 1 total rcpts 2627 max rcpts/h 24 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 029436F3420C49F657CC16FF8644E6D99AC33947 X-UiO-SPAM-Test: remote_host: 129.240.52.6 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 171 total 1357315 max/h 1397 blacklist 0 greylist 0 ratelimit 0 X-UiOonly: 8129E71021A041E337563D03FDEE4535B3FF59C1 Archived-At: Cc: "rmcat@ietf.org" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "mramalho@cisco.com" , =?utf-8?B?QW5uYSBCcnVuc3Ryw7Zt?= , Xiaoqing Zhu , Varun Singh Subject: Re: [rmcat] test cases for coupled cc [was: Re: Review of draft-ietf-rmcat-eval-test-02] X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 14:36:24 -0000 --_000_FA953D2237A146458F2056C79A4B2806ifiuiono_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SEkgWmFoZWQsIEhpIE1pcmphLA0KDQpQbGVhc2Ugc2VlIGlubGluZQ0KDQovU2FmaXF1bA0KDQoN Ck9uIDEwLiBmZWIuIDIwMTYsIGF0IDEwLjI0LCBaYWhlZHV6emFtYW4gU2Fya2VyIDx6YWhlZHV6 emFtYW4uc2Fya2VyQGVyaWNzc29uLmNvbTxtYWlsdG86emFoZWR1enphbWFuLnNhcmtlckBlcmlj c3Nvbi5jb20+PiB3cm90ZToNCg0KSGkgTWlyamEsDQoNCnBsZWFzZSBzZWUgaW5saW5lLi4uLg0K DQpPbiAyMDE2LTAyLTA5IDE1OjUxLCBNaXJqYSBLw7xobGV3aW5kIHdyb3RlOg0KDQpUaGUgdGVz dCBjYXNlcyBpbiB0aGUgZHJhZnQgd2VyZSBkZXNpZ25lZCBmb3IgZW5kLXBvaW50IGFkYXB0YXRp b24NCmFsZ29yaXRobSB3aXRob3V0IGNvdXBsZWQgY29uZ2VzdGlvbiBjb250cm9sIGluIG1pbmQg aS5lLiBubyBuZWVkDQpmb3Igc2hhcmVkIGJvdHRsZW5lY2sgZGV0ZWN0aW9uIGFuZCBmbG93IHBy aW9yaXR5LiBJbiB0aGUgbGFzdCBJRVRGDQptZWV0aW5nIHdlIHRhbGtlZCBhYm91dCB0aGUgcG9z c2liaWxpdHkgb2YgZXh0ZW5kaW5nIHRoZSB0ZXN0IGNhc2VzDQp0byBpbmNsdWRlIGNvdXBsZWQg Y29uZ2VzdGlvbiBjb250cm9sIGFsZ29yaXRobS4NCg0KSSBiZWxpZXZlIHdlIGRlY2lkZWQgYWxy ZWFkeSBhdCB0aGUgbGFzdCBtZWV0aW5nIHRoYXQgd2UgbmVlZCB0bw0KYWRhcHQgdGhpcyBkcmFm dCB0byBpbmNsdWRlIHVzZXMgY2FzZXMgZm9yIGNvdXBsZWQgY29uZ2VzdGlvbiAoYW5kDQp0aGF0 4oCZcyB3aHkgd2UgYXNrZWQgU2FmaXF1bCB0byBwcm9wb3NlIHNvbWUpLg0KDQpUaGF0IGlzIHdo YXQgSSBjYW4gYWxzbyByZWNhbGwgYnV0IGRpZG4ndCBzZWUgYW55dGhpbmcgaW4gdGhlIG1lZXRp bmcNCm1pbnV0ZXMgc28gd2FzIG5vdCBzdXJlIHdoYXQgd2UgYWdyZWVkIG9uLiBNYXkgYmUgbWlz c2VkIGl0IGluIHRoZSBtZWV0aW5nIG1pbnV0ZXMuDQoNCg0KDQpOb3cgaWYgd2UgZXh0ZW5kIHRo ZSB0ZXN0IGNhc2VzIHRoZW4gSSBkb24ndCB0aGluayBvbmx5IGFkZGluZyB0aGUNCnR3byBwcm9w b3NlZCB0ZXN0IGNhc2VzIHdpbGwgYmUgc3VmZmljaWVudC4NCg0KWWVzLCB0aGF0IG1pZ2h0IGJl IHRydWUgYnV0IGFkZGluZyB0aGVzZSB1c2UgY2FzZXMgYmVsb3cgd291bGQNCnByb2JhYmx5IGJl IGEgZ29vZCBzdGFydGluZyBwb2ludC4NCg0KSWYgSSB1bmRlcnN0YW5kIHNoYWZpcXVsJ3MgbGFz dCBtYWlsLCBpdCBpcyBmaW5lIHdpdGggb25seSBoYXZpbmcgdGVzdCByZXN1bHRzIHdpdGggcHJp b3JpdHkgZm9yIDUuNCB0ZXN0IGNhc2UuDQoNCkZvciBzaW1wbGljaXR5LCBJIHN1Z2dlc3RlZCB0 byB1c2Ugb25seSB0ZXN0IGNhc2UgNS40LCBidXQgSSBhbSBub3QgYWdhaW5zdCB1c2luZyBvdGhl ciBjYXNlcy4NCkkgY2FuIGFkZCBzb21lIHJlY29tbWVuZGF0aW9ucyBmb3Igb3RoZXIgY2FzZXMg dG9vLg0KDQoNCg0KV2Ugd2lsbCBuZWVkIHRvIGlkZW50aWZ5IGFsbCB0aGUgdGVzdCBjYXNlcyB0 aG9zZSBhcmUgc3VpdGFibGUgZm9yDQpydW5uaW5nIHdpdGggY291cGxlZCBjb25nZXN0aW9uIGNv bnRyb2wuDQoNCk5vdCBzdXJlLCBpZiB5b3Ugb25seSBoYXZlIG9uZSBmbG93IHRoYXQgdGVzdCBj YXNlIGlzIHNpbXBseSBub3QNCnN1aXRhYmxlIGFuZCB0aGF04oCZcyBmaW5lLg0KWWVzLCB0aGF0 IGlzIG9uZSBpZGVudGlmaWNhdGlvbiBjcml0ZXJpYS4gQnV0IG1heSBiZSB3ZSBkb250IG5lZWQg cmVzdWx0cyBmb3IgYWxsIHRoZSB0ZXN0IGNhc2VzIHdobyBoYXMgbW9yZSB0aGFuIG9uZSBmbG93 LiBzZWUgbXkgcHJldmlvdXMgY29tbWVudC4NCg0KKzENCg0KDQoNCkxpa2UgNS4yIGNhbiBiZSBy dW4gd2l0aCBwcmlvcml0eSBwZXIgZmxvdy4gQnkgZG9pbmcgdGhpcyB3ZSBjYW4NCm1lbnRpb24g KGluIGVhY2ggdGVzdCBjYXNlIG9yIGluIG9uZSBwbGFjZSBpbiB0aGUgZG9jdW1lbnQpIHRoYXQN Cm9uZSBjYW4gcnVuIHRlc3RzIHdpdGggZmxvdyBwcmlvcml0eSBhbmQgcGVyaGFwcyBnaXZlIHNv bWUgbWVhbnMgdG8NCmV2YWx1YXRlIHRoZSBhdmFpbGFibGUgY2FwYWNpdHkgZGlzdHJpYnV0aW9u IHdpdGggc29tZSBlcXVhdGlvbg0KbGlrZSB0aGUgb25lIG1lbnRpb25lZCBoZXJlIGluIHRoZSBw cm9wb3NlZCB0ZXN0IGNhc2UgNi4zLg0KDQpZZXMuDQoNCkhvd2V2ZXIsIHRoZW4gdGhpcyBkb2N1 bWVudCBhbHNvIG5lZWRzIHRvIGluY2x1ZGUgZGVzY3JpcHRpb24gZm9yDQpzaGFyZWQgYm90dGxl bmVjayBkZXRlY3Rpb24uDQoNCldoeT8NCkJjb3MgSSBkb250IHRoaW5rIHRoZSBkb2N1bWVudCBu b3cgZXZlbiBtZW50aW9uICJzaGFyZWQgYm90dGxlbmVjayIgYW5kIHRvIG1lIGNvdXBsZWQgY29u Z2VzdGlvbiBjb250cm9sIGRvZXMgbm90IG1ha2Ugc2Vuc2Ugd2l0aG91dCBzaGFyZWQgYm90dGxl bmVjay4NCg0KVGhlIGRvY3VtZW50IGNvdmVycyB0aGUgYmFzaWMgc2NlbmFyaW9zIHdoZXJlIGZs b3dzIHNoYXJlIGEgY29tbW9uIGJvdHRsZW5lY2suICBXZSBjYW4gc2ltcGx5IGFkZCBhIGxpbmUg c2F5aW5nIOKAnHRoZXNlIGFkZGl0aW9uYWwgY291cGxlZC1jYyB0ZXN0LWNhc2VzIGFyZSB1c2Vk IGZvciBmbG93cyBzaGFyaW5nIGEgYm90dGxlbmVja+KAnS4NCg0KDQpJbiB0aGUgc2ltcGxlc3Qg Zm9ybSwgd2UgY2FuIHBlcmhhcHMgYXNzdW1lIHRoYXQgdGhlIGlkZW50aWZpZWQNCnRlc3QgY2Fz ZXMgaGF2ZSBzaW5nbGUgYm90dGxlbmVjayBwb2ludC4NCg0KWWVzLg0KDQoNCkkgdGhpbmsgd2Ug bmVlZCB0byBkaXNjdXNzIHdoYXQgaXMgYmVzdCBwb3NzaWJsZSB3YXkgdG8gZXh0ZW5kIHRoZQ0K dGVzdCBjYXNlcyBpZiB3ZSBhZ3JlZWQgdG8gZG8gdGhhdC4NCg0KQXMgSSBzYWlkIEkgdGhpbmsg d2UgYWdyZWVkIGFscmVhZHkuIFBsZWFzZSBmb2xsb3dpbmcgd2l0aCBTYWZpcXVsIG9uDQp0aGlz IQ0KDQoNCkJ1dCBiZWZvcmUgdGhhdCBJIHdvdWxkIGxpa2UgdG8ga25vdyBpZiB0aGUgV0cgaXMg T0sgd2l0aCBleHRlbmRpbmcNCnRoZSB0ZXN0IGNhc2VzIGZvciBjb3VwbGVkIGNvbmdlc3Rpb24g Y29udHJvbC4NCg0KQW55IGZ1cnRoZXIgZmVlZGJhY2sgb24gdGhpcyBmcm9tIHRoZSBncm91cCBp cyBvZiBjb3Vyc2Ugd2VsY29tZSENClBsZWFzZSBzcGVhayB1cCBub3chDQoNCg0KQW5kIHdpbGwg aXQgYmUgYSBjb21wdWxzb3J5IChjYW5kaWRhdGUgYWxnb3JpdGhtcyBNVVNUIHByZXNlbnQNCnJl c3VsdHMpIG9yIG9wdGlvbmFsIChjYW5kaWRhdGUgYWxnb3JpdGhtcyBNQVkgcHJlc2VudCByZXN1 bHRzKQ0KcGFydCBvZiB0aGUgdGVzdCBjYXNlLg0KDQpJIGd1ZXNzIG9ubHkgY2FuZGlkYXRlcyB0 aGF0IHVzZSBjb3VwbGVkIGNjLi4/DQoNCmhtbS4uLg0KDQpJIGFtIGEgYml0IGNvbmZ1c2VkIG5v dy4gQXJlIHdlIHRhbGtpbmcgYWJvdXQgdGVzdCBjYXNlKHMpIHRvIGV2YWx1YXRlIHRoZSBDb3Vw bGVkIENDIG9yIHRoZSB1c2Ugb2YgQ291cGxlZCBDQyBpbiB0aGUgY2FuZGlkYXRlIENDPw0KDQoN CldpdGhvdXQgbWFraW5nIGl0IGNvbXB1bHNvcnksIEkgc3VnZ2VzdGVkIHRvIGFkZCB0aGVzZSBp biB0aGUgb3RoZXIgY2FzZXMuIFdlIGNhbiBwZXJoYXBzIHNheToNCg0K4oCcV2hlbiBmbG93cyBz aGFyZSBhIGNvbW1vbiBib3R0bGVuZWNrLCBjb21iaW5pbmcgdGhlaXIgY29uZ2VzdGlvbiBjb250 cm9sbGVycyBjYW4gYmUgYmVuZWZpY2lhbC4NClRoZXNlIGFkZGl0aW9uYWwgdGVzdCBjYXNlcyBj YW4gYmUgdXNlZCB0byBldmFsdWF0ZSBhIGNvbmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc20gd2hl biB1c2luZyBhIG1ldGhvZCB0byBjb3VwbGUgZmxvd3MsIHN1Y2ggYXMgW0ktRC5pZXRmLXJtY2F0 LWNvdXBsZWQtY2NdLiINCg0KRG9lcyB0aGlzIHB1dCBpdCBiZXR0ZXI/DQoNClJlZ2FyZHMsDQpT YWZpcXVsDQoNCg0KQlINCg0KLS0NClphaGVkDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQpBTk0gWkFIRURVWlpBTUFOIFNBUktFUg0KDQoNCkVy aWNzc29uIEFCDQpTZXJ2aWNlcywgTWVkaWEgYW5kIE5ldHdvcmsgRmVhdHVyZXMNCkxhYm9yYXRv cmllZ3LDpG5kIDExDQo5NzEyOCBMdWxlw6UsIFN3ZWRlbg0KUGhvbmUgKzQ2IDEwIDcxNyAzNyA0 Mw0KRmF4ICs0NiA5MjAgOTk2IDIxDQpTTVMvTU1TICs0NiA3NiAxMTUgMzcgNDMNCnphaGVkdXp6 YW1hbi5zYXJrZXJAZXJpY3Nzb24uY29tPG1haWx0bzp6YWhlZHV6emFtYW4uc2Fya2VyQGVyaWNz c29uLmNvbT4NCnd3dy5lcmljc3Nvbi5jb20NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCg0K --_000_FA953D2237A146458F2056C79A4B2806ifiuiono_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSEkgWmFoZWQsIEhpIE1pcmphLA0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UGxlYXNl IHNlZSBpbmxpbmU8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFr OiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQovU2FmaXF1bDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMTAuIGZlYi4gMjAxNiwgYXQgMTAuMjQsIFphaGVk dXp6YW1hbiBTYXJrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp6YWhlZHV6emFtYW4uc2Fya2VyQGVy aWNzc29uLmNvbSIgY2xhc3M9IiI+emFoZWR1enphbWFuLnNhcmtlckBlcmljc3Nvbi5jb208L2E+ Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSBNaXJqYSw8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpwbGVhc2Ugc2VlIGlubGluZS4uLi48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpPbiAyMDE2LTAyLTA5IDE1OjUxLCBNaXJqYSBLw7xobGV3aW5kIHdyb3RlOjxiciBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KVGhlIHRlc3QgY2FzZXMgaW4gdGhl IGRyYWZ0IHdlcmUgZGVzaWduZWQgZm9yIGVuZC1wb2ludCBhZGFwdGF0aW9uPGJyIGNsYXNzPSIi Pg0KYWxnb3JpdGhtIHdpdGhvdXQgY291cGxlZCBjb25nZXN0aW9uIGNvbnRyb2wgaW4gbWluZCBp LmUuIG5vIG5lZWQ8YnIgY2xhc3M9IiI+DQpmb3Igc2hhcmVkIGJvdHRsZW5lY2sgZGV0ZWN0aW9u IGFuZCBmbG93IHByaW9yaXR5LiBJbiB0aGUgbGFzdCBJRVRGPGJyIGNsYXNzPSIiPg0KbWVldGlu ZyB3ZSB0YWxrZWQgYWJvdXQgdGhlIHBvc3NpYmlsaXR5IG9mIGV4dGVuZGluZyB0aGUgdGVzdCBj YXNlczxiciBjbGFzcz0iIj4NCnRvIGluY2x1ZGUgY291cGxlZCBjb25nZXN0aW9uIGNvbnRyb2wg YWxnb3JpdGhtLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkkg YmVsaWV2ZSB3ZSBkZWNpZGVkIGFscmVhZHkgYXQgdGhlIGxhc3QgbWVldGluZyB0aGF0IHdlIG5l ZWQgdG88YnIgY2xhc3M9IiI+DQphZGFwdCB0aGlzIGRyYWZ0IHRvIGluY2x1ZGUgdXNlcyBjYXNl cyBmb3IgY291cGxlZCBjb25nZXN0aW9uIChhbmQ8YnIgY2xhc3M9IiI+DQp0aGF04oCZcyB3aHkg d2UgYXNrZWQgU2FmaXF1bCB0byBwcm9wb3NlIHNvbWUpLjxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxiciBjbGFzcz0iIj4NClRoYXQgaXMgd2hhdCBJIGNhbiBhbHNvIHJlY2FsbCBidXQg ZGlkbid0IHNlZSBhbnl0aGluZyBpbiB0aGUgbWVldGluZzxiciBjbGFzcz0iIj4NCm1pbnV0ZXMg c28gd2FzIG5vdCBzdXJlIHdoYXQgd2UgYWdyZWVkIG9uLiBNYXkgYmUgbWlzc2VkIGl0IGluIHRo ZSBtZWV0aW5nIG1pbnV0ZXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KTm93IGlmIHdlIGV4dGVuZCB0aGUgdGVzdCBj YXNlcyB0aGVuIEkgZG9uJ3QgdGhpbmsgb25seSBhZGRpbmcgdGhlPGJyIGNsYXNzPSIiPg0KdHdv IHByb3Bvc2VkIHRlc3QgY2FzZXMgd2lsbCBiZSBzdWZmaWNpZW50LjxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClllcywgdGhhdCBtaWdodCBiZSB0cnVlIGJ1dCBh ZGRpbmcgdGhlc2UgdXNlIGNhc2VzIGJlbG93IHdvdWxkPGJyIGNsYXNzPSIiPg0KcHJvYmFibHkg YmUgYSBnb29kIHN0YXJ0aW5nIHBvaW50LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxi ciBjbGFzcz0iIj4NCklmIEkgdW5kZXJzdGFuZCBzaGFmaXF1bCdzIGxhc3QgbWFpbCwgaXQgaXMg ZmluZSB3aXRoIG9ubHkgaGF2aW5nIHRlc3QgcmVzdWx0cyB3aXRoIHByaW9yaXR5IGZvciA1LjQg dGVzdCBjYXNlLjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5Gb3Igc2ltcGxpY2l0eSwgSSBzdWdnZXN0 ZWQgdG8gdXNlIG9ubHkgdGVzdCBjYXNlIDUuNCwgYnV0IEkgYW0gbm90IGFnYWluc3QgdXNpbmcg b3RoZXIgY2FzZXMuPGJyIGNsYXNzPSIiPg0KSSBjYW4gYWRkIHNvbWUgcmVjb21tZW5kYXRpb25z IGZvciBvdGhlciBjYXNlcyB0b28uPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPldlIHdpbGwgbmVlZCB0byBpZGVudGlm eSBhbGwgdGhlIHRlc3QgY2FzZXMgdGhvc2UgYXJlIHN1aXRhYmxlIGZvcjxiciBjbGFzcz0iIj4N CnJ1bm5pbmcgd2l0aCBjb3VwbGVkIGNvbmdlc3Rpb24gY29udHJvbC48YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpOb3Qgc3VyZSwgaWYgeW91IG9ubHkgaGF2ZSBv bmUgZmxvdyB0aGF0IHRlc3QgY2FzZSBpcyBzaW1wbHkgbm90PGJyIGNsYXNzPSIiPg0Kc3VpdGFi bGUgYW5kIHRoYXTigJlzIGZpbmUuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KWWVzLCB0 aGF0IGlzIG9uZSBpZGVudGlmaWNhdGlvbiBjcml0ZXJpYS4gQnV0IG1heSBiZSB3ZSBkb250IG5l ZWQgcmVzdWx0cyBmb3IgYWxsIHRoZSB0ZXN0IGNhc2VzIHdobyBoYXMgbW9yZSB0aGFuIG9uZSBm bG93LiBzZWUgbXkgcHJldmlvdXMgY29tbWVudC48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+JiM0Mzsx PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkxpa2UgNS4yIGNhbiBiZSBydW4gd2l0aCBwcmlv cml0eSBwZXIgZmxvdy4gQnkgZG9pbmcgdGhpcyB3ZSBjYW48YnIgY2xhc3M9IiI+DQptZW50aW9u IChpbiBlYWNoIHRlc3QgY2FzZSBvciBpbiBvbmUgcGxhY2UgaW4gdGhlIGRvY3VtZW50KSB0aGF0 PGJyIGNsYXNzPSIiPg0Kb25lIGNhbiBydW4gdGVzdHMgd2l0aCBmbG93IHByaW9yaXR5IGFuZCBw ZXJoYXBzIGdpdmUgc29tZSBtZWFucyB0bzxiciBjbGFzcz0iIj4NCmV2YWx1YXRlIHRoZSBhdmFp bGFibGUgY2FwYWNpdHkgZGlzdHJpYnV0aW9uIHdpdGggc29tZSBlcXVhdGlvbjxiciBjbGFzcz0i Ij4NCmxpa2UgdGhlIG9uZSBtZW50aW9uZWQgaGVyZSBpbiB0aGUgcHJvcG9zZWQgdGVzdCBjYXNl IDYuMy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpZZXMuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+SG93ZXZlciwgdGhlbiB0aGlzIGRvY3VtZW50IGFsc28gbmVlZHMgdG8gaW5jbHVkZSBkZXNj cmlwdGlvbiBmb3I8YnIgY2xhc3M9IiI+DQpzaGFyZWQgYm90dGxlbmVjayBkZXRlY3Rpb24uPGJy IGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KV2h5PzxiciBjbGFzcz0i Ij4NCjwvYmxvY2txdW90ZT4NCkJjb3MgSSBkb250IHRoaW5rIHRoZSBkb2N1bWVudCBub3cgZXZl biBtZW50aW9uICZxdW90O3NoYXJlZCBib3R0bGVuZWNrJnF1b3Q7IGFuZCB0byBtZSBjb3VwbGVk IGNvbmdlc3Rpb24gY29udHJvbCBkb2VzIG5vdCBtYWtlIHNlbnNlIHdpdGhvdXQgc2hhcmVkIGJv dHRsZW5lY2suPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoZSBkb2N1bWVudCBjb3ZlcnMgdGhlIGJh c2ljIHNjZW5hcmlvcyB3aGVyZSBmbG93cyBzaGFyZSBhIGNvbW1vbiBib3R0bGVuZWNrLiAmbmJz cDtXZSBjYW4gc2ltcGx5IGFkZCBhIGxpbmUgc2F5aW5nIOKAnHRoZXNlIGFkZGl0aW9uYWwgY291 cGxlZC1jYyB0ZXN0LWNhc2VzIGFyZSB1c2VkIGZvciBmbG93cyBzaGFyaW5nIGEgYm90dGxlbmVj a+KAnS48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj5JbiB0aGUgc2ltcGxlc3QgZm9ybSwgd2UgY2FuIHBlcmhhcHMgYXNzdW1lIHRoYXQgdGhl IGlkZW50aWZpZWQ8YnIgY2xhc3M9IiI+DQp0ZXN0IGNhc2VzIGhhdmUgc2luZ2xlIGJvdHRsZW5l Y2sgcG9pbnQuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KWWVz LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCkkgdGhpbmsgd2UgbmVlZCB0byBkaXNjdXNzIHdoYXQgaXMg YmVzdCBwb3NzaWJsZSB3YXkgdG8gZXh0ZW5kIHRoZTxiciBjbGFzcz0iIj4NCnRlc3QgY2FzZXMg aWYgd2UgYWdyZWVkIHRvIGRvIHRoYXQuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJy IGNsYXNzPSIiPg0KQXMgSSBzYWlkIEkgdGhpbmsgd2UgYWdyZWVkIGFscmVhZHkuIFBsZWFzZSBm b2xsb3dpbmcgd2l0aCBTYWZpcXVsIG9uPGJyIGNsYXNzPSIiPg0KdGhpcyE8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQpCdXQgYmVmb3JlIHRoYXQgSSB3b3VsZCBsaWtlIHRvIGtub3cgaWYgdGhlIFdHIGlz IE9LIHdpdGggZXh0ZW5kaW5nPGJyIGNsYXNzPSIiPg0KdGhlIHRlc3QgY2FzZXMgZm9yIGNvdXBs ZWQgY29uZ2VzdGlvbiBjb250cm9sLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBj bGFzcz0iIj4NCkFueSBmdXJ0aGVyIGZlZWRiYWNrIG9uIHRoaXMgZnJvbSB0aGUgZ3JvdXAgaXMg b2YgY291cnNlIHdlbGNvbWUhPGJyIGNsYXNzPSIiPg0KUGxlYXNlIHNwZWFrIHVwIG5vdyE8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQpBbmQgd2lsbCBpdCBiZSBhIGNvbXB1bHNvcnkgKGNhbmRpZGF0ZSBh bGdvcml0aG1zIE1VU1QgcHJlc2VudDxiciBjbGFzcz0iIj4NCnJlc3VsdHMpIG9yIG9wdGlvbmFs IChjYW5kaWRhdGUgYWxnb3JpdGhtcyBNQVkgcHJlc2VudCByZXN1bHRzKTxiciBjbGFzcz0iIj4N CnBhcnQgb2YgdGhlIHRlc3QgY2FzZS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIg Y2xhc3M9IiI+DQpJIGd1ZXNzIG9ubHkgY2FuZGlkYXRlcyB0aGF0IHVzZSBjb3VwbGVkIGNjLi4/ PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KaG1tLi4uPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBhbSBhIGJpdCBjb25mdXNlZCBub3cuIEFyZSB3ZSB0 YWxraW5nIGFib3V0IHRlc3QgY2FzZShzKSB0byBldmFsdWF0ZSB0aGUgQ291cGxlZCBDQyBvciB0 aGUgdXNlIG9mIENvdXBsZWQgQ0MgaW4gdGhlIGNhbmRpZGF0ZSBDQz88YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+V2l0aG91dCBtYWtpbmcgaXQgY29tcHVsc29yeSwgSSBzdWdnZXN0ZWQgdG8gYWRk IHRoZXNlIGluIHRoZSBvdGhlciBjYXNlcy4gV2UgY2FuIHBlcmhhcHMgc2F5OiZuYnNwOzwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+4oCc V2hlbiBmbG93cyBzaGFyZSBhIGNvbW1vbiBib3R0bGVuZWNrLCBjb21iaW5pbmcgdGhlaXIgY29u Z2VzdGlvbiBjb250cm9sbGVycyBjYW4gYmUgYmVuZWZpY2lhbC4mbmJzcDs8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5UaGVzZSBhZGRpdGlvbmFsIHRlc3QgY2FzZXMgY2FuIGJlIHVzZWQg dG8gZXZhbHVhdGUgYSBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtIHdoZW4gdXNpbmcgYSBt ZXRob2QgdG8gY291cGxlIGZsb3dzLCBzdWNoIGFzIFtJLUQuaWV0Zi1ybWNhdC1jb3VwbGVkLWNj XS4mcXVvdDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkRvZXMgdGhpcyBwdXQgaXQgYmV0dGVyPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UmVnYXJkcyw8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+U2FmaXF1bDwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCkJSPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0gPGJyIGNsYXNz PSIiPg0KWmFoZWQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxiciBjbGFzcz0iIj4NCkFOTSBaQUhF RFVaWkFNQU4gU0FSS0VSPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KRXJpY3Nzb24gQUI8YnIgY2xhc3M9IiI+DQpTZXJ2aWNlcywgTWVkaWEgYW5kIE5ldHdvcmsg RmVhdHVyZXM8YnIgY2xhc3M9IiI+DQpMYWJvcmF0b3JpZWdyw6RuZCAxMTxiciBjbGFzcz0iIj4N Cjk3MTI4IEx1bGXDpSwgU3dlZGVuPGJyIGNsYXNzPSIiPg0KUGhvbmUgJiM0Mzs0NiAxMCA3MTcg MzcgNDM8YnIgY2xhc3M9IiI+DQpGYXggJiM0Mzs0NiA5MjAgOTk2IDIxPGJyIGNsYXNzPSIiPg0K U01TL01NUyAmIzQzOzQ2IDc2IDExNSAzNyA0MzxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0 bzp6YWhlZHV6emFtYW4uc2Fya2VyQGVyaWNzc29uLmNvbSIgY2xhc3M9IiI+emFoZWR1enphbWFu LnNhcmtlckBlcmljc3Nvbi5jb208L2E+PGJyIGNsYXNzPSIiPg0Kd3d3LmVyaWNzc29uLmNvbTxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_FA953D2237A146458F2056C79A4B2806ifiuiono_-- From nobody Tue Feb 16 04:05:29 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C7B1B354F for ; Tue, 16 Feb 2016 04:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRfs5vhhU_MC for ; Tue, 16 Feb 2016 04:05:24 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A5691B3538 for ; Tue, 16 Feb 2016 04:05:13 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-b2-56c310778409 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3E.38.28465.77013C65; Tue, 16 Feb 2016 13:05:11 +0100 (CET) Received: from [150.132.141.91] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.248.2; Tue, 16 Feb 2016 13:05:08 +0100 From: Zaheduzzaman Sarker To: Stefan Holmer , rmcat WG , "Michael Ramalho (mramalho)" , "Xiaoqing Zhu (xiaoqzhu)" , Varun Singh References: Organization: Ericsson AB Message-ID: <56C31073.8040508@ericsson.com> Date: Tue, 16 Feb 2016 13:05:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM2K7k265wOEwg79flCyu7j/HYvH+M7/F 6psf2CxmnOCweN2yjMmB1WPK742sHmeXTWXyWLCp1GPJkp9MASxRXDYpqTmZZalF+nYJXBnX pt9hLphQUnHvzj+mBsb2sC5GTg4JAROJWUcmM0LYYhIX7q1n62Lk4hASOMwo0fPyISuEs4ZR Ysmla+xdjBwcbAI2Eo8X+4E0CAM1f9uwgQ3EFhE4xShxej83iC0kECBx+s13FhCbX0BSYkPD bmYQm1dAW2LShT9gcRYBVYn9B/+zg9iiAhEShzu72CFqBCVOznwCVsMpECix5+ZDsOOYBSwk Zs4/D2XLS2x/O4cZ5BwhAV2JrpdxExgFZyHpnoWkYxaSjgWMzKsYRYtTi4tz042M9VKLMpOL i/Pz9PJSSzYxAgP74JbfujsYV792PMQowMGoxMNbEHEoTIg1say4MvcQowQHs5II779XQCHe lMTKqtSi/Pii0pzU4kOM0hwsSuK8a5zXhwkJpCeWpGanphakFsFkmTg4pRoYV1yYvMQnQZ7z 1f3OuRVV2btXhEtdEA5i/dsl6Cdlox3yeLb0tqIUfbY/S9OLzNXaSgS2Jm/8m7V7yjTDjR0X ucQWHNBQurI5f1Yrp9Bt1WkT3YvOFhnWiTkK5fI9FRdlCWNd9fi4wYbXjsGeKuuO89ec5mq4 zrru2evcn0Wn/218vfH5z9hgJZbijERDLeai4kQAo1Bw/2gCAAA= Archived-At: Subject: Re: [rmcat] Review on draft-ietf-rmcat-eval-test-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 12:05:28 -0000 Hi Stefan, Thanks for your detailed review. We really appreciate this. You have brought up couple of points that we should discuss a bit more. please see inline below. BR Zahed (on behalf of all the authors) On 2016-02-07 13:05, Stefan Holmer wrote: > Hi, > > Sorry for being late with this review, here are my comments: > > *General comments:* > > * We consider audio and video content, but should we also consider > slide shows and/or screen content? In my experience those often > sources are widely different in their rate characteristics, and may > be very bursty. I think it could be interesting to see how different > candidates handle the case where they are source limited most of the > time (static image, encoder produces < 50 kbps), and every now and > then there's a slide change. The test cases here supposed to cover interactive real-time media hence we can discuss if screen sharing and slide shows is covered in the RMCAT requirements. The eval criteria draft is not so clear about this. This need to be clarified there first. We will have to look at the traffic characteristics of the such an use case. It would be nice if you can provide traces of such scenario. will it be very much different case than the media pause and resume testcase? what does make it different? If we think is as competition among multiple flows then we have test case 5.2 and 5.4 to cover that. However if we think is as perceived video quality then it fits more when the performance of the whole RTC system is under investigation. That is not in the scope of the test cases. > * Each video stream is often accompanied by a constant bitrate audio > stream in these test cases, but it's not clear to me why? Due to the difference in required bandwidth for audio and video, video streams were considered more challenging than audio streams. It was also assumed that in case of congestion one would like to adapt the video rate first before adapting audio rate. Hence the focus was on video streams. Hence it was decided that we can have test cases where audio can have constant bitrate. I think we > need to clarify how the audio stream is going to be evaluated. Are > we going to look at end-to-end latency and jitter? yes that is the idea, I think both of the metrics you mentioned is already captured in the test cases. > * It's suggested that video resolution should be specified in the test > cases, but we don't seem to suggest that video quality should be > evaluated (PSNR/SSIM). How are we then expecting that video > resolution will matter in these tests? One can say the whole media source behavior description requires video quality evaluation. We had discussed this at length in the design team and agreed that we need some sort of guidance for the behavior to produce some comparable results. This is also part of why the WG has been asking to evaluate at least two candidates using the same system so that the comparison is more fair. But the question is, how the change of resolution really changes packet patterns on the wire? This also has been discussed when we proposed different way of modeling synthetic video sources. At IETF 88 I showed that the video framesize of 720p 25fps 800kbps encoded stream is almost a match of the same with 480p 25fps 800kbps. Hence for CC evaluation purpose the change of resolution should not really matter much. Do we allow the encoder to > internally scale down the resolution depending on the available > bandwidth? yes, isnt is natural to do that? In that case, will be really be evaluating CC candidates > or are we starting to lean towards comparing full RTC systems? > no, comparing full RTC system was never on the menu at all. In fact the test cases are designed so that we can test candidate algorithms to see if they are safe enough to deploy in the Internet or not. This also serves the purpose of comparing the test results. If there is any confusion on this CC candidate versus full RTC system comparison, please post some suggestions to clarify that. To be honest, when you asked about the screen sharing case it felt like comparing full RTC system :-). > > *Raw comments:* > > 4.1. Evaluation metircs . . . . . . . . . . . . . . . . . . . 7 > Comments: > > * metrics > > > *Section 3* > * > * > It should be noted that > depending on the test cases it is possible to have different path > characteristics in of the either directions. > > Comments: > > * "in either of the directions" > * There is a bullet which looks misplaced after this. > > > In a testbed environment laboratory there may exist a significant > amount of traffic on portions of the network path between the > endpoints that is not desired for the purposes of these RMCAT > tests. > > Comments: > > * I think we should define what a testbed environment laboratory is > somewhere. Is it a LAN with some network emulator, or is it a fully > simulated network? We can elaborate that. The laboratory is a LAN with real machines and routers. > > > + Bottleneck queue size: defines size of queue in terms of > queuing time when the queue is full (in milliseconds). > > Comments: > > * "the size of the queue" > > > * Application-related: defines the traffic source behaviour for > implementing the test case > > Comments: > > * In this section we mention Video/Voice as media types. Should we > also consider screen content/slide shows? See general comments. > * Under adaptability we mention resolution as being an option of > adaptation. It's not clear to me how we should evaluate something > like that without comparing the visual quality in some way. See > general comments. > > > *Section 4.3* > * > * > Also it is possible > that the media traffic generator used in a particular > simulator or testbed if not capable of generating higher > bitrate. Hence we have selected a suitable bitrate range > > Comments: > > * Spelling errors: > o "testbed is not" > o "bit rate" > > *Section 5.1* > * > * > maximum Media Bit Rate is Greater than Link Capacity. In this > case, the application will attempt to ramp up to its maximum bit > rate, since the link capacity is limited to a value lower, the > congestion control scheme is expected to stabilize the sending bit > rate close to the available bottleneck capacity. This situation > can occur when the endpoints are connected via thin long networks > even though the advertised capacity of the access network may be > higher. > > Comments: > > * I don't understand the last sentence here. Isn't it simpler to refer > to e.g. cable/adsl links where the uplink may be in the order of 256 > - 1024 kbps. you can think of a client connected to a wifi network that has a wire connection (as you mentioned) to the Internet. we can clarify this. > > > It should be noted that the exact variation in available capacity due > to any of the above depends on the under-lying technologies. Hence, > we describe a set of known factors, which may be extended to devise a > more specific test case targeting certain behaviour in a certain > network environment. > > Expected behavior: the candidate algorithm is expected to detect the > path capacity constraint, converges to bottleneck link's capacity and > > Comments: > > * "underlying" > * "targeting*a* certain" > * "converges to *the* bottleneck link's capacity" > > > o Path characteristics: as described in Section 4.2 > > Comments: > > * I don't think there is a point in mentioning that we are using the > defaults. > > * This test uses the following one way propagation delays of 50 > ms and 100 ms. > > Comments: > > * "This test uses one way propagation delays of 50 ms and 100 ms" > * Is this referring to two instances of the test, or to forward and > backward delays? two different runs of the test. need to clarify that. good catch. > > > *Section 5.2* > * > * > Expected behavior: the candidate algorithms is expected to detect the > variation in available capacity and adapt the media stream(s) > accordingly. The flows stabilize around their maximum bitrate as the > as the maximum link capacity is large enough to accommodate the > flows. When the available capacity drops, the flow(s) adapts by > decreasing its sending bit rate, and when congestion disappears, the > flow(s) are again expected to ramp up. > > Comments: > > * spelling error "maximum bitrate as the maximum link capacity" > * Rewrite last sentence as plural. > > > *Section 5.3* > * > * > It is expected that the candidate algorithms is able to cope with the > lack of feedback information and adapt to minimize the performance > degradation of media flows in the forward channel. > > It should be noted that for this test case: logs are compared with > the reference case, i.e, when the backward channel has no impairments > > Comments: > > * "algorithms *are* able" > * End last sentence with ". > * I think the test duration should be longer since this is a fairly > complicated scenario. What about 300 s? if running 300s shows different behavior than running for 100s then we should change it. Do you have any data to share? > > > *Section 5.4* > > In this test case, more than one RMCAT media flow shares the > bottleneck link and each of them uses the same congestion control > algorithm. This is a typical scenario where a real-time interactive > application sends more than one media flows to the same destination > and these flows are multiplexed over the same port. > > Comments: > > * > * I don't think multiplexing is a good example here. There is no > reason why they would actually fight for bandwidth between each > other if they are multiplexed over the same port, as they may as > well run a single CC and allocate the available bandwidth between > them. Better to take an example of two or more different endpoints > in the same office calling two or more endpoints in another office, > or similar. Fine but I believe we are still talking about RTP as protocol and there almost everything is done per SSRC basis hence the congestion control should be able to operate per SSRC basis. Of course one can aggregate the congestion control but then that is special case, like using coupled CC. > * misspelled: "one media flows" should be "one media flow" > > > Testbed topology: Three media sources S1, S2, S3 are connected to > respective R1, R2, R3. > > Comments: > > * Should probably be "are connected to R1, R2 and R3 respectively". > > > > +---------+------------+------------+----------+ > | Flow IF | Media type | Start time | End time | > +---------+------------+------------+----------+ > > Comments: > > * Flow ID > > > *Section 5.1* > > * Path capacity ratio: 1.0 > Comments: > > * Not necessary to mention as I think it is the default? Also > mentioned in other places. > > + Congestion control: Default TCP congestion control. > Comments: > > * Should we suggest what the default TCP CC could be? New reno, Cubic? yes we can. what do you suggest? > > *Section 5.8* > * > * > In this test case, more than one real-time interactive media flows > share the link bandwidth and all flows reach to a steady state by > utilizing the link capacity in an optimum way. At these stage one of > the media flow is paused for a moment. This event will result in > more available bandwidth for the rest of the flows and as they are on > a shared link. When the paused media flow will resume it would no > longer have the same bandwidth share on the link. It has to make > it's way through the other existing flows in the link to achieve a > fair share of the link capacity. This test case is important > specially for real-time interactive media which consists of more than > one media flows and can pause/resume media flow at any point of time > during the session. This test case directly addresses the > requirement number 5 in [I-D.ietf-rmcat-cc-requirements]. One can > think it as a variation of test case defined in Section 5.4. > However, it is different as the candidate algorithms can use > different strategies to increase its efficiency, for example the > fairness, convergence time, reduce oscillation etc, by capitalizing > the fact that they have previous information of the link. > > Comments: > > * Several spelling errors: > o "At *this* stage one of the media *flows* is paused for a moment." > o > o "This event will result in more available bandwidth for the rest > of the flows *(and)* as they are on a shared link. When the > paused media flow *resumes* it *will* no longer have the same > bandwidth share on the link." > o > o " ... one media flows and can pause/resume media *flows* at any > point of time during the session." > o > o "However, it is different as the candidate algorithms can use > different strategies to increase *their* efficiency, for example > *(the)* fairness" > > > *Section 6* > It has been noticed that there are other interesting test cases > besides the basis test cases listed above. > > Comments: > > * "base" > > *Section 6.2* > Testbed attributes: > > o Test duration: 120s > > o Path characteristics: > > * Reference bottleneck capacity between A and B = 2Mbps. > ... > > * One-Way propagation delay: > > 1. Between S1 and R1: 100ms > > 2. Between S2 and R2: 40ms > > 3. Between S3 and R3: 40ms > > Comments: > > * Duration should probably be at least 300s given the complexity of > this setup. > * Does the reference bottleneck capacity apply to all links or only A > and B? If only A and B, what's the reference for the other links? to all links. > * In my opinion this test case is complex enough without different > one-way propagation delays on the links. Again thanks for the typos fix and nits. From nobody Tue Feb 16 04:14:40 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CFA1B35C6 for ; Tue, 16 Feb 2016 04:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFQWx2yVfaLa for ; Tue, 16 Feb 2016 04:14:37 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721871B35CA for ; Tue, 16 Feb 2016 04:14:36 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-49-56c312aa7eb6 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 62.BE.15637.AA213C65; Tue, 16 Feb 2016 13:14:34 +0100 (CET) Received: from [150.132.141.91] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.248.2; Tue, 16 Feb 2016 13:14:33 +0100 To: Safiqul Islam References: <170F0EA5-EAB0-4B01-A8DF-56A0B2923A9A@ifi.uio.no> <56AA17AD.8060806@ericsson.com> <56BB01D5.5040902@ericsson.com> From: Zaheduzzaman Sarker Organization: Ericsson AB Message-ID: <56C312A9.1000609@ericsson.com> Date: Tue, 16 Feb 2016 13:14:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020907090705080302000705" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbHdVXeV0OEwg9PvxC1O/LjMbLFh9RQW i/ef+S1W3/zAZnGr5Qyjxd4mf4vXLcuYHNg9pvzeyOqxc9Zddo8lS34yeaxe/ZDZ4++FVjaP Yx++sgWwRXHZpKTmZJalFunbJXBl3LvDXnBoImPF8mciDYwbYroYOTkkBEwkjve/ZYOwxSQu 3FsPZHNxCAkcZpQ43TGDFcJZwyjR+uknC0iVsECyxLcdN8BsEQF1iTUXZrJAFL1llHi5dyqY wywwl0li3r/n7F2MHBxsAjYSjxf7gTTwC0hKbGjYzQxi8wpoS3zavYMRxGYRUJW4vmIOK4gt KhAhcbizix2iRlDi5MwnYMs4Bewk/t1vBetlFgiTOD3tBAvIeCEBXYmul3ETGAVnIemYhaQK wraQmDn/PCOErS2xbOFrZghbQ6J1zlx2ZPEFjGyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2 MQKj6eCW36o7GC+/cTzEKMDBqMTDWxBxKEyINbGsuDL3EKMEB7OSCO+/V0Ah3pTEyqrUovz4 otKc1OJDjNIcLErivGuc14cJCaQnlqRmp6YWpBbBZJk4OKUaGPnOyPUInJj/vFw0buLbA41H 8nNy99zuLf31ZnLuaes1RyxetC5rfXW5bFmIb8THCO0pV2PmFqZp3N+oOGH+7rj52qe/Fdy1 N/YzOKjxli3VJPvz41k+4pNeVB3a+6DxyhnWbbdvGzPu50gtDn0QLODz4KQUB39nmsn+vt/z +9XSTder97yJvK/EUpyRaKjFXFScCADbez8EogIAAA== Archived-At: Cc: "rmcat@ietf.org" , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , "mramalho@cisco.com" , =?UTF-8?Q?Anna_Brunstr=c3=b6m?= , Xiaoqing Zhu , Varun Singh Subject: Re: [rmcat] test cases for coupled cc [was: Re: Review of draft-ietf-rmcat-eval-test-02] X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 12:14:39 -0000 --------------020907090705080302000705 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Please see inline. BR Zahed On 02/10/2016 03:36 PM, Safiqul Islam wrote: > HI Zahed, Hi Mirja, > > Please see inline > > /Safiqul > > >> On 10. feb. 2016, at 10.24, Zaheduzzaman Sarker=20 >> > > wrote: >> >> Hi Mirja, >> >> please see inline.... >> >> On 2016-02-09 15:51, Mirja K=C3=BChlewind wrote: >>>> >>>> The test cases in the draft were designed for end-point adaptation >>>> algorithm without coupled congestion control in mind i.e. no need >>>> for shared bottleneck detection and flow priority. In the last IETF >>>> meeting we talked about the possibility of extending the test cases >>>> to include coupled congestion control algorithm. >>> >>> I believe we decided already at the last meeting that we need to >>> adapt this draft to include uses cases for coupled congestion (and >>> that=E2=80=99s why we asked Safiqul to propose some). >> >> That is what I can also recall but didn't see anything in the meeting >> minutes so was not sure what we agreed on. May be missed it in the=20 >> meeting minutes. >> >>> >>>> >>>> Now if we extend the test cases then I don't think only adding the >>>> two proposed test cases will be sufficient. >>> >>> Yes, that might be true but adding these use cases below would >>> probably be a good starting point. >> >> If I understand shafiqul's last mail, it is fine with only having=20 >> test results with priority for 5.4 test case. > > For simplicity, I suggested to use only test case 5.4, but I am not=20 > against using other cases. > I can add some recommendations for other cases too. A section in 5.4 describing the required changed to run with couple CC=20 should be enough. > >> >>> >>>> We will need to identify all the test cases those are suitable for >>>> running with coupled congestion control. >>> >>> Not sure, if you only have one flow that test case is simply not >>> suitable and that=E2=80=99s fine. >> Yes, that is one identification criteria. But may be we dont need=20 >> results for all the test cases who has more than one flow. see my=20 >> previous comment. > > +1 > > >>> >>>> Like 5.2 can be run with priority per flow. By doing this we can >>>> mention (in each test case or in one place in the document) that >>>> one can run tests with flow priority and perhaps give some means to >>>> evaluate the available capacity distribution with some equation >>>> like the one mentioned here in the proposed test case 6.3. >>> >>> Yes. >>> >>>> However, then this document also needs to include description for >>>> shared bottleneck detection. >>> >>> Why? >> Bcos I dont think the document now even mention "shared bottleneck"=20 >> and to me coupled congestion control does not make sense without=20 >> shared bottleneck. > > The document covers the basic scenarios where flows share a common=20 > bottleneck. We can simply add a line saying =E2=80=9Cthese additional = > coupled-cc test-cases are used for flows sharing a bottleneck=E2=80=9D.= yes, something like that. > >>> >>>> In the simplest form, we can perhaps assume that the identified >>>> test cases have single bottleneck point. >>> >>> Yes. >>> >>>> >>>> I think we need to discuss what is best possible way to extend the >>>> test cases if we agreed to do that. >>> >>> As I said I think we agreed already. Please following with Safiqul on= >>> this! >>> >>>> >>>> But before that I would like to know if the WG is OK with extending >>>> the test cases for coupled congestion control. >>> >>> Any further feedback on this from the group is of course welcome! >>> Please speak up now! >>> >>>> >>>> And will it be a compulsory (candidate algorithms MUST present >>>> results) or optional (candidate algorithms MAY present results) >>>> part of the test case. >>> >>> I guess only candidates that use coupled cc..? >> >> hmm... >> >> I am a bit confused now. Are we talking about test case(s) to=20 >> evaluate the Coupled CC or the use of Coupled CC in the candidate CC? > > > Without making it compulsory, I suggested to add these in the other=20 > cases. We can perhaps say: > > =E2=80=9CWhen flows share a common bottleneck, combining their congesti= on=20 > controllers can be beneficial. > These additional test cases can be used to evaluate a congestion=20 > control mechanism when using a method to couple flows, such as=20 > [I-D.ietf-rmcat-coupled-cc]." > > Does this put it better? I dont think this document to referent to any candidate solution. I think the test cases should be defined so that one can evaluate other=20 alternatives if there is any. Now, if there is more than one coupled CC=20 solution and the candidate algorithms perform differently with different = solution, how that will help us to evaluate coupled Congestion control=20 algorithms. How does the WG plans to solve such situation? --------------020907090705080302000705 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi,

    Please see inline.

    BR

    Zahed

    On 02/10/2016 03:36 PM, Safiqul Islam wrote:
    HI Zahed, Hi Mirja,

    Please see inline

    /Safiqul


    On 10. feb. 2016, at 10.24, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:

    Hi Mirja,

    please see inline....

    On 2016-02-09 15:51, Mirja K=C3=BChlewind wrote:

    The test cases in the draft were designed for end-point adaptation
    algorithm without coupled congestion control in mind i.e. no need
    for shared bottleneck detection and flow priority. In the last IETF
    meeting we talked about the possibility of extending the test cases
    to include coupled congestion control algorithm.

    I believe we decided already at the last meeting that we need to
    adapt this draft to include uses cases for coupled congestion (and
    that=E2=80=99s why we asked Safiqul to propose some).=

    That is what I can also recall but didn't see anything in the meeting
    minutes so was not sure what we agreed on. May be missed it in the meeting minutes.



    Now if we extend the test cases then I don't think only adding the
    two proposed test cases will be sufficient.

    Yes, that might be true but adding these use cases below would
    probably be a good starting point.

    If I understand shafiqul's last mail, it is fine with only having test results with priority for 5.4 test case.

    For simplicity, I suggested to use only test case 5.4, but I am not against using other cases.
    I can add some recommendations for other cases too.
    A section in 5.4 describing the required changed to run with couple CC should be enough.



    We will need to identify all the test cases those are suitable for<= br class=3D""> running with coupled congestion control.

    Not sure, if you only have one flow that test case is simply not
    suitable and that=E2=80=99s fine.
    Yes, that is one identification criteria. But may be we dont need results for all the test cases who has more than one flow. see my previous comment.

    +1



    Like 5.2 can be = run with priority per flow. By doing this we can
    mention (in each test case or in one place in the document) that
    one can run tests with flow priority and perhaps give some means to
    evaluate the available capacity distribution with some equation
    like the one mentioned here in the proposed test case 6.3.

    Yes.

    However, then th= is document also needs to include description for
    shared bottleneck detection.

    Why?
    Bcos I dont think the document now even mention "shared bottleneck" and to me coupled congestion control does not make sense without shared bottleneck.<= br class=3D"">

    The document covers the basic scenarios where flows share a common bottleneck. =C2=A0We can simply add a line saying =E2=80=9Cthese additional coupled-cc test-cases are = used for flows sharing a bottleneck=E2=80=9D.
    yes, something like that.


    In the simplest form, we can perhaps assume that the identified
    test cases have single bottleneck point.

    Yes.


    I think we need to discuss what is best possible way to extend the
    test cases if we agreed to do that.

    As I said I think we agreed already. Please following with Safiqul on
    this!


    But before that I would like to know if the WG is OK with extending
    the test cases for coupled congestion control.

    Any further feedback on this from the group is of course welcome!
    Please speak up now!


    And will it be a compulsory (candidate algorithms MUST present
    results) or optional (candidate algorithms MAY present results)
    part of the test case.

    I guess only candidates that use coupled cc..?

    hmm...

    I am a bit confused now. Are we talking about test case(s) to evaluate the Coupled CC or the use of Coupled CC in the candidate CC?


    Without making it compulsory, I suggested= to add these in the other cases. We can perhaps say:=C2= =A0

    =E2=80=9CWhen flows share a common bottle= neck, combining their congestion controllers can be beneficial.=C2=A0
    These additional test cases can be used to evaluate a congestion control mechanism when using a method to couple flows, such as [I-D.ietf-rmcat-coupled-cc]."

    Does this put it better?
    I dont think this document to referent to any candidate solution.
    =
    I think the test cases should be defined so that one can evaluate other alternatives if there is any. Now, if there is more than one coupled CC solution and the candidate algorithms perform differently with different solution, how that will help us to evaluate coupled Congestion control algorithms. How does the WG plans to solve such situation?


    --------------020907090705080302000705-- From nobody Tue Feb 16 08:42:27 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2C51B2FB9 for ; Tue, 16 Feb 2016 08:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GVVNiFtGmSF for ; Tue, 16 Feb 2016 08:42:12 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4BE21B2F98 for ; Tue, 16 Feb 2016 08:42:12 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aVihW-0006Ic-GY for rmcat@ietf.org; Tue, 16 Feb 2016 17:42:10 +0100 Received: from rrcs-173-197-88-133.west.biz.rr.com ([173.197.88.133] helo=[10.10.5.117]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1aVihV-0004AW-ON for rmcat@ietf.org; Tue, 16 Feb 2016 17:42:10 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Michael Welzl In-Reply-To: <56C312A9.1000609@ericsson.com> Date: Tue, 16 Feb 2016 06:42:05 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <170F0EA5-EAB0-4B01-A8DF-56A0B2923A9A@ifi.uio.no> <56AA17AD.8060806@ericsson.com> <56BB01D5.5040902@ericsson.com> <56C312A9.1000609@ericsson.com> To: "rmcat@ietf.org" X-Mailer: Apple Mail (2.3112) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 14 msgs/h 8 sum rcpts/h 16 sum msgs/h 9 total rcpts 38283 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 02421250BD5774C175FB9C9F02E5CE80AA33C4CB X-UiO-SPAM-Test: remote_host: 173.197.88.133 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 8 total 76 max/h 10 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [rmcat] test cases for coupled cc [was: Re: Review of draft-ietf-rmcat-eval-test-02] X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 16:42:18 -0000 Hi, My 2 cents about one bit here, cutting away the rest: > On 16. feb. 2016, at 02.14, Zaheduzzaman Sarker = wrote: > (..) > On 02/10/2016 03:36 PM, Safiqul Islam wrote: (..) >> Without making it compulsory, I suggested to add these in the other = cases. We can perhaps say:=20 >>=20 >> =E2=80=9CWhen flows share a common bottleneck, combining their = congestion controllers can be beneficial.=20 >> These additional test cases can be used to evaluate a congestion = control mechanism when using a method to couple flows, such as = [I-D.ietf-rmcat-coupled-cc]." >>=20 >> Does this put it better? > I dont think this document to referent to any candidate solution. >=20 > I think the test cases should be defined so that one can evaluate = other alternatives if there is any. Now, if there is more than one = coupled CC solution and the candidate algorithms perform differently = with different solution, how that will help us to evaluate coupled = Congestion control algorithms. How does the WG plans to solve such = situation? The sentence Safiqul proposed mentions the coupled-cc draft as an = example - not more, not less. Remove it if you want, and nothing has = changed: this isn=E2=80=99t about evaluating coupled CC. algorithms, = it=E2=80=99s about evaluating how congestion control algorithms work = when they are combined with a method to couple them. It=E2=80=99s not = mandatory either - but if you want to test how e.g. SCReAM operates when = coupled, these test cases probable make sense. That=E2=80=99s all this = says. Cheers, Michael From nobody Tue Feb 16 09:09:02 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18101B30C0 for ; Tue, 16 Feb 2016 09:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybIrdn7g8ieu for ; Tue, 16 Feb 2016 09:08:56 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB531B30BC for ; Tue, 16 Feb 2016 09:08:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B6A4CD9315; Tue, 16 Feb 2016 18:08:53 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XXZT-dRb+op0; Tue, 16 Feb 2016 18:08:53 +0100 (MET) Received: from [172.16.42.38] (host176-90-dynamic.54-82-r.retail.telecomitalia.it [82.54.90.176]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 5876CD9305; Tue, 16 Feb 2016 18:08:53 +0100 (MET) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Feb 2016 18:08:50 +0100 Message-Id: <6902D83B-55B3-4D22-8B37-A71A89720DDF@tik.ee.ethz.ch> To: "rmcat WG (rmcat@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Cc: =?utf-8?Q?Anna_Brunstr=C3=B6m?= Subject: [rmcat] Wireless test cases X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 17:08:57 -0000 Hi all, quick questions on the wireless test cases:=20 First, who did already run all or some of the test cases, and which?=20 And, second, should all the wireless test cases (both mobile and wifi) = be part of the set of 'base' test cases for which we as a group would = like to see results before moving a candidate document forward or do we = need to even pick a subset of those? Mirja =20= From nobody Tue Feb 16 13:59:16 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3FA1A8A98 for ; Tue, 16 Feb 2016 13:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VphOuqDfrsk5 for ; Tue, 16 Feb 2016 13:59:11 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8669D1A8A92 for ; Tue, 16 Feb 2016 13:59:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12436; q=dns/txt; s=iport; t=1455659951; x=1456869551; h=from:to:subject:date:message-id:mime-version; bh=QpOB8VraTQGmiaqVvTKjAdAmFbIPGJP12OnNV2HXr4U=; b=aHz5jgGkfmlLtgRphztf973WT/4Y4kOa/nyr0v0V2EuKJGDQLLx7vI9R EtB+oqCvgHyAaQHQy2nximrOlDZTXTrRC0TdomBLS3UJGGN9N1c2gAMup RWU7accYWx7F2K/HtSkGvrzcrlCEA1osXDjF1vM7Mcxt7kR97Jdoih0vY I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgA9m8NW/51dJa1egm5MUnO6LgENg?= =?us-ascii?q?WeHTjgUAQEBAQEBAX8LhEgtXgGBACYBBBuIEpxSnnQBAQEBBgEBAQEBG4YRhDW?= =?us-ascii?q?EDIRgBZZ/AYEWjDuOeo4/AR4BAUKBfYFmiA09fAEBAQ?= X-IronPort-AV: E=Sophos; i="5.22,456,1449532800"; d="scan'208,217"; a="77407701" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2016 21:59:10 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u1GLxAZ4018115 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 16 Feb 2016 21:59:10 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 16 Feb 2016 15:59:08 -0600 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1104.009; Tue, 16 Feb 2016 15:59:08 -0600 From: "Michael Ramalho (mramalho)" To: "rmcat@ietf.org" Thread-Topic: Review of rmcat-cc-codec-interactions Thread-Index: AdFpBT+VvJLrH95+Q4CjBDwjlIgDCA== Date: Tue, 16 Feb 2016 21:59:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.213.84] Content-Type: multipart/alternative; boundary="_000_cbfb25002da84c24b5eb70b298731926XCHALN017ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [rmcat] Review of rmcat-cc-codec-interactions X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 21:59:15 -0000 --_000_cbfb25002da84c24b5eb70b298731926XCHALN017ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I have reviewed draft-zanaty-rmcat-cc-codec-interactions. My only comments = concern Section 5.2.2 (Startup Ramp). In what follows I have added two sentences and modified a sentence in this = section. ****EXISTING TEXT**** 5.2.2. Startup Ramp Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an import= ant moment in a conversation. Rapid rate adaptation during startup is ther= efore important. The codec should minimize its startup media rate as much = as possible without adversely impacting the user experience, and support a = strategy for rapid rate ramp. The CC should allow the highest startup medi= a rate as possible without adversely impacting network conditions, and also= support rapid rate ramp until stabilizing on the available bandwidth. Sta= rtup can be viewed as a negotiation between the codec and the CC. The code= c requests a startup rate and ramp, and the CC responds with the allowable = parameters which may be lower/slower. The RMCAT requirements also include = the possibility of bandwidth history to further accelerate or even eliminat= e startup ramp time. While this is highly desirable from an application vi= ewpoint, it may be less acceptable to network operators, since it is in ess= ence a gamble on current congestion state matching historical state, with t= he potential for significant congestion contribution if the gamble was wron= g. Note that startup can often commence before user interaction or convers= ation to reduce the chance of clipped media. ****EXISTING TEXT**** ****PROPOSED TEXT**** 5.2.2. Startup Ramp Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an import= ant moment in a conversation. Rapid rate adaptation during startup is ther= efore important. The codec should minimize its startup media rate as much = as possible without adversely impacting the user experience, and support a = strategy for rapid rate ramp. The CC should allow the highest startup medi= a rate as possible without adversely impacting network conditions, and also= support rapid rate ramp until stabilizing on the available bandwidth. Sta= rtup can be viewed as a negotiation between the codec and the CC. The spec= ification of the ramp may take a number of forms depending on the interface= to the codec; for example, a percentage bit rate increase per RTT (or othe= r time interval), or an increased transmit window (in number of packets and= /or octets allowed outstanding) are all potential forms. The codec request= s a startup rate and ramp, and the CC responds with the allowable parameter= s which may be lower/slower. The RMCAT requirements also include the possi= bility of bandwidth history to further accelerate or even eliminate startup= ramp time. While this acceleration or elimination in ramp time is benefici= al to the session user experience when bandwidth is sufficient, it can be d= etrimental if significant congestion results (the user experience of this s= ession and all other sessions traversing the point of congestion may unnece= ssarily degrade). Therefore, it is recommended that use of potentially sta= le congestion state for acceleration or elimination in ramp up be limited t= o topologies or deployments believed to have sufficient bandwidth margin or= those in which the potential transient congestion risk is acceptable. Not= e that startup can often commence before user interaction or conversation t= o reduce the chance of clipped media. ****PROPOSED TEXT**** The modification deletes the reference to "network operators", as I think t= he point may be made that many network administrators (be they service prov= iders or other "network operators") or network designers/sizers would also = have the same concern. I have reviewed this change with the present authors and they generally app= rove of it. Other edits are welcome. Regards, Michael A. Ramalho, Ph.D. --_000_cbfb25002da84c24b5eb70b298731926XCHALN017ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    All,

     =

    I have reviewed draft-za= naty-rmcat-cc-codec-interactions. My only comments concern Section 5.2.2 (S= tartup Ramp).

     =

    In what follows I have a= dded two sentences and modified a sentence in this section.

     =

    ****EXISTING TEXT****

    5.2.2.  Startup Ram= p

     =

    Startup Ramp (from Codec= to CC, and from CC to Codec): Startup is an important moment in a conversa= tion.  Rapid rate adaptation during startup is therefore important.&nb= sp; The codec should minimize its startup media rate as much as possible without adversely impacting the user experience, = and support a strategy for rapid rate ramp.  The CC should allow the h= ighest startup media rate as possible without adversely impacting network c= onditions, and also support rapid rate ramp until stabilizing on the available bandwidth.  Startup can be vi= ewed as a negotiation between the codec and the CC.  The codec request= s a startup rate and ramp, and the CC responds with the allowable parameter= s which may be lower/slower.  The RMCAT requirements also include the possibility of bandwidth history to further accelerate or= even eliminate startup ramp time.  While this is highly desirable fro= m an application viewpoint, it may be less acceptable to network operators,= since it is in essence a gamble on current congestion state matching historical state, with the potential for signifi= cant congestion contribution if the gamble was wrong.  Note that start= up can often commence before user interaction or conversation to reduce the= chance of clipped media.

    ****EXISTING TEXT****

     =

    ****PROPOSED TEXT****

    5.2.2.  Startup Ram= p

     =

    Startup Ramp (from Codec= to CC, and from CC to Codec): Startup is an important moment in a conversa= tion.  Rapid rate adaptation during startup is therefore important.&nb= sp; The codec should minimize its startup media rate as much as possible without adversely impacting the user experience, = and support a strategy for rapid rate ramp.  The CC should allow the h= ighest startup media rate as possible without adversely impacting network c= onditions, and also support rapid rate ramp until stabilizing on the available bandwidth.  Startup can be vi= ewed as a negotiation between the codec and the CC.  The specification= of the ramp may take a number of forms depending on the interface to the c= odec; for example, a percentage bit rate increase per RTT (or other time interval), or an increased transmit window (in numb= er of packets and/or octets allowed outstanding) are all potential forms.&n= bsp; The codec requests a startup rate and ramp, and the CC responds with t= he allowable parameters which may be lower/slower.  The RMCAT requirements also include the possibility of= bandwidth history to further accelerate or even eliminate startup ramp tim= e. While this acceleration or elimination in ramp time is beneficial to the= session user experience when bandwidth is sufficient, it can be detrimental if significant congestion results (th= e user experience of this session and all other sessions traversing the poi= nt of congestion may unnecessarily degrade).  Therefore, it is recomme= nded that use of potentially stale congestion state for acceleration or elimination in ramp up be limited to topologies = or deployments believed to have sufficient bandwidth margin or those in whi= ch the potential transient congestion risk is acceptable.  Note that s= tartup can often commence before user interaction or conversation to reduce the chance of clipped media.

    ****PROPOSED TEXT****

     =

    The modification deletes= the reference to “network operators”, as I think the point may= be made that many network administrators (be they service providers or oth= er “network operators”) or network designers/sizers would also have the same concern.

     =

    I have reviewed this cha= nge with the present authors and they generally approve of it. Other edits = are welcome.

     =

    Regards,

     =

    Michael A. Ramalho, Ph.D= .

    --_000_cbfb25002da84c24b5eb70b298731926XCHALN017ciscocom_-- From nobody Fri Feb 19 12:27:24 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD401ACCFF for ; Fri, 19 Feb 2016 12:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.207 X-Spam-Level: X-Spam-Status: No, score=-14.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXyYU5RZAmqE for ; Fri, 19 Feb 2016 12:27:21 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074CB1ACCE3 for ; Fri, 19 Feb 2016 12:27:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1470; q=dns/txt; s=iport; t=1455913641; x=1457123241; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yZRT/YGnipc7yq8eeLu5ORf0E+OHcLMvN8IxjqDF8nc=; b=DeJuwr+cyNHM5Ye7dlTDPXdU3rhOeLCfIm3vcyYy52uQYkVYZozsR3M2 7jaQ/VRy/pqhWJ53lfxH8dJH3EY2xoxtdyvrkYODJfLgD7ZSQb1Er3DIf +UPqbC+CPNizJ/fcq3HuW6kimJDNMUehFVXN8r3lUknb/XcANMse5Oy8J E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DwBwBresdW/5hdJa1egzpSbQaFfqVXA?= =?us-ascii?q?QQBjmQBDYFoIYVsAoFXOBQBAQEBAQEBZCeEQQEBAQICeRACAQgRBAEBCiUPIx0?= =?us-ascii?q?IAgQBDQUJiBEOvAQBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhhKEO4QzhDwFjWKJJ?= =?us-ascii?q?QGNXYxDgjCORwEeAQFCggMZgUhqAYc+fQEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,472,1449532800"; d="scan'208";a="240381456" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2016 20:27:12 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1JKRBZ3002887 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Feb 2016 20:27:12 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 19 Feb 2016 14:27:11 -0600 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1104.009; Fri, 19 Feb 2016 14:27:11 -0600 From: "Xiaoqing Zhu (xiaoqzhu)" To: =?iso-8859-1?Q?Mirja_K=FChlewind?= , "rmcat WG (rmcat@ietf.org)" Thread-Topic: [rmcat] Wireless test cases Thread-Index: AQHRaNy/VapPwARipkaYL6fylYsp7Z8z0rMz Date: Fri, 19 Feb 2016 20:27:11 +0000 Message-ID: <1455913631142.29407@cisco.com> References: <6902D83B-55B3-4D22-8B37-A71A89720DDF@tik.ee.ethz.ch> In-Reply-To: <6902D83B-55B3-4D22-8B37-A71A89720DDF@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.152.13.83] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: =?iso-8859-1?Q?Anna_Brunstr=F6m?= Subject: Re: [rmcat] Wireless test cases X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 20:27:22 -0000 Hi Mirja, =0A= =0A= For evaluation of NADA, we have previously run NS-3-based simulation test o= n the Wi-Fi test cases as described in Sections 4.1 and 4.2 of the draft. = =0A= =0A= So far we've only tested with a fixed number of RMCAT flows only. The test = scenarios with TCP background flows yet and varying number of flows are in = the pipeline. Results were presented earlier at IETF-93:=0A= =0A= http://www.ietf.org/proceedings/93/slides/slides-93-rmcat-1.pdf=0A= =0A= As for Sec. 3 on Cellular Network Specific Test Cases, would appreciate mor= e detailed information on how to set those up, or relevant pointers/code on= cellular network simulators. =0A= =0A= Thanks,=0A= Xiaoqing=0A= ________________________________________=0A= From: rmcat on behalf of Mirja K=FChlewind =0A= Sent: Tuesday, February 16, 2016 11:08 AM=0A= To: rmcat WG (rmcat@ietf.org)=0A= Cc: Anna Brunstr=F6m=0A= Subject: [rmcat] Wireless test cases=0A= =0A= Hi all,=0A= =0A= quick questions on the wireless test cases:=0A= =0A= First, who did already run all or some of the test cases, and which?=0A= =0A= And, second, should all the wireless test cases (both mobile and wifi) be p= art of the set of 'base' test cases for which we as a group would like to s= ee results before moving a candidate document forward or do we need to even= pick a subset of those?=0A= =0A= Mirja=0A= =0A= From nobody Wed Feb 24 03:01:56 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4141A1A88 for ; Wed, 24 Feb 2016 03:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POehMJeSBItn for ; Wed, 24 Feb 2016 03:01:53 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA391A1A17 for ; Wed, 24 Feb 2016 03:01:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id DB17BD9309; Wed, 24 Feb 2016 12:01:50 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KZKqiQPEdTTH; Wed, 24 Feb 2016 12:01:50 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 9AD0CD9307; Wed, 24 Feb 2016 12:01:50 +0100 (MET) To: Zaheduzzaman Sarker References: <170F0EA5-EAB0-4B01-A8DF-56A0B2923A9A@ifi.uio.no> <56AA17AD.8060806@ericsson.com> <56BB01D5.5040902@ericsson.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <56CD8D9D.70803@tik.ee.ethz.ch> Date: Wed, 24 Feb 2016 12:01:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56BB01D5.5040902@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Safiqul Islam , "rmcat@ietf.org" , "mramalho@cisco.com" , =?UTF-8?Q?Anna_Brunstr=c3=b6m?= , Varun Singh , Xiaoqing Zhu Subject: Re: [rmcat] test cases for coupled cc [was: Re: Review of draft-ietf-rmcat-eval-test-02] X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 11:01:55 -0000 Hi Zahed, quickly on this point: On 10.02.2016 10:24, Zaheduzzaman Sarker wrote: >> >I believe we decided already at the last meeting that we need to >> >adapt this draft to include uses cases for coupled congestion (and >> >that’s why we asked Safiqul to propose some). > That is what I can also recall but didn't see anything in the meeting > minutes so was not sure what we agreed on. May be missed it in the > meeting minutes. I guess there was no official decision of the wg to include text for coupled-cc, however, Safiqul volunteered to provide some input here and I don't recall that there have been any objections to include this. I also don't see how this could be a problem. I agree with you and Safiqul that we don't need to consider coupled-cc for all test cases; only where it makes sense (e.g. test cases with one flow do not make any sense...) If anybody has a different opinion, please speak up now! Mirja From nobody Wed Feb 24 03:06:19 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF691A87AF for ; Wed, 24 Feb 2016 03:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnKUoE3LQxwa for ; Wed, 24 Feb 2016 03:06:16 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E26D1A871E for ; Wed, 24 Feb 2016 03:06:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 04398D930B; Wed, 24 Feb 2016 12:06:15 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wT0aqdwnduFP; Wed, 24 Feb 2016 12:06:14 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id C1DB5D9307; Wed, 24 Feb 2016 12:06:14 +0100 (MET) To: Zaheduzzaman Sarker References: <170F0EA5-EAB0-4B01-A8DF-56A0B2923A9A@ifi.uio.no> <56AA17AD.8060806@ericsson.com> <56BB01D5.5040902@ericsson.com> <56C312A9.1000609@ericsson.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <56CD8EA6.9010603@tik.ee.ethz.ch> Date: Wed, 24 Feb 2016 12:06:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "rmcat@ietf.org" , Michael Welzl Subject: Re: [rmcat] test cases for coupled cc [was: Re: Review of draft-ietf-rmcat-eval-test-02] X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 11:06:18 -0000 Hi Zahed, I agree with Michael. My view is here that we need to evaluate each combination of a certain scheme to couple things using a certain congestion control algorithm separately. That means, if someone proposes a new (generic) scheme for coupling, we as a group would only advise to use this scheme with a certain cc algorithm if we have seen results for this specific combination. Does this make sense to you? I hope this also reflects the view of the wg. If not, please let us now and we would need to discuss this again. Mirja On 16.02.2016 17:42, Michael Welzl wrote: > Hi, > > My 2 cents about one bit here, cutting away the rest: > > >> On 16. feb. 2016, at 02.14, Zaheduzzaman Sarker wrote: >> (..) >> On 02/10/2016 03:36 PM, Safiqul Islam wrote: > (..) > > >>> Without making it compulsory, I suggested to add these in the other cases. We can perhaps say: >>> >>> “When flows share a common bottleneck, combining their congestion controllers can be beneficial. >>> These additional test cases can be used to evaluate a congestion control mechanism when using a method to couple flows, such as [I-D.ietf-rmcat-coupled-cc]." >>> >>> Does this put it better? >> I dont think this document to referent to any candidate solution. >> >> I think the test cases should be defined so that one can evaluate other alternatives if there is any. Now, if there is more than one coupled CC solution and the candidate algorithms perform differently with different solution, how that will help us to evaluate coupled Congestion control algorithms. How does the WG plans to solve such situation? > > The sentence Safiqul proposed mentions the coupled-cc draft as an example - not more, not less. Remove it if you want, and nothing has changed: this isn’t about evaluating coupled CC. algorithms, it’s about evaluating how congestion control algorithms work when they are combined with a method to couple them. It’s not mandatory either - but if you want to test how e.g. SCReAM operates when coupled, these test cases probable make sense. That’s all this says. > > Cheers, > Michael > From nobody Wed Feb 24 03:31:27 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515621A88BD for ; Wed, 24 Feb 2016 03:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os0lZA-jpj98 for ; Wed, 24 Feb 2016 03:31:23 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DF71A890F for ; Wed, 24 Feb 2016 03:31:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D5E3BD9309; Wed, 24 Feb 2016 12:31:21 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BW5lklLgl8ih; Wed, 24 Feb 2016 12:31:21 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 793CAD9307; Wed, 24 Feb 2016 12:31:21 +0100 (MET) To: "Michael Ramalho (mramalho)" , "rmcat@ietf.org" , Mo Zanaty References: From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <56CD9488.8020705@tik.ee.ethz.ch> Date: Wed, 24 Feb 2016 12:31:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rmcat] Review of rmcat-cc-codec-interactions X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 11:31:26 -0000 Hi Mo, hi Michael, two comments as individual: Reading this text part now, I don't think we need to negotiate the startup ramp. Actually I'm not even sure what the term 'ramp' is supposed to mean here. I believe we need is to indicate the maximum initial sending rate from the cc to the codec. If the codec then delivers data with a lower rate that should not be a problem for the cc. And the initial (max) sending can solely be chosen by the cc, as it might either use a default value or some cached info from previous transmission to the same receiver (over the same access network). Further, I agree that it is good to add one sentence that this rate has to be chosen carefully (and a different value than a conservative default can only be used if further information about or from the network is available). But I don't really understand what exactly you want say with the two sentences that you have added below...? Mirja On 16.02.2016 22:59, Michael Ramalho (mramalho) wrote: > All, > > I have reviewed draft-zanaty-rmcat-cc-codec-interactions. My only comments > concern Section 5.2.2 (Startup Ramp). > > In what follows I have added two sentences and modified a sentence in this > section. > > ****EXISTING TEXT**** > > 5.2.2. Startup Ramp > > Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an > important moment in a conversation. Rapid rate adaptation during startup is > therefore important. The codec should minimize its startup media rate as > much as possible without adversely impacting the user experience, and support > a strategy for rapid rate ramp. The CC should allow the highest startup > media rate as possible without adversely impacting network conditions, and > also support rapid rate ramp until stabilizing on the available bandwidth. > Startup can be viewed as a negotiation between the codec and the CC. The > codec requests a startup rate and ramp, and the CC responds with the > allowable parameters which may be lower/slower. The RMCAT requirements also > include the possibility of bandwidth history to further accelerate or even > eliminate startup ramp time. While this is highly desirable from an > application viewpoint, it may be less acceptable to network operators, since > it is in essence a gamble on current congestion state matching historical > state, with the potential for significant congestion contribution if the > gamble was wrong. Note that startup can often commence before user > interaction or conversation to reduce the chance of clipped media. > > ****EXISTING TEXT**** > > ****PROPOSED TEXT**** > > 5.2.2. Startup Ramp > > Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an > important moment in a conversation. Rapid rate adaptation during startup is > therefore important. The codec should minimize its startup media rate as > much as possible without adversely impacting the user experience, and support > a strategy for rapid rate ramp. The CC should allow the highest startup > media rate as possible without adversely impacting network conditions, and > also support rapid rate ramp until stabilizing on the available bandwidth. > Startup can be viewed as a negotiation between the codec and the CC. The > specification of the ramp may take a number of forms depending on the > interface to the codec; for example, a percentage bit rate increase per RTT > (or other time interval), or an increased transmit window (in number of > packets and/or octets allowed outstanding) are all potential forms. The > codec requests a startup rate and ramp, and the CC responds with the > allowable parameters which may be lower/slower. The RMCAT requirements also > include the possibility of bandwidth history to further accelerate or even > eliminate startup ramp time. While this acceleration or elimination in ramp > time is beneficial to the session user experience when bandwidth is > sufficient, it can be detrimental if significant congestion results (the user > experience of this session and all other sessions traversing the point of > congestion may unnecessarily degrade). Therefore, it is recommended that use > of potentially stale congestion state for acceleration or elimination in ramp > up be limited to topologies or deployments believed to have sufficient > bandwidth margin or those in which the potential transient congestion risk is > acceptable. Note that startup can often commence before user interaction or > conversation to reduce the chance of clipped media. > > ****PROPOSED TEXT**** > > The modification deletes the reference to “network operators”, as I think the > point may be made that many network administrators (be they service providers > or other “network operators”) or network designers/sizers would also have the > same concern. > > I have reviewed this change with the present authors and they generally > approve of it. Other edits are welcome. > > Regards, > > Michael A. Ramalho, Ph.D. > From nobody Wed Feb 24 03:33:32 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89601A8A12 for ; Wed, 24 Feb 2016 03:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2JAjW_ic0BX for ; Wed, 24 Feb 2016 03:33:29 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC821A8A0F for ; Wed, 24 Feb 2016 03:33:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A4CE0D9309; Wed, 24 Feb 2016 12:33:27 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vwrpWEYh53vl; Wed, 24 Feb 2016 12:33:27 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 67BE7D9307; Wed, 24 Feb 2016 12:33:27 +0100 (MET) To: "Xiaoqing Zhu (xiaoqzhu)" , "rmcat WG (rmcat@ietf.org)" References: <6902D83B-55B3-4D22-8B37-A71A89720DDF@tik.ee.ethz.ch> <1455913631142.29407@cisco.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <56CD9506.7080902@tik.ee.ethz.ch> Date: Wed, 24 Feb 2016 12:33:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <1455913631142.29407@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Zaheduzzaman Sarker , =?UTF-8?Q?Anna_Brunstr=c3=b6m?= Subject: Re: [rmcat] Wireless test cases X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 11:33:30 -0000 Hi Xiaoqing, On 19.02.2016 21:27, Xiaoqing Zhu (xiaoqzhu) wrote: > As for Sec. 3 on Cellular Network Specific Test Cases, would appreciate > more detailed information on how to set those up, or relevant pointers/code > on cellular network simulators. Can you let us/Zahed know what exactly you need/is missing? Thanks, Mirja From nobody Wed Feb 24 08:50:22 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756911B3964 for ; Wed, 24 Feb 2016 08:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.207 X-Spam-Level: X-Spam-Status: No, score=-14.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuQSfCJjaThQ for ; Wed, 24 Feb 2016 08:50:20 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD8C1B3938 for ; Wed, 24 Feb 2016 08:50:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1357; q=dns/txt; s=iport; t=1456332602; x=1457542202; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1Wl7ru/LGlArtg+wZ0ia828F+i3dCGqJXfiLQL5KqfY=; b=EoNVS5GyKFFgoPO+W7n96z44oTf3P3km5FAXGGBhiwdKdRe08awCmOXT UZR0QWiJWg1pIdS4qpG6TIj7I0vCniFgOjZeiYkZM6/Y1OC6RcS9Ut22d aeapIoQ2N2g61Mjn7AKTPm/UkcB9fTmoQ6LQfStriRn+7z975zliAFBfO s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnBABT3s1W/4MNJK1egzqBPwaFfaYDA?= =?us-ascii?q?QQBjmQBDYFmhg4CgUQ4FAEBAQEBAQFkJ4RBAQEBBHkQAgEIEQQBAQEJJQ8jHQg?= =?us-ascii?q?CBAENBYgfvmwBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhhKEOoQFEQEchDwBBI1ii?= =?us-ascii?q?SUBjV6OdI5IAR4BAUKCAxmBSGoBhi40fQEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,494,1449532800"; d="scan'208";a="242019837" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Feb 2016 16:50:01 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1OGo1Td011446 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 16:50:01 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 24 Feb 2016 10:50:00 -0600 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1104.009; Wed, 24 Feb 2016 10:50:01 -0600 From: "Xiaoqing Zhu (xiaoqzhu)" To: =?iso-8859-1?Q?Mirja_K=FChlewind?= , "rmcat WG (rmcat@ietf.org)" Thread-Topic: [rmcat] Wireless test cases Thread-Index: AQHRaNy/VapPwARipkaYL6fylYsp7Z8z0rMzgAeuggD///D6rw== Date: Wed, 24 Feb 2016 16:50:00 +0000 Message-ID: <1456332600778.99326@cisco.com> References: <6902D83B-55B3-4D22-8B37-A71A89720DDF@tik.ee.ethz.ch> <1455913631142.29407@cisco.com>,<56CD9506.7080902@tik.ee.ethz.ch> In-Reply-To: <56CD9506.7080902@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.248.47] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Zaheduzzaman Sarker , =?iso-8859-1?Q?Anna_Brunstr=F6m?= Subject: Re: [rmcat] Wireless test cases X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 16:50:21 -0000 Hi Mirja, all, =0A= =0A= Zahed and I have indeed discussed about this in Yokohama. Maybe I did not m= ake it clear in my previous email, trying again. =0A= =0A= Basically, to carry out tests in Sec 3 (Cellular Network Specific Test Case= s), one needs to run it over a module that simulates packet behavior over c= ellular links -- just like for the Wi-Fi portion of the test cases, we reli= ed on the Wi-Fi module in NS3 simulators to do so. =0A= =0A= What is missing is the cellular network simulator, preferably as a plug-in = module for NS3, over which we can run rate adaptation tests. =0A= =0A= Thanks,=0A= Xiaoqing=0A= =0A= =0A= ________________________________________=0A= From: Mirja K=FChlewind =0A= Sent: Wednesday, February 24, 2016 3:33 AM=0A= To: Xiaoqing Zhu (xiaoqzhu); rmcat WG (rmcat@ietf.org)=0A= Cc: Anna Brunstr=F6m; Zaheduzzaman Sarker=0A= Subject: Re: [rmcat] Wireless test cases=0A= =0A= Hi Xiaoqing,=0A= =0A= On 19.02.2016 21:27, Xiaoqing Zhu (xiaoqzhu) wrote:=0A= > As for Sec. 3 on Cellular Network Specific Test Cases, would appreciate= =0A= > more detailed information on how to set those up, or relevant pointers/co= de=0A= > on cellular network simulators.=0A= =0A= Can you let us/Zahed know what exactly you need/is missing?=0A= =0A= Thanks,=0A= Mirja= From nobody Wed Feb 24 09:03:25 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B211A1B2F51 for ; Wed, 24 Feb 2016 09:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beWnVeUgYtuQ for ; Wed, 24 Feb 2016 09:03:21 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814741A90C4 for ; Wed, 24 Feb 2016 09:03:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 89AE2D930E; Wed, 24 Feb 2016 18:03:19 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mjLHiIhd2kK7; Wed, 24 Feb 2016 18:03:19 +0100 (MET) Received: from [192.168.220.145] (178-83-155-34.dynamic.hispeed.ch [178.83.155.34]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 3B47BD930D; Wed, 24 Feb 2016 18:03:15 +0100 (MET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: =?iso-8859-1?Q?Mirja_K=FChlewind?= In-Reply-To: <1456332600778.99326@cisco.com> Date: Wed, 24 Feb 2016 18:02:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <41376CF6-1F97-45A5-A8E3-186DBB1219ED@tik.ee.ethz.ch> References: <6902D83B-55B3-4D22-8B37-A71A89720DDF@tik.ee.ethz.ch> <1455913631142.29407@cisco.com> <56CD9506.7080902@tik.ee.ethz.ch> <1456332600778.99326@cisco.com> To: "Xiaoqing Zhu (xiaoqzhu)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "rmcat WG \(rmcat@ietf.org\)" , Zaheduzzaman Sarker , =?iso-8859-1?Q?Anna_Brunstr=F6m?= Subject: Re: [rmcat] Wireless test cases X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 17:03:23 -0000 Hi Xiaoqing, > Am 24.02.2016 um 17:50 schrieb Xiaoqing Zhu (xiaoqzhu) = : >=20 > Hi Mirja, all,=20 >=20 > Zahed and I have indeed discussed about this in Yokohama. Maybe I did = not make it clear in my previous email, trying again.=20 >=20 > Basically, to carry out tests in Sec 3 (Cellular Network Specific Test = Cases), one needs to run it over a module that simulates packet behavior = over cellular links -- just like for the Wi-Fi portion of the test = cases, we relied on the Wi-Fi module in NS3 simulators to do so. =20 >=20 > What is missing is the cellular network simulator, preferably as a = plug-in module for NS3, over which we can run rate adaptation tests. =20 I though that this is available in the mean time.=20 Zahed, do you have link or is this already included in the latest = version of ns-3? Mirja =20 >=20 > Thanks, > Xiaoqing >=20 >=20 > ________________________________________ > From: Mirja K=FChlewind > Sent: Wednesday, February 24, 2016 3:33 AM > To: Xiaoqing Zhu (xiaoqzhu); rmcat WG (rmcat@ietf.org) > Cc: Anna Brunstr=F6m; Zaheduzzaman Sarker > Subject: Re: [rmcat] Wireless test cases >=20 > Hi Xiaoqing, >=20 > On 19.02.2016 21:27, Xiaoqing Zhu (xiaoqzhu) wrote: >> As for Sec. 3 on Cellular Network Specific Test Cases, would = appreciate >> more detailed information on how to set those up, or relevant = pointers/code >> on cellular network simulators. >=20 > Can you let us/Zahed know what exactly you need/is missing? >=20 > Thanks, > Mirja From nobody Wed Feb 24 13:20:09 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4AE1B405D for ; Wed, 24 Feb 2016 13:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.207 X-Spam-Level: X-Spam-Status: No, score=-14.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qmk0BfiqBIJ9 for ; Wed, 24 Feb 2016 13:20:05 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31421B405C for ; Wed, 24 Feb 2016 13:20:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3549; q=dns/txt; s=iport; t=1456348804; x=1457558404; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mxBikEt46mY1KYlHRfw96IjMvKpzYZdZNRiM+iZ9NSw=; b=iQyH1KEC0bG5QJ6g9oeTyXvV3UAyt4IdZHVxYpLdRynO/XJcwalBq9s8 3fvEussGxp787apuKmNTZrmatde32twRvPF17O4DySNVr71NdIhDqfyD0 p97CO+ebA/bUdOF7yXxUReiDXlQbP4NR5Zni+Gx+vzkOFiRx6F42ZqaQj M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAgAWHs5W/5BdJa1egzqBPwaFfaYAA?= =?us-ascii?q?QQBjmQBDYFmhg4CgUk4FAEBAQEBAQFkJ4RBAQEBBHkQAgEIEQQBAQEJJQ8jHQg?= =?us-ascii?q?CBAENBRuIBL1pAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYShDqEM4Q8AQSXBwGNX?= =?us-ascii?q?oFehESIUo5IAR4BAUKCMIE0agGGYn0BAQE?= X-IronPort-AV: E=Sophos;i="5.22,494,1449532800"; d="scan'208";a="80072348" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Feb 2016 21:20:03 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u1OLK3KT000521 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 21:20:03 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 24 Feb 2016 15:20:02 -0600 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1104.009; Wed, 24 Feb 2016 15:20:03 -0600 From: "Xiaoqing Zhu (xiaoqzhu)" To: =?Windows-1252?Q?Mirja_K=FChlewind?= , Zaheduzzaman Sarker Thread-Topic: [rmcat] test cases for coupled cc [was: Re: Review of draft-ietf-rmcat-eval-test-02] Thread-Index: AQHRaNkX0vq8sww8W0WWIuewig2D7p87eaMAgABDeEo= Date: Wed, 24 Feb 2016 21:20:02 +0000 Message-ID: <1456348802855.68317@cisco.com> References: <170F0EA5-EAB0-4B01-A8DF-56A0B2923A9A@ifi.uio.no> <56AA17AD.8060806@ericsson.com> <56BB01D5.5040902@ericsson.com> <56C312A9.1000609@ericsson.com> , <56CD8EA6.9010603@tik.ee.ethz.ch> In-Reply-To: <56CD8EA6.9010603@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.248.47] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rmcat@ietf.org" , Michael Welzl Subject: Re: [rmcat] test cases for coupled cc [was: Re: Review of draft-ietf-rmcat-eval-test-02] X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 21:20:07 -0000 Hi, =0A= =0A= I would like to provide my input on this discussion. =0A= =0A= My understanding is that the test case draft specifies scenarios over which= we would like to evaluate candidate algorithms (oh well, stating the obvio= us.) As such, Sec 5.4 (Competing Flows with Same RMCAT Algorithm) is a good= place to add one flavor/variation of the test set up, whereby all senders = share the same physical node so that one can test how a coupled CC solution= works. =0A= =0A= I don't see why the test case draft need to say anything additional (e.g., = whether a proposed CC solution should be combined with which flavor of the = candidate algorithm) beyond describing that sub-test case. =0A= =0A= Thanks,=0A= Xiaoqing=0A= =0A= =0A= =0A= ________________________________________=0A= From: rmcat on behalf of Mirja K=FChlewind =0A= Sent: Wednesday, February 24, 2016 3:06 AM=0A= To: Zaheduzzaman Sarker=0A= Cc: rmcat@ietf.org; Michael Welzl=0A= Subject: Re: [rmcat] test cases for coupled cc [was: Re: Review of draft-ie= tf-rmcat-eval-test-02]=0A= =0A= Hi Zahed,=0A= =0A= I agree with Michael. My view is here that we need to evaluate each=0A= combination of a certain scheme to couple things using a certain congestion= =0A= control algorithm separately. That means, if someone proposes a new (generi= c)=0A= scheme for coupling, we as a group would only advise to use this scheme wit= h=0A= a certain cc algorithm if we have seen results for this specific combinatio= n.=0A= Does this make sense to you?=0A= =0A= I hope this also reflects the view of the wg. If not, please let us now and= =0A= we would need to discuss this again.=0A= =0A= Mirja=0A= =0A= =0A= On 16.02.2016 17:42, Michael Welzl wrote:=0A= > Hi,=0A= >=0A= > My 2 cents about one bit here, cutting away the rest:=0A= >=0A= >=0A= >> On 16. feb. 2016, at 02.14, Zaheduzzaman Sarker wrote:=0A= >> (..)=0A= >> On 02/10/2016 03:36 PM, Safiqul Islam wrote:=0A= > (..)=0A= >=0A= >=0A= >>> Without making it compulsory, I suggested to add these in the other cas= es. We can perhaps say:=0A= >>>=0A= >>> =93When flows share a common bottleneck, combining their congestion con= trollers can be beneficial.=0A= >>> These additional test cases can be used to evaluate a congestion contro= l mechanism when using a method to couple flows, such as [I-D.ietf-rmcat-co= upled-cc]."=0A= >>>=0A= >>> Does this put it better?=0A= >> I dont think this document to referent to any candidate solution.=0A= >>=0A= >> I think the test cases should be defined so that one can evaluate other = alternatives if there is any. Now, if there is more than one coupled CC sol= ution and the candidate algorithms perform differently with different solut= ion, how that will help us to evaluate coupled Congestion control algorithm= s. How does the WG plans to solve such situation?=0A= >=0A= > The sentence Safiqul proposed mentions the coupled-cc draft as an example= - not more, not less. Remove it if you want, and nothing has changed: this= isn=92t about evaluating coupled CC. algorithms, it=92s about evaluating h= ow congestion control algorithms work when they are combined with a method = to couple them. It=92s not mandatory either - but if you want to test how e= .g. SCReAM operates when coupled, these test cases probable make sense. Tha= t=92s all this says.=0A= >=0A= > Cheers,=0A= > Michael=0A= >=0A= From nobody Wed Feb 24 14:52:50 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54891A1B03 for ; Wed, 24 Feb 2016 14:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.206 X-Spam-Level: X-Spam-Status: No, score=-14.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxOP8H9ME-uf for ; Wed, 24 Feb 2016 14:52:42 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75AF11A1AC6 for ; Wed, 24 Feb 2016 14:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19323; q=dns/txt; s=iport; t=1456354362; x=1457563962; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=hj2xyRCMSgbKkdMBzNXU6fGdcHG++cLAP4gFQPlZwMs=; b=jTtmsvxbo5X/kHNnp2A0sKLb6fKB0yZW/66eMSrOgv0iwIcpxeAKQ/WM 0ecJ9RqRuOgto16SkBNfn6GlIqtbChzAhHl84OLe5vSGamxsVTCHidHaF vK3W3v0sCBFujPwCzGlRUvT1XjkgaqcSYze8kRAIfLmSEirCV1U9evqJf M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgDTM85W/5FdJa1egm5MUm0GumgBD?= =?us-ascii?q?YFmI4VrAoE+OBQBAQEBAQEBZCeEQgEBBIEJAgEIPwcyFBECBAESiB8OvXcBAQE?= =?us-ascii?q?BAQEBAwEBAQEBAQEVBIYShDqED1OEDQWNYoURhBQBhVeCboUZjnSOSAEeAQFCg?= =?us-ascii?q?X6BZmoBhiU9fQEBAQ?= X-IronPort-AV: E=Sophos; i="5.22,495,1449532800"; d="scan'208,217"; a="76514635" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Feb 2016 22:52:41 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u1OMqeO0028890 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 22:52:40 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 24 Feb 2016 16:52:39 -0600 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.009; Wed, 24 Feb 2016 16:52:39 -0600 From: "Mo Zanaty (mzanaty)" To: =?iso-8859-1?Q?Mirja_K=FChlewind?= , "Michael Ramalho (mramalho)" , "rmcat WG (rmcat@ietf.org)" Thread-Topic: [rmcat] Review of rmcat-cc-codec-interactions Thread-Index: AQHRb1YQg5ItDOIHuEW1CiCQOpj5pA== Date: Wed, 24 Feb 2016 22:52:39 +0000 Message-ID: References: <56CD9488.8020705@tik.ee.ethz.ch> In-Reply-To: <56CD9488.8020705@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.245.175] Content-Type: multipart/alternative; boundary="_000_D2F3370B5A554mzanatyciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [rmcat] Review of rmcat-cc-codec-interactions X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 22:52:48 -0000 --_000_D2F3370B5A554mzanatyciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mirja, Startup "Ramp" refers to rate (or window) increase over time at startup, no= t just the initial rate/window. The old app-interaction draft described thi= s in section 5 (Interfaces and Interactions), but we were asked to remove t= his in the new cc-codec-interactions draft. Should we add this back? https://tools.ietf.org/html/draft-ietf-rmcat-app-interaction-01#section-5 o Startup Ramp (CC-Codec): Initial rate (or number of packets in window-based CC proposals) and strategy for increasing the rate (or window) during media startup, similar to TCP intial congestion window and slow start. See Section 5.4.3 for details. While an initial window may be sufficient for TCP apps, it can be insuffici= ent for codecs at startup. A codec can make many different (more intelligen= t) decisions at startup depending on the target ramp, versus usually making= very poor decisions if only an initial rate is given. If the only cc-codec interaction at startup is an initial rate, then Allowe= d Rate can already capture that interaction without anything special needed= for startup. However, startup is indeed special because the initial rate i= s very transient and rapid increase is expected. Codecs can make better dec= isions if they are aware of the CC startup dynamics. For example, if the codec is only told 300 kbps, it may adapt to a very low= resolution like CIF with poor quantization in order to maintain a stable, = moderate frame rate at 300 kbps. If instead it is told 300 kbps ramping up = geometrically to 2.5 Mbps in 0.5 seconds, it may target HD 1080p with bette= r quantization and pace the initial frame over a longer time until the star= tup rate stabilizes before attempting full frame rate. Cheers, Mo On 2/24/16, 6:31 AM, Mirja K=FChlewind > wrote: Hi Mo, hi Michael, two comments as individual: Reading this text part now, I don't think we need to negotiate the startup ramp. Actually I'm not even sure what the term 'ramp' is supposed to mean here. I believe we need is to indicate the maximum initial sending rate fro= m the cc to the codec. If the codec then delivers data with a lower rate that should not be a problem for the cc. And the initial (max) sending can solel= y be chosen by the cc, as it might either use a default value or some cached info from previous transmission to the same receiver (over the same access network). Further, I agree that it is good to add one sentence that this rate has to = be chosen carefully (and a different value than a conservative default can onl= y be used if further information about or from the network is available). But= I don't really understand what exactly you want say with the two sentences th= at you have added below...? Mirja On 16.02.2016 22:59, Michael Ramalho (mramalho) wrote: All, I have reviewed draft-zanaty-rmcat-cc-codec-interactions. My only comments concern Section 5.2.2 (Startup Ramp). In what follows I have added two sentences and modified a sentence in this section. ****EXISTING TEXT**** 5.2.2. Startup Ramp Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an important moment in a conversation. Rapid rate adaptation during startup i= s therefore important. The codec should minimize its startup media rate as much as possible without adversely impacting the user experience, and suppo= rt a strategy for rapid rate ramp. The CC should allow the highest startup media rate as possible without adversely impacting network conditions, and also support rapid rate ramp until stabilizing on the available bandwidth. Startup can be viewed as a negotiation between the codec and the CC. The codec requests a startup rate and ramp, and the CC responds with the allowable parameters which may be lower/slower. The RMCAT requirements als= o include the possibility of bandwidth history to further accelerate or even eliminate startup ramp time. While this is highly desirable from an application viewpoint, it may be less acceptable to network operators, sinc= e it is in essence a gamble on current congestion state matching historical state, with the potential for significant congestion contribution if the gamble was wrong. Note that startup can often commence before user interaction or conversation to reduce the chance of clipped media. ****EXISTING TEXT**** ****PROPOSED TEXT**** 5.2.2. Startup Ramp Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an important moment in a conversation. Rapid rate adaptation during startup i= s therefore important. The codec should minimize its startup media rate as much as possible without adversely impacting the user experience, and suppo= rt a strategy for rapid rate ramp. The CC should allow the highest startup media rate as possible without adversely impacting network conditions, and also support rapid rate ramp until stabilizing on the available bandwidth. Startup can be viewed as a negotiation between the codec and the CC. The specification of the ramp may take a number of forms depending on the interface to the codec; for example, a percentage bit rate increase per RTT (or other time interval), or an increased transmit window (in number of packets and/or octets allowed outstanding) are all potential forms. The codec requests a startup rate and ramp, and the CC responds with the allowable parameters which may be lower/slower. The RMCAT requirements als= o include the possibility of bandwidth history to further accelerate or even eliminate startup ramp time. While this acceleration or elimination in ramp time is beneficial to the session user experience when bandwidth is sufficient, it can be detrimental if significant congestion results (the us= er experience of this session and all other sessions traversing the point of congestion may unnecessarily degrade). Therefore, it is recommended that u= se of potentially stale congestion state for acceleration or elimination in ra= mp up be limited to topologies or deployments believed to have sufficient bandwidth margin or those in which the potential transient congestion risk = is acceptable. Note that startup can often commence before user interaction o= r conversation to reduce the chance of clipped media. ****PROPOSED TEXT**** The modification deletes the reference to "network operators", as I think t= he point may be made that many network administrators (be they service provide= rs or other "network operators") or network designers/sizers would also have t= he same concern. I have reviewed this change with the present authors and they generally approve of it. Other edits are welcome. Regards, Michael A. Ramalho, Ph.D. --_000_D2F3370B5A554mzanatyciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
    Hi Mirja,

    Startup &quo= t;Ramp" refers to rate (or window) increase over time at startup, not = just the initial rate/window. The old app-interaction draft described this = in section 5 (Interfaces and Interactions), but we were asked to remove this in the new cc-codec-interactions draft. S= hould we add this back?


       o  Startup Ramp (CC-C= odec): Initial rate (or number of packets in
          window-based CC pr= oposals) and strategy for increasing the rate
          (or window) during= media startup, similar to TCP intial congestion
          window and slow st= art.  See Section 5.4.3 for details.

    While an ini= tial window may be sufficient for TCP apps, it can be insufficient for code= cs at startup. A codec can make many different (more intelligent) decisions= at startup depending on the target ramp, versus usually making very poor decisions if only an initial rate is= given.

    If the only = cc-codec interaction at startup is an initial rate, then Allowed Rate can a= lready capture that interaction without anything special needed for startup= . However, startup is indeed special because the initial rate is very transient and rapid increase is expected.= Codecs can make better decisions if they are aware of the CC startup dynam= ics.

    For example, if the codec is only told 300 kbps, it may adapt to a ver= y low resolution like CIF with poor quantization in order to maintain a sta= ble, moderate frame rate at 300 kbps. If instead it is told 300 kbps rampin= g up geometrically to 2.5 Mbps in 0.5 seconds, it may target HD 1080p with better quantization and pace the = initial frame over a longer time until the startup rate stabilizes before a= ttempting full frame rate.

    Cheers,
    Mo

    Hi Mo, hi Mi= chael,

    two comments= as individual:

    Reading this= text part now, I don't think we need to negotiate the startup
    ramp. Actual= ly I'm not even sure what the term 'ramp' is supposed to mean
    here. I beli= eve we need is to indicate the maximum initial sending rate from
    the cc to th= e codec. If the codec then delivers data with a lower rate that
    should not b= e a problem for the cc. And the initial (max) sending can solely
    be chosen by= the cc, as it might either use a default value or some cached
    info from pr= evious transmission to the same receiver (over the same access
    network).

    Further, I a= gree that it is good to add one sentence that this rate has to be
    chosen caref= ully (and a different value than a conservative default can only
    be used if f= urther information about or from the network is available). But I
    don't really= understand what exactly you want say with the two sentences that
    you have add= ed below...?

    Mirja


    On 16.02.201= 6 22:59, Michael Ramalho (mramalho) wrote:
    All,

    I have reviewed draft-zanaty-rmcat-cc-codec-interactions. My only comm= ents
    concern Section 5.2.2 (Startup Ramp).

    In what follows I have added two sentences and modified a sentence in = this
    section.

    ****EXISTING TEXT****

    5.2.2.  Startup Ramp

    Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an
    important moment in a conversation.  Rapid rate adaptation d= uring startup is
    therefore important.  The codec should minimize its startup = media rate as
    much as possible without adversely impacting the user experience, and = support
    a strategy for rapid rate ramp.  The CC should allow the hig= hest startup
    media rate as possible without adversely impacting network conditions,= and
    also support rapid rate ramp until stabilizing on the available bandwi= dth.
    Startup can be viewed as a negotiation between the codec and the CC.&n= bsp; The
    codec requests a startup rate and ramp, and the CC responds with the
    allowable parameters which may be lower/slower.  The RMCAT r= equirements also
    include the possibility of bandwidth history to further accelerate or = even
    eliminate startup ramp time.  While this is highly desirable= from an
    application viewpoint, it may be less acceptable to network operators,= since
    it is in essence a gamble on current congestion state matching histori= cal
    state, with the potential for significant congestion contribution if t= he
    gamble was wrong.  Note that startup can often commence befo= re user
    interaction or conversation to reduce the chance of clipped media.

    ****EXISTING TEXT****

    ****PROPOSED TEXT****

    5.2.2.  Startup Ramp

    Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an
    important moment in a conversation.  Rapid rate adaptation d= uring startup is
    therefore important.  The codec should minimize its startup = media rate as
    much as possible without adversely impacting the user experience, and = support
    a strategy for rapid rate ramp.  The CC should allow the hig= hest startup
    media rate as possible without adversely impacting network conditions,= and
    also support rapid rate ramp until stabilizing on the available bandwi= dth.
    Startup can be viewed as a negotiation between the codec and the CC.&n= bsp; The
    specification of the ramp may take a number of forms depending on the<= /div>
    interface to the codec; for example, a percentage bit rate increase pe= r RTT
    (or other time interval), or an increased transmit window (in number o= f
    packets and/or octets allowed outstanding) are all potential forms.&nb= sp; The
    codec requests a startup rate and ramp, and the CC responds with the
    allowable parameters which may be lower/slower.  The RMCAT r= equirements also
    include the possibility of bandwidth history to further accelerate or = even
    eliminate startup ramp time. While this acceleration or elimination in= ramp
    time is beneficial to the session user experience when bandwidth is
    sufficient, it can be detrimental if significant congestion results (t= he user
    experience of this session and all other sessions traversing the point= of
    congestion may unnecessarily degrade).  Therefore, it is rec= ommended that use
    of potentially stale congestion state for acceleration or elimination = in ramp
    up be limited to topologies or deployments believed to have sufficient=
    bandwidth margin or those in which the potential transient congestion = risk is
    acceptable.  Note that startup can often commence before use= r interaction or
    conversation to reduce the chance of clipped media.

    ****PROPOSED TEXT****

    The modification deletes the reference to “network operatorsR= 21;, as I think the
    point may be made that many network administrators (be they service pr= oviders
    or other “network operators”) or network designers/sizers = would also have the
    same concern.

    I have reviewed this change with the present authors and they generall= y
    approve of it. Other edits are welcome.

    Regards,

    Michael A. Ramalho, Ph.D.


    --_000_D2F3370B5A554mzanatyciscocom_-- From nobody Wed Feb 24 23:46:44 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D58E1A046D for ; Wed, 24 Feb 2016 23:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oWp6x5sJVfB for ; Wed, 24 Feb 2016 23:46:41 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14D0D1A0451 for ; Wed, 24 Feb 2016 23:46:40 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-27-56ceb15efdb7 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A2.48.28465.E51BEC65; Thu, 25 Feb 2016 08:46:38 +0100 (CET) Received: from [150.132.142.224] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.248.2; Thu, 25 Feb 2016 08:45:47 +0100 To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , "Xiaoqing Zhu (xiaoqzhu)" References: <6902D83B-55B3-4D22-8B37-A71A89720DDF@tik.ee.ethz.ch> <1455913631142.29407@cisco.com> <56CD9506.7080902@tik.ee.ethz.ch> <1456332600778.99326@cisco.com> <41376CF6-1F97-45A5-A8E3-186DBB1219ED@tik.ee.ethz.ch> From: Zaheduzzaman Sarker Organization: Ericsson AB Message-ID: <56CEB129.10307@ericsson.com> Date: Thu, 25 Feb 2016 08:45:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <41376CF6-1F97-45A5-A8E3-186DBB1219ED@tik.ee.ethz.ch> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM2K7h27cxnNhBndvqVmc+HGZ2WLD6iks FqtvfmCzeN2yjMmBxWPK742sHkuW/GTy+Huhlc3j2IevbAEsUVw2Kak5mWWpRfp2CVwZnzc1 sxY84q34/yKugfEfVxcjJ4eEgInEpLad7BC2mMSFe+vZuhi5OIQEDjNK3L2yjxnCWcsosf7R YRaQKmEBDYlpH/uZQWwRgQqJBWePMUIU3WeUePzjEdgoZoFsiQWXnwI1cHCwCdhIPF7sBxLm F5CU2NCwmxkkzCugKXH8XwhImEVAVWLqje1gI0UFIiQOd3aBTeEVEJQ4OfMJ2FpOASeJZX83 soO0MgvYSzzYWgaxSFti2cLXYBOFBHQlul7GTWAUmoWkeRZCwywkDQsYmVcxihanFhfnphsZ 66UWZSYXF+fn6eWllmxiBIb5wS2/dXcwrn7teIhRgINRiYd3w9+zYUKsiWXFlbmHGCU4mJVE eM8vPhcmxJuSWFmVWpQfX1Sak1p8iFGag0VJnHeN8/owIYH0xJLU7NTUgtQimCwTB6dUA6NN s96px6cn7koQ7pj0dumX6VGJjNb3H8tvYWGv5f76jTHn//ETeesWPhN2t1+j+q04deHtZQZv P6+anf/ki8yFBEt55u1n3tf0zvrb8/HFm/vlkgrdbNzJq3ruFvxccvXwE/FVSrddkg9Hsi/u Mpe8Pb9TJHxJT8O+070fdQombWCJ3N+/+sU0JZbijERDLeai4kQAY/bSiG8CAAA= Archived-At: Cc: "rmcat WG \(rmcat@ietf.org\)" , =?UTF-8?Q?Anna_Brunstr=c3=b6m?= Subject: Re: [rmcat] Wireless test cases X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 07:46:43 -0000 Yes, NS-3 has necessary modules to run LTE simulations. https://www.nsnam.org/docs/models/html/lte.html BR Zahed On 02/24/2016 06:02 PM, Mirja K=FChlewind wrote: > Hi Xiaoqing, > >> Am 24.02.2016 um 17:50 schrieb Xiaoqing Zhu (xiaoqzhu) : >> >> Hi Mirja, all, >> >> Zahed and I have indeed discussed about this in Yokohama. Maybe I did = not make it clear in my previous email, trying again. >> >> Basically, to carry out tests in Sec 3 (Cellular Network Specific Test= Cases), one needs to run it over a module that simulates packet behavior= over cellular links -- just like for the Wi-Fi portion of the test cases= , we relied on the Wi-Fi module in NS3 simulators to do so. >> >> What is missing is the cellular network simulator, preferably as a plu= g-in module for NS3, over which we can run rate adaptation tests. > I though that this is available in the mean time. > > Zahed, do you have link or is this already included in the latest versi= on of ns-3? > > Mirja > > =20 >> Thanks, >> Xiaoqing >> >> >> ________________________________________ >> From: Mirja K=FChlewind >> Sent: Wednesday, February 24, 2016 3:33 AM >> To: Xiaoqing Zhu (xiaoqzhu); rmcat WG (rmcat@ietf.org) >> Cc: Anna Brunstr=F6m; Zaheduzzaman Sarker >> Subject: Re: [rmcat] Wireless test cases >> >> Hi Xiaoqing, >> >> On 19.02.2016 21:27, Xiaoqing Zhu (xiaoqzhu) wrote: >>> As for Sec. 3 on Cellular Network Specific Test Cases, would apprecia= te >>> more detailed information on how to set those up, or relevant pointer= s/code >>> on cellular network simulators. >> Can you let us/Zahed know what exactly you need/is missing? >> >> Thanks, >> Mirja From nobody Thu Feb 25 00:31:53 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BA31A19E5 for ; Thu, 25 Feb 2016 00:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLsoKZ2wE_ug for ; Thu, 25 Feb 2016 00:31:51 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE2F21A01A1 for ; Thu, 25 Feb 2016 00:31:50 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-f6-56cebbf4bf2b Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F6.01.28465.4FBBEC65; Thu, 25 Feb 2016 09:31:48 +0100 (CET) Received: from [150.132.142.224] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.248.2; Thu, 25 Feb 2016 09:31:48 +0100 From: Zaheduzzaman Sarker To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <170F0EA5-EAB0-4B01-A8DF-56A0B2923A9A@ifi.uio.no> <56AA17AD.8060806@ericsson.com> <56BB01D5.5040902@ericsson.com> <56CD8D9D.70803@tik.ee.ethz.ch> Organization: Ericsson AB Message-ID: <56CEBBF3.4040708@ericsson.com> Date: Thu, 25 Feb 2016 09:31:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56CD8D9D.70803@tik.ee.ethz.ch> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2K7n+6X3efCDK4t1LQ48eMys8WG1VNY LN5/5rdYffMDm8WtljOMFnub/C1etyxjcmD3mPJ7I6vHzll32T2WLPnJ5LF69UNmj78XWtk8 jn34yhbAFsVlk5Kak1mWWqRvl8CVcbj9JFvBXd6KT41/2RoY53F3MXJySAiYSGzrXcgIYYtJ XLi3nq2LkYtDSOAwo8TXo93MEM5aRon7TW+AMhwcbAI2Eo8X+4E0CAskS3zbcYMFxBYRcJOY t2o9K0T9TUaJn6+3gjUzC/xhlFiyaRrYCn4BSYkNDbuZQWxeAW2Jpfv2MYHYLAKqEgsaZoDV iApESBzu7GKHqBGUODnzCdgGTgEdifu/9oLZzAIWEjPnn2eEsLUlli18zQxynJCArkTXy7gJ jEKzkHTPQtIxC0nHAkbmVYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiB8XFwy2/dHYyrXzse YhTgYFTi4d3w92yYEGtiWXFl7iFGCQ5mJRHe84vPhQnxpiRWVqUW5ccXleakFh9ilOZgURLn XeO8PkxIID2xJDU7NbUgtQgmy8TBKdXA2PHaKTrH0GGHThPbnJUmT7Q1b9/Xj7xQe/Gdf1Zs 0QVt37obRnlSdjNEOualOXJHWij+efxN6Z/D4z+V6m8COK9cY+DL+socY7DPLLvO1PaVLBfr m4Cw/PQ5wpV9x80/275hD9hst0blhp2OV800DvW6n1uOi6wW51q0atLc2wbdt9Lq/s1XYinO SDTUYi4qTgQAUzeULosCAAA= Archived-At: Cc: Safiqul Islam , "rmcat@ietf.org" , "mramalho@cisco.com" , =?UTF-8?Q?Anna_Brunstr=c3=b6m?= , Varun Singh , Xiaoqing Zhu Subject: Re: [rmcat] test cases for coupled cc [was: Re: Review of draft-ietf-rmcat-eval-test-02] X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 08:31:52 -0000 On 2016-02-24 12:01, Mirja K=C3=BChlewind wrote: > Hi Zahed, > > quickly on this point: > > On 10.02.2016 10:24, Zaheduzzaman Sarker wrote: >>> >I believe we decided already at the last meeting that we need to >>> >adapt this draft to include uses cases for coupled congestion (and >>> >that=E2=80=99s why we asked Safiqul to propose some). >> That is what I can also recall but didn't see anything in the meeting >> minutes so was not sure what we agreed on. May be missed it in the >> meeting minutes. > > I guess there was no official decision of the wg to include text for > coupled-cc, however, Safiqul volunteered to provide some input here and= > I don't recall that there have been any objections to include this. I > also don't see how this could be a problem. I didn't see this as a problem however I had some confusions and=20 questions those needed to be clarified. > > I agree with you and Safiqul that we don't need to consider coupled-cc > for all test cases; only where it makes sense (e.g. test cases with one= > flow do not make any sense...) > > If anybody has a different opinion, please speak up now! > > Mirja --=20 Zahed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= ANM ZAHEDUZZAMAN SARKER Ericsson AB Services, Media and Network Features Laboratoriegr=C3=A4nd 11 97128 Lule=C3=A5, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= From nobody Thu Feb 25 01:03:26 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7CB1A875E for ; Thu, 25 Feb 2016 01:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bztg_w0kfTIF for ; Thu, 25 Feb 2016 01:03:23 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03F91A8759 for ; Thu, 25 Feb 2016 01:03:22 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-f7-56cec3584996 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BD.97.28465.853CEC65; Thu, 25 Feb 2016 10:03:20 +0100 (CET) Received: from [150.132.142.224] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.248.2; Thu, 25 Feb 2016 10:03:19 +0100 To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <170F0EA5-EAB0-4B01-A8DF-56A0B2923A9A@ifi.uio.no> <56AA17AD.8060806@ericsson.com> <56BB01D5.5040902@ericsson.com> <56C312A9.1000609@ericsson.com> <56CD8EA6.9010603@tik.ee.ethz.ch> From: Zaheduzzaman Sarker Organization: Ericsson AB Message-ID: <56CEC358.9060103@ericsson.com> Date: Thu, 25 Feb 2016 10:03:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56CD8EA6.9010603@tik.ee.ethz.ch> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM2K7vW7E4XNhBo1zjC1+nN3JarFh9RQW i9U3P7A5MHssWfKTyWP16ofMHsc+fGULYI7isklJzcksSy3St0vgyjj2PLDgKFfFktnbmRsY V3N0MXJySAiYSLxr3cgKYYtJXLi3ng3EFhI4zCjxZ5VeFyMXkL2WUeLikZ1gCWGBZIk3F28z gdgiAm4S81atZ4Uoes4k8XH9K3aQBLOAp8TZb0+Aijg42ARsJB4v9gMJ8wtISmxo2M0MYvMK aEusXvKSEcRmEVCV2LfjFtgRogIREoc7u9ghagQlTs58wgJicwroSaztecIMMd5CYub884wQ trbEsoWvmUFWCQnoSnS9jJvAKDQLSfcsJB2zkHQsYGRexShanFpcnJtuZKyXWpSZXFycn6eX l1qyiREY1ge3/Nbdwbj6teMhRgEORiUe3g1/z4YJsSaWFVfmHmKU4GBWEuG13HsuTIg3JbGy KrUoP76oNCe1+BCjNAeLkjjvGuf1YUIC6YklqdmpqQWpRTBZJg5OqQZG22KuJ3OWPFoXvnTK K2/HhsgweWlpdZcnV8ollmea3CvJm6DrPO0Fk0ShZtvNV7sMl7X2fv+8QeaI5M58SasPYSIB rF7KezxeyjV3z9OKS9mVNjth4srnJY1L7IwuV8cwPFyyc86udw84215uets2/c79jfufHD6y lz/y6WKv2D8x1/dv+tV6UomlOCPRUIu5qDgRAO0ROmZnAgAA Archived-At: Cc: "rmcat@ietf.org" , Michael Welzl Subject: Re: [rmcat] test cases for coupled cc [was: Re: Review of draft-ietf-rmcat-eval-test-02] X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 09:03:25 -0000 Hi Mirja, Please see inline below. BR Zahed On 02/24/2016 12:06 PM, Mirja K=C3=BChlewind wrote: > Hi Zahed, > > I agree with Michael. My view is here that we need to evaluate each=20 > combination of a certain scheme to couple things using a certain=20 > congestion control algorithm separately.=20 Fine. but again what exactly are we supposed to evaluate? the=20 performance of the congestion control algorithm or the performance of=20 the coupled congestion control algorithm? or something else. > That means, if someone proposes a new (generic) scheme for coupling,=20 > we as a group would only advise to use this scheme with a certain cc=20 > algorithm if we have seen results for this specific combination. Does=20 > this make sense to you? Kind of, this means it is fine to have a coupled congestion control that = may not work will all the combinations even if RMCAT proposes more that=20 one congestion control algorithms. I didnt get the "generic" part though. How can the WG call a coupled=20 congestion "generic" even if that fails to show results with all the=20 RMCAT CC algorithms (assuming RMCAT has proposed more than one CC=20 algorithms)? > > > I hope this also reflects the view of the wg. If not, please let us=20 > now and we would need to discuss this again. > > Mirja > > From nobody Thu Feb 25 07:58:06 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9B01B2B77 for ; Thu, 25 Feb 2016 07:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44sozzmm-FxW for ; Thu, 25 Feb 2016 07:58:02 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E977B1B2B5A for ; Thu, 25 Feb 2016 07:58:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 576AED9316; Thu, 25 Feb 2016 16:58:00 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mCSz0kiWtJU4; Thu, 25 Feb 2016 16:58:00 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 11408D930C; Thu, 25 Feb 2016 16:58:00 +0100 (MET) To: "Mo Zanaty (mzanaty)" , "Michael Ramalho (mramalho)" , "rmcat WG (rmcat@ietf.org)" References: <56CD9488.8020705@tik.ee.ethz.ch> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <56CF2486.3040004@tik.ee.ethz.ch> Date: Thu, 25 Feb 2016 16:57:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rmcat] Review of rmcat-cc-codec-interactions X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 15:58:05 -0000 Hi Mo, again individual comments: You are actually right that for the initial rate, allowed rate is enough as an interface. I can see that the start up behavior would be interesting, but I don't understand how you define this in an interface. Would you say something like 'I use slow start' or 'I will increase by x [some unit] within x ms'. However, even if you say something like this, it's still no promise that the codec can rely on because there simply might be congestion. So not sure how useful this is. However, if we keep this ramp, we need to be much more clear about what this means. My other point actually was/is that I don't think we really need a negotiation here (as currently described in the text); it's enough to have an interface that signals the intended behavior from the cc to the codec. Or have you been thinking about something like 'I support slow start and this alternative algo' and the the codec say 'please take the alternative'...? This sound very complicated to me. Mirja On 24.02.2016 23:52, Mo Zanaty (mzanaty) wrote: > Hi Mirja, > > Startup "Ramp" refers to rate (or window) increase over time at startup, not > just the initial rate/window. The old app-interaction draft described this in > section 5 (Interfaces and Interactions), but we were asked to remove this in > the new cc-codec-interactions draft. Should we add this back? > > https://tools.ietf.org/html/draft-ietf-rmcat-app-interaction-01#section-5 > > o Startup Ramp (CC-Codec): Initial rate (or number of packets in > window-based CC proposals) and strategy for increasing the rate > (or window) during media startup, similar to TCP intial congestion > window and slow start. See Section 5.4.3 for details. > > While an initial window may be sufficient for TCP apps, it can be > insufficient for codecs at startup. A codec can make many different (more > intelligent) decisions at startup depending on the target ramp, versus > usually making very poor decisions if only an initial rate is given. > > If the only cc-codec interaction at startup is an initial rate, then Allowed > Rate can already capture that interaction without anything special needed for > startup. However, startup is indeed special because the initial rate is very > transient and rapid increase is expected. Codecs can make better decisions if > they are aware of the CC startup dynamics. > > For example, if the codec is only told 300 kbps, it may adapt to a very low > resolution like CIF with poor quantization in order to maintain a stable, > moderate frame rate at 300 kbps. If instead it is told 300 kbps ramping up > geometrically to 2.5 Mbps in 0.5 seconds, it may target HD 1080p with better > quantization and pace the initial frame over a longer time until the startup > rate stabilizes before attempting full frame rate. > > Cheers, > Mo > > > On 2/24/16, 6:31 AM, Mirja Kühlewind > wrote: > > Hi Mo, hi Michael, > > two comments as individual: > > Reading this text part now, I don't think we need to negotiate the startup > ramp. Actually I'm not even sure what the term 'ramp' is supposed to mean > here. I believe we need is to indicate the maximum initial sending rate from > the cc to the codec. If the codec then delivers data with a lower rate that > should not be a problem for the cc. And the initial (max) sending can solely > be chosen by the cc, as it might either use a default value or some cached > info from previous transmission to the same receiver (over the same access > network). > > Further, I agree that it is good to add one sentence that this rate has to be > chosen carefully (and a different value than a conservative default can only > be used if further information about or from the network is available). But I > don't really understand what exactly you want say with the two sentences that > you have added below...? > > Mirja > > > On 16.02.2016 22:59, Michael Ramalho (mramalho) wrote: > > All, > > I have reviewed draft-zanaty-rmcat-cc-codec-interactions. My only comments > concern Section 5.2.2 (Startup Ramp). > > In what follows I have added two sentences and modified a sentence in this > section. > > ****EXISTING TEXT**** > > 5.2.2. Startup Ramp > > Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an > important moment in a conversation. Rapid rate adaptation during startup is > therefore important. The codec should minimize its startup media rate as > much as possible without adversely impacting the user experience, and support > a strategy for rapid rate ramp. The CC should allow the highest startup > media rate as possible without adversely impacting network conditions, and > also support rapid rate ramp until stabilizing on the available bandwidth. > Startup can be viewed as a negotiation between the codec and the CC. The > codec requests a startup rate and ramp, and the CC responds with the > allowable parameters which may be lower/slower. The RMCAT requirements also > include the possibility of bandwidth history to further accelerate or even > eliminate startup ramp time. While this is highly desirable from an > application viewpoint, it may be less acceptable to network operators, since > it is in essence a gamble on current congestion state matching historical > state, with the potential for significant congestion contribution if the > gamble was wrong. Note that startup can often commence before user > interaction or conversation to reduce the chance of clipped media. > > ****EXISTING TEXT**** > > ****PROPOSED TEXT**** > > 5.2.2. Startup Ramp > > Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an > important moment in a conversation. Rapid rate adaptation during startup is > therefore important. The codec should minimize its startup media rate as > much as possible without adversely impacting the user experience, and support > a strategy for rapid rate ramp. The CC should allow the highest startup > media rate as possible without adversely impacting network conditions, and > also support rapid rate ramp until stabilizing on the available bandwidth. > Startup can be viewed as a negotiation between the codec and the CC. The > specification of the ramp may take a number of forms depending on the > interface to the codec; for example, a percentage bit rate increase per RTT > (or other time interval), or an increased transmit window (in number of > packets and/or octets allowed outstanding) are all potential forms. The > codec requests a startup rate and ramp, and the CC responds with the > allowable parameters which may be lower/slower. The RMCAT requirements also > include the possibility of bandwidth history to further accelerate or even > eliminate startup ramp time. While this acceleration or elimination in ramp > time is beneficial to the session user experience when bandwidth is > sufficient, it can be detrimental if significant congestion results (the user > experience of this session and all other sessions traversing the point of > congestion may unnecessarily degrade). Therefore, it is recommended that use > of potentially stale congestion state for acceleration or elimination in ramp > up be limited to topologies or deployments believed to have sufficient > bandwidth margin or those in which the potential transient congestion risk is > acceptable. Note that startup can often commence before user interaction or > conversation to reduce the chance of clipped media. > > ****PROPOSED TEXT**** > > The modification deletes the reference to “network operators”, as I think the > point may be made that many network administrators (be they service providers > or other “network operators”) or network designers/sizers would also have the > same concern. > > I have reviewed this change with the present authors and they generally > approve of it. Other edits are welcome. > > Regards, > > Michael A. Ramalho, Ph.D. > > From nobody Thu Feb 25 08:12:54 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B141B2C41 for ; Thu, 25 Feb 2016 08:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mh8G_Mamb7hN for ; Thu, 25 Feb 2016 08:12:50 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2306B1B2C49 for ; Thu, 25 Feb 2016 08:12:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 50EB2D9317; Thu, 25 Feb 2016 17:12:48 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1zJjncPX3XB7; Thu, 25 Feb 2016 17:12:48 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 0379BD9316; Thu, 25 Feb 2016 17:12:48 +0100 (MET) To: Zaheduzzaman Sarker References: <170F0EA5-EAB0-4B01-A8DF-56A0B2923A9A@ifi.uio.no> <56AA17AD.8060806@ericsson.com> <56BB01D5.5040902@ericsson.com> <56CD8D9D.70803@tik.ee.ethz.ch> <56CEBBF3.4040708@ericsson.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <56CF27FE.8050800@tik.ee.ethz.ch> Date: Thu, 25 Feb 2016 17:12:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56CEBBF3.4040708@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Safiqul Islam , "rmcat@ietf.org" , "mramalho@cisco.com" , =?UTF-8?Q?Anna_Brunstr=c3=b6m?= , Varun Singh , Xiaoqing Zhu Subject: Re: [rmcat] test cases for coupled cc [was: Re: Review of draft-ietf-rmcat-eval-test-02] X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 16:12:52 -0000 Are your questions now clarified? If not, what exactly are the questions? On 25.02.2016 09:31, Zaheduzzaman Sarker wrote: > > > On 2016-02-24 12:01, Mirja Kühlewind wrote: >> Hi Zahed, >> >> quickly on this point: >> >> On 10.02.2016 10:24, Zaheduzzaman Sarker wrote: >>>>> I believe we decided already at the last meeting that we need to >>>>> adapt this draft to include uses cases for coupled congestion (and >>>>> that’s why we asked Safiqul to propose some). >>> That is what I can also recall but didn't see anything in the meeting >>> minutes so was not sure what we agreed on. May be missed it in the >>> meeting minutes. >> >> I guess there was no official decision of the wg to include text for >> coupled-cc, however, Safiqul volunteered to provide some input here and >> I don't recall that there have been any objections to include this. I >> also don't see how this could be a problem. > I didn't see this as a problem however I had some confusions and > questions those needed to be clarified. > >> >> I agree with you and Safiqul that we don't need to consider coupled-cc >> for all test cases; only where it makes sense (e.g. test cases with one >> flow do not make any sense...) >> >> If anybody has a different opinion, please speak up now! >> >> Mirja > From nobody Thu Feb 25 08:20:30 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE04A1B2C75 for ; Thu, 25 Feb 2016 08:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSpEcvmLiGqI for ; Thu, 25 Feb 2016 08:20:28 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7F291B2C73 for ; Thu, 25 Feb 2016 08:20:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7CE35D9316; Thu, 25 Feb 2016 17:20:25 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Gri-APrwGJp7; Thu, 25 Feb 2016 17:20:25 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 33DA6D930E; Thu, 25 Feb 2016 17:20:25 +0100 (MET) To: Zaheduzzaman Sarker References: <170F0EA5-EAB0-4B01-A8DF-56A0B2923A9A@ifi.uio.no> <56AA17AD.8060806@ericsson.com> <56BB01D5.5040902@ericsson.com> <56C312A9.1000609@ericsson.com> <56CD8EA6.9010603@tik.ee.ethz.ch> <56CEC358.9060103@ericsson.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <56CF29C7.20200@tik.ee.ethz.ch> Date: Thu, 25 Feb 2016 17:20:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56CEC358.9060103@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "rmcat@ietf.org" , Michael Welzl Subject: Re: [rmcat] test cases for coupled cc [was: Re: Review of draft-ietf-rmcat-eval-test-02] X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 16:20:29 -0000 Hi Zahed, see inline. On 25.02.2016 10:03, Zaheduzzaman Sarker wrote: > Hi Mirja, > > Please see inline below. > > BR > > Zahed > > > > On 02/24/2016 12:06 PM, Mirja Kühlewind wrote: >> Hi Zahed, >> >> I agree with Michael. My view is here that we need to evaluate each >> combination of a certain scheme to couple things using a certain >> congestion control algorithm separately. > Fine. but again what exactly are we supposed to evaluate? the > performance of the congestion control algorithm or the performance of > the coupled congestion control algorithm? or something else. The performance of the combined system of the coupling algo and the selected cc aglo. >> That means, if someone proposes a new (generic) scheme for coupling, >> we as a group would only advise to use this scheme with a certain cc >> algorithm if we have seen results for this specific combination. Does >> this make sense to you? > Kind of, this means it is fine to have a coupled congestion control that > may not work will all the combinations even if RMCAT proposes more that > one congestion control algorithms. Yes (as long as this is clearly stated in the doc). > > I didnt get the "generic" part though. How can the WG call a coupled > congestion "generic" even if that fails to show results with all the > RMCAT CC algorithms (assuming RMCAT has proposed more than one CC > algorithms)? That's only a matter of how it is described in the doc. Basically you say, we describe this in a generic way, but it's only tested together with these algos. If you want use it with others, it might be possible, but you have to (adapt and) test it on your own. Important is that you have both in the same doc: the generic description and how it is applied to certain algos. Does that make sense? Or it this a problem for any of your work? I believe that is at least the approach we are currently taking for the coupled-cc draft that we have. Micheal, please speak up if you have a different view here! Mirja >> >> >> I hope this also reflects the view of the wg. If not, please let us >> now and we would need to discuss this again. >> >> Mirja >> >> > From nobody Thu Feb 25 09:42:40 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338B11A904D for ; Thu, 25 Feb 2016 09:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.207 X-Spam-Level: X-Spam-Status: No, score=-14.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzCYpAxS-FPg for ; Thu, 25 Feb 2016 09:42:36 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDCB1A6FFA for ; Thu, 25 Feb 2016 09:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2657; q=dns/txt; s=iport; t=1456422156; x=1457631756; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UAqFNz2ZUcIyf3icI4Tnu63vZs6ykpSkb9JfgTsWeNQ=; b=cSd/CvQ35i13JxHa2LG8HCibtWicmXx4IcglfCQsz9ueTbMFgLBhoxAM lswFG6YmEYmqhnZaHITJJxWDQfZTYd4ITBspo9VkjCPuWxKwkNt8sMiE5 vSJ6FqWA/mHZxSb6TZEeDHpdV+wyJv4Lu6z0JasGfypZI3yIJG17JgQKj 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DXCQCCPM9W/4sNJK1egzpSbQaFfaVPA?= =?us-ascii?q?QQBkFkhhWwCgUI7EQEBAQEBAQFkJ4RBAQEBBHkQAgEIEQQBAQEJJQ8jHQgCBAE?= =?us-ascii?q?NBYgfDr1VAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGEoQ6hAURARw0hAgFjWKJJ?= =?us-ascii?q?gGNXoFejRaFcohWATYsggMZgUhqAYZlNH4BAQE?= X-IronPort-AV: E=Sophos;i="5.22,498,1449532800"; d="scan'208";a="241850905" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Feb 2016 17:42:35 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u1PHgZFs005368 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Feb 2016 17:42:35 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 25 Feb 2016 11:42:35 -0600 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1104.009; Thu, 25 Feb 2016 11:42:35 -0600 From: "Xiaoqing Zhu (xiaoqzhu)" To: Zaheduzzaman Sarker , =?iso-8859-1?Q?Mirja_K=FChlewind?= Thread-Topic: [rmcat] Wireless test cases Thread-Index: AQHRaNy/VapPwARipkaYL6fylYsp7Z8z0rMzgAeuggD///D6r4AAaxCAgAD2roCAAEFM0A== Date: Thu, 25 Feb 2016 17:42:35 +0000 Message-ID: <1456422154539.54776@cisco.com> References: <6902D83B-55B3-4D22-8B37-A71A89720DDF@tik.ee.ethz.ch> <1455913631142.29407@cisco.com> <56CD9506.7080902@tik.ee.ethz.ch> <1456332600778.99326@cisco.com> <41376CF6-1F97-45A5-A8E3-186DBB1219ED@tik.ee.ethz.ch>, <56CEB129.10307@ericsson.com> In-Reply-To: <56CEB129.10307@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.248.82] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rmcat WG \(rmcat@ietf.org\)" , =?iso-8859-1?Q?Anna_Brunstr=F6m?= Subject: Re: [rmcat] Wireless test cases X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 17:42:39 -0000 Thanks for the pointer, Zahed. That's a good place to start. Would it be = possible for you to share your NS-3 code/script for testing SCReAM over LTE= ? =0A= =0A= BTW, you may want to update the corresponding link in the wireless-test-cas= e document. Currently, the reference on [LTE-simulator] points to the NS-3 = manual.=0A= =0A= Best,=0A= Xiaoqing=0A= =0A= ________________________________________=0A= From: Zaheduzzaman Sarker =0A= Sent: Wednesday, February 24, 2016 11:45 PM=0A= To: Mirja K=FChlewind; Xiaoqing Zhu (xiaoqzhu)=0A= Cc: rmcat WG (rmcat@ietf.org); Anna Brunstr=F6m=0A= Subject: Re: [rmcat] Wireless test cases=0A= =0A= Yes,=0A= =0A= NS-3 has necessary modules to run LTE simulations.=0A= =0A= https://www.nsnam.org/docs/models/html/lte.html=0A= =0A= BR=0A= =0A= Zahed=0A= =0A= On 02/24/2016 06:02 PM, Mirja K=FChlewind wrote:=0A= > Hi Xiaoqing,=0A= >=0A= >> Am 24.02.2016 um 17:50 schrieb Xiaoqing Zhu (xiaoqzhu) :=0A= >>=0A= >> Hi Mirja, all,=0A= >>=0A= >> Zahed and I have indeed discussed about this in Yokohama. Maybe I did no= t make it clear in my previous email, trying again.=0A= >>=0A= >> Basically, to carry out tests in Sec 3 (Cellular Network Specific Test C= ases), one needs to run it over a module that simulates packet behavior ove= r cellular links -- just like for the Wi-Fi portion of the test cases, we r= elied on the Wi-Fi module in NS3 simulators to do so.=0A= >>=0A= >> What is missing is the cellular network simulator, preferably as a plug-= in module for NS3, over which we can run rate adaptation tests.=0A= > I though that this is available in the mean time.=0A= >=0A= > Zahed, do you have link or is this already included in the latest version= of ns-3?=0A= >=0A= > Mirja=0A= >=0A= >=0A= >> Thanks,=0A= >> Xiaoqing=0A= >>=0A= >>=0A= >> ________________________________________=0A= >> From: Mirja K=FChlewind =0A= >> Sent: Wednesday, February 24, 2016 3:33 AM=0A= >> To: Xiaoqing Zhu (xiaoqzhu); rmcat WG (rmcat@ietf.org)=0A= >> Cc: Anna Brunstr=F6m; Zaheduzzaman Sarker=0A= >> Subject: Re: [rmcat] Wireless test cases=0A= >>=0A= >> Hi Xiaoqing,=0A= >>=0A= >> On 19.02.2016 21:27, Xiaoqing Zhu (xiaoqzhu) wrote:=0A= >>> As for Sec. 3 on Cellular Network Specific Test Cases, would appreciate= =0A= >>> more detailed information on how to set those up, or relevant pointers/= code=0A= >>> on cellular network simulators.=0A= >> Can you let us/Zahed know what exactly you need/is missing?=0A= >>=0A= >> Thanks,=0A= >> Mirja=0A= =0A= =0A= From nobody Thu Feb 25 23:51:36 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4541ACE60 for ; Thu, 25 Feb 2016 23:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyEa0tuTDK1U for ; Thu, 25 Feb 2016 23:51:32 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1E41ACE5D for ; Thu, 25 Feb 2016 23:51:32 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-6b-56d00402644e Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E7.F9.15637.20400D65; Fri, 26 Feb 2016 08:51:30 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.43]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0248.002; Fri, 26 Feb 2016 08:51:29 +0100 From: Zaheduzzaman Sarker To: "Xiaoqing Zhu (xiaoqzhu)" , =?iso-8859-1?Q?Mirja_K=FChlewind?= Thread-Topic: [rmcat] Wireless test cases Thread-Index: AQHRaNy93yyeJ8RdHEqMqFOo52opxJ8zxVWAgAdGhwCAAFhzAIAAA5eAgAEHcoCAAJX9gIAA/EPg Date: Fri, 26 Feb 2016 07:51:29 +0000 Message-ID: References: <6902D83B-55B3-4D22-8B37-A71A89720DDF@tik.ee.ethz.ch> <1455913631142.29407@cisco.com> <56CD9506.7080902@tik.ee.ethz.ch> <1456332600778.99326@cisco.com> <41376CF6-1F97-45A5-A8E3-186DBB1219ED@tik.ee.ethz.ch>, <56CEB129.10307@ericsson.com> <1456422154539.54776@cisco.com> In-Reply-To: <1456422154539.54776@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7qC4Ty4Uwg3/3ZCxO/LjMbLFh9RQW i9U3P7BZvG5ZxuTA4jHl90ZWjyVLfjJ5/L3QyuZx7MNXtgCWKC6blNSczLLUIn27BK6Mg8uD C45JVDTPuM/SwHhYuIuRg0NCwETizxuvLkZOIFNM4sK99WxdjFwcQgKHGSUet59lgnAWM0rc 3PGQGaSBTcBG4vFiP5AGEYEqiU9r7jKB2MwCuRL3P3xgB7GFBTQkHs1qYoOo0ZQ4PbUNyo6S uL3+MCOIzSKgKrF++UlWkJG8Ar4Szx6mQKyazyRx9fwFFpAaTgEdiWt/loLNZwQ67vupNVC7 xCVuPZnPBHG0gMSSPeeZIWxRiZeP/7FC2IoS7U8bGCHq9SRuTJ3CBmFrSyxb+BqsnldAUOLk zCcsExjFZiEZOwtJyywkLbOQtCxgZFnFKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERhjB7f8 Vt3BePmN4yFGAQ5GJR7eD9/PhwmxJpYVV+YeYpTgYFYS4eX6CxTiTUmsrEotyo8vKs1JLT7E KM3BoiTOu8Z5fZiQQHpiSWp2ampBahFMlomDU6qBMfjQpNoc2Z51yttjI62YThp2OvZvSTgx 5fGVVbmZEsdm3fFZ5J540fzUp4ddma3hChstLjALdPW//Dg17q/yG/F8a4aQtG0Ppk5ak/j6 wZqgmjL+vxF3zikvbX/EmPP97dKphz8bb7k5u0PBfaeQ/suKqqXa2sp5BwK0uZOKN+3O1ryd otzso8RSnJFoqMVcVJwIADctEdmtAgAA Archived-At: Cc: "rmcat WG \(rmcat@ietf.org\)" , =?iso-8859-1?Q?Anna_Brunstr=F6m?= Subject: Re: [rmcat] Wireless test cases X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 07:51:34 -0000 Hi, We didn't used NS-3 simulator to evaluation SCReAM over LTE, we used our pr= oprietary simulator. However, I have looked into the NS-3 simulator and talked with the LTE modu= le implementer of NS-3 (LUNA). My conclusion is, the draft can be realized = in the NS-3 simulator. BR Zahed=20 > -----Original Message----- > From: Xiaoqing Zhu (xiaoqzhu) [mailto:xiaoqzhu@cisco.com] > Sent: den 25 februari 2016 18:43 > To: Zaheduzzaman Sarker; Mirja K=FChlewind > Cc: rmcat WG (rmcat@ietf.org); Anna Brunstr=F6m > Subject: Re: [rmcat] Wireless test cases >=20 > Thanks for the pointer, Zahed. That's a good place to start. Would it b= e > possible for you to share your NS-3 code/script for testing SCReAM over L= TE? >=20 > BTW, you may want to update the corresponding link in the wireless-test-c= ase > document. Currently, the reference on [LTE-simulator] points to the NS-3 > manual. >=20 > Best, > Xiaoqing >=20 > ________________________________________ > From: Zaheduzzaman Sarker > Sent: Wednesday, February 24, 2016 11:45 PM > To: Mirja K=FChlewind; Xiaoqing Zhu (xiaoqzhu) > Cc: rmcat WG (rmcat@ietf.org); Anna Brunstr=F6m > Subject: Re: [rmcat] Wireless test cases >=20 > Yes, >=20 > NS-3 has necessary modules to run LTE simulations. >=20 > https://www.nsnam.org/docs/models/html/lte.html >=20 > BR >=20 > Zahed >=20 > On 02/24/2016 06:02 PM, Mirja K=FChlewind wrote: > > Hi Xiaoqing, > > > >> Am 24.02.2016 um 17:50 schrieb Xiaoqing Zhu (xiaoqzhu) > : > >> > >> Hi Mirja, all, > >> > >> Zahed and I have indeed discussed about this in Yokohama. Maybe I did = not > make it clear in my previous email, trying again. > >> > >> Basically, to carry out tests in Sec 3 (Cellular Network Specific Test= Cases), > one needs to run it over a module that simulates packet behavior over cel= lular > links -- just like for the Wi-Fi portion of the test cases, we relied on = the Wi-Fi > module in NS3 simulators to do so. > >> > >> What is missing is the cellular network simulator, preferably as a plu= g-in > module for NS3, over which we can run rate adaptation tests. > > I though that this is available in the mean time. > > > > Zahed, do you have link or is this already included in the latest versi= on of ns- > 3? > > > > Mirja > > > > > >> Thanks, > >> Xiaoqing > >> > >> > >> ________________________________________ > >> From: Mirja K=FChlewind > >> Sent: Wednesday, February 24, 2016 3:33 AM > >> To: Xiaoqing Zhu (xiaoqzhu); rmcat WG (rmcat@ietf.org) > >> Cc: Anna Brunstr=F6m; Zaheduzzaman Sarker > >> Subject: Re: [rmcat] Wireless test cases > >> > >> Hi Xiaoqing, > >> > >> On 19.02.2016 21:27, Xiaoqing Zhu (xiaoqzhu) wrote: > >>> As for Sec. 3 on Cellular Network Specific Test Cases, would > >>> appreciate more detailed information on how to set those up, or > >>> relevant pointers/code on cellular network simulators. > >> Can you let us/Zahed know what exactly you need/is missing? > >> > >> Thanks, > >> Mirja >=20 From nobody Fri Feb 26 00:03:24 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC7B1A0381 for ; Fri, 26 Feb 2016 00:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1_afO2u5KVq for ; Fri, 26 Feb 2016 00:03:22 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96AAB1A0371 for ; Fri, 26 Feb 2016 00:03:21 -0800 (PST) X-AuditID: c1b4fb30-f79ec6d000002212-45-56d006c77c47 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C0.98.08722.7C600D65; Fri, 26 Feb 2016 09:03:19 +0100 (CET) Received: from [150.132.141.43] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.248.2; Fri, 26 Feb 2016 09:03:18 +0100 To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <170F0EA5-EAB0-4B01-A8DF-56A0B2923A9A@ifi.uio.no> <56AA17AD.8060806@ericsson.com> <56BB01D5.5040902@ericsson.com> <56CD8D9D.70803@tik.ee.ethz.ch> <56CEBBF3.4040708@ericsson.com> <56CF27FE.8050800@tik.ee.ethz.ch> From: Zaheduzzaman Sarker Organization: Ericsson AB Message-ID: <56D006C6.6050600@ericsson.com> Date: Fri, 26 Feb 2016 09:03:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CF27FE.8050800@tik.ee.ethz.ch> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2K7ru5xtgthBhunqluc+HGZ2WLD6iks Fu8/81usvvmBzeJWyxlGi71N/havW5YxObB7TPm9kdVj56y77B5Llvxk8li9+iGzx98LrWwe xz58ZQtgi+KySUnNySxLLdK3S+DKuHJkDmPBJP6KlSt72RoY23m6GDk5JARMJF60P2KDsMUk LtxbD2RzcQgJHGaUOL1wDjOEs4ZR4u+C6WBVwgLJEt923GABsUUE3CTmrVrPClE0l0niVkc7 E4jDLPCHUWLJpmmMXYwcHGwCNhKPF/uBNPALSEpsaNjNDGLzCmhLzL+4jQnEZhFQlejsvQEW FxWIkTj+7hwjRI2gxMmZT8CWcQroSbxe840dxGYWsJCYOf88I4QtL9G8dTYzyCohAV2Jrpdx ExiFZiHpnoWkYxaSjgWMzKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAuPj4JbfBjsYXz53 PMQowMGoxMP74fv5MCHWxLLiytxDjBIczEoivFx/gUK8KYmVValF+fFFpTmpxYcYpTlYlMR5 VzuvDxMSSE8sSc1OTS1ILYLJMnFwSjUwSupXWe4oKyu849TmcyQr8JsY2znPk2ptUptefeMW ev1kRwzD/2N6Ui815720LvykkHNJg3H5wQ0/up6xq18Jy2u+YMbN3+xY4J7Zp5lpFptz4Mdt t8O3vXQ7Lm458nPCNavJ04x3W7RlT7Ao6H9ke6y247I9p/CM7T/l8/eEOxoq7bvycKmLEktx RqKhFnNRcSIAQflN9osCAAA= Archived-At: Cc: Safiqul Islam , "rmcat@ietf.org" , "mramalho@cisco.com" , =?UTF-8?Q?Anna_Brunstr=c3=b6m?= , Varun Singh , Xiaoqing Zhu Subject: Re: [rmcat] test cases for coupled cc [was: Re: Review of draft-ietf-rmcat-eval-test-02] X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 08:03:23 -0000 Hi Mirja, I had my questions asked in the beginning of the this email thread (kind of repeated in other mails). Things got lot better now. Thanks. BR Zahed On 2016-02-25 17:12, Mirja Kühlewind wrote: > Are your questions now clarified? If not, what exactly are the questions? > > On 25.02.2016 09:31, Zaheduzzaman Sarker wrote: >> >> >> On 2016-02-24 12:01, Mirja Kühlewind wrote: >>> Hi Zahed, >>> >>> quickly on this point: >>> >>> On 10.02.2016 10:24, Zaheduzzaman Sarker wrote: >>>>>> I believe we decided already at the last meeting that we need to >>>>>> adapt this draft to include uses cases for coupled congestion (and >>>>>> that’s why we asked Safiqul to propose some). >>>> That is what I can also recall but didn't see anything in the meeting >>>> minutes so was not sure what we agreed on. May be missed it in the >>>> meeting minutes. >>> >>> I guess there was no official decision of the wg to include text for >>> coupled-cc, however, Safiqul volunteered to provide some input here and >>> I don't recall that there have been any objections to include this. I >>> also don't see how this could be a problem. >> I didn't see this as a problem however I had some confusions and >> questions those needed to be clarified. >> >>> >>> I agree with you and Safiqul that we don't need to consider coupled-cc >>> for all test cases; only where it makes sense (e.g. test cases with one >>> flow do not make any sense...) >>> >>> If anybody has a different opinion, please speak up now! >>> >>> Mirja >> -- Zahed ================================================== ANM ZAHEDUZZAMAN SARKER Ericsson AB Services, Media and Network Features Laboratoriegränd 11 97128 LuleÃ¥, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ================================================== From nobody Fri Feb 26 00:15:51 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB68E1A6FA3 for ; Fri, 26 Feb 2016 00:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WxWOpx8w_H0 for ; Fri, 26 Feb 2016 00:15:49 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA1151A21A9 for ; Fri, 26 Feb 2016 00:15:48 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-40-56d009b15c9c Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8C.C3.28465.1B900D65; Fri, 26 Feb 2016 09:15:46 +0100 (CET) Received: from [150.132.141.43] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.248.2; Fri, 26 Feb 2016 09:15:44 +0100 To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <170F0EA5-EAB0-4B01-A8DF-56A0B2923A9A@ifi.uio.no> <56AA17AD.8060806@ericsson.com> <56BB01D5.5040902@ericsson.com> <56C312A9.1000609@ericsson.com> <56CD8EA6.9010603@tik.ee.ethz.ch> <56CEC358.9060103@ericsson.com> <56CF29C7.20200@tik.ee.ethz.ch> From: Zaheduzzaman Sarker Organization: Ericsson AB Message-ID: <56D009B0.2030005@ericsson.com> Date: Fri, 26 Feb 2016 09:15:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CF29C7.20200@tik.ee.ethz.ch> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM2K7t+4mzgthBmsmS1v8OLuT1WLD6iks FqtvfmBzYPZYsuQnk8fq1Q+ZPY59+MoWwBzFZZOSmpNZllqkb5fAldEw7SxbQb94RfvfbsYG xi1CXYycHBICJhK3H11hhbDFJC7cW8/WxcjFISRwmFHiw9mFjBDOGkaJn4cesoBUCQskS7y5 eJsJxBYRcJOYt2o9K0TRSmaJSWfnM4MkmAU8Jc5+ewJUxMHBJmAj8XixH0iYX0BSYkPDbmaQ MK+AtsSahWogYRYBVYmHu2ewg9iiAjESx9+dYwSxeQUEJU7OfAK2llNAR+LF/uVMENMtJGbO P88IYctLNG+dDTZSSEBXoutl3ARGoVlIumch6ZiFpGMBI/MqRtHi1OLi3HQjY73Uoszk4uL8 PL281JJNjMDAPrjlt+4OxtWvHQ8xCnAwKvHwfvh+PkyINbGsuDL3EKMEB7OSCC/XX6AQb0pi ZVVqUX58UWlOavEhRmkOFiVx3jXO68OEBNITS1KzU1MLUotgskwcnFINjO5x7BuWPVj5J2fP gdSmeedZFR78/vF5qkBKjsrP+/uYT9wW2i/AvEi60cxzZUDyzvKy44+fXyidbrXs29GJymwy BRrzVrrNefj03Le5K/v2HnI9G/RVTtf4btnimZsP7Zp06OOFl8t2vdW/H/I1L5rLeyPj3fTu nkeP4/19fsf96f+uG/pyf4akEktxRqKhFnNRcSIAdTKlpWgCAAA= Archived-At: Cc: "rmcat@ietf.org" , Michael Welzl Subject: Re: [rmcat] test cases for coupled cc [was: Re: Review of draft-ietf-rmcat-eval-test-02] X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 08:15:50 -0000 On 2016-02-25 17:20, Mirja Kühlewind wrote: >>> >>> I agree with Michael. My view is here that we need to evaluate each >>> combination of a certain scheme to couple things using a certain >>> congestion control algorithm separately. >> Fine. but again what exactly are we supposed to evaluate? the >> performance of the congestion control algorithm or the performance of >> the coupled congestion control algorithm? or something else. > > The performance of the combined system of the coupling algo and the > selected cc aglo. ok, the current draft says "This document describes the test cases to be used in the performance evaluation of those candidate algorithms." as now we are talking about combined system, this needs to be changed I guess. right? but we need to clarify what this combined system means, I hope we are not leaning towards the whole RTC system evaluation. > >>> That means, if someone proposes a new (generic) scheme for coupling, >>> we as a group would only advise to use this scheme with a certain cc >>> algorithm if we have seen results for this specific combination. Does >>> this make sense to you? >> Kind of, this means it is fine to have a coupled congestion control that >> may not work will all the combinations even if RMCAT proposes more that >> one congestion control algorithms. > > Yes (as long as this is clearly stated in the doc). ok. but the eval-test draft doesn't need to clarify that, right? > >> >> I didnt get the "generic" part though. How can the WG call a coupled >> congestion "generic" even if that fails to show results with all the >> RMCAT CC algorithms (assuming RMCAT has proposed more than one CC >> algorithms)? > > That's only a matter of how it is described in the doc. Basically you > say, we describe this in a generic way, but it's only tested together > with these algos. If you want use it with others, it might be possible, > but you have to (adapt and) test it on your own. Important is that you > have both in the same doc: the generic description and how it is applied > to certain algos. Does that make sense? Or it this a problem for any of > your work? Ok so here "generic" does not mean the algorithm is generic, it points to the generic description of the coupled CC. No problem for any work as long as the above clarification text is not part of the eval-test draft. > > I believe that is at least the approach we are currently taking for the > coupled-cc draft that we have. Micheal, please speak up if you have a > different view here! > BR -- Zahed ================================================== ANM ZAHEDUZZAMAN SARKER Ericsson AB Services, Media and Network Features Laboratoriegränd 11 97128 LuleÃ¥, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ================================================== From nobody Fri Feb 26 00:55:50 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E501AD05D for ; Fri, 26 Feb 2016 00:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.984 X-Spam-Level: X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LR88Vm9NM9lc for ; Fri, 26 Feb 2016 00:55:41 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64121AD059 for ; Fri, 26 Feb 2016 00:55:39 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id xg9so30650048igb.1 for ; Fri, 26 Feb 2016 00:55:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=webrtc-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rLtz8kyZMGc71cIhb93XGOmy/7fFkyO0FYa38Cl9AC4=; b=gA+TS6Ntt0WhRBAylA7AV0h3YZT7/PFwZhkN0r1a231UcY4TywgENYaOB1zsibiv5O wqPdUo7GjncNkSlqVIAGsoQgZBCgLZQqtA35JWSzKiHGYHERBmUQDSAGfp6Lal5pmBIb FaMm1a246KAbNK5JbsUZD4XES/jfdrCWUvb9WjvHkVo2Li0UfoRDzR+keCP9xDLELxnk SIZdPYMv3VmhC59bwqIdl3XRrlBw8qjum3PAZQHrO+DSb0RHJHQlYMvWVLQWkzHbGOUg cFZ/HukSFKYJle7EiGe6avbyYX5LC057M1u+r4koBmQBu8Pnk7nvHyKHcIXoXNzgnU0S rxhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rLtz8kyZMGc71cIhb93XGOmy/7fFkyO0FYa38Cl9AC4=; b=LAJ4bsuSWF8IsEI63IRrqUmyL23Dx7Uv3s6cTk+c7kv3oMqIaPAMCVRpuX6xEfRosr KmiLqaDEtCAyNA4fwXeTbTKOfhfOgV4RHOjMwjMmgl5UM2L031BHCc4q7Mvo+onfrxR2 48s5ZyaK23Y8j4E27jX2AHLGMo9wuwR1JFMt70XoGuJm74REQJp/m+Eygxrpz9DTU5ui 7ykvHxz6g06SiI69dAQtxBrK79eqBUpA3mIyyXXipRk2D2Hcy9iFGHKaLUZXfP+OWKHg Hqe8udAEwBna9HVNuhR1YHl9eNyIUx2zL2s3qDLqyC7DZfpGYdy2YPGwEsYiEor1D/iS TQYA== X-Gm-Message-State: AD7BkJKo2+d4MoNa1yJRB2+9EIBNugR17VkuNjvt8HfkI4n9MdylNIQMncm7XPMVpv9OFUa2/PIlkJP9X35CV53J X-Received: by 10.50.87.7 with SMTP id t7mr1770053igz.65.1456476938825; Fri, 26 Feb 2016 00:55:38 -0800 (PST) MIME-Version: 1.0 References: <6902D83B-55B3-4D22-8B37-A71A89720DDF@tik.ee.ethz.ch> <1455913631142.29407@cisco.com> <56CD9506.7080902@tik.ee.ethz.ch> <1456332600778.99326@cisco.com> <41376CF6-1F97-45A5-A8E3-186DBB1219ED@tik.ee.ethz.ch> <56CEB129.10307@ericsson.com> <1456422154539.54776@cisco.com> In-Reply-To: From: Stefan Holmer Date: Fri, 26 Feb 2016 08:55:29 +0000 Message-ID: To: Zaheduzzaman Sarker , "Xiaoqing Zhu (xiaoqzhu)" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=047d7bf0c28e90549d052ca8760b Archived-At: Cc: "rmcat WG \(rmcat@ietf.org\)" , =?UTF-8?Q?Anna_Brunstr=C3=B6m?= Subject: Re: [rmcat] Wireless test cases X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 08:55:50 -0000 --047d7bf0c28e90549d052ca8760b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As a first step we'll probably look into at least some of the wifi test cases, but I don't know how soon we can have those done. Our current focus is on improving the loss-based part of GCC, and after that we can focus on further tests. If it's reasonably simple to run lte tests then it sounds good to run some of those too. If we can share code to set up NS3 for wifi and lte tests, that would be great. /Stefan On Fri, Feb 26, 2016 at 8:51 AM Zaheduzzaman Sarker < zaheduzzaman.sarker@ericsson.com> wrote: > Hi, > > We didn't used NS-3 simulator to evaluation SCReAM over LTE, we used our > proprietary simulator. > However, I have looked into the NS-3 simulator and talked with the LTE > module implementer of NS-3 (LUNA). My conclusion is, the draft can be > realized in the NS-3 simulator. > > BR > > Zahed > > > -----Original Message----- > > From: Xiaoqing Zhu (xiaoqzhu) [mailto:xiaoqzhu@cisco.com] > > Sent: den 25 februari 2016 18:43 > > To: Zaheduzzaman Sarker; Mirja K=C3=BChlewind > > Cc: rmcat WG (rmcat@ietf.org); Anna Brunstr=C3=B6m > > Subject: Re: [rmcat] Wireless test cases > > > > Thanks for the pointer, Zahed. That's a good place to start. Would it > be > > possible for you to share your NS-3 code/script for testing SCReAM over > LTE? > > > > BTW, you may want to update the corresponding link in the > wireless-test-case > > document. Currently, the reference on [LTE-simulator] points to the NS-= 3 > > manual. > > > > Best, > > Xiaoqing > > > > ________________________________________ > > From: Zaheduzzaman Sarker > > Sent: Wednesday, February 24, 2016 11:45 PM > > To: Mirja K=C3=BChlewind; Xiaoqing Zhu (xiaoqzhu) > > Cc: rmcat WG (rmcat@ietf.org); Anna Brunstr=C3=B6m > > Subject: Re: [rmcat] Wireless test cases > > > > Yes, > > > > NS-3 has necessary modules to run LTE simulations. > > > > https://www.nsnam.org/docs/models/html/lte.html > > > > BR > > > > Zahed > > > > On 02/24/2016 06:02 PM, Mirja K=C3=BChlewind wrote: > > > Hi Xiaoqing, > > > > > >> Am 24.02.2016 um 17:50 schrieb Xiaoqing Zhu (xiaoqzhu) > > : > > >> > > >> Hi Mirja, all, > > >> > > >> Zahed and I have indeed discussed about this in Yokohama. Maybe I di= d > not > > make it clear in my previous email, trying again. > > >> > > >> Basically, to carry out tests in Sec 3 (Cellular Network Specific > Test Cases), > > one needs to run it over a module that simulates packet behavior over > cellular > > links -- just like for the Wi-Fi portion of the test cases, we relied o= n > the Wi-Fi > > module in NS3 simulators to do so. > > >> > > >> What is missing is the cellular network simulator, preferably as a > plug-in > > module for NS3, over which we can run rate adaptation tests. > > > I though that this is available in the mean time. > > > > > > Zahed, do you have link or is this already included in the latest > version of ns- > > 3? > > > > > > Mirja > > > > > > > > >> Thanks, > > >> Xiaoqing > > >> > > >> > > >> ________________________________________ > > >> From: Mirja K=C3=BChlewind > > >> Sent: Wednesday, February 24, 2016 3:33 AM > > >> To: Xiaoqing Zhu (xiaoqzhu); rmcat WG (rmcat@ietf.org) > > >> Cc: Anna Brunstr=C3=B6m; Zaheduzzaman Sarker > > >> Subject: Re: [rmcat] Wireless test cases > > >> > > >> Hi Xiaoqing, > > >> > > >> On 19.02.2016 21:27, Xiaoqing Zhu (xiaoqzhu) wrote: > > >>> As for Sec. 3 on Cellular Network Specific Test Cases, would > > >>> appreciate more detailed information on how to set those up, or > > >>> relevant pointers/code on cellular network simulators. > > >> Can you let us/Zahed know what exactly you need/is missing? > > >> > > >> Thanks, > > >> Mirja > > > > --047d7bf0c28e90549d052ca8760b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    As a first step we'll probably look into at least some= of the wifi test cases, but I don't know how soon we can have those do= ne. Our current focus is on improving the loss-based part of GCC, and after= that we can focus on further tests.

    If it's reasona= bly simple to run lte tests then it sounds good to run some of those too. I= f we can share code to set up NS3 for wifi and lte tests, that would be gre= at.

    /Stefan

    On Fri, Feb 26, 2016 at 8:51 AM Zaheduzzaman Sarker &l= t;zaheduzzaman.sarker@e= ricsson.com> wrote:
    Hi,

    We didn't used NS-3 simulator to evaluation SCReAM over LTE, we used ou= r proprietary simulator.
    However, I have looked into the NS-3 simulator and talked with the LTE modu= le implementer of NS-3 (LUNA). My conclusion is, the draft can be realized = in the NS-3 simulator.

    BR

    Zahed

    > -----Original Message-----
    > From: Xiaoqing Zhu (xiaoqzhu) [mailto:xiaoqzhu@cisco.com]
    > Sent: den 25 februari 2016 18:43
    > To: Zaheduzzaman Sarker; Mirja K=C3=BChlewind
    > Cc: rmcat WG (rmca= t@ietf.org); Anna Brunstr=C3=B6m
    > Subject: Re: [rmcat] Wireless test cases
    >
    > Thanks for the pointer, Zahed.=C2=A0 That's a good place to start.= =C2=A0 Would it be
    > possible for you to share your NS-3 code/script for testing SCReAM ove= r LTE?
    >
    > BTW, you may want to update the corresponding link in the wireless-tes= t-case
    > document. Currently, the reference on [LTE-simulator] points to the NS= -3
    > manual.
    >
    > Best,
    > Xiaoqing
    >
    > ________________________________________
    > From: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
    > Sent: Wednesday, February 24, 2016 11:45 PM
    > To: Mirja K=C3=BChlewind; Xiaoqing Zhu (xiaoqzhu)
    > Cc: rmcat WG (rmca= t@ietf.org); Anna Brunstr=C3=B6m
    > Subject: Re: [rmcat] Wireless test cases
    >
    > Yes,
    >
    > NS-3 has necessary modules to run LTE simulations.
    >
    > https://www.nsnam.org/docs/models/html/lte.html<= /a>
    >
    > BR
    >
    > Zahed
    >
    > On 02/24/2016 06:02 PM, Mirja K=C3=BChlewind wrote:
    > > Hi Xiaoqing,
    > >
    > >> Am 24.02.2016 um 17:50 schrieb Xiaoqing Zhu (xiaoqzhu)
    > <    xiaoqzhu@c= isco.com>:
    > >>
    > >> Hi Mirja, all,
    > >>
    > >> Zahed and I have indeed discussed about this in Yokohama. May= be I did not
    > make it clear in my previous email, trying again.
    > >>
    > >> Basically, to carry out tests in Sec 3 (Cellular Network Spec= ific Test Cases),
    > one needs to run it over a module that simulates packet behavior over = cellular
    > links -- just like for the Wi-Fi portion of the test cases, we relied = on the Wi-Fi
    > module in NS3 simulators to do so.
    > >>
    > >> What is missing is the cellular network simulator, preferably= as a plug-in
    > module for NS3, over which we can run rate adaptation tests.
    > > I though that this is available in the mean time.
    > >
    > > Zahed, do you have link or is this already included in the latest= version of ns-
    > 3?
    > >
    > > Mirja
    > >
    > >
    > >> Thanks,
    > >> Xiaoqing
    > >>
    > >>
    > >> ________________________________________
    > >> From: Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch&= gt;
    > >> Sent: Wednesday, February 24, 2016 3:33 AM
    > >> To: Xiaoqing Zhu (xiaoqzhu); rmcat WG (rmcat@ietf.org)
    > >> Cc: Anna Brunstr=C3=B6m; Zaheduzzaman Sarker
    > >> Subject: Re: [rmcat] Wireless test cases
    > >>
    > >> Hi Xiaoqing,
    > >>
    > >> On 19.02.2016 21:27, Xiaoqing Zhu (xiaoqzhu) wrote:
    > >>> As for Sec. 3 on Cellular Network Specific Test Cases, wo= uld
    > >>> appreciate more detailed information on how to set those = up, or
    > >>> relevant pointers/code on cellular network simulators. > >> Can you let us/Zahed know what exactly you need/is missing? > >>
    > >> Thanks,
    > >> Mirja
    >

    --047d7bf0c28e90549d052ca8760b-- From nobody Fri Feb 26 08:50:42 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE15E1AD0AD for ; Fri, 26 Feb 2016 08:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.206 X-Spam-Level: X-Spam-Status: No, score=-14.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-QaoftxbYN7 for ; Fri, 26 Feb 2016 08:50:32 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D9C1AD0D0 for ; Fri, 26 Feb 2016 08:50:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15285; q=dns/txt; s=iport; t=1456505431; x=1457715031; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+HoEfDObFBhER0IHRiVX4wt8XgNhaIClKCahIsVebM4=; b=KzOid33JScfynUefRT4T8P1NmfWFsXOispgjNFIA7vmuvGHWr0vVkytO Vg4eHeLwKNP1qDf6QC5fhMNXzcABK7mdQftNjhFfiRwMycq4hlY85i6lg RqYGKtszI/6PO89Q6qAC+Y+uxmqT6lOfg77gH6+JVZgld1o6f/MXziYdH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3CAAMgdBW/4sNJK1egm5MUm0GhX6lX?= =?us-ascii?q?AEEAZBaIYVyAhyBKjsRAQEBAQEBAWQnhEEBAQEEI1YMBAIBCBEEAQEBCR4DAgI?= =?us-ascii?q?CDSMUCQgCBAENBYgfDq8UjloBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYSgz19h?= =?us-ascii?q?AURASUPFwmCSoE6BYswi1gBjV+BXo0WhXKIVgE2LIIDGYFIagGHGDR+AQEB?= X-IronPort-AV: E=Sophos; i="5.22,498,1449532800"; d="scan'208,217"; a="80069532" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Feb 2016 16:50:30 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u1QGoU8I005693 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Feb 2016 16:50:30 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 26 Feb 2016 10:50:29 -0600 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1104.009; Fri, 26 Feb 2016 10:50:30 -0600 From: "Xiaoqing Zhu (xiaoqzhu)" To: Stefan Holmer , Zaheduzzaman Sarker , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [rmcat] Wireless test cases Thread-Index: AQHRaNy/VapPwARipkaYL6fylYsp7Z8z0rMzgAeuggD///D6r4AAaxCAgAD2roCAAEFM0IABUqOAgAAR4YCAAB8TBg== Date: Fri, 26 Feb 2016 16:50:30 +0000 Message-ID: <1456505429198.23062@cisco.com> References: <6902D83B-55B3-4D22-8B37-A71A89720DDF@tik.ee.ethz.ch> <1455913631142.29407@cisco.com> <56CD9506.7080902@tik.ee.ethz.ch> <1456332600778.99326@cisco.com> <41376CF6-1F97-45A5-A8E3-186DBB1219ED@tik.ee.ethz.ch> <56CEB129.10307@ericsson.com> <1456422154539.54776@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.248.33] Content-Type: multipart/alternative; boundary="_000_145650542919823062ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rmcat WG \(rmcat@ietf.org\)" , =?utf-8?B?QW5uYSBCcnVuc3Ryw7Zt?= Subject: Re: [rmcat] Wireless test cases X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 16:50:35 -0000 --_000_145650542919823062ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCLSSB3aWxsIGxvb2sgaW50byBzaGFyaW5nIHRoZSBOUzMgY29kZS9zY3JpcHQgZm9yIFdpRmkg dGVzdHMuDQoNCg0KQXMgZm9yIExURSB0ZXN0IGNhc2VzOiAgaXQncyBnb29kIHRvIGtub3cgdGhh dCBpdCBjYW4gYmUgZG9uZS4gIEJ1dCwgc2luY2UgdGhlcmUgaXMgbm8gcHJlY2VkZW5jZSB0byBm b2xsb3csIHRoaXMgbWF5IHRha2Ugc3Vic3RhbnRpYWwgdGltZSBhbmQgZWZmb3J0LiBTbyB3ZSBt YXkgbm90IGdldCBhcm91bmQgdG8gdGFja2xlIHRoYXQgc29vbi4NCg0KDQpUaGFua3MsDQoNClhp YW9xaW5nDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogU3Rl ZmFuIEhvbG1lciA8c3RlZmFuQHdlYnJ0Yy5vcmc+DQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDI2 LCAyMDE2IDEyOjU1IEFNDQpUbzogWmFoZWR1enphbWFuIFNhcmtlcjsgWGlhb3FpbmcgWmh1ICh4 aWFvcXpodSk7IE1pcmphIEvDvGhsZXdpbmQNCkNjOiBybWNhdCBXRyAocm1jYXRAaWV0Zi5vcmcp OyBBbm5hIEJydW5zdHLDtm0NClN1YmplY3Q6IFJlOiBbcm1jYXRdIFdpcmVsZXNzIHRlc3QgY2Fz ZXMNCg0KQXMgYSBmaXJzdCBzdGVwIHdlJ2xsIHByb2JhYmx5IGxvb2sgaW50byBhdCBsZWFzdCBz b21lIG9mIHRoZSB3aWZpIHRlc3QgY2FzZXMsIGJ1dCBJIGRvbid0IGtub3cgaG93IHNvb24gd2Ug Y2FuIGhhdmUgdGhvc2UgZG9uZS4gT3VyIGN1cnJlbnQgZm9jdXMgaXMgb24gaW1wcm92aW5nIHRo ZSBsb3NzLWJhc2VkIHBhcnQgb2YgR0NDLCBhbmQgYWZ0ZXIgdGhhdCB3ZSBjYW4gZm9jdXMgb24g ZnVydGhlciB0ZXN0cy4NCg0KSWYgaXQncyByZWFzb25hYmx5IHNpbXBsZSB0byBydW4gbHRlIHRl c3RzIHRoZW4gaXQgc291bmRzIGdvb2QgdG8gcnVuIHNvbWUgb2YgdGhvc2UgdG9vLiBJZiB3ZSBj YW4gc2hhcmUgY29kZSB0byBzZXQgdXAgTlMzIGZvciB3aWZpIGFuZCBsdGUgdGVzdHMsIHRoYXQg d291bGQgYmUgZ3JlYXQuDQoNCi9TdGVmYW4NCg0KT24gRnJpLCBGZWIgMjYsIDIwMTYgYXQgODo1 MSBBTSBaYWhlZHV6emFtYW4gU2Fya2VyIDx6YWhlZHV6emFtYW4uc2Fya2VyQGVyaWNzc29uLmNv bTxtYWlsdG86emFoZWR1enphbWFuLnNhcmtlckBlcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpLA0K DQpXZSBkaWRuJ3QgdXNlZCBOUy0zIHNpbXVsYXRvciB0byBldmFsdWF0aW9uIFNDUmVBTSBvdmVy IExURSwgd2UgdXNlZCBvdXIgcHJvcHJpZXRhcnkgc2ltdWxhdG9yLg0KSG93ZXZlciwgSSBoYXZl IGxvb2tlZCBpbnRvIHRoZSBOUy0zIHNpbXVsYXRvciBhbmQgdGFsa2VkIHdpdGggdGhlIExURSBt b2R1bGUgaW1wbGVtZW50ZXIgb2YgTlMtMyAoTFVOQSkuIE15IGNvbmNsdXNpb24gaXMsIHRoZSBk cmFmdCBjYW4gYmUgcmVhbGl6ZWQgaW4gdGhlIE5TLTMgc2ltdWxhdG9yLg0KDQpCUg0KDQpaYWhl ZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFhpYW9xaW5nIFpodSAo eGlhb3F6aHUpIFttYWlsdG86eGlhb3F6aHVAY2lzY28uY29tPG1haWx0bzp4aWFvcXpodUBjaXNj by5jb20+XQ0KPiBTZW50OiBkZW4gMjUgZmVicnVhcmkgMjAxNiAxODo0Mw0KPiBUbzogWmFoZWR1 enphbWFuIFNhcmtlcjsgTWlyamEgS8O8aGxld2luZA0KPiBDYzogcm1jYXQgV0cgKHJtY2F0QGll dGYub3JnPG1haWx0bzpybWNhdEBpZXRmLm9yZz4pOyBBbm5hIEJydW5zdHLDtm0NCj4gU3ViamVj dDogUmU6IFtybWNhdF0gV2lyZWxlc3MgdGVzdCBjYXNlcw0KPg0KPiBUaGFua3MgZm9yIHRoZSBw b2ludGVyLCBaYWhlZC4gIFRoYXQncyBhIGdvb2QgcGxhY2UgdG8gc3RhcnQuICBXb3VsZCBpdCBi ZQ0KPiBwb3NzaWJsZSBmb3IgeW91IHRvIHNoYXJlIHlvdXIgTlMtMyBjb2RlL3NjcmlwdCBmb3Ig dGVzdGluZyBTQ1JlQU0gb3ZlciBMVEU/DQo+DQo+IEJUVywgeW91IG1heSB3YW50IHRvIHVwZGF0 ZSB0aGUgY29ycmVzcG9uZGluZyBsaW5rIGluIHRoZSB3aXJlbGVzcy10ZXN0LWNhc2UNCj4gZG9j dW1lbnQuIEN1cnJlbnRseSwgdGhlIHJlZmVyZW5jZSBvbiBbTFRFLXNpbXVsYXRvcl0gcG9pbnRz IHRvIHRoZSBOUy0zDQo+IG1hbnVhbC4NCj4NCj4gQmVzdCwNCj4gWGlhb3FpbmcNCj4NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBGcm9tOiBaYWhlZHV6emFt YW4gU2Fya2VyIDx6YWhlZHV6emFtYW4uc2Fya2VyQGVyaWNzc29uLmNvbTxtYWlsdG86emFoZWR1 enphbWFuLnNhcmtlckBlcmljc3Nvbi5jb20+Pg0KPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5 IDI0LCAyMDE2IDExOjQ1IFBNDQo+IFRvOiBNaXJqYSBLw7xobGV3aW5kOyBYaWFvcWluZyBaaHUg KHhpYW9xemh1KQ0KPiBDYzogcm1jYXQgV0cgKHJtY2F0QGlldGYub3JnPG1haWx0bzpybWNhdEBp ZXRmLm9yZz4pOyBBbm5hIEJydW5zdHLDtm0NCj4gU3ViamVjdDogUmU6IFtybWNhdF0gV2lyZWxl c3MgdGVzdCBjYXNlcw0KPg0KPiBZZXMsDQo+DQo+IE5TLTMgaGFzIG5lY2Vzc2FyeSBtb2R1bGVz IHRvIHJ1biBMVEUgc2ltdWxhdGlvbnMuDQo+DQo+IGh0dHBzOi8vd3d3Lm5zbmFtLm9yZy9kb2Nz L21vZGVscy9odG1sL2x0ZS5odG1sDQo+DQo+IEJSDQo+DQo+IFphaGVkDQo+DQo+IE9uIDAyLzI0 LzIwMTYgMDY6MDIgUE0sIE1pcmphIEvDvGhsZXdpbmQgd3JvdGU6DQo+ID4gSGkgWGlhb3Fpbmcs DQo+ID4NCj4gPj4gQW0gMjQuMDIuMjAxNiB1bSAxNzo1MCBzY2hyaWViIFhpYW9xaW5nIFpodSAo eGlhb3F6aHUpDQo+IDx4aWFvcXpodUBjaXNjby5jb208bWFpbHRvOnhpYW9xemh1QGNpc2NvLmNv bT4+Og0KPiA+Pg0KPiA+PiBIaSBNaXJqYSwgYWxsLA0KPiA+Pg0KPiA+PiBaYWhlZCBhbmQgSSBo YXZlIGluZGVlZCBkaXNjdXNzZWQgYWJvdXQgdGhpcyBpbiBZb2tvaGFtYS4gTWF5YmUgSSBkaWQg bm90DQo+IG1ha2UgaXQgY2xlYXIgaW4gbXkgcHJldmlvdXMgZW1haWwsIHRyeWluZyBhZ2Fpbi4N Cj4gPj4NCj4gPj4gQmFzaWNhbGx5LCB0byBjYXJyeSBvdXQgdGVzdHMgaW4gU2VjIDMgKENlbGx1 bGFyIE5ldHdvcmsgU3BlY2lmaWMgVGVzdCBDYXNlcyksDQo+IG9uZSBuZWVkcyB0byBydW4gaXQg b3ZlciBhIG1vZHVsZSB0aGF0IHNpbXVsYXRlcyBwYWNrZXQgYmVoYXZpb3Igb3ZlciBjZWxsdWxh cg0KPiBsaW5rcyAtLSBqdXN0IGxpa2UgZm9yIHRoZSBXaS1GaSBwb3J0aW9uIG9mIHRoZSB0ZXN0 IGNhc2VzLCB3ZSByZWxpZWQgb24gdGhlIFdpLUZpDQo+IG1vZHVsZSBpbiBOUzMgc2ltdWxhdG9y cyB0byBkbyBzby4NCj4gPj4NCj4gPj4gV2hhdCBpcyBtaXNzaW5nIGlzIHRoZSBjZWxsdWxhciBu ZXR3b3JrIHNpbXVsYXRvciwgcHJlZmVyYWJseSBhcyBhIHBsdWctaW4NCj4gbW9kdWxlIGZvciBO UzMsIG92ZXIgd2hpY2ggd2UgY2FuIHJ1biByYXRlIGFkYXB0YXRpb24gdGVzdHMuDQo+ID4gSSB0 aG91Z2ggdGhhdCB0aGlzIGlzIGF2YWlsYWJsZSBpbiB0aGUgbWVhbiB0aW1lLg0KPiA+DQo+ID4g WmFoZWQsIGRvIHlvdSBoYXZlIGxpbmsgb3IgaXMgdGhpcyBhbHJlYWR5IGluY2x1ZGVkIGluIHRo ZSBsYXRlc3QgdmVyc2lvbiBvZiBucy0NCj4gMz8NCj4gPg0KPiA+IE1pcmphDQo+ID4NCj4gPg0K PiA+PiBUaGFua3MsDQo+ID4+IFhpYW9xaW5nDQo+ID4+DQo+ID4+DQo+ID4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gRnJvbTogTWlyamEgS8O8aGxld2lu ZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaDxtYWlsdG86bWlyamEua3VlaGxld2lu ZEB0aWsuZWUuZXRoei5jaD4+DQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIw MTYgMzozMyBBTQ0KPiA+PiBUbzogWGlhb3FpbmcgWmh1ICh4aWFvcXpodSk7IHJtY2F0IFdHIChy bWNhdEBpZXRmLm9yZzxtYWlsdG86cm1jYXRAaWV0Zi5vcmc+KQ0KPiA+PiBDYzogQW5uYSBCcnVu c3Ryw7ZtOyBaYWhlZHV6emFtYW4gU2Fya2VyDQo+ID4+IFN1YmplY3Q6IFJlOiBbcm1jYXRdIFdp cmVsZXNzIHRlc3QgY2FzZXMNCj4gPj4NCj4gPj4gSGkgWGlhb3FpbmcsDQo+ID4+DQo+ID4+IE9u IDE5LjAyLjIwMTYgMjE6MjcsIFhpYW9xaW5nIFpodSAoeGlhb3F6aHUpIHdyb3RlOg0KPiA+Pj4g QXMgZm9yIFNlYy4gMyBvbiBDZWxsdWxhciBOZXR3b3JrIFNwZWNpZmljIFRlc3QgQ2FzZXMsIHdv dWxkDQo+ID4+PiBhcHByZWNpYXRlIG1vcmUgZGV0YWlsZWQgaW5mb3JtYXRpb24gb24gaG93IHRv IHNldCB0aG9zZSB1cCwgb3INCj4gPj4+IHJlbGV2YW50IHBvaW50ZXJzL2NvZGUgb24gY2VsbHVs YXIgbmV0d29yayBzaW11bGF0b3JzLg0KPiA+PiBDYW4geW91IGxldCB1cy9aYWhlZCBrbm93IHdo YXQgZXhhY3RseSB5b3UgbmVlZC9pcyBtaXNzaW5nPw0KPiA+Pg0KPiA+PiBUaGFua3MsDQo+ID4+ IE1pcmphDQo+DQoNCg== --_000_145650542919823062ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZSI+PCEtLSBwIHsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAw cHg7IH0tLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgZGlyPSJsdHIiIHN0eWxlPSJmb250LXNp emU6MTJwdDtjb2xvcjojMDAwMDAwO2JhY2tncm91bmQtY29sb3I6I0ZGRkZGRjtmb250LWZhbWls eTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmOyI+DQo8cD7igItJIHdpbGwgbG9v ayBpbnRvIHNoYXJpbmcgdGhlIE5TMyBjb2RlL3NjcmlwdCBmb3IgV2lGaSB0ZXN0cy4mbmJzcDs8 YnI+DQo8L3A+DQo8cD48YnI+DQo8L3A+DQo8cD5BcyBmb3IgTFRFIHRlc3QgY2FzZXM6ICZuYnNw O2l0J3MgZ29vZCB0byBrbm93IHRoYXQgaXQgY2FuIGJlIGRvbmUuICZuYnNwO0J1dCwgc2luY2Ug dGhlcmUgaXMgbm8gcHJlY2VkZW5jZSB0byBmb2xsb3csIHRoaXMgbWF5IHRha2Ugc3Vic3RhbnRp YWwgdGltZSBhbmQmbmJzcDtlZmZvcnQuIFNvIHdlIG1heSBub3QgZ2V0IGFyb3VuZCB0byB0YWNr bGUgdGhhdCBzb29uLjwvcD4NCjxwPjxicj4NCjwvcD4NCjxwPlRoYW5rcyw8L3A+DQo8cD5YaWFv cWluZzwvcD4NCjxwPiZuYnNwOzxicj4NCjwvcD4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMzMs IDMzLCAzMyk7Ij4NCjxociB0YWJpbmRleD0iLTEiIHN0eWxlPSJkaXNwbGF5OmlubGluZS1ibG9j azsgd2lkdGg6OTglIj4NCjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ciIGRpcj0ibHRyIj48Zm9udCBm YWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBjb2xvcj0iIzAwMDAwMCIgc3R5bGU9ImZvbnQtc2l6 ZToxMXB0Ij48Yj5Gcm9tOjwvYj4gU3RlZmFuIEhvbG1lciAmbHQ7c3RlZmFuQHdlYnJ0Yy5vcmcm Z3Q7PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRmVicnVhcnkgMjYsIDIwMTYgMTI6NTUgQU08 YnI+DQo8Yj5Ubzo8L2I+IFphaGVkdXp6YW1hbiBTYXJrZXI7IFhpYW9xaW5nIFpodSAoeGlhb3F6 aHUpOyBNaXJqYSBLw7xobGV3aW5kPGJyPg0KPGI+Q2M6PC9iPiBybWNhdCBXRyAocm1jYXRAaWV0 Zi5vcmcpOyBBbm5hIEJydW5zdHLDtm08YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtybWNhdF0g V2lyZWxlc3MgdGVzdCBjYXNlczwvZm9udD4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IGRpcj0ibHRyIj5BcyBhIGZpcnN0IHN0ZXAgd2UnbGwgcHJvYmFibHkgbG9vayBp bnRvIGF0IGxlYXN0IHNvbWUgb2YgdGhlIHdpZmkgdGVzdCBjYXNlcywgYnV0IEkgZG9uJ3Qga25v dyBob3cgc29vbiB3ZSBjYW4gaGF2ZSB0aG9zZSBkb25lLiBPdXIgY3VycmVudCBmb2N1cyBpcyBv biBpbXByb3ZpbmcgdGhlIGxvc3MtYmFzZWQgcGFydCBvZiBHQ0MsIGFuZCBhZnRlciB0aGF0IHdl IGNhbiBmb2N1cyBvbiBmdXJ0aGVyIHRlc3RzLg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SWYg aXQncyByZWFzb25hYmx5IHNpbXBsZSB0byBydW4gbHRlIHRlc3RzIHRoZW4gaXQgc291bmRzIGdv b2QgdG8gcnVuIHNvbWUgb2YgdGhvc2UgdG9vLiBJZiB3ZSBjYW4gc2hhcmUgY29kZSB0byBzZXQg dXAgTlMzIGZvciB3aWZpIGFuZCBsdGUgdGVzdHMsIHRoYXQgd291bGQgYmUgZ3JlYXQuPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4vU3RlZmFuPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjxk aXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiPk9uIEZyaSwgRmViIDI2LCAy MDE2IGF0IDg6NTEgQU0gWmFoZWR1enphbWFuIFNhcmtlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnph aGVkdXp6YW1hbi5zYXJrZXJAZXJpY3Nzb24uY29tIj56YWhlZHV6emFtYW4uc2Fya2VyQGVyaWNz c29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7IGJvcmRlci1sZWZ0OjFweCAjY2Nj IHNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCkhpLDxicj4NCjxicj4NCldlIGRpZG4ndCB1c2Vk IE5TLTMgc2ltdWxhdG9yIHRvIGV2YWx1YXRpb24gU0NSZUFNIG92ZXIgTFRFLCB3ZSB1c2VkIG91 ciBwcm9wcmlldGFyeSBzaW11bGF0b3IuPGJyPg0KSG93ZXZlciwgSSBoYXZlIGxvb2tlZCBpbnRv IHRoZSBOUy0zIHNpbXVsYXRvciBhbmQgdGFsa2VkIHdpdGggdGhlIExURSBtb2R1bGUgaW1wbGVt ZW50ZXIgb2YgTlMtMyAoTFVOQSkuIE15IGNvbmNsdXNpb24gaXMsIHRoZSBkcmFmdCBjYW4gYmUg cmVhbGl6ZWQgaW4gdGhlIE5TLTMgc2ltdWxhdG9yLjxicj4NCjxicj4NCkJSPGJyPg0KPGJyPg0K WmFoZWQ8YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0 OyBGcm9tOiBYaWFvcWluZyBaaHUgKHhpYW9xemh1KSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp4 aWFvcXpodUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj54aWFvcXpodUBjaXNjby5jb208L2E+ XTxicj4NCiZndDsgU2VudDogZGVuIDI1IGZlYnJ1YXJpIDIwMTYgMTg6NDM8YnI+DQomZ3Q7IFRv OiBaYWhlZHV6emFtYW4gU2Fya2VyOyBNaXJqYSBLw7xobGV3aW5kPGJyPg0KJmd0OyBDYzogcm1j YXQgV0cgKDxhIGhyZWY9Im1haWx0bzpybWNhdEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJt Y2F0QGlldGYub3JnPC9hPik7IEFubmEgQnJ1bnN0csO2bTxicj4NCiZndDsgU3ViamVjdDogUmU6 IFtybWNhdF0gV2lyZWxlc3MgdGVzdCBjYXNlczxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcyBm b3IgdGhlIHBvaW50ZXIsIFphaGVkLiZuYnNwOyBUaGF0J3MgYSBnb29kIHBsYWNlIHRvIHN0YXJ0 LiZuYnNwOyBXb3VsZCBpdCBiZTxicj4NCiZndDsgcG9zc2libGUgZm9yIHlvdSB0byBzaGFyZSB5 b3VyIE5TLTMgY29kZS9zY3JpcHQgZm9yIHRlc3RpbmcgU0NSZUFNIG92ZXIgTFRFPzxicj4NCiZn dDs8YnI+DQomZ3Q7IEJUVywgeW91IG1heSB3YW50IHRvIHVwZGF0ZSB0aGUgY29ycmVzcG9uZGlu ZyBsaW5rIGluIHRoZSB3aXJlbGVzcy10ZXN0LWNhc2U8YnI+DQomZ3Q7IGRvY3VtZW50LiBDdXJy ZW50bHksIHRoZSByZWZlcmVuY2Ugb24gW0xURS1zaW11bGF0b3JdIHBvaW50cyB0byB0aGUgTlMt Mzxicj4NCiZndDsgbWFudWFsLjxicj4NCiZndDs8YnI+DQomZ3Q7IEJlc3QsPGJyPg0KJmd0OyBY aWFvcWluZzxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQomZ3Q7IEZyb206IFphaGVkdXp6YW1hbiBTYXJrZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzp6YWhlZHV6emFtYW4uc2Fya2VyQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnphaGVkdXp6YW1hbi5zYXJrZXJAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQomZ3Q7IFNl bnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgMTE6NDUgUE08YnI+DQomZ3Q7IFRvOiBN aXJqYSBLw7xobGV3aW5kOyBYaWFvcWluZyBaaHUgKHhpYW9xemh1KTxicj4NCiZndDsgQ2M6IHJt Y2F0IFdHICg8YSBocmVmPSJtYWlsdG86cm1jYXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5y bWNhdEBpZXRmLm9yZzwvYT4pOyBBbm5hIEJydW5zdHLDtm08YnI+DQomZ3Q7IFN1YmplY3Q6IFJl OiBbcm1jYXRdIFdpcmVsZXNzIHRlc3QgY2FzZXM8YnI+DQomZ3Q7PGJyPg0KJmd0OyBZZXMsPGJy Pg0KJmd0Ozxicj4NCiZndDsgTlMtMyBoYXMgbmVjZXNzYXJ5IG1vZHVsZXMgdG8gcnVuIExURSBz aW11bGF0aW9ucy48YnI+DQomZ3Q7PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5uc25h bS5vcmcvZG9jcy9tb2RlbHMvaHRtbC9sdGUuaHRtbCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwczovL3d3dy5uc25hbS5vcmcvZG9jcy9tb2RlbHMvaHRtbC9sdGUuaHRt bDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBCUjxicj4NCiZndDs8YnI+DQomZ3Q7IFphaGVkPGJy Pg0KJmd0Ozxicj4NCiZndDsgT24gMDIvMjQvMjAxNiAwNjowMiBQTSwgTWlyamEgS8O8aGxld2lu ZCB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgSGkgWGlhb3FpbmcsPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyBBbSAyNC4wMi4yMDE2IHVtIDE3OjUwIHNjaHJpZWIgWGlhb3FpbmcgWmh1 ICh4aWFvcXpodSk8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86eGlhb3F6aHVAY2lzY28u Y29tIiB0YXJnZXQ9Il9ibGFuayI+eGlhb3F6aHVAY2lzY28uY29tPC9hPiZndDs6PGJyPg0KJmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgSGkgTWlyamEsIGFsbCw8YnI+DQomZ3Q7ICZn dDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBaYWhlZCBhbmQgSSBoYXZlIGluZGVlZCBkaXNjdXNz ZWQgYWJvdXQgdGhpcyBpbiBZb2tvaGFtYS4gTWF5YmUgSSBkaWQgbm90PGJyPg0KJmd0OyBtYWtl IGl0IGNsZWFyIGluIG15IHByZXZpb3VzIGVtYWlsLCB0cnlpbmcgYWdhaW4uPGJyPg0KJmd0OyAm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgQmFzaWNhbGx5LCB0byBjYXJyeSBvdXQgdGVzdHMg aW4gU2VjIDMgKENlbGx1bGFyIE5ldHdvcmsgU3BlY2lmaWMgVGVzdCBDYXNlcyksPGJyPg0KJmd0 OyBvbmUgbmVlZHMgdG8gcnVuIGl0IG92ZXIgYSBtb2R1bGUgdGhhdCBzaW11bGF0ZXMgcGFja2V0 IGJlaGF2aW9yIG92ZXIgY2VsbHVsYXI8YnI+DQomZ3Q7IGxpbmtzIC0tIGp1c3QgbGlrZSBmb3Ig dGhlIFdpLUZpIHBvcnRpb24gb2YgdGhlIHRlc3QgY2FzZXMsIHdlIHJlbGllZCBvbiB0aGUgV2kt Rmk8YnI+DQomZ3Q7IG1vZHVsZSBpbiBOUzMgc2ltdWxhdG9ycyB0byBkbyBzby48YnI+DQomZ3Q7 ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBXaGF0IGlzIG1pc3NpbmcgaXMgdGhlIGNlbGx1 bGFyIG5ldHdvcmsgc2ltdWxhdG9yLCBwcmVmZXJhYmx5IGFzIGEgcGx1Zy1pbjxicj4NCiZndDsg bW9kdWxlIGZvciBOUzMsIG92ZXIgd2hpY2ggd2UgY2FuIHJ1biByYXRlIGFkYXB0YXRpb24gdGVz dHMuPGJyPg0KJmd0OyAmZ3Q7IEkgdGhvdWdoIHRoYXQgdGhpcyBpcyBhdmFpbGFibGUgaW4gdGhl IG1lYW4gdGltZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgWmFoZWQsIGRvIHlvdSBo YXZlIGxpbmsgb3IgaXMgdGhpcyBhbHJlYWR5IGluY2x1ZGVkIGluIHRoZSBsYXRlc3QgdmVyc2lv biBvZiBucy08YnI+DQomZ3Q7IDM/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE1pcmph PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaGFua3Ms PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBYaWFvcWluZzxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBGcm9tOiBNaXJqYSBLw7xobGV3aW5kICZs dDs8YSBocmVmPSJtYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCIgdGFyZ2V0 PSJfYmxhbmsiPm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8L2E+Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsgU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAzOjMzIEFNPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBUbzogWGlhb3FpbmcgWmh1ICh4aWFvcXpodSk7IHJtY2F0IFdHICg8 YSBocmVmPSJtYWlsdG86cm1jYXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ybWNhdEBpZXRm Lm9yZzwvYT4pPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBDYzogQW5uYSBCcnVuc3Ryw7ZtOyBaYWhlZHV6 emFtYW4gU2Fya2VyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3JtY2F0XSBXaXJl bGVzcyB0ZXN0IGNhc2VzPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgSGkg WGlhb3FpbmcsPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgT24gMTkuMDIu MjAxNiAyMToyNywgWGlhb3FpbmcgWmh1ICh4aWFvcXpodSkgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsgQXMgZm9yIFNlYy4gMyBvbiBDZWxsdWxhciBOZXR3b3JrIFNwZWNpZmljIFRlc3Qg Q2FzZXMsIHdvdWxkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgYXBwcmVjaWF0ZSBtb3JlIGRldGFp bGVkIGluZm9ybWF0aW9uIG9uIGhvdyB0byBzZXQgdGhvc2UgdXAsIG9yPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsgcmVsZXZhbnQgcG9pbnRlcnMvY29kZSBvbiBjZWxsdWxhciBuZXR3b3JrIHNpbXVs YXRvcnMuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBDYW4geW91IGxldCB1cy9aYWhlZCBrbm93IHdoYXQg ZXhhY3RseSB5b3UgbmVlZC9pcyBtaXNzaW5nPzxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7ICZndDsmZ3Q7IE1pcmphPGJyPg0KJmd0Ozxicj4N Cjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_145650542919823062ciscocom_-- From nobody Fri Feb 26 09:10:40 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35731B2A38 for ; Fri, 26 Feb 2016 09:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EihW6pE8eUM6 for ; Fri, 26 Feb 2016 09:10:36 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3544A1B2B93 for ; Fri, 26 Feb 2016 09:10:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E93A9D9317; Fri, 26 Feb 2016 18:10:33 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MnznZZqwr3-5; Fri, 26 Feb 2016 18:10:33 +0100 (MET) Received: from [192.168.178.33] (x5f7025c8.dyn.telefonica.de [95.112.37.200]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 41446D9303; Fri, 26 Feb 2016 18:10:33 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <1456505429198.23062@cisco.com> Date: Fri, 26 Feb 2016 18:10:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4423F12C-8D64-48EF-BEF2-017FB8171222@tik.ee.ethz.ch> References: <6902D83B-55B3-4D22-8B37-A71A89720DDF@tik.ee.ethz.ch> <1455913631142.29407@cisco.com> <56CD9506.7080902@tik.ee.ethz.ch> <1456332600778.99326@cisco.com> <41376CF6-1F97-45A5-A8E3-186DBB1219ED@tik.ee.ethz.ch> <56CEB129.10307@ericsson.com> <1456422154539.54776@cisco.com> <1456505429198.23062@cisco.com> To: "Xiaoqing Zhu (xiaoqzhu)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "rmcat WG \(rmcat@ietf.org\)" , Zaheduzzaman Sarker , Stefan Holmer , =?utf-8?Q?Anna_Brunstr=C3=B6m?= Subject: Re: [rmcat] Wireless test cases X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 17:10:39 -0000 Hi all, thanks for you feedback. This brings me back to my original question: Would the working group = require to see evaluation results to the mobile and wireless test cases = before moving to publication for experimental or are the basic test = cases (in draft-ietf-rmcat-eval-test-02) sufficient to move on and = classify the candidates to be safe for experimentation in the Internet? Mirja > Am 26.02.2016 um 17:50 schrieb Xiaoqing Zhu (xiaoqzhu) = : >=20 > =E2=80=8BI will look into sharing the NS3 code/script for WiFi tests.=20= >=20 > As for LTE test cases: it's good to know that it can be done. But, = since there is no precedence to follow, this may take substantial time = and effort. So we may not get around to tackle that soon. >=20 > Thanks, > Xiaoqing > =20 > From: Stefan Holmer > Sent: Friday, February 26, 2016 12:55 AM > To: Zaheduzzaman Sarker; Xiaoqing Zhu (xiaoqzhu); Mirja K=C3=BChlewind > Cc: rmcat WG (rmcat@ietf.org); Anna Brunstr=C3=B6m > Subject: Re: [rmcat] Wireless test cases > =20 > As a first step we'll probably look into at least some of the wifi = test cases, but I don't know how soon we can have those done. Our = current focus is on improving the loss-based part of GCC, and after that = we can focus on further tests. >=20 > If it's reasonably simple to run lte tests then it sounds good to run = some of those too. If we can share code to set up NS3 for wifi and lte = tests, that would be great. >=20 > /Stefan >=20 > On Fri, Feb 26, 2016 at 8:51 AM Zaheduzzaman Sarker = wrote: > Hi, >=20 > We didn't used NS-3 simulator to evaluation SCReAM over LTE, we used = our proprietary simulator. > However, I have looked into the NS-3 simulator and talked with the LTE = module implementer of NS-3 (LUNA). My conclusion is, the draft can be = realized in the NS-3 simulator. >=20 > BR >=20 > Zahed >=20 > > -----Original Message----- > > From: Xiaoqing Zhu (xiaoqzhu) [mailto:xiaoqzhu@cisco.com] > > Sent: den 25 februari 2016 18:43 > > To: Zaheduzzaman Sarker; Mirja K=C3=BChlewind > > Cc: rmcat WG (rmcat@ietf.org); Anna Brunstr=C3=B6m > > Subject: Re: [rmcat] Wireless test cases > > > > Thanks for the pointer, Zahed. That's a good place to start. Would = it be > > possible for you to share your NS-3 code/script for testing SCReAM = over LTE? > > > > BTW, you may want to update the corresponding link in the = wireless-test-case > > document. Currently, the reference on [LTE-simulator] points to the = NS-3 > > manual. > > > > Best, > > Xiaoqing > > > > ________________________________________ > > From: Zaheduzzaman Sarker > > Sent: Wednesday, February 24, 2016 11:45 PM > > To: Mirja K=C3=BChlewind; Xiaoqing Zhu (xiaoqzhu) > > Cc: rmcat WG (rmcat@ietf.org); Anna Brunstr=C3=B6m > > Subject: Re: [rmcat] Wireless test cases > > > > Yes, > > > > NS-3 has necessary modules to run LTE simulations. > > > > https://www.nsnam.org/docs/models/html/lte.html > > > > BR > > > > Zahed > > > > On 02/24/2016 06:02 PM, Mirja K=C3=BChlewind wrote: > > > Hi Xiaoqing, > > > > > >> Am 24.02.2016 um 17:50 schrieb Xiaoqing Zhu (xiaoqzhu) > > : > > >> > > >> Hi Mirja, all, > > >> > > >> Zahed and I have indeed discussed about this in Yokohama. Maybe I = did not > > make it clear in my previous email, trying again. > > >> > > >> Basically, to carry out tests in Sec 3 (Cellular Network Specific = Test Cases), > > one needs to run it over a module that simulates packet behavior = over cellular > > links -- just like for the Wi-Fi portion of the test cases, we = relied on the Wi-Fi > > module in NS3 simulators to do so. > > >> > > >> What is missing is the cellular network simulator, preferably as = a plug-in > > module for NS3, over which we can run rate adaptation tests. > > > I though that this is available in the mean time. > > > > > > Zahed, do you have link or is this already included in the latest = version of ns- > > 3? > > > > > > Mirja > > > > > > > > >> Thanks, > > >> Xiaoqing > > >> > > >> > > >> ________________________________________ > > >> From: Mirja K=C3=BChlewind > > >> Sent: Wednesday, February 24, 2016 3:33 AM > > >> To: Xiaoqing Zhu (xiaoqzhu); rmcat WG (rmcat@ietf.org) > > >> Cc: Anna Brunstr=C3=B6m; Zaheduzzaman Sarker > > >> Subject: Re: [rmcat] Wireless test cases > > >> > > >> Hi Xiaoqing, > > >> > > >> On 19.02.2016 21:27, Xiaoqing Zhu (xiaoqzhu) wrote: > > >>> As for Sec. 3 on Cellular Network Specific Test Cases, would > > >>> appreciate more detailed information on how to set those up, or > > >>> relevant pointers/code on cellular network simulators. > > >> Can you let us/Zahed know what exactly you need/is missing? > > >> > > >> Thanks, > > >> Mirja > > >=20 From nobody Sat Feb 27 01:02:42 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737851B3856 for ; Sat, 27 Feb 2016 01:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-szDU2ROiUs for ; Sat, 27 Feb 2016 01:02:39 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87621B3855 for ; Sat, 27 Feb 2016 01:02:38 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-61-56d1662cda6d Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 19.14.15637.C2661D65; Sat, 27 Feb 2016 10:02:36 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.14]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Sat, 27 Feb 2016 10:02:36 +0100 From: Ingemar Johansson S To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [rmcat] Wireless test cases Thread-Index: AQHRcNCFaApSKJXM2EuRihgDFSt8Jp8/mCqw Date: Sat, 27 Feb 2016 09:02:35 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA43D7C65E@ESESSMB205.ericsson.se> References: <6902D83B-55B3-4D22-8B37-A71A89720DDF@tik.ee.ethz.ch> <1455913631142.29407@cisco.com> <56CD9506.7080902@tik.ee.ethz.ch> <1456332600778.99326@cisco.com> <41376CF6-1F97-45A5-A8E3-186DBB1219ED@tik.ee.ethz.ch> <56CEB129.10307@ericsson.com> <1456422154539.54776@cisco.com> <1456505429198.23062@cisco.com> <4423F12C-8D64-48EF-BEF2-017FB8171222@tik.ee.ethz.ch> In-Reply-To: <4423F12C-8D64-48EF-BEF2-017FB8171222@tik.ee.ethz.ch> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2J7oK5O2sUwg+lfzS1O/LjMbLFh9RQW i9U3P7BZdB08xWzxumUZkwOrx5TfG1k9liz5yeTx90Irm8exD1/ZPH7vW8QWwBrFZZOSmpNZ llqkb5fAldHz7glzwRXbijOPbjM3MHbYdDFyckgImEh8/zCXHcIWk7hwbz1bFyMXh5DAYUaJ ve0fmSCcxYwSb5+sZwGpYhOwkVh56DtjFyMHh4iAl8TnT4EgNcwCvxklVh09AlYjLKAh8WhW ExuILSKgKXF6ahuUbSSx+OouZhCbRUBVou3kEyYQm1fAV2LHmzWsEMtaWCR6pz1jA1nAKeAk cfG9IkgNo4CsxP3v98DmMwuIS9x6Mp8J4moBiSV7zjND2KISLx//Y4WwFSWuTl/OBDKGGeiG 9bv0IVoVJaZ0P2SHWCsocXLmE5YJjGKzkEydhdAxC0nHLCQdCxhZVjGKFqcWJ+WmGxnrpRZl JhcX5+fp5aWWbGIERt7BLb9VdzBefuN4iFGAg1GJh/fDjQthQqyJZcWVuYcYJTiYlUR4G5Iu hgnxpiRWVqUW5ccXleakFh9ilOZgURLnXeO8PkxIID2xJDU7NbUgtQgmy8TBKdXAGCI49aTa xtsuS2ZW2osaL0lyYG+4WTfXfr22wDSDRM5Zd17nmUxcuszR807s8+hO0yPPvFYKJEYHZ7G5 a4hq7fwxx9LiDfOPzzeq9pTd++n0Xp3x+c3HKfNXNiSfiw2qfPpvGn+D+LJpG1/vmWRgUvHX 5VZEEfNnwZSl1avK5WWPayrv+BOfrcRSnJFoqMVcVJwIABjUbFa4AgAA Archived-At: Cc: "rmcat WG \(rmcat@ietf.org\)" , Zaheduzzaman Sarker , Stefan Holmer , =?utf-8?B?QW5uYSBCcnVuc3Ryw7Zt?= , "Xiaoqing Zhu \(xiaoqzhu\)" Subject: Re: [rmcat] Wireless test cases X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2016 09:02:41 -0000 SGkNCg0KRm9yIHdoYXQgaXTCtHMgd29ydGguDQpJIHdpbGwgcnVuIHRoZSBMVEUgdGVzdCBjYXNl cyBhbmQgdGhlIGJhc2ljIHRlc3QgY2FzZXMgd2l0aCBTQ1JlQU0gaW4gb3VyIHByb3ByaWV0YXJ5 ICBzeXN0ZW0gc2ltdWxhdG9yLiBJIHdpbGwgcG9zc2libHkgYWxzbyBydW4gc29tZSBXaUZpIHRl c3RjYXNlIGluIG91ciBzaW11bGF0b3IuDQpJIHdpbGwgbm90IHJ1biBpbiBOUzMgaG93ZXZlciwg c2ltcGxlIHJlYXNvbiBpcyB0aGF0IEkgZG9uJ3QgaGF2ZSB0aW1lIHRvIGRlbHZlIGludG8gdGhh dCBwbGF0Zm9ybS4NCg0KL0luZ2VtYXINCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBNaXJqYSBLw7xobGV3aW5kIFttYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUu ZXRoei5jaF0NCj4gU2VudDogZGVuIDI2IGZlYnJ1YXJpIDIwMTYgMTg6MTENCj4gVG86IFhpYW9x aW5nIFpodSAoeGlhb3F6aHUpDQo+IENjOiBybWNhdCBXRyAocm1jYXRAaWV0Zi5vcmcpOyBaYWhl ZHV6emFtYW4gU2Fya2VyOyBTdGVmYW4gSG9sbWVyOyBBbm5hDQo+IEJydW5zdHLDtm0NCj4gU3Vi amVjdDogUmU6IFtybWNhdF0gV2lyZWxlc3MgdGVzdCBjYXNlcw0KPiANCj4gSGkgYWxsLA0KPiAN Cj4gdGhhbmtzIGZvciB5b3UgZmVlZGJhY2suDQo+IA0KPiBUaGlzIGJyaW5ncyBtZSBiYWNrIHRv IG15IG9yaWdpbmFsIHF1ZXN0aW9uOiBXb3VsZCB0aGUgd29ya2luZyBncm91cCByZXF1aXJlDQo+ IHRvIHNlZSBldmFsdWF0aW9uIHJlc3VsdHMgdG8gdGhlIG1vYmlsZSBhbmQgd2lyZWxlc3MgdGVz dCBjYXNlcyBiZWZvcmUgbW92aW5nDQo+IHRvIHB1YmxpY2F0aW9uIGZvciBleHBlcmltZW50YWwg b3IgYXJlIHRoZSBiYXNpYyB0ZXN0IGNhc2VzIChpbiBkcmFmdC1pZXRmLQ0KPiBybWNhdC1ldmFs LXRlc3QtMDIpIHN1ZmZpY2llbnQgdG8gbW92ZSBvbiBhbmQgY2xhc3NpZnkgdGhlIGNhbmRpZGF0 ZXMgdG8gYmUNCj4gc2FmZSBmb3IgZXhwZXJpbWVudGF0aW9uIGluIHRoZSBJbnRlcm5ldD8NCj4g DQo+IE1pcmphDQo+IA0KPiANCj4gPiBBbSAyNi4wMi4yMDE2IHVtIDE3OjUwIHNjaHJpZWIgWGlh b3FpbmcgWmh1ICh4aWFvcXpodSkNCj4gPHhpYW9xemh1QGNpc2NvLmNvbT46DQo+ID4NCj4gPiDi gItJIHdpbGwgbG9vayBpbnRvIHNoYXJpbmcgdGhlIE5TMyBjb2RlL3NjcmlwdCBmb3IgV2lGaSB0 ZXN0cy4NCj4gPg0KPiA+IEFzIGZvciBMVEUgdGVzdCBjYXNlczogIGl0J3MgZ29vZCB0byBrbm93 IHRoYXQgaXQgY2FuIGJlIGRvbmUuICBCdXQsIHNpbmNlIHRoZXJlDQo+IGlzIG5vIHByZWNlZGVu Y2UgdG8gZm9sbG93LCB0aGlzIG1heSB0YWtlIHN1YnN0YW50aWFsIHRpbWUgYW5kIGVmZm9ydC4g U28gd2UNCj4gbWF5IG5vdCBnZXQgYXJvdW5kIHRvIHRhY2tsZSB0aGF0IHNvb24uDQo+ID4NCj4g PiBUaGFua3MsDQo+ID4gWGlhb3FpbmcNCj4gPg0KPiA+IEZyb206IFN0ZWZhbiBIb2xtZXIgPHN0 ZWZhbkB3ZWJydGMub3JnPg0KPiA+IFNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjYsIDIwMTYgMTI6 NTUgQU0NCj4gPiBUbzogWmFoZWR1enphbWFuIFNhcmtlcjsgWGlhb3FpbmcgWmh1ICh4aWFvcXpo dSk7IE1pcmphIEvDvGhsZXdpbmQNCj4gPiBDYzogcm1jYXQgV0cgKHJtY2F0QGlldGYub3JnKTsg QW5uYSBCcnVuc3Ryw7ZtDQo+ID4gU3ViamVjdDogUmU6IFtybWNhdF0gV2lyZWxlc3MgdGVzdCBj YXNlcw0KPiA+DQo+ID4gQXMgYSBmaXJzdCBzdGVwIHdlJ2xsIHByb2JhYmx5IGxvb2sgaW50byBh dCBsZWFzdCBzb21lIG9mIHRoZSB3aWZpIHRlc3QgY2FzZXMsDQo+IGJ1dCBJIGRvbid0IGtub3cg aG93IHNvb24gd2UgY2FuIGhhdmUgdGhvc2UgZG9uZS4gT3VyIGN1cnJlbnQgZm9jdXMgaXMgb24N Cj4gaW1wcm92aW5nIHRoZSBsb3NzLWJhc2VkIHBhcnQgb2YgR0NDLCBhbmQgYWZ0ZXIgdGhhdCB3 ZSBjYW4gZm9jdXMgb24gZnVydGhlcg0KPiB0ZXN0cy4NCj4gPg0KPiA+IElmIGl0J3MgcmVhc29u YWJseSBzaW1wbGUgdG8gcnVuIGx0ZSB0ZXN0cyB0aGVuIGl0IHNvdW5kcyBnb29kIHRvIHJ1biBz b21lIG9mDQo+IHRob3NlIHRvby4gSWYgd2UgY2FuIHNoYXJlIGNvZGUgdG8gc2V0IHVwIE5TMyBm b3Igd2lmaSBhbmQgbHRlIHRlc3RzLCB0aGF0DQo+IHdvdWxkIGJlIGdyZWF0Lg0KPiA+DQo+ID4g L1N0ZWZhbg0KPiA+DQo+ID4gT24gRnJpLCBGZWIgMjYsIDIwMTYgYXQgODo1MSBBTSBaYWhlZHV6 emFtYW4gU2Fya2VyDQo+IDx6YWhlZHV6emFtYW4uc2Fya2VyQGVyaWNzc29uLmNvbT4gd3JvdGU6 DQo+ID4gSGksDQo+ID4NCj4gPiBXZSBkaWRuJ3QgdXNlZCBOUy0zIHNpbXVsYXRvciB0byBldmFs dWF0aW9uIFNDUmVBTSBvdmVyIExURSwgd2UgdXNlZA0KPiBvdXIgcHJvcHJpZXRhcnkgc2ltdWxh dG9yLg0KPiA+IEhvd2V2ZXIsIEkgaGF2ZSBsb29rZWQgaW50byB0aGUgTlMtMyBzaW11bGF0b3Ig YW5kIHRhbGtlZCB3aXRoIHRoZSBMVEUNCj4gbW9kdWxlIGltcGxlbWVudGVyIG9mIE5TLTMgKExV TkEpLiBNeSBjb25jbHVzaW9uIGlzLCB0aGUgZHJhZnQgY2FuIGJlDQo+IHJlYWxpemVkIGluIHRo ZSBOUy0zIHNpbXVsYXRvci4NCj4gPg0KPiA+IEJSDQo+ID4NCj4gPiBaYWhlZA0KPiA+DQo+ID4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogWGlhb3FpbmcgWmh1ICh4 aWFvcXpodSkgW21haWx0bzp4aWFvcXpodUBjaXNjby5jb21dDQo+ID4gPiBTZW50OiBkZW4gMjUg ZmVicnVhcmkgMjAxNiAxODo0Mw0KPiA+ID4gVG86IFphaGVkdXp6YW1hbiBTYXJrZXI7IE1pcmph IEvDvGhsZXdpbmQNCj4gPiA+IENjOiBybWNhdCBXRyAocm1jYXRAaWV0Zi5vcmcpOyBBbm5hIEJy dW5zdHLDtm0NCj4gPiA+IFN1YmplY3Q6IFJlOiBbcm1jYXRdIFdpcmVsZXNzIHRlc3QgY2FzZXMN Cj4gPiA+DQo+ID4gPiBUaGFua3MgZm9yIHRoZSBwb2ludGVyLCBaYWhlZC4gIFRoYXQncyBhIGdv b2QgcGxhY2UgdG8gc3RhcnQuICBXb3VsZA0KPiA+ID4gaXQgYmUgcG9zc2libGUgZm9yIHlvdSB0 byBzaGFyZSB5b3VyIE5TLTMgY29kZS9zY3JpcHQgZm9yIHRlc3RpbmcgU0NSZUFNDQo+IG92ZXIg TFRFPw0KPiA+ID4NCj4gPiA+IEJUVywgeW91IG1heSB3YW50IHRvIHVwZGF0ZSB0aGUgY29ycmVz cG9uZGluZyBsaW5rIGluIHRoZQ0KPiA+ID4gd2lyZWxlc3MtdGVzdC1jYXNlIGRvY3VtZW50LiBD dXJyZW50bHksIHRoZSByZWZlcmVuY2Ugb24NCj4gPiA+IFtMVEUtc2ltdWxhdG9yXSBwb2ludHMg dG8gdGhlIE5TLTMgbWFudWFsLg0KPiA+ID4NCj4gPiA+IEJlc3QsDQo+ID4gPiBYaWFvcWluZw0K PiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiA+IEZyb206IFphaGVkdXp6YW1hbiBTYXJrZXIgPHphaGVkdXp6YW1hbi5zYXJrZXJAZXJpY3Nz b24uY29tPg0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAxMTo0NSBQ TQ0KPiA+ID4gVG86IE1pcmphIEvDvGhsZXdpbmQ7IFhpYW9xaW5nIFpodSAoeGlhb3F6aHUpDQo+ ID4gPiBDYzogcm1jYXQgV0cgKHJtY2F0QGlldGYub3JnKTsgQW5uYSBCcnVuc3Ryw7ZtDQo+ID4g PiBTdWJqZWN0OiBSZTogW3JtY2F0XSBXaXJlbGVzcyB0ZXN0IGNhc2VzDQo+ID4gPg0KPiA+ID4g WWVzLA0KPiA+ID4NCj4gPiA+IE5TLTMgaGFzIG5lY2Vzc2FyeSBtb2R1bGVzIHRvIHJ1biBMVEUg c2ltdWxhdGlvbnMuDQo+ID4gPg0KPiA+ID4gaHR0cHM6Ly93d3cubnNuYW0ub3JnL2RvY3MvbW9k ZWxzL2h0bWwvbHRlLmh0bWwNCj4gPiA+DQo+ID4gPiBCUg0KPiA+ID4NCj4gPiA+IFphaGVkDQo+ ID4gPg0KPiA+ID4gT24gMDIvMjQvMjAxNiAwNjowMiBQTSwgTWlyamEgS8O8aGxld2luZCB3cm90 ZToNCj4gPiA+ID4gSGkgWGlhb3FpbmcsDQo+ID4gPiA+DQo+ID4gPiA+PiBBbSAyNC4wMi4yMDE2 IHVtIDE3OjUwIHNjaHJpZWIgWGlhb3FpbmcgWmh1ICh4aWFvcXpodSkNCj4gPiA+IDx4aWFvcXpo dUBjaXNjby5jb20+Og0KPiA+ID4gPj4NCj4gPiA+ID4+IEhpIE1pcmphLCBhbGwsDQo+ID4gPiA+ Pg0KPiA+ID4gPj4gWmFoZWQgYW5kIEkgaGF2ZSBpbmRlZWQgZGlzY3Vzc2VkIGFib3V0IHRoaXMg aW4gWW9rb2hhbWEuIE1heWJlIEkNCj4gPiA+ID4+IGRpZCBub3QNCj4gPiA+IG1ha2UgaXQgY2xl YXIgaW4gbXkgcHJldmlvdXMgZW1haWwsIHRyeWluZyBhZ2Fpbi4NCj4gPiA+ID4+DQo+ID4gPiA+ PiBCYXNpY2FsbHksIHRvIGNhcnJ5IG91dCB0ZXN0cyBpbiBTZWMgMyAoQ2VsbHVsYXIgTmV0d29y ayBTcGVjaWZpYw0KPiA+ID4gPj4gVGVzdCBDYXNlcyksDQo+ID4gPiBvbmUgbmVlZHMgdG8gcnVu IGl0IG92ZXIgYSBtb2R1bGUgdGhhdCBzaW11bGF0ZXMgcGFja2V0IGJlaGF2aW9yDQo+ID4gPiBv dmVyIGNlbGx1bGFyIGxpbmtzIC0tIGp1c3QgbGlrZSBmb3IgdGhlIFdpLUZpIHBvcnRpb24gb2Yg dGhlIHRlc3QNCj4gPiA+IGNhc2VzLCB3ZSByZWxpZWQgb24gdGhlIFdpLUZpIG1vZHVsZSBpbiBO UzMgc2ltdWxhdG9ycyB0byBkbyBzby4NCj4gPiA+ID4+DQo+ID4gPiA+PiBXaGF0IGlzIG1pc3Np bmcgaXMgdGhlIGNlbGx1bGFyIG5ldHdvcmsgc2ltdWxhdG9yLCBwcmVmZXJhYmx5IGFzDQo+ID4g PiA+PiBhIHBsdWctaW4NCj4gPiA+IG1vZHVsZSBmb3IgTlMzLCBvdmVyIHdoaWNoIHdlIGNhbiBy dW4gcmF0ZSBhZGFwdGF0aW9uIHRlc3RzLg0KPiA+ID4gPiBJIHRob3VnaCB0aGF0IHRoaXMgaXMg YXZhaWxhYmxlIGluIHRoZSBtZWFuIHRpbWUuDQo+ID4gPiA+DQo+ID4gPiA+IFphaGVkLCBkbyB5 b3UgaGF2ZSBsaW5rIG9yIGlzIHRoaXMgYWxyZWFkeSBpbmNsdWRlZCBpbiB0aGUgbGF0ZXN0DQo+ ID4gPiA+IHZlcnNpb24gb2YgbnMtDQo+ID4gPiAzPw0KPiA+ID4gPg0KPiA+ID4gPiBNaXJqYQ0K PiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPj4gVGhhbmtzLA0KPiA+ID4gPj4gWGlhb3FpbmcNCj4g PiA+ID4+DQo+ID4gPiA+Pg0KPiA+ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+ID4gPj4gRnJvbTogTWlyamEgS8O8aGxld2luZCA8bWlyamEua3VlaGxl d2luZEB0aWsuZWUuZXRoei5jaD4NCj4gPiA+ID4+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkg MjQsIDIwMTYgMzozMyBBTQ0KPiA+ID4gPj4gVG86IFhpYW9xaW5nIFpodSAoeGlhb3F6aHUpOyBy bWNhdCBXRyAocm1jYXRAaWV0Zi5vcmcpDQo+ID4gPiA+PiBDYzogQW5uYSBCcnVuc3Ryw7ZtOyBa YWhlZHV6emFtYW4gU2Fya2VyDQo+ID4gPiA+PiBTdWJqZWN0OiBSZTogW3JtY2F0XSBXaXJlbGVz cyB0ZXN0IGNhc2VzDQo+ID4gPiA+Pg0KPiA+ID4gPj4gSGkgWGlhb3FpbmcsDQo+ID4gPiA+Pg0K PiA+ID4gPj4gT24gMTkuMDIuMjAxNiAyMToyNywgWGlhb3FpbmcgWmh1ICh4aWFvcXpodSkgd3Jv dGU6DQo+ID4gPiA+Pj4gQXMgZm9yIFNlYy4gMyBvbiBDZWxsdWxhciBOZXR3b3JrIFNwZWNpZmlj IFRlc3QgQ2FzZXMsIHdvdWxkDQo+ID4gPiA+Pj4gYXBwcmVjaWF0ZSBtb3JlIGRldGFpbGVkIGlu Zm9ybWF0aW9uIG9uIGhvdyB0byBzZXQgdGhvc2UgdXAsIG9yDQo+ID4gPiA+Pj4gcmVsZXZhbnQg cG9pbnRlcnMvY29kZSBvbiBjZWxsdWxhciBuZXR3b3JrIHNpbXVsYXRvcnMuDQo+ID4gPiA+PiBD YW4geW91IGxldCB1cy9aYWhlZCBrbm93IHdoYXQgZXhhY3RseSB5b3UgbmVlZC9pcyBtaXNzaW5n Pw0KPiA+ID4gPj4NCj4gPiA+ID4+IFRoYW5rcywNCj4gPiA+ID4+IE1pcmphDQo+ID4gPg0KPiA+ DQo+IA0KDQo= From nobody Mon Feb 29 05:38:54 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA271ACD3F for ; Mon, 29 Feb 2016 05:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.416 X-Spam-Level: X-Spam-Status: No, score=0.416 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2P1uPbX-ezBI for ; Mon, 29 Feb 2016 05:38:50 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DEA31ACDB2 for ; Mon, 29 Feb 2016 05:38:49 -0800 (PST) Received: by mail-ig0-x22f.google.com with SMTP id y8so77867352igp.1 for ; Mon, 29 Feb 2016 05:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=webrtc-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dOwVIMPqmHxrVew9wl1Bk9epVus2S64Fsr9MQfdwGAA=; b=EdLgghrgmJ24i2HXIzH7RExjJOaObTGHEWcOU07xtsOiDhBeCx5kIQIPVF1Vzg/A2a Gael+dvYORplOxEXoR7kUA750p9wISGLHGW+3/yK4KE4CsDNL7832TFcNjwHYXf17cty owuEi9ssfE6V4KdIu2QUaGTDP3IWrmWs2U1DX+xfvvrlv+emwyQGCPCQwhnXQRFUvfCt ZzFNym/bhqTjNVJGxXebcR7Dpye5Ua6WC3EVuWLAMA17/CuC7hZKC+L4SuuaoCLSwXwF zcWGhPI/cEk9hVtL5KZn2m21QCg3KdUtkCT4rQDDlu2LoA3GTOYNAk5HbdftGKfZNyZI a4nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dOwVIMPqmHxrVew9wl1Bk9epVus2S64Fsr9MQfdwGAA=; b=f+vuuLhJo6MqqI9A3o9Htn0Eek1WG//Wvn1FbaNEZClXvEqkSkQvxeUoOSBccnSCKj hJ8AlWokBSbFtJ117eaeU7Anxm3nD2qKQ6D0Q73j2F0L19ZZqlLUf2PfBmATPxym8yvC Ko9ztS7BuEcjCCIfC6FZSou8J+IZhhFoCVOGsWSZDIN5pL1fpgynk0Y243w2kw2VO8zZ XFZkn6QOnexGjTcneO/KtbcdhQLA2Nxxqea1/W5DVWIMea2/qgJf9ckRfQ00JmQ7rtqB 2bUjgxNxuSEb2rnGgk95UCMWQKlfk5paUyl3kRXNNU2H1sgsQBtJDMVnzOkKMfneiKoE qXwQ== X-Gm-Message-State: AD7BkJLTKC/WpjEfaqU9tlYCy46kr3tTLxJhOw+i+y3HHbBgYHYbxW7XLrEX6wBwVim51MLeK1kCRA589d+FwB9+ X-Received: by 10.50.79.137 with SMTP id j9mr10177155igx.65.1456753128924; Mon, 29 Feb 2016 05:38:48 -0800 (PST) MIME-Version: 1.0 References: <6902D83B-55B3-4D22-8B37-A71A89720DDF@tik.ee.ethz.ch> <1455913631142.29407@cisco.com> <56CD9506.7080902@tik.ee.ethz.ch> <1456332600778.99326@cisco.com> <41376CF6-1F97-45A5-A8E3-186DBB1219ED@tik.ee.ethz.ch> <56CEB129.10307@ericsson.com> <1456422154539.54776@cisco.com> <1456505429198.23062@cisco.com> <4423F12C-8D64-48EF-BEF2-017FB8171222@tik.ee.ethz.ch> In-Reply-To: <4423F12C-8D64-48EF-BEF2-017FB8171222@tik.ee.ethz.ch> From: Stefan Holmer Date: Mon, 29 Feb 2016 13:38:38 +0000 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "Xiaoqing Zhu (xiaoqzhu)" Content-Type: multipart/alternative; boundary=089e013a0c1ec6c05a052ce8c475 Archived-At: Cc: "rmcat WG \(rmcat@ietf.org\)" , Zaheduzzaman Sarker , =?UTF-8?Q?Anna_Brunstr=C3=B6m?= Subject: Re: [rmcat] Wireless test cases X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 13:38:52 -0000 --089e013a0c1ec6c05a052ce8c475 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't think we should require mobile/wireless evaluation results before experimental publication. I think we have proof enough from the base test cases, especially with the extra artificial jitter and fast capacity changes. /Stefan On Fri, Feb 26, 2016 at 6:10 PM Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > Hi all, > > thanks for you feedback. > > This brings me back to my original question: Would the working group > require to see evaluation results to the mobile and wireless test cases > before moving to publication for experimental or are the basic test cases > (in draft-ietf-rmcat-eval-test-02) sufficient to move on and classify the > candidates to be safe for experimentation in the Internet? > > Mirja > > > > Am 26.02.2016 um 17:50 schrieb Xiaoqing Zhu (xiaoqzhu) < > xiaoqzhu@cisco.com>: > > > > =E2=80=8BI will look into sharing the NS3 code/script for WiFi tests. > > > > As for LTE test cases: it's good to know that it can be done. But, > since there is no precedence to follow, this may take substantial time an= d > effort. So we may not get around to tackle that soon. > > > > Thanks, > > Xiaoqing > > > > From: Stefan Holmer > > Sent: Friday, February 26, 2016 12:55 AM > > To: Zaheduzzaman Sarker; Xiaoqing Zhu (xiaoqzhu); Mirja K=C3=BChlewind > > Cc: rmcat WG (rmcat@ietf.org); Anna Brunstr=C3=B6m > > Subject: Re: [rmcat] Wireless test cases > > > > As a first step we'll probably look into at least some of the wifi test > cases, but I don't know how soon we can have those done. Our current focu= s > is on improving the loss-based part of GCC, and after that we can focus o= n > further tests. > > > > If it's reasonably simple to run lte tests then it sounds good to run > some of those too. If we can share code to set up NS3 for wifi and lte > tests, that would be great. > > > > /Stefan > > > > On Fri, Feb 26, 2016 at 8:51 AM Zaheduzzaman Sarker < > zaheduzzaman.sarker@ericsson.com> wrote: > > Hi, > > > > We didn't used NS-3 simulator to evaluation SCReAM over LTE, we used ou= r > proprietary simulator. > > However, I have looked into the NS-3 simulator and talked with the LTE > module implementer of NS-3 (LUNA). My conclusion is, the draft can be > realized in the NS-3 simulator. > > > > BR > > > > Zahed > > > > > -----Original Message----- > > > From: Xiaoqing Zhu (xiaoqzhu) [mailto:xiaoqzhu@cisco.com] > > > Sent: den 25 februari 2016 18:43 > > > To: Zaheduzzaman Sarker; Mirja K=C3=BChlewind > > > Cc: rmcat WG (rmcat@ietf.org); Anna Brunstr=C3=B6m > > > Subject: Re: [rmcat] Wireless test cases > > > > > > Thanks for the pointer, Zahed. That's a good place to start. Would > it be > > > possible for you to share your NS-3 code/script for testing SCReAM > over LTE? > > > > > > BTW, you may want to update the corresponding link in the > wireless-test-case > > > document. Currently, the reference on [LTE-simulator] points to the > NS-3 > > > manual. > > > > > > Best, > > > Xiaoqing > > > > > > ________________________________________ > > > From: Zaheduzzaman Sarker > > > Sent: Wednesday, February 24, 2016 11:45 PM > > > To: Mirja K=C3=BChlewind; Xiaoqing Zhu (xiaoqzhu) > > > Cc: rmcat WG (rmcat@ietf.org); Anna Brunstr=C3=B6m > > > Subject: Re: [rmcat] Wireless test cases > > > > > > Yes, > > > > > > NS-3 has necessary modules to run LTE simulations. > > > > > > https://www.nsnam.org/docs/models/html/lte.html > > > > > > BR > > > > > > Zahed > > > > > > On 02/24/2016 06:02 PM, Mirja K=C3=BChlewind wrote: > > > > Hi Xiaoqing, > > > > > > > >> Am 24.02.2016 um 17:50 schrieb Xiaoqing Zhu (xiaoqzhu) > > > : > > > >> > > > >> Hi Mirja, all, > > > >> > > > >> Zahed and I have indeed discussed about this in Yokohama. Maybe I > did not > > > make it clear in my previous email, trying again. > > > >> > > > >> Basically, to carry out tests in Sec 3 (Cellular Network Specific > Test Cases), > > > one needs to run it over a module that simulates packet behavior over > cellular > > > links -- just like for the Wi-Fi portion of the test cases, we relied > on the Wi-Fi > > > module in NS3 simulators to do so. > > > >> > > > >> What is missing is the cellular network simulator, preferably as a > plug-in > > > module for NS3, over which we can run rate adaptation tests. > > > > I though that this is available in the mean time. > > > > > > > > Zahed, do you have link or is this already included in the latest > version of ns- > > > 3? > > > > > > > > Mirja > > > > > > > > > > > >> Thanks, > > > >> Xiaoqing > > > >> > > > >> > > > >> ________________________________________ > > > >> From: Mirja K=C3=BChlewind > > > >> Sent: Wednesday, February 24, 2016 3:33 AM > > > >> To: Xiaoqing Zhu (xiaoqzhu); rmcat WG (rmcat@ietf.org) > > > >> Cc: Anna Brunstr=C3=B6m; Zaheduzzaman Sarker > > > >> Subject: Re: [rmcat] Wireless test cases > > > >> > > > >> Hi Xiaoqing, > > > >> > > > >> On 19.02.2016 21:27, Xiaoqing Zhu (xiaoqzhu) wrote: > > > >>> As for Sec. 3 on Cellular Network Specific Test Cases, would > > > >>> appreciate more detailed information on how to set those up, or > > > >>> relevant pointers/code on cellular network simulators. > > > >> Can you let us/Zahed know what exactly you need/is missing? > > > >> > > > >> Thanks, > > > >> Mirja > > > > > > > --089e013a0c1ec6c05a052ce8c475 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I don't think we should require mobile/wireless evalua= tion results before experimental publication. I think we have proof enough = from the base test cases, especially with the extra artificial jitter and f= ast capacity changes.

    /Stefan

    On Fri, Feb 26, 2016 at 6:10 PM Mirja K=C3=BChlewind <= ;mirja.kuehlewind@tik.ee= .ethz.ch> wrote:
    Hi all,

    thanks for you feedback.

    This brings me back to my original question: Would the working group requir= e to see evaluation results to the mobile and wireless test cases before mo= ving to publication for experimental or are the basic test cases (in draft-= ietf-rmcat-eval-test-02) sufficient to move on and classify the candidates = to be safe for experimentation in the Internet?

    Mirja


    > Am 26.02.2016 um 17:50 schrieb Xiaoqing Zhu (xiaoqzhu) <xiaoqzhu@cisc= o.com>:
    >
    > =E2=80=8BI will look into sharing the NS3 code/script for WiFi tests.<= br> >
    > As for LTE test cases:=C2=A0 it's good to know that it can be done= .=C2=A0 But, since there is no precedence to follow, this may take substant= ial time and effort. So we may not get around to tackle that soon.
    >
    > Thanks,
    > Xiaoqing
    >
    > From: Stefan Holmer <stefan@webrtc.org>
    > Sent: Friday, February 26, 2016 12:55 AM
    > To: Zaheduzzaman Sarker; Xiaoqing Zhu (xiaoqzhu); Mirja K=C3=BChlewind=
    > Cc: rmcat WG (rmcat@ietf.org); Anna Brunstr=C3=B6m
    > Subject: Re: [rmcat] Wireless test cases
    >
    > As a first step we'll probably look into at least some of the wifi= test cases, but I don't know how soon we can have those done. Our curr= ent focus is on improving the loss-based part of GCC, and after that we can= focus on further tests.
    >
    > If it's reasonably simple to run lte tests then it sounds good to = run some of those too. If we can share code to set up NS3 for wifi and lte = tests, that would be great.
    >
    > /Stefan
    >
    > On Fri, Feb 26, 2016 at 8:51 AM Zaheduzzaman Sarker <za= heduzzaman.sarker@ericsson.com> wrote:
    > Hi,
    >
    > We didn't used NS-3 simulator to evaluation SCReAM over LTE, we us= ed our proprietary simulator.
    > However, I have looked into the NS-3 simulator and talked with the LTE= module implementer of NS-3 (LUNA). My conclusion is, the draft can be real= ized in the NS-3 simulator.
    >
    > BR
    >
    > Zahed
    >
    > > -----Original Message-----
    > > From: Xiaoqing Zhu (xiaoqzhu) [mailto:xiaoqzhu@cisco.com]
    > > Sent: den 25 februari 2016 18:43
    > > To: Zaheduzzaman Sarker; Mirja K=C3=BChlewind
    > > Cc: rmcat WG (rmcat@ietf.org); Anna Brunstr=C3=B6m
    > > Subject: Re: [rmcat] Wireless test cases
    > >
    > > Thanks for the pointer, Zahed.=C2=A0 That's a good place to s= tart.=C2=A0 Would it be
    > > possible for you to share your NS-3 code/script for testing SCReA= M over LTE?
    > >
    > > BTW, you may want to update the corresponding link in the wireles= s-test-case
    > > document. Currently, the reference on [LTE-simulator] points to t= he NS-3
    > > manual.
    > >
    > > Best,
    > > Xiaoqing
    > >
    > > ________________________________________
    > > From: Zaheduzzaman Sarker <zaheduzzaman.sarker@eri= csson.com>
    > > Sent: Wednesday, February 24, 2016 11:45 PM
    > > To: Mirja K=C3=BChlewind; Xiaoqing Zhu (xiaoqzhu)
    > > Cc: rmcat WG (rmcat@ietf.org); Anna Brunstr=C3=B6m
    > > Subject: Re: [rmcat] Wireless test cases
    > >
    > > Yes,
    > >
    > > NS-3 has necessary modules to run LTE simulations.
    > >
    > > https://www.nsnam.org/do= cs/models/html/lte.html
    > >
    > > BR
    > >
    > > Zahed
    > >
    > > On 02/24/2016 06:02 PM, Mirja K=C3=BChlewind wrote:
    > > > Hi Xiaoqing,
    > > >
    > > >> Am 24.02.2016 um 17:50 schrieb Xiaoqing Zhu (xiaoqzhu) > > <xiaoqzhu@cisco.com>:
    > > >>
    > > >> Hi Mirja, all,
    > > >>
    > > >> Zahed and I have indeed discussed about this in Yokohama= . Maybe I did not
    > > make it clear in my previous email, trying again.
    > > >>
    > > >> Basically, to carry out tests in Sec 3 (Cellular Network= Specific Test Cases),
    > > one needs to run it over a module that simulates packet behavior = over cellular
    > > links -- just like for the Wi-Fi portion of the test cases, we re= lied on the Wi-Fi
    > > module in NS3 simulators to do so.
    > > >>
    > > >> What is missing is the cellular network simulator, prefe= rably as a plug-in
    > > module for NS3, over which we can run rate adaptation tests.
    > > > I though that this is available in the mean time.
    > > >
    > > > Zahed, do you have link or is this already included in the l= atest version of ns-
    > > 3?
    > > >
    > > > Mirja
    > > >
    > > >
    > > >> Thanks,
    > > >> Xiaoqing
    > > >>
    > > >>
    > > >> ________________________________________
    > > >> From: Mirja K=C3=BChlewind <mirja.kuehlewi= nd@tik.ee.ethz.ch>
    > > >> Sent: Wednesday, February 24, 2016 3:33 AM
    > > >> To: Xiaoqing Zhu (xiaoqzhu); rmcat WG (rmcat@ietf.org)
    > > >> Cc: Anna Brunstr=C3=B6m; Zaheduzzaman Sarker
    > > >> Subject: Re: [rmcat] Wireless test cases
    > > >>
    > > >> Hi Xiaoqing,
    > > >>
    > > >> On 19.02.2016 21:27, Xiaoqing Zhu (xiaoqzhu) wrote:
    > > >>> As for Sec. 3 on Cellular Network Specific Test Case= s, would
    > > >>> appreciate more detailed information on how to set t= hose up, or
    > > >>> relevant pointers/code on cellular network simulator= s.
    > > >> Can you let us/Zahed know what exactly you need/is missi= ng?
    > > >>
    > > >> Thanks,
    > > >> Mirja
    > >
    >

    --089e013a0c1ec6c05a052ce8c475-- From nobody Mon Feb 29 14:43:16 2016 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9411B3E60 for ; Mon, 29 Feb 2016 14:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.206 X-Spam-Level: X-Spam-Status: No, score=-14.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8S0x8ZdrqyI for ; Mon, 29 Feb 2016 14:43:11 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E531B3E5B for ; Mon, 29 Feb 2016 14:43:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21747; q=dns/txt; s=iport; t=1456785791; x=1457995391; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OJ0Lxmd6HEf/f03MWIGvzE/si29dbWU78EgUQkAT0+k=; b=ZP+bWRkkSYCZ2meEMQiJ65zTzOvy68emX49pEebL5qrkmV2/fqOKGtb/ yTWKWLtL551oMOhtNAVfldxOGWd8THVabyj14nYBi+TWNlccDm5p/cQST YEQKHm+SncOX4UaR41tpb8uhPi/7w04EGcPIHw9D+mnVt70fDJ3spIxTb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAgBRyNRW/4QNJK1egm5MUm0GhgCle?= =?us-ascii?q?gEEAY5nAQ2BZyGFcgIcgR84FAEBAQEBAQFkJ4RBAQEBAwEjVgUHBAIBCBEEAQE?= =?us-ascii?q?BCR4DAgICDSMUCQgCBAENBRuHfAgOsRmPAwEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?REEhhKDPX2EBREBJQ8XCYJKgToFizGHRIQXAYgDhV6BXo0WhXOIVgEeAQFCggM?= =?us-ascii?q?ZgUhqAYcZNH4BAQE?= X-IronPort-AV: E=Sophos;i="5.22,521,1449532800"; d="scan'208,217";a="243133482" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Feb 2016 22:43:09 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u1TMh9cp003007 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Feb 2016 22:43:09 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 29 Feb 2016 16:43:09 -0600 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1104.009; Mon, 29 Feb 2016 16:43:09 -0600 From: "Xiaoqing Zhu (xiaoqzhu)" To: Stefan Holmer , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [rmcat] Wireless test cases Thread-Index: AQHRaNy/VapPwARipkaYL6fylYsp7Z8z0rMzgAeuggD///D6r4AAaxCAgAD2roCAAEFM0IABUqOAgAAR4YCAAB8TBoAAaz4AgAR7ygCAAChdWA== Date: Mon, 29 Feb 2016 22:43:09 +0000 Message-ID: <1456785789094.25849@cisco.com> References: <6902D83B-55B3-4D22-8B37-A71A89720DDF@tik.ee.ethz.ch> <1455913631142.29407@cisco.com> <56CD9506.7080902@tik.ee.ethz.ch> <1456332600778.99326@cisco.com> <41376CF6-1F97-45A5-A8E3-186DBB1219ED@tik.ee.ethz.ch> <56CEB129.10307@ericsson.com> <1456422154539.54776@cisco.com> <1456505429198.23062@cisco.com> <4423F12C-8D64-48EF-BEF2-017FB8171222@tik.ee.ethz.ch>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.152.13.77] Content-Type: multipart/alternative; boundary="_000_145678578909425849ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rmcat WG \(rmcat@ietf.org\)" , Zaheduzzaman Sarker , =?utf-8?B?QW5uYSBCcnVuc3Ryw7Zt?= Subject: Re: [rmcat] Wireless test cases X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 22:43:14 -0000 --_000_145678578909425849ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCLVGhpcyBpcyBteSB2aWV3IHRvby4NCg0KDQpJIHN0aWxsIGJlbGlldmUgdGhhdCBpdCdzIGlt cG9ydGFudCB0byB1bmRlcnN0YW5kIGNhbmRpZGF0ZSBzb2x1dGlvbiBiZWhhdmlvciBvdmVyIHdp cmVsZXNzLiBNeSBjb2xsZWFndWVzIGFuZCBJIGFyZSBhY3RpdmVseSB3b3JraW5nIG9uIHRoYXQu ICBJIGp1c3QgZG9uJ3QgdGhpbmsgaXQncyByZWFsaXN0aWMgdG8gdGllIHRoZSBwcm9ncmVzcyBv ZiB0aGUgY2FuZGlkYXRlIHNvbHV0aW9uIGRyYWZ0cyB0byBzdWNoIGV2YWx1YXRpb25zLCBmb3Ig dHdvIHJlYXNvbnM6DQoNCmEpICB0aGUgd2lyZWxlc3MgdGVzdCBjYXNlIGRyYWZ0IGl0c2VsZiBp cyBzdGlsbCBldm9sdmluZzsNCg0KYikgIGZvbGtzIGhhdmUgbm90IHlldCBjb252ZXJnZWQgb24g YSBjb21tb24gcGxhdGZvcm0gKHRlc3RiZWQgb3Igc2ltdWxhdGlvbikgZm9yIGNhcnJ5aW5nIG91 dCB3aXJlbGVzcyB0ZXN0cy4gVGhhdCBtYWtlcyBpdCBoYXJkIHRvIGNvbXBhcmUgYWNyb3NzIGNh bmRpZGF0ZSBzb2x1dGlvbnMuDQoNCg0KVGhhbmtzLA0KDQpYaWFvcWluZw0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogU3RlZmFuIEhvbG1lciA8c3RlZmFuQHdlYnJ0 Yy5vcmc+DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI5LCAyMDE2IDc6MzggQU0NClRvOiBNaXJq YSBLw7xobGV3aW5kOyBYaWFvcWluZyBaaHUgKHhpYW9xemh1KQ0KQ2M6IFphaGVkdXp6YW1hbiBT YXJrZXI7IHJtY2F0IFdHIChybWNhdEBpZXRmLm9yZyk7IEFubmEgQnJ1bnN0csO2bQ0KU3ViamVj dDogUmU6IFtybWNhdF0gV2lyZWxlc3MgdGVzdCBjYXNlcw0KDQpJIGRvbid0IHRoaW5rIHdlIHNo b3VsZCByZXF1aXJlIG1vYmlsZS93aXJlbGVzcyBldmFsdWF0aW9uIHJlc3VsdHMgYmVmb3JlIGV4 cGVyaW1lbnRhbCBwdWJsaWNhdGlvbi4gSSB0aGluayB3ZSBoYXZlIHByb29mIGVub3VnaCBmcm9t IHRoZSBiYXNlIHRlc3QgY2FzZXMsIGVzcGVjaWFsbHkgd2l0aCB0aGUgZXh0cmEgYXJ0aWZpY2lh bCBqaXR0ZXIgYW5kIGZhc3QgY2FwYWNpdHkgY2hhbmdlcy4NCg0KL1N0ZWZhbg0KDQpPbiBGcmks IEZlYiAyNiwgMjAxNiBhdCA2OjEwIFBNIE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdp bmRAdGlrLmVlLmV0aHouY2g8bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+ PiB3cm90ZToNCkhpIGFsbCwNCg0KdGhhbmtzIGZvciB5b3UgZmVlZGJhY2suDQoNClRoaXMgYnJp bmdzIG1lIGJhY2sgdG8gbXkgb3JpZ2luYWwgcXVlc3Rpb246IFdvdWxkIHRoZSB3b3JraW5nIGdy b3VwIHJlcXVpcmUgdG8gc2VlIGV2YWx1YXRpb24gcmVzdWx0cyB0byB0aGUgbW9iaWxlIGFuZCB3 aXJlbGVzcyB0ZXN0IGNhc2VzIGJlZm9yZSBtb3ZpbmcgdG8gcHVibGljYXRpb24gZm9yIGV4cGVy aW1lbnRhbCBvciBhcmUgdGhlIGJhc2ljIHRlc3QgY2FzZXMgKGluIGRyYWZ0LWlldGYtcm1jYXQt ZXZhbC10ZXN0LTAyKSBzdWZmaWNpZW50IHRvIG1vdmUgb24gYW5kIGNsYXNzaWZ5IHRoZSBjYW5k aWRhdGVzIHRvIGJlIHNhZmUgZm9yIGV4cGVyaW1lbnRhdGlvbiBpbiB0aGUgSW50ZXJuZXQ/DQoN Ck1pcmphDQoNCg0KPiBBbSAyNi4wMi4yMDE2IHVtIDE3OjUwIHNjaHJpZWIgWGlhb3FpbmcgWmh1 ICh4aWFvcXpodSkgPHhpYW9xemh1QGNpc2NvLmNvbTxtYWlsdG86eGlhb3F6aHVAY2lzY28uY29t Pj46DQo+DQo+IOKAi0kgd2lsbCBsb29rIGludG8gc2hhcmluZyB0aGUgTlMzIGNvZGUvc2NyaXB0 IGZvciBXaUZpIHRlc3RzLg0KPg0KPiBBcyBmb3IgTFRFIHRlc3QgY2FzZXM6ICBpdCdzIGdvb2Qg dG8ga25vdyB0aGF0IGl0IGNhbiBiZSBkb25lLiAgQnV0LCBzaW5jZSB0aGVyZSBpcyBubyBwcmVj ZWRlbmNlIHRvIGZvbGxvdywgdGhpcyBtYXkgdGFrZSBzdWJzdGFudGlhbCB0aW1lIGFuZCBlZmZv cnQuIFNvIHdlIG1heSBub3QgZ2V0IGFyb3VuZCB0byB0YWNrbGUgdGhhdCBzb29uLg0KPg0KPiBU aGFua3MsDQo+IFhpYW9xaW5nDQo+DQo+IEZyb206IFN0ZWZhbiBIb2xtZXIgPHN0ZWZhbkB3ZWJy dGMub3JnPG1haWx0bzpzdGVmYW5Ad2VicnRjLm9yZz4+DQo+IFNlbnQ6IEZyaWRheSwgRmVicnVh cnkgMjYsIDIwMTYgMTI6NTUgQU0NCj4gVG86IFphaGVkdXp6YW1hbiBTYXJrZXI7IFhpYW9xaW5n IFpodSAoeGlhb3F6aHUpOyBNaXJqYSBLw7xobGV3aW5kDQo+IENjOiBybWNhdCBXRyAocm1jYXRA aWV0Zi5vcmc8bWFpbHRvOnJtY2F0QGlldGYub3JnPik7IEFubmEgQnJ1bnN0csO2bQ0KPiBTdWJq ZWN0OiBSZTogW3JtY2F0XSBXaXJlbGVzcyB0ZXN0IGNhc2VzDQo+DQo+IEFzIGEgZmlyc3Qgc3Rl cCB3ZSdsbCBwcm9iYWJseSBsb29rIGludG8gYXQgbGVhc3Qgc29tZSBvZiB0aGUgd2lmaSB0ZXN0 IGNhc2VzLCBidXQgSSBkb24ndCBrbm93IGhvdyBzb29uIHdlIGNhbiBoYXZlIHRob3NlIGRvbmUu IE91ciBjdXJyZW50IGZvY3VzIGlzIG9uIGltcHJvdmluZyB0aGUgbG9zcy1iYXNlZCBwYXJ0IG9m IEdDQywgYW5kIGFmdGVyIHRoYXQgd2UgY2FuIGZvY3VzIG9uIGZ1cnRoZXIgdGVzdHMuDQo+DQo+ IElmIGl0J3MgcmVhc29uYWJseSBzaW1wbGUgdG8gcnVuIGx0ZSB0ZXN0cyB0aGVuIGl0IHNvdW5k cyBnb29kIHRvIHJ1biBzb21lIG9mIHRob3NlIHRvby4gSWYgd2UgY2FuIHNoYXJlIGNvZGUgdG8g c2V0IHVwIE5TMyBmb3Igd2lmaSBhbmQgbHRlIHRlc3RzLCB0aGF0IHdvdWxkIGJlIGdyZWF0Lg0K Pg0KPiAvU3RlZmFuDQo+DQo+IE9uIEZyaSwgRmViIDI2LCAyMDE2IGF0IDg6NTEgQU0gWmFoZWR1 enphbWFuIFNhcmtlciA8emFoZWR1enphbWFuLnNhcmtlckBlcmljc3Nvbi5jb208bWFpbHRvOnph aGVkdXp6YW1hbi5zYXJrZXJAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQo+IEhpLA0KPg0KPiBXZSBk aWRuJ3QgdXNlZCBOUy0zIHNpbXVsYXRvciB0byBldmFsdWF0aW9uIFNDUmVBTSBvdmVyIExURSwg d2UgdXNlZCBvdXIgcHJvcHJpZXRhcnkgc2ltdWxhdG9yLg0KPiBIb3dldmVyLCBJIGhhdmUgbG9v a2VkIGludG8gdGhlIE5TLTMgc2ltdWxhdG9yIGFuZCB0YWxrZWQgd2l0aCB0aGUgTFRFIG1vZHVs ZSBpbXBsZW1lbnRlciBvZiBOUy0zIChMVU5BKS4gTXkgY29uY2x1c2lvbiBpcywgdGhlIGRyYWZ0 IGNhbiBiZSByZWFsaXplZCBpbiB0aGUgTlMtMyBzaW11bGF0b3IuDQo+DQo+IEJSDQo+DQo+IFph aGVkDQo+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBYaWFvcWlu ZyBaaHUgKHhpYW9xemh1KSBbbWFpbHRvOnhpYW9xemh1QGNpc2NvLmNvbTxtYWlsdG86eGlhb3F6 aHVAY2lzY28uY29tPl0NCj4gPiBTZW50OiBkZW4gMjUgZmVicnVhcmkgMjAxNiAxODo0Mw0KPiA+ IFRvOiBaYWhlZHV6emFtYW4gU2Fya2VyOyBNaXJqYSBLw7xobGV3aW5kDQo+ID4gQ2M6IHJtY2F0 IFdHIChybWNhdEBpZXRmLm9yZzxtYWlsdG86cm1jYXRAaWV0Zi5vcmc+KTsgQW5uYSBCcnVuc3Ry w7ZtDQo+ID4gU3ViamVjdDogUmU6IFtybWNhdF0gV2lyZWxlc3MgdGVzdCBjYXNlcw0KPiA+DQo+ ID4gVGhhbmtzIGZvciB0aGUgcG9pbnRlciwgWmFoZWQuICBUaGF0J3MgYSBnb29kIHBsYWNlIHRv IHN0YXJ0LiAgV291bGQgaXQgYmUNCj4gPiBwb3NzaWJsZSBmb3IgeW91IHRvIHNoYXJlIHlvdXIg TlMtMyBjb2RlL3NjcmlwdCBmb3IgdGVzdGluZyBTQ1JlQU0gb3ZlciBMVEU/DQo+ID4NCj4gPiBC VFcsIHlvdSBtYXkgd2FudCB0byB1cGRhdGUgdGhlIGNvcnJlc3BvbmRpbmcgbGluayBpbiB0aGUg d2lyZWxlc3MtdGVzdC1jYXNlDQo+ID4gZG9jdW1lbnQuIEN1cnJlbnRseSwgdGhlIHJlZmVyZW5j ZSBvbiBbTFRFLXNpbXVsYXRvcl0gcG9pbnRzIHRvIHRoZSBOUy0zDQo+ID4gbWFudWFsLg0KPiA+ DQo+ID4gQmVzdCwNCj4gPiBYaWFvcWluZw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+IEZyb206IFphaGVkdXp6YW1hbiBTYXJrZXIgPHphaGVk dXp6YW1hbi5zYXJrZXJAZXJpY3Nzb24uY29tPG1haWx0bzp6YWhlZHV6emFtYW4uc2Fya2VyQGVy aWNzc29uLmNvbT4+DQo+ID4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAxMTo0 NSBQTQ0KPiA+IFRvOiBNaXJqYSBLw7xobGV3aW5kOyBYaWFvcWluZyBaaHUgKHhpYW9xemh1KQ0K PiA+IENjOiBybWNhdCBXRyAocm1jYXRAaWV0Zi5vcmc8bWFpbHRvOnJtY2F0QGlldGYub3JnPik7 IEFubmEgQnJ1bnN0csO2bQ0KPiA+IFN1YmplY3Q6IFJlOiBbcm1jYXRdIFdpcmVsZXNzIHRlc3Qg Y2FzZXMNCj4gPg0KPiA+IFllcywNCj4gPg0KPiA+IE5TLTMgaGFzIG5lY2Vzc2FyeSBtb2R1bGVz IHRvIHJ1biBMVEUgc2ltdWxhdGlvbnMuDQo+ID4NCj4gPiBodHRwczovL3d3dy5uc25hbS5vcmcv ZG9jcy9tb2RlbHMvaHRtbC9sdGUuaHRtbA0KPiA+DQo+ID4gQlINCj4gPg0KPiA+IFphaGVkDQo+ ID4NCj4gPiBPbiAwMi8yNC8yMDE2IDA2OjAyIFBNLCBNaXJqYSBLw7xobGV3aW5kIHdyb3RlOg0K PiA+ID4gSGkgWGlhb3FpbmcsDQo+ID4gPg0KPiA+ID4+IEFtIDI0LjAyLjIwMTYgdW0gMTc6NTAg c2NocmllYiBYaWFvcWluZyBaaHUgKHhpYW9xemh1KQ0KPiA+IDx4aWFvcXpodUBjaXNjby5jb208 bWFpbHRvOnhpYW9xemh1QGNpc2NvLmNvbT4+Og0KPiA+ID4+DQo+ID4gPj4gSGkgTWlyamEsIGFs bCwNCj4gPiA+Pg0KPiA+ID4+IFphaGVkIGFuZCBJIGhhdmUgaW5kZWVkIGRpc2N1c3NlZCBhYm91 dCB0aGlzIGluIFlva29oYW1hLiBNYXliZSBJIGRpZCBub3QNCj4gPiBtYWtlIGl0IGNsZWFyIGlu IG15IHByZXZpb3VzIGVtYWlsLCB0cnlpbmcgYWdhaW4uDQo+ID4gPj4NCj4gPiA+PiBCYXNpY2Fs bHksIHRvIGNhcnJ5IG91dCB0ZXN0cyBpbiBTZWMgMyAoQ2VsbHVsYXIgTmV0d29yayBTcGVjaWZp YyBUZXN0IENhc2VzKSwNCj4gPiBvbmUgbmVlZHMgdG8gcnVuIGl0IG92ZXIgYSBtb2R1bGUgdGhh dCBzaW11bGF0ZXMgcGFja2V0IGJlaGF2aW9yIG92ZXIgY2VsbHVsYXINCj4gPiBsaW5rcyAtLSBq dXN0IGxpa2UgZm9yIHRoZSBXaS1GaSBwb3J0aW9uIG9mIHRoZSB0ZXN0IGNhc2VzLCB3ZSByZWxp ZWQgb24gdGhlIFdpLUZpDQo+ID4gbW9kdWxlIGluIE5TMyBzaW11bGF0b3JzIHRvIGRvIHNvLg0K PiA+ID4+DQo+ID4gPj4gV2hhdCBpcyBtaXNzaW5nIGlzIHRoZSBjZWxsdWxhciBuZXR3b3JrIHNp bXVsYXRvciwgcHJlZmVyYWJseSBhcyBhIHBsdWctaW4NCj4gPiBtb2R1bGUgZm9yIE5TMywgb3Zl ciB3aGljaCB3ZSBjYW4gcnVuIHJhdGUgYWRhcHRhdGlvbiB0ZXN0cy4NCj4gPiA+IEkgdGhvdWdo IHRoYXQgdGhpcyBpcyBhdmFpbGFibGUgaW4gdGhlIG1lYW4gdGltZS4NCj4gPiA+DQo+ID4gPiBa YWhlZCwgZG8geW91IGhhdmUgbGluayBvciBpcyB0aGlzIGFscmVhZHkgaW5jbHVkZWQgaW4gdGhl IGxhdGVzdCB2ZXJzaW9uIG9mIG5zLQ0KPiA+IDM/DQo+ID4gPg0KPiA+ID4gTWlyamENCj4gPiA+ DQo+ID4gPg0KPiA+ID4+IFRoYW5rcywNCj4gPiA+PiBYaWFvcWluZw0KPiA+ID4+DQo+ID4gPj4N Cj4gPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPj4g RnJvbTogTWlyamEgS8O8aGxld2luZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaDxt YWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD4+DQo+ID4gPj4gU2VudDogV2Vk bmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAzOjMzIEFNDQo+ID4gPj4gVG86IFhpYW9xaW5nIFpo dSAoeGlhb3F6aHUpOyBybWNhdCBXRyAocm1jYXRAaWV0Zi5vcmc8bWFpbHRvOnJtY2F0QGlldGYu b3JnPikNCj4gPiA+PiBDYzogQW5uYSBCcnVuc3Ryw7ZtOyBaYWhlZHV6emFtYW4gU2Fya2VyDQo+ ID4gPj4gU3ViamVjdDogUmU6IFtybWNhdF0gV2lyZWxlc3MgdGVzdCBjYXNlcw0KPiA+ID4+DQo+ ID4gPj4gSGkgWGlhb3FpbmcsDQo+ID4gPj4NCj4gPiA+PiBPbiAxOS4wMi4yMDE2IDIxOjI3LCBY aWFvcWluZyBaaHUgKHhpYW9xemh1KSB3cm90ZToNCj4gPiA+Pj4gQXMgZm9yIFNlYy4gMyBvbiBD ZWxsdWxhciBOZXR3b3JrIFNwZWNpZmljIFRlc3QgQ2FzZXMsIHdvdWxkDQo+ID4gPj4+IGFwcHJl Y2lhdGUgbW9yZSBkZXRhaWxlZCBpbmZvcm1hdGlvbiBvbiBob3cgdG8gc2V0IHRob3NlIHVwLCBv cg0KPiA+ID4+PiByZWxldmFudCBwb2ludGVycy9jb2RlIG9uIGNlbGx1bGFyIG5ldHdvcmsgc2lt dWxhdG9ycy4NCj4gPiA+PiBDYW4geW91IGxldCB1cy9aYWhlZCBrbm93IHdoYXQgZXhhY3RseSB5 b3UgbmVlZC9pcyBtaXNzaW5nPw0KPiA+ID4+DQo+ID4gPj4gVGhhbmtzLA0KPiA+ID4+IE1pcmph DQo+ID4NCj4NCg0K --_000_145678578909425849ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZSI+PCEtLSBwIHsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAw cHg7IH0tLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgZGlyPSJsdHIiIHN0eWxlPSJmb250LXNp emU6MTJwdDtjb2xvcjojMDAwMDAwO2JhY2tncm91bmQtY29sb3I6I0ZGRkZGRjtmb250LWZhbWls eTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmOyI+DQo8cD7igItUaGlzIGlzIG15 IHZpZXcgdG9vLiAmbmJzcDs8YnI+DQo8L3A+DQo8cD48YnI+DQo8L3A+DQo8cD5JIHN0aWxsIGJl bGlldmUgdGhhdCBpdCdzIGltcG9ydGFudCB0byB1bmRlcnN0YW5kIGNhbmRpZGF0ZSBzb2x1dGlv biBiZWhhdmlvciBvdmVyJm5ic3A7d2lyZWxlc3MuIE15IGNvbGxlYWd1ZXMgYW5kIEkmbmJzcDth cmUgYWN0aXZlbHkgd29ya2luZyBvbiB0aGF0LiZuYnNwOyZuYnNwO0kganVzdCBkb24ndCB0aGlu ayBpdCdzIHJlYWxpc3RpYyB0byB0aWUgdGhlJm5ic3A7cHJvZ3Jlc3Mgb2YgdGhlIGNhbmRpZGF0 ZSBzb2x1dGlvbiZuYnNwO2RyYWZ0cyB0byBzdWNoIGV2YWx1YXRpb25zLCBmb3INCiB0d28gcmVh c29uczo8L3A+DQo8cD5hKSZuYnNwOyZuYnNwO3RoZSB3aXJlbGVzcyB0ZXN0IGNhc2UgZHJhZnQg aXRzZWxmIGlzIHN0aWxsIGV2b2x2aW5nOzxicj4NCjwvcD4NCjxwPmIpICZuYnNwO2ZvbGtzIGhh dmUgbm90IHlldCBjb252ZXJnZWQgb24gYSBjb21tb24gcGxhdGZvcm0gKHRlc3RiZWQgb3Igc2lt dWxhdGlvbikgZm9yIGNhcnJ5aW5nIG91dCZuYnNwO3dpcmVsZXNzIHRlc3RzLiBUaGF0IG1ha2Vz IGl0IGhhcmQgdG8mbmJzcDtjb21wYXJlJm5ic3A7YWNyb3NzIGNhbmRpZGF0ZSZuYnNwO3NvbHV0 aW9ucy4mbmJzcDs8YnI+DQo8L3A+DQo8cD48YnI+DQo8L3A+DQo8cD5UaGFua3MsPGJyPg0KPC9w Pg0KPHA+WGlhb3Fpbmc8YnI+DQo8L3A+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDMzLCAzMywg MzMpOyI+DQo8aHIgdGFiaW5kZXg9Ii0xIiBzdHlsZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7IHdp ZHRoOjk4JSI+DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNnIiBkaXI9Imx0ciI+PGZvbnQgZmFjZT0i Q2FsaWJyaSwgc2Fucy1zZXJpZiIgY29sb3I9IiMwMDAwMDAiIHN0eWxlPSJmb250LXNpemU6MTFw dCI+PGI+RnJvbTo8L2I+IFN0ZWZhbiBIb2xtZXIgJmx0O3N0ZWZhbkB3ZWJydGMub3JnJmd0Ozxi cj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDI5LCAyMDE2IDc6MzggQU08YnI+DQo8 Yj5Ubzo8L2I+IE1pcmphIEvDvGhsZXdpbmQ7IFhpYW9xaW5nIFpodSAoeGlhb3F6aHUpPGJyPg0K PGI+Q2M6PC9iPiBaYWhlZHV6emFtYW4gU2Fya2VyOyBybWNhdCBXRyAocm1jYXRAaWV0Zi5vcmcp OyBBbm5hIEJydW5zdHLDtm08YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtybWNhdF0gV2lyZWxl c3MgdGVzdCBjYXNlczwvZm9udD4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IGRpcj0ibHRyIj5JIGRvbid0IHRoaW5rIHdlIHNob3VsZCByZXF1aXJlIG1vYmlsZS93aXJl bGVzcyBldmFsdWF0aW9uIHJlc3VsdHMgYmVmb3JlIGV4cGVyaW1lbnRhbCBwdWJsaWNhdGlvbi4g SSB0aGluayB3ZSBoYXZlIHByb29mIGVub3VnaCBmcm9tIHRoZSBiYXNlIHRlc3QgY2FzZXMsIGVz cGVjaWFsbHkgd2l0aCB0aGUgZXh0cmEgYXJ0aWZpY2lhbCBqaXR0ZXIgYW5kIGZhc3QgY2FwYWNp dHkgY2hhbmdlcy4NCjxkaXY+DQo8ZGl2Pjxicj4NCi9TdGVmYW48YnI+DQo8YnI+DQo8ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIj5PbiBGcmksIEZlYiAyNiwgMjAxNiBh dCA2OjEwIFBNIE1pcmphIEvDvGhsZXdpbmQgJmx0OzxhIGhyZWY9Im1haWx0bzptaXJqYS5rdWVo bGV3aW5kQHRpay5lZS5ldGh6LmNoIj5taXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPC9h PiZndDsgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDsgYm9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7IHBh ZGRpbmctbGVmdDoxZXgiPg0KSGkgYWxsLDxicj4NCjxicj4NCnRoYW5rcyBmb3IgeW91IGZlZWRi YWNrLjxicj4NCjxicj4NClRoaXMgYnJpbmdzIG1lIGJhY2sgdG8gbXkgb3JpZ2luYWwgcXVlc3Rp b246IFdvdWxkIHRoZSB3b3JraW5nIGdyb3VwIHJlcXVpcmUgdG8gc2VlIGV2YWx1YXRpb24gcmVz dWx0cyB0byB0aGUgbW9iaWxlIGFuZCB3aXJlbGVzcyB0ZXN0IGNhc2VzIGJlZm9yZSBtb3Zpbmcg dG8gcHVibGljYXRpb24gZm9yIGV4cGVyaW1lbnRhbCBvciBhcmUgdGhlIGJhc2ljIHRlc3QgY2Fz ZXMgKGluIGRyYWZ0LWlldGYtcm1jYXQtZXZhbC10ZXN0LTAyKSBzdWZmaWNpZW50DQogdG8gbW92 ZSBvbiBhbmQgY2xhc3NpZnkgdGhlIGNhbmRpZGF0ZXMgdG8gYmUgc2FmZSBmb3IgZXhwZXJpbWVu dGF0aW9uIGluIHRoZSBJbnRlcm5ldD88YnI+DQo8YnI+DQpNaXJqYTxicj4NCjxicj4NCjxicj4N CiZndDsgQW0gMjYuMDIuMjAxNiB1bSAxNzo1MCBzY2hyaWViIFhpYW9xaW5nIFpodSAoeGlhb3F6 aHUpICZsdDs8YSBocmVmPSJtYWlsdG86eGlhb3F6aHVAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFu ayIgY2xhc3M9ImNyZW1lZCI+eGlhb3F6aHVAY2lzY28uY29tPC9hPiZndDs6PGJyPg0KJmd0Ozxi cj4NCiZndDsg4oCLSSB3aWxsIGxvb2sgaW50byBzaGFyaW5nIHRoZSBOUzMgY29kZS9zY3JpcHQg Zm9yIFdpRmkgdGVzdHMuPGJyPg0KJmd0Ozxicj4NCiZndDsgQXMgZm9yIExURSB0ZXN0IGNhc2Vz OiZuYnNwOyBpdCdzIGdvb2QgdG8ga25vdyB0aGF0IGl0IGNhbiBiZSBkb25lLiZuYnNwOyBCdXQs IHNpbmNlIHRoZXJlIGlzIG5vIHByZWNlZGVuY2UgdG8gZm9sbG93LCB0aGlzIG1heSB0YWtlIHN1 YnN0YW50aWFsIHRpbWUgYW5kIGVmZm9ydC4gU28gd2UgbWF5IG5vdCBnZXQgYXJvdW5kIHRvIHRh Y2tsZSB0aGF0IHNvb24uPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDsgWGlh b3Fpbmc8YnI+DQomZ3Q7PGJyPg0KJmd0OyBGcm9tOiBTdGVmYW4gSG9sbWVyICZsdDs8YSBocmVm PSJtYWlsdG86c3RlZmFuQHdlYnJ0Yy5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iY3JlbWVk Ij5zdGVmYW5Ad2VicnRjLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyBTZW50OiBGcmlkYXksIEZlYnJ1 YXJ5IDI2LCAyMDE2IDEyOjU1IEFNPGJyPg0KJmd0OyBUbzogWmFoZWR1enphbWFuIFNhcmtlcjsg WGlhb3FpbmcgWmh1ICh4aWFvcXpodSk7IE1pcmphIEvDvGhsZXdpbmQ8YnI+DQomZ3Q7IENjOiBy bWNhdCBXRyAoPGEgaHJlZj0ibWFpbHRvOnJtY2F0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9ImNyZW1lZCI+cm1jYXRAaWV0Zi5vcmc8L2E+KTsgQW5uYSBCcnVuc3Ryw7ZtPGJyPg0K Jmd0OyBTdWJqZWN0OiBSZTogW3JtY2F0XSBXaXJlbGVzcyB0ZXN0IGNhc2VzPGJyPg0KJmd0Ozxi cj4NCiZndDsgQXMgYSBmaXJzdCBzdGVwIHdlJ2xsIHByb2JhYmx5IGxvb2sgaW50byBhdCBsZWFz dCBzb21lIG9mIHRoZSB3aWZpIHRlc3QgY2FzZXMsIGJ1dCBJIGRvbid0IGtub3cgaG93IHNvb24g d2UgY2FuIGhhdmUgdGhvc2UgZG9uZS4gT3VyIGN1cnJlbnQgZm9jdXMgaXMgb24gaW1wcm92aW5n IHRoZSBsb3NzLWJhc2VkIHBhcnQgb2YgR0NDLCBhbmQgYWZ0ZXIgdGhhdCB3ZSBjYW4gZm9jdXMg b24gZnVydGhlciB0ZXN0cy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJZiBpdCdzIHJlYXNvbmFibHkg c2ltcGxlIHRvIHJ1biBsdGUgdGVzdHMgdGhlbiBpdCBzb3VuZHMgZ29vZCB0byBydW4gc29tZSBv ZiB0aG9zZSB0b28uIElmIHdlIGNhbiBzaGFyZSBjb2RlIHRvIHNldCB1cCBOUzMgZm9yIHdpZmkg YW5kIGx0ZSB0ZXN0cywgdGhhdCB3b3VsZCBiZSBncmVhdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAv U3RlZmFuPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gRnJpLCBGZWIgMjYsIDIwMTYgYXQgODo1MSBB TSBaYWhlZHV6emFtYW4gU2Fya2VyICZsdDs8YSBocmVmPSJtYWlsdG86emFoZWR1enphbWFuLnNh cmtlckBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iY3JlbWVkIj56YWhlZHV6 emFtYW4uc2Fya2VyQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgSGksPGJy Pg0KJmd0Ozxicj4NCiZndDsgV2UgZGlkbid0IHVzZWQgTlMtMyBzaW11bGF0b3IgdG8gZXZhbHVh dGlvbiBTQ1JlQU0gb3ZlciBMVEUsIHdlIHVzZWQgb3VyIHByb3ByaWV0YXJ5IHNpbXVsYXRvci48 YnI+DQomZ3Q7IEhvd2V2ZXIsIEkgaGF2ZSBsb29rZWQgaW50byB0aGUgTlMtMyBzaW11bGF0b3Ig YW5kIHRhbGtlZCB3aXRoIHRoZSBMVEUgbW9kdWxlIGltcGxlbWVudGVyIG9mIE5TLTMgKExVTkEp LiBNeSBjb25jbHVzaW9uIGlzLCB0aGUgZHJhZnQgY2FuIGJlIHJlYWxpemVkIGluIHRoZSBOUy0z IHNpbXVsYXRvci48YnI+DQomZ3Q7PGJyPg0KJmd0OyBCUjxicj4NCiZndDs8YnI+DQomZ3Q7IFph aGVkPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCiZndDsgJmd0OyBGcm9tOiBYaWFvcWluZyBaaHUgKHhpYW9xemh1KSBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzp4aWFvcXpodUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iY3Jl bWVkIj54aWFvcXpodUBjaXNjby5jb208L2E+XTxicj4NCiZndDsgJmd0OyBTZW50OiBkZW4gMjUg ZmVicnVhcmkgMjAxNiAxODo0Mzxicj4NCiZndDsgJmd0OyBUbzogWmFoZWR1enphbWFuIFNhcmtl cjsgTWlyamEgS8O8aGxld2luZDxicj4NCiZndDsgJmd0OyBDYzogcm1jYXQgV0cgKDxhIGhyZWY9 Im1haWx0bzpybWNhdEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSJjcmVtZWQiPnJt Y2F0QGlldGYub3JnPC9hPik7IEFubmEgQnJ1bnN0csO2bTxicj4NCiZndDsgJmd0OyBTdWJqZWN0 OiBSZTogW3JtY2F0XSBXaXJlbGVzcyB0ZXN0IGNhc2VzPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IFRoYW5rcyBmb3IgdGhlIHBvaW50ZXIsIFphaGVkLiZuYnNwOyBUaGF0J3MgYSBnb29k IHBsYWNlIHRvIHN0YXJ0LiZuYnNwOyBXb3VsZCBpdCBiZTxicj4NCiZndDsgJmd0OyBwb3NzaWJs ZSBmb3IgeW91IHRvIHNoYXJlIHlvdXIgTlMtMyBjb2RlL3NjcmlwdCBmb3IgdGVzdGluZyBTQ1Jl QU0gb3ZlciBMVEU/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEJUVywgeW91IG1heSB3 YW50IHRvIHVwZGF0ZSB0aGUgY29ycmVzcG9uZGluZyBsaW5rIGluIHRoZSB3aXJlbGVzcy10ZXN0 LWNhc2U8YnI+DQomZ3Q7ICZndDsgZG9jdW1lbnQuIEN1cnJlbnRseSwgdGhlIHJlZmVyZW5jZSBv biBbTFRFLXNpbXVsYXRvcl0gcG9pbnRzIHRvIHRoZSBOUy0zPGJyPg0KJmd0OyAmZ3Q7IG1hbnVh bC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQmVzdCw8YnI+DQomZ3Q7ICZndDsgWGlh b3Fpbmc8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBGcm9tOiBaYWhlZHV6emFtYW4gU2Fy a2VyICZsdDs8YSBocmVmPSJtYWlsdG86emFoZWR1enphbWFuLnNhcmtlckBlcmljc3Nvbi5jb20i IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iY3JlbWVkIj56YWhlZHV6emFtYW4uc2Fya2VyQGVyaWNz c29uLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkg MjQsIDIwMTYgMTE6NDUgUE08YnI+DQomZ3Q7ICZndDsgVG86IE1pcmphIEvDvGhsZXdpbmQ7IFhp YW9xaW5nIFpodSAoeGlhb3F6aHUpPGJyPg0KJmd0OyAmZ3Q7IENjOiBybWNhdCBXRyAoPGEgaHJl Zj0ibWFpbHRvOnJtY2F0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9ImNyZW1lZCI+ cm1jYXRAaWV0Zi5vcmc8L2E+KTsgQW5uYSBCcnVuc3Ryw7ZtPGJyPg0KJmd0OyAmZ3Q7IFN1Ympl Y3Q6IFJlOiBbcm1jYXRdIFdpcmVsZXNzIHRlc3QgY2FzZXM8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgWWVzLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBOUy0zIGhhcyBuZWNl c3NhcnkgbW9kdWxlcyB0byBydW4gTFRFIHNpbXVsYXRpb25zLjxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5uc25hbS5vcmcvZG9jcy9tb2RlbHMvaHRt bC9sdGUuaHRtbCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9ImNyZW1l ZCI+DQpodHRwczovL3d3dy5uc25hbS5vcmcvZG9jcy9tb2RlbHMvaHRtbC9sdGUuaHRtbDwvYT48 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQlI8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgWmFoZWQ8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgT24gMDIvMjQvMjAxNiAw NjowMiBQTSwgTWlyamEgS8O8aGxld2luZCB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyBIaSBY aWFvcWluZyw8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBBbSAy NC4wMi4yMDE2IHVtIDE3OjUwIHNjaHJpZWIgWGlhb3FpbmcgWmh1ICh4aWFvcXpodSk8YnI+DQom Z3Q7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzp4aWFvcXpodUBjaXNjby5jb20iIHRhcmdldD0i X2JsYW5rIiBjbGFzcz0iY3JlbWVkIj54aWFvcXpodUBjaXNjby5jb208L2E+Jmd0Ozo8YnI+DQom Z3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgSGkgTWlyamEsIGFsbCw8 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgWmFoZWQgYW5k IEkgaGF2ZSBpbmRlZWQgZGlzY3Vzc2VkIGFib3V0IHRoaXMgaW4gWW9rb2hhbWEuIE1heWJlIEkg ZGlkIG5vdDxicj4NCiZndDsgJmd0OyBtYWtlIGl0IGNsZWFyIGluIG15IHByZXZpb3VzIGVtYWls LCB0cnlpbmcgYWdhaW4uPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn dDsmZ3Q7IEJhc2ljYWxseSwgdG8gY2Fycnkgb3V0IHRlc3RzIGluIFNlYyAzIChDZWxsdWxhciBO ZXR3b3JrIFNwZWNpZmljIFRlc3QgQ2FzZXMpLDxicj4NCiZndDsgJmd0OyBvbmUgbmVlZHMgdG8g cnVuIGl0IG92ZXIgYSBtb2R1bGUgdGhhdCBzaW11bGF0ZXMgcGFja2V0IGJlaGF2aW9yIG92ZXIg Y2VsbHVsYXI8YnI+DQomZ3Q7ICZndDsgbGlua3MgLS0ganVzdCBsaWtlIGZvciB0aGUgV2ktRmkg cG9ydGlvbiBvZiB0aGUgdGVzdCBjYXNlcywgd2UgcmVsaWVkIG9uIHRoZSBXaS1GaTxicj4NCiZn dDsgJmd0OyBtb2R1bGUgaW4gTlMzIHNpbXVsYXRvcnMgdG8gZG8gc28uPGJyPg0KJmd0OyAmZ3Q7 ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IFdoYXQgaXMgbWlzc2luZyBpcyB0aGUg Y2VsbHVsYXIgbmV0d29yayBzaW11bGF0b3IsIHByZWZlcmFibHkgYXMgYSBwbHVnLWluPGJyPg0K Jmd0OyAmZ3Q7IG1vZHVsZSBmb3IgTlMzLCBvdmVyIHdoaWNoIHdlIGNhbiBydW4gcmF0ZSBhZGFw dGF0aW9uIHRlc3RzLjxicj4NCiZndDsgJmd0OyAmZ3Q7IEkgdGhvdWdoIHRoYXQgdGhpcyBpcyBh dmFpbGFibGUgaW4gdGhlIG1lYW4gdGltZS48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7IFphaGVkLCBkbyB5b3UgaGF2ZSBsaW5rIG9yIGlzIHRoaXMgYWxyZWFkeSBpbmNs dWRlZCBpbiB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgbnMtPGJyPg0KJmd0OyAmZ3Q7IDM/PGJyPg0K Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBNaXJqYTxicj4NCiZndDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgVGhhbmtzLDxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBYaWFvcWluZzxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IEZy b206IE1pcmphIEvDvGhsZXdpbmQgJmx0OzxhIGhyZWY9Im1haWx0bzptaXJqYS5rdWVobGV3aW5k QHRpay5lZS5ldGh6LmNoIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9ImNyZW1lZCI+bWlyamEua3Vl aGxld2luZEB0aWsuZWUuZXRoei5jaDwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IFNl bnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgMzozMyBBTTxicj4NCiZndDsgJmd0OyAm Z3Q7Jmd0OyBUbzogWGlhb3FpbmcgWmh1ICh4aWFvcXpodSk7IHJtY2F0IFdHICg8YSBocmVmPSJt YWlsdG86cm1jYXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iY3JlbWVkIj5ybWNh dEBpZXRmLm9yZzwvYT4pPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IENjOiBBbm5hIEJydW5zdHLD tm07IFphaGVkdXp6YW1hbiBTYXJrZXI8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgU3ViamVjdDog UmU6IFtybWNhdF0gV2lyZWxlc3MgdGVzdCBjYXNlczxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBIaSBYaWFvcWluZyw8YnI+DQomZ3Q7ICZndDsgJmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgT24gMTkuMDIuMjAxNiAyMToyNywgWGlhb3Fpbmcg Wmh1ICh4aWFvcXpodSkgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBBcyBmb3Ig U2VjLiAzIG9uIENlbGx1bGFyIE5ldHdvcmsgU3BlY2lmaWMgVGVzdCBDYXNlcywgd291bGQ8YnI+ DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGFwcHJlY2lhdGUgbW9yZSBkZXRhaWxlZCBpbmZvcm1h dGlvbiBvbiBob3cgdG8gc2V0IHRob3NlIHVwLCBvcjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZn dDsgcmVsZXZhbnQgcG9pbnRlcnMvY29kZSBvbiBjZWxsdWxhciBuZXR3b3JrIHNpbXVsYXRvcnMu PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IENhbiB5b3UgbGV0IHVzL1phaGVkIGtub3cgd2hhdCBl eGFjdGx5IHlvdSBuZWVkL2lzIG1pc3Npbmc/PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgTWlyamE8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_145678578909425849ciscocom_--