[Cerowrt-devel] BBR congestion control algorithm for TCP innet-next

[dpreed at reed.com]

The assumption that each flow on a path has a minimum, stable  RTT fails in wireless and multi path networks.



However, it's worth remembering two things: buffering above a certain level is never an improvement, and flows through any shared router come and go quite frequently on the real Internet.

Thus RTT on a single flow is not a reasonable measure of congestion. ECN marking is far better and packet drops are required for bounding time to recover after congestion failure.

The authors suffer from typical naivete by thinking all flows are for file transfer and that file transfer throughput is the right basic perspective, rather than end to end latency/jitter due to sharing, and fair sharing stability.




-----Original Message-----
From: "Jonathan Morton" <chromatix99 at gmail.com>
Sent: Sat, Sep 17, 2016 at 4:11 pm
To: "Maciej Soltysiak" <maciej at soltysiak.com>
Cc: "Maciej Soltysiak" <maciej at soltysiak.com>, "cerowrt-devel at lists.bufferbloat.net" <cerowrt-devel at lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next


> On 17 Sep, 2016, at 21:34, Maciej Soltysiak  wrote:
> 
> Cake and fq_codel work on all packets and aim to signal packet loss early to network stacks by dropping; BBR works on TCP and aims to prevent packet loss. 

By dropping, *or* by ECN marking.  The latter avoids packet loss.

 - Jonathan Morton

_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel