Subject: [tcpm] last_max in CUBIC

From: Nicolas Kuhn <[email-masked]>
Date: Thu, 23 Apr 2015 18:22:23 +0200

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, but we have  W_max == W_last_max,
which makes that CUBIC does not reduce W_last_max and “loops”, would not have its expected behaviour.  

— Problem resolution — 

Based on that observation, we have changed the following CUBIC code as follows:
 
      if (W_max < W_last_max){     
-> 
      if (W_max <= W_last_max){    

We plot the updated performance in cwnd_case_1_NK.pdf and cwnd_case_2_NK.pdf.

— Discussion — 

We acknowledge that this effect may not occur often in real life and might be a simulation
artefact. However, we have been looking around and are wondering the rationale of having

      if (W_max < W_last_max){   

instead of 

      if (W_max <= W_last_max){   

What do you think about it ?
Why would not we change the ‘<‘ for a ‘<=‘ ?

Kind regards,  

Nicolas KUHN
Emmanuel LOCHIN
Si Quoc Viet TRANG

---

From: Neal Cardwell <[email-masked]>
Date: Thu, 23 Apr 2015 15:58:18 -0400

On Thu, Apr 23, 2015 at 12:22 PM, Nicolas Kuhn
<[email-masked]> wrote:
> 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.
> “new last_max_cwnd”, that is the W_last_max in the CUBIC draft
> [https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic].
>
>
>
> 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?

neal

---

From: Nicolas Kuhn <[email-masked]>
Date: Fri, 24 Apr 2015 10:07:21 +0200

> On 23 Apr 2015, at 21:58, Neal Cardwell <[email-masked]> wrote:
> 
> <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi all,
>> 

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