[Bloat] geoff huston's take on BBR

Geoff Huston gih at apnic.net
Tue Jun 12 03:49:26 EDT 2018



> On 12 Jun 2018, at 4:55 pm, Dave Taht <dave.taht at gmail.com> wrote:
> 
> On Mon, Jun 11, 2018 at 10:58 PM, Kevin Darbyshire-Bryant
> <kevin at darbyshire-bryant.me.uk> wrote:
>> 
>> 
>>> On 11 Jun 2018, at 22:27, Dave Taht <dave.taht at gmail.com> wrote:
>>> 
>>> https://ripe76.ripe.net/presentations/10-2018-05-15-bbr.pdf
>> 
>> Fascinating!
>> 
>> "       • BBR changes all those assumptions, and could potentially push many networks into sustained instability
>> 
>>        • –  We cannot use the conventional network control mechanisms to regulate BBR flows
>> 
>> • Selective packet drop just won’t create back pressure on the flow”
>> 
>> And I keep on seeing questions on whether BBR understands ECN - if not…. well I think we see the results.
> 
> I think geoff goofed in his testing of BBR, starting all flows at the
> same time, thus syncing up their probing periods. Real traffic is not
> correlated this way.
> (I made the same mistake on my initial bbr testing)

no - I started the flows at 10, 20 and 30 seconds after the initial flow started.


> 
> I do agree that bbr treats aqm drops as "noise", not backpressure. And
> bbr scares me.
> 
> I look forward very much to bbr one day soon doing some sort of sane,
> conservative, response to ecn marks.
> 


I’m not sure that I understand this comment.

Part of the pressure going on here is the issue of whether the endpoints can and should trust the signals and.or manipulation that they get from the network infrastructure. BBR is using a different form of feedback to control its send rate. Essentially BBR is taking a delay variance measurement 1 / 8 of the time to adjust its internal model of the end-to-end delay bandwidth product (every 8th RTT). ECN provides a constant information flow, and this certainly matches the requirements of loss-based TCP, where every ACK contributes to the TCP flow dynamic, but it does not seem to me to be a good match to BBR’s requirements. 

The idea with BBR is to drive the network path such at the internal routers are sitting just at the initial onset of queuing. In theory ECN will not trigger at the onset of queuing, but will trigger later in the cycle of queue buildup.



> PS having fq on the link makes cubic and bbr cohabitate just fine.
> fq_codel vs bbr behavior was reasonable, though bbr lost a lot more
> packets before finding a decent state.

I guess that "It Depends" - my long delay experiments in the presentation referenced above showed cubic being completely crowded out by BBR.


Geoff



More information about the Bloat mailing list