Re: [Cerowrt-devel] BBR congestion control algorithm for TCP in net-next

[Alan Jenkins <alan.christopher.jenkins@gmail.com>]

On 21/09/2016, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Wed, 21 Sep 2016, Dave Taht wrote:
>
>> I dunno, I'm just reading tea leaves here!
>>
>> can't wait for the paper!
>
> +1.
>
> I would like to understand how BBR interacts with a window-fully-open
> classic TCP session and FIFO induced delay that is in steady-state before
> the BBR session starts.
>
> So let's say I have 100ms of lightspeed-in-fiber RTT, and I am then
> running a file transfer with some other TCP algorithm which is sitting
> there, window fully open, creating an additional 100ms of
> stupid-router-FIFO-buffering delay.
>
> So new BBR TCP session comes along, sees 200ms of RTT, and starts sending.
> I guess the classic TCP algorithm still keeps its window fully open, and
> doesn't care that RTT now increased to 210ms by the BBR flow packets.
>
> Now what? BBR flow sees increased latency, and backs off, right? So how
> much of the bandwidth will each flow get? How do these interact?

I don't know what you're reading, but the BBR code that's just been
submitted does not back off when latency increases.  Period.

If less well-behaved flows drove up the minimum latency measured over
the 10 second interval, BBR would treat this as a longer pipe, and
will seek to fill it.  It would *increase* the number of packets
in-flight.

That assumes the measured maximum bandwidth (over an interval of
10*rtt) remains constant.  (Say there were 100 BBR flows, then you
added one CUBIC flow to bloat the buffer).  I don't have a good
intuition for how the bandwidth estimation behaves in general.