4 ms·
slow start is kind of orthogonal as you say, so lets forget about that. the real meat of this work is to try to address the fact that for whatever reason, buff
by convolvatron 10y ago
slow start is kind of orthogonal as you say, so lets forget about that.
the real meat of this work is to try to address the fact that for whatever reason, buffers are being provisioned well in excess of something that might represent the fractional delay bandwidth product end to end.
so this leaves traditional tcp filling up these huge buffers until it gets a loss. a decent red policy would take care of this.
the key observation is that if you look at the end to end latency, once you start excess buffering, there is an inflection point. this is the point we are trying to find, where the send rate actually matches a fair share without just dumping packets up to be queued. if you plot latency vs issue rate you can see it very clearly. latency is flat until you start queueing, and then it goes up because you're waiting in line.
it makes a lot of sense.
particularly if everyone plays along. a really interesting question is what happens if this cc is a minority player in a mix of other adaptation machines.
at the bottom end you're under the right set point. but thats a lot better than taking a classic exponential backoff on the eventual loss.
- jnordwick 10y agoI can definitely see its use over longish connections, and I can definitely see disabling the patch on a local network these shouldn't be issues (because you have control of the program endpoints). I wonder how it works for things like delivering gaming or real-time-ish feeds where dumping packets might not be such a bad thing (as in they can be written to handle data). Looks interesting though and definitely better for throughput over random networks.
- an_account 10y agoCorrect me if I'm wrong, but doesn't bufferbloat kill latency, which hurts gaming/real time more than normal web browsing? So wouldn't this be a major improvement for those type of applications?
- Filligree 10y agoIt does, and the usual solution is to not load your link heavily while gaming. If it's someone else's link that's loaded, then you're screwed. However, most games are deeply inflexible on how much bandwidth they use, and additionally tend to use UDP. Running out of bandwidth doesn't degrade the game; it makes them break entirely. As a result of both of these, with a few exceptions, this work won't be directly useful to games.
- apenwarr 10y agoNot directly. But if more people use bbr for their TCP sessions, there will be less latency caused by sessions alongside the gaming session.
- jnordwick 10y agoNot always. It depends on how you are processing incoming packets and if you can do it bulk or elide some processing when you have more to work with.