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

[Mirja Kühlewind <[e-mail]>]

Hi all,

just a quick thought in addition (as an individual): if you use CBR cross traffic, it would potentially also be interesting to add another evaluation metric and that’s the loss rate of the CBR traffic because this tells you how 'aggressive' your impact on cross traffic is.

Mirja


> Am 27.08.2015 um 10:42 schrieb Zaheduzzaman Sarker <[e-mail]>:
> 
> 
> 
> 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 [phone]
> Fax [phone]
> SMS/MMS [phone]
> [e-mail]
> www.ericsson.com
> 
> ==================================================