On Wed, Apr 15, 2020 at 11:08 AM Jonathan Morton <[email protected]> wrote:
> I think the important point here is that reliably defining whose traffic > is "more equal" than the rest - in the Animal Farm sense - is a Hard > Problem, one that has been tackled many times over the years without any > significant success. It's also one that we don't even *need* to solve, as > long as the "fair share" is sufficient to let the critical applications > work. > Agreed. ISTM that this is the only reasonable way to address underprovisioned links. If a link is underprovisioned temporarily: * Small flows are not the problem, so we can give them low latency with no penalty under any circumstance. FQ does this without overallocating (unnecessarily reserving) capacity to these flows. * Large flows that are congestion-controlled and rapidly capacity-seeking will always try to fill up the pipe, so the best you can do in the short term is to divide some portion of the capacity equally among them in a value-free manner. Low latency is not generally required for these (in fact, Reno et al. preclude it), so FQ seems fine. * Large flows that are either completely unresponsive or that slowly respond to congestion (e.g., clients dropping from 4K to HD on sustained buffer underruns) are the flows that really want to be low latency but have to suffer in the case of a heavily constrained pipe because not doing so would be unfair to the other classes of flows at the bottleneck. Maybe the priority should be to reduce rapidly capacity-seeking flows first, but not enough to create the perverse incentive for all large flows to ignore congestion signals. If the link turns out to be perpetually underprovisioned: * The network needs to fix that by adding capacity, period. There's no other solution. While doing this will result in capacity-seeking flows sending more traffic, there is no link anywhere that would have unbounded demand at any given time: there is always some other link that would become new bottleneck. If you're the bottleneck and you aren't an access network, you're probably doing it wrong. Kyle
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
