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 ==================================================
- [rmcat] Sections 5.1 and 5.2 of draft-ietf-rmcat-… Sergio Mena
- Re: [rmcat] Sections 5.1 and 5.2 of draft-ietf-rm… Zaheduzzaman Sarker
- Re: [rmcat] Sections 5.1 and 5.2 of draft-ietf-rm… Sergio Mena
- Re: [rmcat] Sections 5.1 and 5.2 of draft-ietf-rm… Xiaoqing Zhu (xiaoqzhu)
- Re: [rmcat] Sections 5.1 and 5.2 of draft-ietf-rm… Zaheduzzaman Sarker
- Re: [rmcat] Sections 5.1 and 5.2 of draft-ietf-rm… Mirja Kühlewind
- Re: [rmcat] Sections 5.1 and 5.2 of draft-ietf-rm… Zaheduzzaman Sarker
- Re: [rmcat] Sections 5.1 and 5.2 of draft-ietf-rm… Sergio Mena