Subject: [tsvwg] a good cite for somewhere

From: Dave Taht <[email-masked]>
Date: Tue, 1 Feb 2022 08:52:14 -0800

I don't where or on what this paper could be cited, but I thought it
established a good baseline

https://blog.apnic.net/2022/01/26/beyond-bufferbloat-end-to-end-congestion-control-cannot-avoid-latency-spikes/

-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC

---

From: <[email-masked]>
Date: Wed, 2 Feb 2022 08:28:00 +0000

Dave,

Thanks for the link.

There are two somewhat generic modes of large communication network operation, overprovision (better real-time services) or overbook (better economical use of capacity/better service multiplex). The authors recommend to mix those modes of operation and I agree with that:

Quote (note that authors refer to wireless networks with fast capacity changes): "How can latency spikes be avoided?
......
Treat traffic differently. This is like underutilization, but smarter. The idea is to underutilize the link, but only for traffic that is latency sensitive. Never fill more than 1/10th or 1/20th of the capacity with time-sensitive traffic, and suddenly you can handle large capacity drops. The rest of the link can be filled with traffic that is not as latency sensitive. The caveat is that when the capacity drops, the latency-sensitive traffic must be given priority on the link until capacity bounces back up. If this is handled at the point of congestion, then we can have the best of both worlds."

RG: I note that L4S based transport was critisised because it failed to fill a bottleneck by more than 80%. To me that may be part of the design. My aim isn't one or the other kind of transport, I'd prefer to have a reliably operatable overprovisioned default transport in addition to the existing overbooked default transport. Both need to co-exist where capacity can't reliably be wasted.

RG: That said, who should get the ECN bits?
- one ECN solution meeting demands of both kinds of transport. Desirable, if easy to implement and operate. Doesn't seem to work well under all of today's operational conditions.
- then one option is, either overbooked or overprovisioned to use the ECN bits. I think the backward compatibility/detection issue is linked to this approach, as ECN originally wasn't designed mainly aiming on overprovisioned transport.
- or to have one ECN mechanism per transport (overprovisioned/overbooked). Unless we find another spare header bit parsed by a scheduler, that likely means two standard DSCPs allowing for two reliably end-to-end operatable default transports making use of different ECN marking schemes.

I think preferences of most of those active on the list are known, I'm not interested in repeating a vote on that.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg <[email-masked]> Im Auftrag von Dave Taht
Gesendet: Dienstag, 1. Februar 2022 17:52
An: tsvwg IETF list <[email-masked]>
Betreff: [tsvwg] a good cite for somewhere

I don't where or on what this paper could be cited, but I thought it established a good baseline