Re: [AVTCORE] RTP over QUIC experiments

[Phillip Hallam-Baker <[e-mail]>]

A piece of context that should probably be borne in mind is that the
principle design concern of the 1980s was breaking the Internet
accidentally. For the past 20+ years we have had to face millions of idiots
and criminals trying to break it on purpose.

If your Internet infrastructure is so pathetic that it can't cope with
someone pumping 10 packets down a link on connection startup before getting
a response then it deserves to DIE and probably did so long ago.

Remember when we were trying to deal with spam and some people were
prattling on about how we can't do this or that because 'the Internet' in
some part of the world is delivered by PDP-8s or people on bicycles? I am
not kidding, those were actual objections made and the people making them
thought they were true and of course they were utterly irrelevant anecdotes.

There are some objections in this area where I am very tempted to respond,
'let me know where that system is and I will go round and break it myself
because that's what you deserve'. Sure, I do the retro computing thing,
recently acquired a ZX-80 and an Oric. But what I don't do is demand the
rest of the world have a guy walking in front of their packets with a red
flag so my machines can keep up.

In the apps area we have learned to tell users that software has a sell-by
date. If you can't read my Web site because you are still using IE4, that
is your problem buddy. Folk who are still on 10-BaseT need to work out any
issues for themselves. And they are not likely to be streaming video in any
case.


Once we factor in the need to address malice as the cause of network
collapse, it becomes obvious that we are going to require circuit breaker
type mechanisms.


On Tue, Nov 23, 2021 at 11:54 AM Spencer Dawkins at IETF <
[e-mail]> wrote:

> Just to echo what Justin said ...
>
> On Mon, Nov 15, 2021 at 7:33 PM Justin Uberti <
> [e-mail]> wrote:
>
>>
>>
>> On Mon, Nov 15, 2021 at 12:35 PM Joerg Ott <[e-mail]> 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
>