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

[Sergio Mena <[e-mail]>]

Hi Zahed,

Please see inline [SM]

Regards,

Sergio


On 27/08/15 10:42, Zaheduzzaman Sarker wrote:
>
>
> 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.

[SM] The main reasons why I raised the question (during rmcat session in 
Prague, and later on in this mailing list) of using CBR traffic to limit 
the bottleneck capacity are the following.

  * When one changes the nominal (i.e., physical) line rate of a network 
link (the bottleneck link in our case), there are other important 
parameters that are affected. For instance, packet transmission delay 
changes. Also, importantly enough for CC, the queue sizes in ms will 
also change (since queue sizes are usually specified in terms of packets 
or bytes in real networks).

  * Another important reason is that, in the wild, it is likely that a 
CC algorithm needs to react to abrupt changes in background traffic, 
roughly as likely as it needs to react to changes in topology. And, IMO, 
the test cases you guys are proposing should cover most use cases that 
are likely to occur in real life.

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

[SM] So far, I did not need to change the specified times for the 
backward path in 5.3, in order to expose the features of the CC 
algorithm that this test case is supposed to check (mainly congested 
feedback paths). Bear in mind that the CBR does not ramp up: it starts 
right at the CBR rate. So I think the times specified in the draft are 
fine as they are. Of course, my implementation of the tests is work in 
progress, so I'll let you know quickly if I observe anything else.

I think it would be relatively easy to implement CBR in a real testbed 
(it is simply a process that starts at a given time and sends UDP 
packets at the specified rate right from the beginning). So it takes in 
the order of 100s of ms (1/2 the rtt) for the whole path to "feel" it; 
this is not a problem for 5.3 where times are specified in the order of 
10s of seconds.

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

[SM] The way I understand it: if there are other hops in the real 
testbed we use to run the rmcat tests, the non-bottleneck links should 
have a capacity so high that the particular value of the capacity does 
not matter. Otherwise, there may be losses/queuing delay at places other 
than the bottleneck, /even in the absence of CBR traffic/. If that was 
the case, then the full topology should be specified in the draft, so 
that the results are reproducible (but I do not think that 5.1 5.2 5.3 
should have more than one bottleneck link per direction).

>
> BR