Re: [arch-d] A Public Option for the Core

[Christian Huitema <[e-mail]>]

On 8/17/2020 9:42 AM, Toerless Eckert wrote:
> ...
> Instead of just talking about some of the tools (CC, ACM), it would be
> nice to try to set goals first, to see if we could get agreement there:
>
> -> I would like traffic to get the same throughput under congestion
>    whatever its RTT is.

I agree, but there is a fundamental issue. Flows with short RTT will
react faster to changing conditions than flows with shorter RTT, so
short term averages will always show some benefit to short delays.

> -> I would like for traffic to get bandwidth share indpendent of the
>    number of 5 tuple flows it utilizes (no gaming the system). But
>    rather fair per subscriber (weighted by how much the subscriber pays).

Yes. Basic fairness means all subscribers should be treated the same. At
the same time, there are some interesting questions. Assume that the
same function could be implemented as an app on my PC and or as a self
contained IOT device. Should the IOT device that has its own IP address
get more bandwidth than the app that shares the IP address with other
apps on the PC? I suppose that this is only a problem for local area
networks, since after that all traffic gets to share the subscribed
bandwidth, but I could see some needs here.

>
> -> I would like to be able for traffic to indicate preferences for
>    lower latency or higher throughput... If you ask for lower latency,
>    you get less throughput.

No. That's where we differ. We have tried designing this sort of
two-classes system in the past, modelling that as a game between the
application and the network, and trying to define strategies that were
robust against player's misbehavior. There is no sign that applications
would be ready for that.

On the other hand, there is plenty of research and deployment experience
for CC algorithms that deliver low latency if the network cooperates:
LEDBAT, BBR and L4S come to mind. There is also evidence of algorithms
that can lead to large delays especially in presence of buffer bloat:
Reno and Cubic. Let's assume that delay-sensitive applications use a
delay-minimizing CC algorithm. If the network "isolates" each
application in its own queue and serves them fairly, then the LEDBAT
users get low delay and the Cubic users get high bandwidth, and
everybody is happy.

>
> -> Goodput always > 95%
I don't know how to measure that. But yes of course, we don't want
congestion collapse.
>
> That would be a start for the most simple "one-size-fits" all i could
> imagine. But there is a lot more things i would like to factor in beyond
> that.

Sure. But I like your general approach.

-- Christian Huitema