Just to echo what Justin said ... On Mon, Nov 15, 2021 at 7:33 PM Justin Uberti < [email protected]> wrote:
> > > On Mon, Nov 15, 2021 at 12:35 PM Joerg Ott <[email protected]> wrote: > >> snip > This would indeed be one option in the (more desirable?) design space: >> the question is if you should allow libraries out there without >> congestion control just because something claims it's real-time media >> and does its own. >> >> Somebody may have mentioned the circuit breaker last week in some >> context (too many slots, sorry). >> > > I was one of the people who brought up the notion of the circuit breaker. > I feel like the key point of the circuit breaker is to prevent abuse, > rather than to enforce a specific rate equation. Ultimately I feel that > 2020 taught us that we could have enormous traffic from apps that were > performing their own congestion control (i.e., Zoom, Teams, Meet, Webex, > and various others) and the internet would not break. Accordingly we should > feel empowered to have a sufficiently wide envelope for RTC apps while > imposing some sort of guardrail if someone starts spraying out 100 Mbps > without any acknowledgement... > This is exactly the intention of network transport circuit breakers described in https://www.rfc-editor.org/rfc/rfc8084.html. (That's actually a pretty nuanced discussion of the topic - what you'd expect from a Gorry document - and well worth the read. https://www.rfc-editor.org/rfc/rfc8085.html#section-3.6 does distinguish between applications intended for use within a managed domain and applications intended for use on the general Internet. https://www.rfc-editor.org/rfc/rfc8083.html#section-4 can do a better job than a tunneling circuit breaker, because the application is better understood, but both RFC 8084 and RFC 8085 are informative references, in the best sense of the term. Best, Spencer
