On 21/09/2016, Mikael Abrahamsson <[email protected]> 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. _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
