> On 27 Nov, 2018, at 12:50 pm, Mikael Abrahamsson <swm...@swm.pp.se> wrote: > > Could someone perhaps comment on the thinking in the transport protocol > design "crowd" when it comes to this?
BBR purports to aim for the optimum of maximum throughput at minimum latency; there is a sharp knee in the throughput-latency graph, at least in an idealised scenario. In practice it's more complicated, hence the gradual evolution of BBR. Previously, there has been a dichotomy between loss-based TCPs which aim for maximum throughput regardless of latency, and delay-based TCPs which aim for minimum latency with little regard for throughput. Pretty much nobody uses the latter in the real world, because they get outcompeted by loss-based traffic when they meekly back down at the first sign of a queuing delay. Everyone uses loss-based TCPs, generally NewReno, CUBIC, or Compound. CUBIC is specifically designed to spend most of its time near queue saturation, by growing more slowly when near the cwnd at which loss was last experienced than when distant from it. Compound is actually an interesting special case. It's a very straightforward combination of a loss-based TCP and a delay-based one, such that it spends a lot of time at or near the optimum operating point - at least in theory. However, it will always eventually transition into a NewReno-like mode, and fill the queue until loss is experienced. LEDBAT is a delay-based algorithm that can be applied to protocols other than TCP. It's often used in BitTorrent clients as part of µTP. However, the sheer weight of flows employed by BT clients tends to overwhelm the algorithm, as remote senders often collectively flood the queue with near-simultaneous bursts in response to changes in collective swarm state. BT client authors seem to be ill-equipped to address this problem adequately. - Jonathan Morton _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
