Re: [tcpm] last_max in CUBIC

[Neal Cardwell <[e-mail]>]

On Thu, Apr 23, 2015 at 12:22 PM, Nicolas Kuhn
<[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?

neal