Re: [tcpm] last_max in CUBIC

[Nicolas Kuhn <[e-mail]>]

> On 23 Apr 2015, at 21:58, Neal Cardwell <[e-mail]> wrote:
> 
> On Thu, Apr 23, 2015 at 12:22 PM, Nicolas Kuhn
> <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi all,
>> 
>> We were currently working on CUBIC and LEDBAT in NS-2, using Michael Welzl’s
>> updated TCP Linux for NS-2
>> [http://www.ietf.org/mail-archive/web/iccrg/current/msg01160.html].
>> We see some strange behaviour in CUBIC’s window reduction, which we wanted
>> to share with you here.
>> 
>> — Topology —
>> 
>> The topology is a simple dumbbell topology with a bottleneck of 10Mbps and
>> an RTT of 100ms. The queue size of the router is set
>> to 42 packets (with DropTail). There are two non-application limited bulk
>> flows that randomly start within the first second of the simulation.
>> Flow#1 is CUBIC (using ns-2.35/tcp/src/tcp_cubic.c version);
>> Flow#2 is LEDBAT with a target delay of 5 ms or 25ms.
>> 
>> — Problem illustration —
>> 
>> In cwnd_case_1_default.pdf and cwnd_case_2_default.pdf, we plot the
>> congestion window evaluation and the
>> “new last_max_cwnd”, that is the W_last_max in the CUBIC draft
>> [https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic].
>> 
>> 
>> 
>> We recall here how CUBIC deals with fast convergence:
>> 
>>      if (W_max < W_last_max){
>>          W_last_max = W_max;
>>          W_max = W_max*(2-beta)/2;
>>      } else {
>>          W_last_max = W_max
>>      }
>> 
>> In the case with LEDBAT25, at 15s, W_last_max “should” have been reduced,
> 
> Can you explain why you feel that in the case with LEDBAT25, at 15s,
> W_last_max should have been reduced?
> 
> AFAICT, in the LEDBAT25 case with the existing CUBIC code
> (cwnd_case_2_default.pdf) the CUBIC behavior is reasonable. From 15s
> to 50s CUBIC finds that it is able to get cwnd up all the way to the
> max value from the previous epoch before another loss happens. That
> suggests that there are no other competing flows, and the situation is
> stable, so it is reasonable to try to make cwnd quickly plateau at the
> same level in the next epoch, rather than some lower level.
> 
> Can you summarize why this seems problematic?
> 

It may be a simulation artefact (would not happen much in real life), and I do 
not believe that it would be somehow problematic; CUBIC is very aggressive
anyway - reducing its aggressiveness in such corner cases is not “needed”. 

I just wanted to point out that this “strange” behaviour can be assessed by 
changing 
      if (W_max < W_last_max){   
by 
      if (W_max <= W_last_max){   

and that it might have a slight impact on the fairness of CUBIC with latecomer 
flows. 

Nicolas 

> neal