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 3ECFF1A8AEE; Wed, 26 Aug 2015 08:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Vpzl7QKmookv; Wed, 26 Aug 2015 08:08:30 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274871A8AE0; Wed, 26 Aug 2015 08:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23341; q=dns/txt; s=iport; t=1440601710; x=1441811310; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sXIZgNdrW1GRu2DTYnbftVehB3Vx0ai2fY4q/GNilro=; b=aDR3PIicoLeCyxgF5iaTQtThRPWIYSXKiqIc8rW88oVj7Ss0eV4oZ5vr QGZUktEBAxf8jsPP5Yqe4b40bGeo/7krBrBS9eLhmROm01HmjTz4Fs2/s ozUk+wOLgFiLQr7+z4/aqH0NfshWi/d/wfJmBFwnFmG7IV54TVUU2V3yJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CIAgB51d1V/4QNJK1dgk5NgT0GvWIBCYZjgRACgTo4FAEBAQEBAQGBCoQjAQEBBC1BCxACAQgRAwEBASgHMhQJCAIEAQ0FiC7IegEBAQEBAQEBAQEBAQEBAQEBAQEBAReKWIEDhHkRBgGELAWMa4U2gxYBjHGBSoQyjCyESYNqJoN+cYFIgQQBAQE X-IronPort-AV: E=Sophos; i="5.17,416,1437436800"; d="scan'208,217"; a="21786424" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP; 26 Aug 2015 15:08:29 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t7QF8T5S009633 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Aug 2015 15:08:29 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 26 Aug 2015 10:08:28 -0500 Received: from xhc-rcd-x05.cisco.com (173.37.183.79) by xch-rcd-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 26 Aug 2015 10:08:28 -0500 Received: from xmb-rcd-x01.cisco.com ([169.254.1.191]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0248.002; Wed, 26 Aug 2015 10:08:28 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: "Sergio Mena de la Cruz (semena)" , Zaheduzzaman Sarker Thread-Topic: Sections 5.1 and 5.2 of draft-ietf-rmcat-eval-test-01 Thread-Index: AQHQ1cPMOMHy7axU30OV0G2Tiz2fRp4bbSGAgALewoCAACqyAA== Date: Wed, 26 Aug 2015 15:08:27 +0000 Message-ID: References: <55CC8DC7.40903@cisco.com> <55DD6C49.1050901@cisco.com> In-Reply-To: <55DD6C49.1050901@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [173.37.102.30] Content-Type: multipart/alternative; boundary="_000_D203239425D91xiaoqzhuciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rmcat@ietf.org" , "draft-ietf-rmcat-eval-test@ietf.org" Subject: Re: [rmcat] Sections 5.1 and 5.2 of draft-ietf-rmcat-eval-test-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: Wed, 26 Aug 2015 15:08:33 -0000 --_000_D203239425D91xiaoqzhuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I concur with Sergio=92s suggestions. One thought: instead of stating variation within each sub-section, we can s= tate that there exists two options of changing bandwidth in the beginning o= f Sec 5. This will also be consistent with the option/flexibility we now of= fer for folks to pick different initial capacities and scale rest of the BW= values accordingly. Best, Xiaoqing From: "Sergio Mena de la Cruz (semena)" > Date: Wednesday, August 26, 2015 at 12:35 AM To: Zaheduzzaman Sarker > Cc: "draft-ietf-rmcat-eval-test@ietf.org" >, "rmcat@ietf.org" > Subject: Re: Sections 5.1 and 5.2 of draft-ietf-rmcat-eval-test-01 Hi Zahed, First of all, your question. By "insensitive traffic" I meant that the flow= is CBR, so it won't back off whether other traffic is present in the bottl= eneck link or not. Maybe we can find a better name for this... On the other hand, in the last days, I have been working on an ns3 implemen= tation of some of the test cases in the draft. I realized that it would be = coherent (and useful, IMO) for 5.3 to also have a "b" version where both fo= rward and backward paths are changed by a CBR, similarly to 5.1 and 5.2. Le= t me know your thoughts on this. Regards, Sergio On 24/08/15 13:45, Zaheduzzaman Sarker wrote: Hi Sergio, Thanks for your effort. I think the proposed changes looks good. As we have plan to update the variation of path capacity relative to initia= l path capacity for test case 5.1 and test case 5.2, we need to change the = respective text in the 5.1b and 5.2b to be aligned with that. One clarification question : in 5.1b what does the =93insensitive traffic= =94 means in the new text? BR Zahed From: Sergio Mena [mailto:semena@cisco.com] Sent: den 13 augusti 2015 14:30 To: Zaheduzzaman Sarker Cc: draft-ietf-rmcat-eval-test@ietf.org; rmcat@ietf.org Subject: Sections 5.1 and 5.2 of draft-ietf-rmcat-eval-test-01 Zahed, [CCed the author list of the rmcat test cases draft, as well as the rmcat m= ailing list] There was a discussion triggered at rmcat main session in Prague on how to = simulate bottleneck-link bandwidth changes. Two options were discussed (1) = changing the physical link throughput (currently specified in the draft), a= nd (2) using an insensitive CBR UDP flow as background traffic. My understanding from the discussion during the session was that none of th= ese two options can simulate the other and, therefore, we somehow need to t= est how candidate algorithms adapt in both cases. You and I then had an offline discussion on the subject in which you sugges= ted me to review sections 5.1 and 5.2 of the test cases draft, and propose = an alternate text to extend these two test cases to the background traffic = option. I have reviewed sections 5.1 and 5.2 and come up with a proposal for extend= ing them to using insensitive background traffic, in addition to the curren= t option in the text (physical link throughput change). Please find below what I would like to propose as updated text for 5.1 and = 5.2. [Text in square brackets are instructions to locate and replace the or= iginal text]. Thanks, Sergio Mena PS Proposed changes: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Section 5.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [In the three-bullet list after the first paragraph, change the text in the= second bullet from:] o change in available capacity (e.g., due to interface change, routing change). [to] o change in available capacity (e.g., due to interface change, routing change, sharp change in background traffic). --- [Replace the paragraph immediately after the three-bullet list mentioned ab= ove, the one that starts with] It should be noted that the exact variation... [with the following] The test case defined in this section (5.1) is divided into two subcases 5.= 1a and 5.1b. The main difference is how the bottleneck-link capacity is changed in the testbed. I= n 5.1a, the goal is to simulate a modification in the underlying physical properties, such as rout= ing change or interface change. In 5.1b, the goal is to simulate a sharp change in background traff= ic to which the candidate algorithm is to adapt. --- [Change the last item of testbed attributes from] * Competing traffic: + Number of sources : Zero (0) [to] * Competing traffic: + In 5.1a - Number of sources : Zero (0) + In 5.1b - Number of sources : One (1) - Type of sources : CBR traffic - Sending bitrate : See test specific information below. - Traffic direction : Forward - Congestion control : None (insensitive traffic) - Traffic timeline: - Start time : 0s - End time : 100s --- [Change 2nd bullet of test-specific information from] * This test uses bottleneck path capacity variation as listed in Table 1 [to] * This test uses bottleneck path capacity variation as listed in Table 1. - In 5.1a, the path capacity transitions are achieved by instantly= changing the physical throughput of the bottleneck link. For simplicity, when= changing the bottleneck link throughput, other parameters such as queue l= ength in packets will be left unchanged, even if it implies that the new = queue has a different length in milliseconds. - In 5.1b, the path capacity transitions are achieved by instantly= changing the sending bitrate of the competing CBR flow. The new sending bitra= te must be the difference between the bottleneck link-capacity (4 Mbps, as = specified in 4.2) and the capacity specified in Table 1. The sharp bitrate change in the CBR flow might imply the losses = on both the application-related traffic and the CBR flow. As a result, the r= eaction of the candidate algorithm might be different in 5.1a and in 5.1b, = hence the distinction between the two sub-cases. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Section 5.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [Insert this after the first paragraph of the section] Analogously to Section 5.1, the present test case (5.2) is divided into two= subcases 5.2a and 5.2b. The main difference is the same: 5.2a simulates a change in the underlying = physical network properties, such as routing change or interface change; whereas 5.2b simulates a sharp = change in background competing traffic. --- [Change last paragraph from] Test Specific Information: This test uses path capacity variation as listed in Table 2 with a corresponding end time of 125 seconds. [to] Test Specific Information: This test uses path capacity variation as listed in Table 2 with a corresponding end time of 125 seconds. The two media flows stop at time 124. --_000_D203239425D91xiaoqzhuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I concur with Sergio=92s suggestions.   

One thought: instead of stating variation within each sub-section, we = can state that there exists two options of changing bandwidth in the beginn= ing of Sec 5. This will also be consistent with the option/flexibility we n= ow offer for folks to pick different initial capacities and scale rest of the BW values accordingly. 

Best,
Xiaoqing


From: "Sergio Mena de la Cruz = (semena)" <semena@cisco.com= >
Date: Wednesday, August 26, 2015 at= 12:35 AM
To: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.c= om>
Cc: "draft-ietf-rmcat-eval-test@ietf.org"= <draft-ietf-rmca= t-eval-test@ietf.org>, "rmcat= @ietf.org" <rmcat@ietf.org>
Subject: Re: Sections 5.1 and 5.2 o= f draft-ietf-rmcat-eval-test-01


Hi Zahed,

First of all, your question. By "insensitive traffic" I meant tha= t the flow is CBR, so it won't back off whether other traffic is present in= the bottleneck link or not. Maybe we can find a better name for this...
On the other hand, in the last days, I have been working on an ns3 implemen= tation of some of the test cases in the draft. I realized that it would be = coherent (and useful, IMO) for 5.3 to also have a "b" version whe= re both forward and backward paths are changed by a CBR, similarly to 5.1 and 5.2. Let me know your thoughts on this.

Regards,

Sergio



On 24/08/15 13:45, Zaheduzzaman Sarker wrote:

Hi Sergio,

 

Thanks for your effort.<= /span>

 

I think the proposed changes looks = good.

 

As we have plan to update the varia= tion of path capacity relative to initial path capacity for test case 5.1 a= nd test case 5.2, we need to change the respective text in the 5.1b and 5.2b to be aligned with that.

 

One clarification question : in 5.1= b what does the =93insensitive traffic=94 means in the new text?=

 

BR

 

Zahed

 

From: Sergio Mena = [mailto= :semena@cisco.com]
Sent: den 13 augusti 2015 14:30
To: Zaheduzzaman Sarker
Cc: draft-ietf-rmcat-eval-test@ietf.org; rmcat@ietf.org
Subject: Sections 5.1 and 5.2 of draft-ietf-rmcat-eval-test-01<= /o:p>

 

Zahed,

[CCed the author list of the rmcat test cases draft, as well as the rmca= t mailing list]

There was a discussion triggered at rmcat main session in Prague on how to = simulate bottleneck-link bandwidth changes. Two options were discussed (1) = changing the physical link throughput (currently specified in the draft), a= nd (2) using an insensitive CBR UDP flow as background traffic.

My understanding from the discussion during the session was that none of th= ese two options can simulate the other and, therefore, we somehow need to t= est how candidate algorithms adapt in both cases.

You and I then had an offline discussion on the subject in which you sugges= ted me to review sections 5.1 and 5.2 of the test cases draft, and propose = an alternate text to extend these two test cases to the background traffic = option.

I have reviewed sections 5.1 and 5.2 and come up with a proposal for extend= ing them to using insensitive background traffic, in addition to the curren= t option in the text (physical link throughput change).

Please find below what I would like to propose as updated text for 5.1 and = 5.2. [Text in square brackets are instructions to locate and replace the or= iginal text].

Thanks,

Sergio Mena


PS Proposed changes:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Section 5.1
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

[In the three-bullet list after the first paragraph, change the text in the= second bullet from:]

    o change in available capacity (e.g., due to interface c= hange,
      routing change).

[to]

    o change in available capacity (e.g., due to interface c= hange,
      routing change, sharp change in background t= raffic).

---

[Replace the paragraph immediately after the three-bullet list mentioned ab= ove, the one that starts with]

It should be noted that the exact variation...

[with the following]

The test case defined in this section (5.1) is divided into two subcases 5.= 1a and 5.1b. The main
difference is how the bottleneck-link capacity is changed in the testbed. I= n 5.1a, the goal is to
simulate a modification in the underlying physical properties, such as rout= ing change or interface
change. In 5.1b, the goal is to simulate a sharp change in background traff= ic to which the candidate
algorithm is to adapt.

---

[Change the last item of testbed attributes from]

      *  Competing traffic:

         +  Number of sour= ces : Zero (0)

[to]

      *  Competing traffic:

         +  In 5.1a

            - Number= of sources : Zero (0)

         +  In 5.1b

            - Number= of sources : One (1)

            - Type o= f sources : CBR traffic

            - Sendin= g bitrate : See test specific information below.

            - Traffi= c direction : Forward

            - Conges= tion control : None (insensitive traffic)

            - Traffi= c timeline:

            &nb= sp; - Start time : 0s

            &nb= sp; - End time : 100s

---

[Change 2nd bullet of test-specific information from]

      *  This test uses bottleneck path capac= ity variation as listed in
         Table 1

[to]

      *  This test uses bottleneck path capac= ity variation as listed in
         Table 1.

         - In 5.1a, the path capaci= ty transitions are achieved by instantly changing the
           physical throu= ghput of the bottleneck link. For simplicity, when changing
           the bottleneck= link throughput, other parameters such as queue length in
           packets will b= e left unchanged, even if it implies that the new queue has a
           different leng= th in milliseconds.

         - In 5.1b, the path capaci= ty transitions are achieved by instantly changing the
           sending bitrat= e of the competing CBR flow. The new sending bitrate must be
           the difference= between the bottleneck link-capacity (4 Mbps, as specified in
           4.2) and the c= apacity specified in Table 1.

           The sharp bitr= ate change in the CBR flow might imply the losses on both the
           application-re= lated traffic and the CBR flow. As a result, the reaction of
           the candidate = algorithm might be different in 5.1a and in 5.1b, hence the
           distinction be= tween the two sub-cases.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Section 5.2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

[Insert this after the first paragraph of the section]

Analogously to Section 5.1, the present test case (5.2) is divided into two= subcases 5.2a and 5.2b.
The main difference is the same: 5.2a simulates a change in the underlying = physical network properties,
such as routing change or interface change; whereas 5.2b simulates a sharp = change in background
competing traffic.

---

[Change last paragraph from]

   Test Specific Information: This test uses path capacity variat= ion as
   listed in Table 2 with a corresponding end time of 125 seconds= .

[to]

   Test Specific Information: This test uses path capacity variat= ion as
   listed in Table 2 with a corresponding end time of 125 seconds= . The
   two media flows stop at time 124.


 --_000_D203239425D91xiaoqzhuciscocom_--