Re: [rmcat] Sections 5.1 and 5.2 of draft-ietf-rmcat-eval-test-01

Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> Thu, 27 August 2015 08:43 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 80C0F1B2EE4; Thu, 27 Aug 2015 01:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CHYg3y8cqvhM; Thu, 27 Aug 2015 01:42:59 -0700 (PDT)
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 6365D1B382D; Thu, 27 Aug 2015 01:42:58 -0700 (PDT)
X-AuditID: c1b4fb25-f79a26d00000149a-1f-55decd9037b6
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D6.69.05274.09DCED55; Thu, 27 Aug 2015 10:42:56 +0200 (CEST)
Received: from [150.132.141.68] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.210.2; Thu, 27 Aug 2015 10:42:55 +0200
To: Sergio Mena <semena@cisco.com>
References: <55CC8DC7.40903@cisco.com> <E0F7A68B07B53F4FBD12DABD61CBA90E129E89A2@ESESSMB307.ericsson.se> <55DD6C49.1050901@cisco.com>
From: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
Organization: Ericsson AB
Message-ID: <55DECD8F.3070500@ericsson.com>
Date: Thu, 27 Aug 2015 10:42:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <55DD6C49.1050901@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvje6Es/dCDX7sk7SYeP8su8Xqmx/Y LNZM/8buwOwx5fdGVo8lS34yBTBFcdmkpOZklqUW6dslcGVM3yJTME+o4sGBduYGxl18XYyc HBICJhIH1m9gh7DFJC7cW8/WxcjFISRwlFFiw7keFghnDaPE5o89YFXCAk4STXMWsoDYIgJK Es2XHzFCFHUySiz5tYu1i5GDg1mgROLOySwQk03ARuLxYj+Qcn4BSYkNDbuZQWxeAW2J7+vX MoLYLAKqEjuubAMbKSoQIzF/xXSoGkGJkzOfgMU5BTQluicvZAOxmQUsJGbOP88IYctLNG+d zQyySkhAV6LrZdwERqFZSLpnIemYhaRjASPzKkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzA YD645bfqDsbLbxwPMQpwMCrx8Crk3wsVYk0sK67MPcQozcGiJM774hRQSCA9sSQ1OzW1ILUo vqg0J7X4ECMTB6dUAyPPr7ZYfyO+nE39/PeE7Hs0nz8/zad35aH/t+WvdF6fKp5Vwql0Xej+ j7qDX+5uvbSMJ7ZJe1vz2S/r3wg1rfhjdL+igeuhx++tDKyzFkSXtZyWjzjqMkNjdXZXr4J8 G4vc8pZJhr+lj175lG48Z3pNP9ef736nHijyz/NgX8Tx4/BZZevioC1KLMUZiYZazEXFiQD/ zfG+RwIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/rmcat/geBXJ3uupMI4xSnUHR7UPmRYfc0>
Cc: "rmcat@ietf.org" <rmcat@ietf.org>, "draft-ietf-rmcat-eval-test@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." <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: Thu, 27 Aug 2015 08:43:00 -0000


On 2015-08-26 09:35, Sergio Mena wrote:
>
> 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 bottleneck link or not. Maybe we can find a better name for this...
ok, understood. To me "flow is CBR" is good enough.
>
> On the other hand, in the last days, I have been working on an ns3
> implementation 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 forward and backward paths are changed by a CBR,
> similarly to 5.1 and 5.2. Let me know your thoughts on this.
is it possible to share your findings so that we can also have a look at 
the characteristics the new test option (path capacity limitation by 
introducing CBR) is revealing (applicable for 5.1 and 5.2 as well)? I 
think it is better to discuss and learn more about the test case 
characteristics before we add the new option.

For test case 5.3, it is important that the path capacity change in the 
backward path happens at the right time so that we can see the effect of 
lost or delayed feedback in the forward path. have you seen any change 
required at the time one need to start the CBR traffic to introduce the 
capacity change at correct time? How easy will it be to do this in a lab 
network?

For 5.1, 5.2 (and 5.3), how do you introduce the competing CBR traffic? 
if there is a single bottleneck node between A and B then the competing 
CBR traffic can share the same path as the media traffic. However, if 
there are multiple nodes between A and B (can happen in the lab 
network), then sharing the same path can create multiple bottlenecks, 
right? I haven't tried that yet. Even if that is the case then I think 
this can be solved by some additional text in the draft but it will 
require different topology than the current assumptions.

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

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