Re: [rmcat] test cases for coupled cc [was: Re: Review of draft-ietf-rmcat-eval-test-02]

Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> Wed, 10 February 2016 09:24 UTC

Return-Path: <zaheduzzaman.sarker@ericsson.com>
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 <rmcat@ietfa.amsl.com>; 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 <rmcat@ietfa.amsl.com>; 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 <rmcat@ietf.org>; 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: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
References: <170F0EA5-EAB0-4B01-A8DF-56A0B2923A9A@ifi.uio.no> <56AA17AD.8060806@ericsson.com> <EA475291-B965-43EE-965B-F5435B595493@tik.ee.ethz.ch>
From: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
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: <EA475291-B965-43EE-965B-F5435B595493@tik.ee.ethz.ch>
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: <http://mailarchive.ietf.org/arch/msg/rmcat/iFxk1CDeAOAyzUqqxSJykcda7Yw>
Cc: Safiqul Islam <safiquli@ifi.uio.no>, "rmcat@ietf.org" <rmcat@ietf.org>, "mramalho@cisco.com" <mramalho@cisco.com>, Anna Brunström <anna.brunstrom@kau.se>, Varun Singh <vsingh.ietf@gmail.com>, Xiaoqing Zhu <xiaoqzhu@cisco.com>
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." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=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

==================================================