[Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S

[Ruediger.Geib at telekom.de]

Jonathan Morton marked [JM] below, Ruediger Geib [RG].

> On 2 Aug, 2019, at 9:29 am, <Ruediger.Geib at telekom.de> <Ruediger.Geib at telekom.de> wrote:
> 
> Hi Jonathan,
> 
> could you provide a real world example of links which are consecutively narrower than sender access links?
> 
> I could figure out a small campus network which has a bottleneck at the Internet access and a second one connecting the terminal equipment. But in a small campus network, the individual terminal could very well have a higher LAN access bandwidth, than the campus - Internet connection (and then there's only one bottleneck again).
> 
> There may be a tradeoff between simplicity and general applicability. Awareness of that tradeoff is important. To me, simplicity is the design aim. 

[JM] A progressive narrowing of effective link capacity is very common in consumer Internet access.  Theoretically you can set up a chain of almost unlimited length of consecutively narrowing bottlenecks, such that a line-rate burst injected at the wide end will experience queuing at every intermediate node.  In practice you can expect typically three or more potentially narrowing points:

[RG] deleted. Please read https://tools.ietf.org/html/rfc5127#page-3 , first two sentences. That's a sound starting point, and I don't think much has changed since 2005. 

[RG] About the bursts to expect, it's probably worth noting that today's most popular application generating traffic bursts is watching video clips streamed over the Internet. Viewers dislike the movies to stall. My impression is, all major CDNs are aware of that and try their best to avoid this situation. In particular, I don't expect streaming bursts to overwhelm access link shaper buffers by design. And that, I think, limits burst sizes of the majority of traffic.

[RG] Other people use their equipment to communicate and play games (that's what I see when I use commuters). Unless gaming pictures are rendered on a server or live pictures of communicating persons are streamed, there should be no bursts. Still I miss the consecutively narrowing bottlenecks with queues being built at each instance with a likelihood justifying major engineering and deployment efforts. Any solution for Best Effort service which is TCP friendly and support scommunication expecting no congestion at the same time should be easy to deploy and come with obvious benefits. 

[RG] I found Sebastian's response sound. I think, there are people interested in avoiding congestion at their access.

[RG] I'd like to repeat again what's important to me: no corner case engineering. Is there something to be added to Sebastian's scenario?