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--