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

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Tue, 09 February 2016 14:51 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 <rmcat@ietfa.amsl.com>; 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 <rmcat@ietfa.amsl.com>; 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 <rmcat@ietf.org>; 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: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
In-Reply-To: <56AA17AD.8060806@ericsson.com>
Date: Tue, 09 Feb 2016 15:51:00 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <EA475291-B965-43EE-965B-F5435B595493@tik.ee.ethz.ch>
References: <170F0EA5-EAB0-4B01-A8DF-56A0B2923A9A@ifi.uio.no> <56AA17AD.8060806@ericsson.com>
To: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rmcat/TcMhJYFymT3guYK81ETNNQCBaHo>
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: [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: Tue, 09 Feb 2016 14:51:07 -0000

Hi Zahed,

see below.

> Am 28.01.2016 um 14:29 schrieb Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>:
> 
>> * I would like to suggest the following two additional test-cases
>>    under section 6 (other potential test cases).
> 
> 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).

> 
> 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’s 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.

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

Mirja


> 
>> 
>> 6.3 Prioritization test
>> 
>> 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:
>> 
>> b_{i} = (p_{i} / Sum(p_{k}) ) * BW   ;  k = {1.. 3}
>> 
>> 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]
>> 
>> Testbed topology: Same as test case defined in section 5.4
>> 
>> Testbed Attribute:
>> 
>> The general description of the testbed parameters is same as Section 5.4
>> with changes in the test specific setup as  below-
>> 
>>   o  Other test specific setup:
>> 
>>       *  RMCAT media flow timeline:
>> 
>>          +  Flow ID: One (1)
>> 
>>          +  Start time: 0s
>> 
>>          +  Flow duration: 119s
>> 
>>          +  Priority: no change
>> 
>>      *  RMCAT media flow timeline:
>> 
>>          +  Flow ID: Two (2)
>> 
>>          +  Start time: 0s
>> 
>>          +  Flow duration: 119s
>> 
>>          +  Priority:  change to 1/3 after 50s
>> 
>>       *  RMCAT media flow timeline:
>> 
>>          +  Flow ID: Three (3)
>> 
>>          +  Start time: 0s
>> 
>>          +  Flow duration: 119s
>> 
>>          +  Priority: change to 2/3 after  50s
>> 
>> 
>> 6.4 RMCAT flows competing with one or more long TCP flows
>> 
>> 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.
>> 
>> The general description of the testbed parameters is same as section 5.6.