Subject: [AVTCORE] RTP over QUIC experiments

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 12 Nov 2021 16:28:03 +0000

Hi Jörg, Mathis + others

It was nice to learn about your activity to try and use SCReAM as example
algorithm to integrate with QUIC. Pages 14-25 in
https://datatracker.ietf.org/meeting/112/materials/slides-112-avtcore-ietf-1
12-avtcore-03

Did you use the new gsteamer plugin from
https://github.com/EricssonResearch/scream/tree/master/gstscream  ?

Observations/Comments: 

+ SCReAM + Reno : Strange that the throughput dropped like that but perhaps
an unlucky outcome of two cascaded congestion controls. 

+ Split of network congestion control and media rate control : QUIC already
today has the congestion control on the connection level, it is then up to
the individual streams to deliver media, subject to the individual stream
priorities. SCReAM is quite similar in that respect, one difference is
perhaps the implementation of the media rate control.  
I think that with QUIC one should do a full split and do the network
congestion control on the QUIC connection level. The congestion control
would then be some low latency version, perhaps BBRv2? or something similar,
I am not sure that the network congestion control in SCReAM is the idea
choice here as it is quite a lot tailored for RTP media. 
The media rate control is done on the stream level and is then subject to
stream priority. This should give a more clean split of functionality. 
My SCReAM experience is that one need to leak some of the congestion signals
from the connection level congestion control up to the stream rate control,
to make the whole thing responsive enough. In the SCReAM code one can see
that the exotic variable queueDelayTrend as well as ECN marks and loss
events are used for this purpose. I believe that something like that is
needed for an RTP (or whatever low latency) media over QUIC. I believe that
it is necessary to leak congestion information from the connection level up
to the stream level, especially to be able to exploit L4S fully, even though
it is a bit of a protocol layer violation.

+ Stream prioritization : … is a problematic area, especially if one stream
is low latency video and another stream is a large chunk of data for e.g. a
large web page. With a simple round robin scheduler, the stream with the
large chunk of data will easily win because it is quite likely to always
have data to transmit. So some WRR is needed. I have even had problems with
the algorithm in SCReAM that prioritizes between two cameras/video coders,
this because the two cameras see different views and thus provide differing
information content/compression need.

+ Page 18 : Inferring the receive timestamp. What is suspect is that you
will essentially halve the estimated queue delay (I assume here that the
reverse path is uncongested). One alternative could be to compute 
receive-ts = send-ts + latest_rtt + min_rtt
where min_rtt is the min RTT over a given time interval

Regards

/Ingemar

---

From: Vidhi Goel <[email-masked]>
Date: Fri, 12 Nov 2021 15:43:57 -0800

Hello,

Have thoroughly read the RTP over QUIC paper https://www.in.tum.de/fileadmin/w00bws/cm/papers/epiq21-rtp-over-quic.pdf <https://www.in.tum.de/fileadmin/w00bws/cm/papers/epiq21-rtp-over-quic.pdf>

What I am trying to understand is, what is the motivation behind running real time congestion control like SCReAM over QUIC congestion control? The results (as Ingemar also mentioned) are not encouraging.
If we want to use a single QUIC connection for media (audio/video using RTP) and other reliable streams, then would it be better to not use QUIC CC for media streams and only use it for reliable streams? Obviously this will violate the current spec which applies congestion control on connection level. But maybe this use case can be specialized.

> + Split of network congestion control and media rate control : QUIC already today has the congestion control on the connection level, it is then up to the individual streams to deliver media, subject to the individual stream priorities. SCReAM is quite similar in that respect, one difference is perhaps the implementation of the media rate control.  

> I think that with QUIC one should do a full split and do the network congestion control on the QUIC connection level. The congestion control would then be some low latency version, perhaps BBRv2? or something similar, I am not sure that the network congestion control in SCReAM is the idea choice here as it is quite a lot tailored for RTP media. 

The impact of cascading two congestion controllers (with different input and output parameters) has not been studied extensively yet. And is a real time CC like SCReAM by itself not enough to control the congestion in the network? In other words, does it need another congestion controller to make sure that the real time data doesn’t cause more congestion in the network?

> My SCReAM experience is that one need to leak some of the congestion signals from the connection level congestion control up to the stream rate control, to make the whole thing responsive enough. In the SCReAM code one can see that the exotic variable queueDelayTrend as well as ECN marks and loss events are used for this purpose. I believe that something like that is needed for an RTP (or whatever low latency) media over QUIC. I believe that it is necessary to leak congestion information from the connection level up to the stream level, especially to be able to exploit L4S fully, even though it is a bit of a protocol layer violation.
We absolutely should allow sharing of network events, like RTT, ECN, packet loss from QUIC to RTP. Not sure how it is protocol layer violation.

> + Page 18 : Inferring the receive timestamp. What is suspect is that you will essentially halve the estimated queue delay (I assume here that the reverse path is uncongested). One alternative could be to compute 

You are right that halving latest_rtt / 2 may not be accurate if the reverse path is not congested, but there is no guarantee for that. So, a more accurate way to compute receive-ts is to use One way timestamps which can be added to QUIC as new Frames.

Thanks,
Vidhi

> On Nov 12, 2021, at 8:28 AM, Ingemar Johansson S <ingemar.s.johansson=[email-masked]> wrote:
> 
> Hi Jörg, Mathis + others
>  
> It was nice to learn about your activity to try and use SCReAM as example algorithm to integrate with QUIC. Pages 14-25 in
> https://datatracker.ietf.org/meeting/112/materials/slides-112-avtcore-ietf-112-avtcore-03 <https://datatracker.ietf.org/meeting/112/materials/slides-112-avtcore-ietf-112-avtcore-03>
> Did you use the new gsteamer plugin from https://github.com/EricssonResearch/scream/tree/master/gstscream <https://github.com/EricssonResearch/scream/tree/master/gstscream>  ?
>  
> Observations/Comments: 
> + SCReAM + Reno : Strange that the throughput dropped like that but perhaps an unlucky outcome of two cascaded congestion controls. 
>  
> + Split of network congestion control and media rate control : QUIC already today has the congestion control on the connection level, it is then up to the individual streams to deliver media, subject to the individual stream priorities. SCReAM is quite similar in that respect, one difference is perhaps the implementation of the media rate control.  
> I think that with QUIC one should do a full split and do the network congestion control on the QUIC connection level. The congestion control would then be some low latency version, perhaps BBRv2? or something similar, I am not sure that the network congestion control in SCReAM is the idea choice here as it is quite a lot tailored for RTP media. 
> The media rate control is done on the stream level and is then subject to stream priority. This should give a more clean split of functionality. 
> My SCReAM experience is that one need to leak some of the congestion signals from the connection level congestion control up to the stream rate control, to make the whole thing responsive enough. In the SCReAM code one can see that the exotic variable queueDelayTrend as well as ECN marks and loss events are used for this purpose. I believe that something like that is needed for an RTP (or whatever low latency) media over QUIC. I believe that it is necessary to leak congestion information from the connection level up to the stream level, especially to be able to exploit L4S fully, even though it is a bit of a protocol layer violation.
>  
> + Stream prioritization : … is a problematic area, especially if one stream is low latency video and another stream is a large chunk of data for e.g. a large web page. With a simple round robin scheduler, the stream with the large chunk of data will easily win because it is quite likely to always have data to transmit. So some WRR is needed. I have even had problems with the algorithm in SCReAM that prioritizes between two cameras/video coders, this because the two cameras see different views and thus provide differing information content/compression need.
>  
> + Page 18 : Inferring the receive timestamp. What is suspect is that you will essentially halve the estimated queue delay (I assume here that the reverse path is uncongested). One alternative could be to compute

---

From: Joerg Ott <[email-masked]>
Date: Mon, 15 Nov 2021 21:19:28 +0100

Hi Ingmar,

On 12.11.21 17:28, Ingemar Johansson S wrote:
> Hi Jörg, Mathis + others
> 
> It was nice to learn about your activity to try and use SCReAM as 
> example algorithm to integrate with QUIC. Pages 14-25 in
> https://datatracker.ietf.org/meeting/112/materials/slides-112-avtcore-ietf-112-avtcore-03 
> <https://datatracker.ietf.org/meeting/112/materials/slides-112-avtcore-ietf-112-avtcore-03>
> 
> https://github.com/EricssonResearch/scream/tree/master/gstscream 
> <https://github.com/EricssonResearch/scream/tree/master/gstscream>  ?

Well, we use your C++ version (forked a bit ago), not the plugin you
refer to.  This experiment has already been ongoing for some time.

> Observations/Comments:
> 
> + SCReAM + Reno : Strange that the throughput dropped like that but 
> perhaps an unlucky outcome of two cascaded congestion controls.

Nested control loops may not play out that well, and this seems just
one artifact of this.

> + Split of network congestion control and media rate control : QUIC 
> already today has the congestion control on the connection level, it is 
> then up to the individual streams to deliver media, subject to the 
> individual stream priorities. SCReAM is quite similar in that respect, 
> one difference is perhaps the implementation of the media rate control.

It is but it attends to the specific needs of real-time media, which
cannot really be said for New Reno and many others.

> would then be some low latency version, perhaps BBRv2? or something 
> similar, I am not sure that the network congestion control in SCReAM is 
> the idea choice here as it is quite a lot tailored for RTP media.

We would have tried BBR(v2) if that was available with quic-go; on our
list, but there is only so much you can do at time :-)

> The media rate control is done on the stream level and is then subject 
> to stream priority. This should give a more clean split of functionality.

Right, we are currently exploring the basic combinations with lots of
tracing and try to understand who impacts whom and what and try to
disentangle implication specifics from protocol aspects.  So take this
as a first step of a more comprehensive evaluation of where we are.

A next step is understanding how you make the two work together so that
you can preserve the fact that QUIC congestion controls everything it
sends; this will then go more into a bit of integration and API
discussion.

> My SCReAM experience is that one need to leak some of the congestion 
> signals from the connection level congestion control up to the stream 
> rate control, to make the whole thing responsive enough. In the SCReAM 
> code one can see that the exotic variable queueDelayTrend as well as ECN 
> marks and loss events are used for this purpose. I believe that 
> something like that is needed for an RTP (or whatever low latency) media 
> over QUIC. I believe that it is necessary to leak congestion information 
> from the connection level up to the stream level, especially to be able 
> to exploit L4S fully, even though it is a bit of a protocol layer violation.

We are all in for leaking (well: sharing) useful information, and one of
the main questions we tried to address is how much RTCP signaling for CC
you would need; well, and it seems we can do already pretty well with
what QUIC has built in.

This helps using RTP with one of its congestion control algorithms on 
top, but we hope it could also help understand what you'll need to do
an RTP++ (or: MOQ) on top of QUIC without all the legacy baggage (if
that turns out to be useful).

> + Stream prioritization : … is a problematic area, especially if one 
> stream is low latency video and another stream is a large chunk of data 
> for e.g. a large web page. With a simple round robin scheduler, the 
> stream with the large chunk of data will easily win because it is quite 
> likely to always have data to transmit. So some WRR is needed. I have 
> even had problems with the algorithm in SCReAM that prioritizes between 
> two cameras/video coders, this because the two cameras see different 
> views and thus provide differing information content/compression need.

This is an interesting data point I'd love to learn more about.  Not
surprised that scheduling would turn out to be one of the harder nuts to
crack.

> where min_rtt is the min RTT over a given time interval

That could work.  Still an area of experimentation (min_rtt may have its
own issues but that would remain to be seen).  QUIC rx timestamps may
help us further. So far, we mostly investigated different ways of
interpolating; tried different alternatives.

Best,
Jörg

---

From: Joerg Ott <[email-masked]>
Date: Mon, 15 Nov 2021 21:34:36 +0100

Hi,

> What I am trying to understand is, what is the motivation behind running 
> real time congestion control like SCReAM over QUIC congestion control? 
> The results (as Ingemar also mentioned) are not encouraging.

we should clarify that this wasn't a design choice but rather part of
systematically looking at the four combinations you get and then see
what happens to each one of them (we didn't expect this one to fare
particularly well but we were initially a bit surprised how poorly it
performed).

> If we want to use a single QUIC connection for media (audio/video using 
> RTP) and other reliable streams, then would it be better to not use QUIC 
> CC for media streams and only use it for reliable streams? Obviously 
> this will violate the current spec which applies congestion control on 
> connection level. But maybe this use case can be specialized.

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).

Indeed, one idea could be having a QUIC "enforce" a limit that it
considers acceptable for the current connection and provide the
RTP CC with the necessary parameters to come to a meaningful rate
itself; as long as the offered load from the RTP CC fits the
enveloped computed by QUIC CC, the DATAGRAMs could just flow;
above that rate, queuing or dropping (or local ECN-style signals)
could follow.

It remains to be seen if shared congestion control between real-time
flows, other datagrams, and regular QUIC streams can be done in a
sensible manner, with acceptable complexity and little brittleness.
And if there is a strong use case for such.  This was quite a bit
discussed in the MOQ side meeting.

>> already today has the congestion control on the connection level, it 
>> is then up to the individual streams to deliver media, subject to the 
>> congestion control on the QUIC connection level. The congestion 
>> control would then be some low latency version, perhaps BBRv2? or 
>> something similar, I am not sure that the network congestion control 
>> in SCReAM is the idea choice here as it is quite a lot tailored for 
>> RTP media. 
> 
> The impact of cascading two congestion controllers (with different input 
> and output parameters) has not been studied extensively yet. And is a 
> real time CC like SCReAM by itself not enough to control the congestion 
> in the network? In other words, does it need another congestion 
> controller to make sure that the real time data doesn’t cause more 
> congestion in the network?

Right.  The main question is: should a QUIC connection trust the
arbitrary datagram source or should it check.  Given that all sources
(datagrams and otherwise) would often be part of the same application,
there is probably not much point in trying to cheat on itself.  Maybe
some sanity checks would make sense, paired with mild adjustments of
the share given to the reliable streams as the codec source traffic
won't be able to follow exactly a given target data rate.

>> code one can see that the exotic variable queueDelayTrend as well as 
>> ECN marks and loss events are used for this purpose. I believe that 
>> something like that is needed for an RTP (or whatever low latency) 
>> media over QUIC. I believe that it is necessary to leak congestion 
>> information from the connection level up to the stream level, 
>> especially to be able to exploit L4S fully, even though it is a bit of 
>> a protocol layer violation.
> We absolutely should allow sharing of network events, like RTT, ECN, 
> packet loss from QUIC to RTP. Not sure how it is protocol layer violation.

Yes.

>> + Page 18 : Inferring the receive timestamp. What is suspect is that 
>> you will essentially halve the estimated queue delay (I assume here 
>> that the reverse path is uncongested). One alternative could be to 
>> compute
> You are right that halving latest_rtt / 2 may not be accurate if the 
> reverse path is not congested, but there is no guarantee for that. So, a 
> more accurate way to compute receive-ts is to use One way timestamps 
> which can be added to QUIC as new Frames.

As long as the metric is taken for what it actually is, a rough
approximation, we can probably work with a number of ways to measure.
More to experiment.

Best,
Jörg

>> On Nov 12, 2021, at 8:28 AM, Ingemar Johansson S 
>> <ingemar.s.johansson=[email-masked] 
>> <mailto:ingemar.s.johansson=[email-masked]>> wrote:
>>
>> Hi Jörg, Mathis + others
>> Did you use the new gsteamer plugin 
>> fromhttps://github.com/EricssonResearch/scream/tree/master/gstscream 
>> already today has the congestion control on the connection level, it 
>> is then up to the individual streams to deliver media, subject to the 
>> congestion control on the QUIC connection level. The congestion 
>> control would then be some low latency version, perhaps BBRv2? or 
>> something similar, I am not sure that the network congestion control 
>> in SCReAM is the idea choice here as it is quite a lot tailored for 
>> RTP media.
>> code one can see that the exotic variable queueDelayTrend as well as 
>> ECN marks and loss events are used for this purpose. I believe that 
>> something like that is needed for an RTP (or whatever low latency) 
>> media over QUIC. I believe that it is necessary to leak congestion 
>> information from the connection level up to the stream level, 
>> especially to be able to exploit L4S fully, even though it is a bit of 
>> a protocol layer violation.
>> stream is low latency video and another stream is a large chunk of 
>> data for e.g. a large web page. With a simple round robin scheduler, 
>> the stream with the large chunk of data will easily win because it is 
>> quite likely to always have data to transmit. So some WRR is needed. I 
>> have even had problems with the algorithm in SCReAM that prioritizes 
>> between two cameras/video coders, this because the two cameras see 
>> different views and thus provide differing information 
>> content/compression need.
>> + Page 18 : Inferring the receive timestamp. What is suspect is that 
>> you will essentially halve the estimated queue delay (I assume here 
>> that the reverse path is uncongested). One alternative could be to compute

---

From: Vidhi Goel <[email-masked]>
Date: Mon, 15 Nov 2021 15:40:52 -0800

> approximation, we can probably work with a number of ways to measure.

I forgot to mention earlier, but the equation for recieve-ts should be (assuming queuing is only in one direction)

receive-ts = send-ts + min_rtt/2 + (latest_rtt - min_rtt)

Right?

Thanks,
Vidhi

> On Nov 15, 2021, at 12:34 PM, Joerg Ott <[email-masked]> wrote:
> 
> Hi,
> 
>>> + Split of network congestion control and media rate control : QUIC already today has the congestion control on the connection level, it is then up to the individual streams to deliver media, subject to the individual stream priorities. SCReAM is quite similar in that respect, one difference is perhaps the implementation of the media rate control. I think that with QUIC one should do a full split and do the network congestion control on the QUIC connection level. The congestion control would then be some low latency version, perhaps BBRv2? or something similar, I am not sure that the network congestion control in SCReAM is the idea choice here as it is quite a lot tailored for RTP media. 
>>> On Nov 12, 2021, at 8:28 AM, Ingemar Johansson S <ingemar.s.johansson=[email-masked] <mailto:ingemar.s.johansson=[email-masked]>> wrote:
>>> 
>>> Hi Jörg, Mathis + others
>>> Did you use the new gsteamer plugin fromhttps://github.com/EricssonResearch/scream/tree/master/gstscream <https://github.com/EricssonResearch/scream/tree/master/gstscream>  ?
>>> Observations/Comments:

---

From: Justin Uberti <[email-masked]>
Date: Mon, 15 Nov 2021 17:32:33 -0800

> 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...

> >> <
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 16 Nov 2021 07:13:53 +0000

Hi Vidhi

You are right 😊

Receive time stamps is of course better, the benefit is that one don’t need to worry about possible reverse path congestion, the drawback is that clock drift needs to be addressed.

/Ingemar

From: Vidhi Goel <[email-masked]> 
Sent: den 16 november 2021 00:41
To: Joerg Ott <[email-masked]>
Cc: Vidhi Goel <vidhi_goel=[email-masked]>; Ingemar Johansson S <ingemar.s.johansson=[email-masked]>; [email-masked]; Ingemar Johansson S <[email-masked]>; IETF QUIC WG <[email-masked]>; [email-masked]
Subject: Re: RTP over QUIC experiments

Right?

Thanks,

Vidhi

On Nov 15, 2021, at 12:34 PM, Joerg Ott <[email-masked] <mailto:[email-masked]> > wrote:

Hi,

Yes.

Best,
Jörg

On Nov 12, 2021, at 8:28 AM, Ingemar Johansson S <ingemar.s.johansson=[email-masked] <mailto:ingemar.s.johansson=[email-masked]>  <mailto:ingemar.s.johansson=[email-masked]>> wrote:

Hi Jörg, Mathis + others
Did you use the new gsteamer plugin fromhttps://github.com/EricssonResearch/scream/tree/master/gstscream <https://github.com/EricssonResearch/scream/tree/master/gstscream <https://protect2.fireeye.com/v1/url?k=4c40e89e-13dbd19b-4c40a805-86d2114eab2f-5bc01f3ec9be70a9&q=1&e=fac4681d-c4fd-439d-89fa-e885e47e4764&u=https%3A%2F%2Fgithub.com%2FEricssonResearch%2Fscream%2Ftree%2Fmaster%2Fgstscream> >  ?

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 16 Nov 2021 08:24:56 +0000

Hi Jörg

Please see inline

/Ingemar

> -----Original Message-----
> From: Joerg Ott <[email-masked]>
> Sent: den 15 november 2021 21:19
> To: Ingemar Johansson S
> <ingemar.s.johansson=[email-masked]>; [email-masked]; IETF
> QUIC WG <[email-masked]>
> Cc: Ingemar Johansson S <[email-masked]>;
> [email-masked]
> > https://protect2.fireeye.com/v1/url?k=08572266-57cc1b66-085762fd-86fc6
> > 812c361-628ef39f33771783&q=1&e=e4b293a8-5f25-4c05-9d2e-
> f15862439753&u=
> >
> https%3A%2F%2Fgithub.com%2FEricssonResearch%2Fscream%2Ftree%2Fm
> aster%2
> > Fgstscream
> > <https://protect2.fireeye.com/v1/url?k=6c2bb408-33b08d08-6c2bf493-
> 86fc6812c361-ff87cf79fe3fb90c&q=1&e=e4b293a8-5f25-4c05-9d2e-
> f15862439753&u=https%3A%2F%2Fgithub.com%2FEricssonResearch%2Fscre
> am%2Ftree%2Fmaster%2Fgstscream>  ?
> 
> Well, we use your C++ version (forked a bit ago), not the plugin you refer to.
> This experiment has already been ongoing for some time.
> 
> > Observations/Comments:
> >

[IJ] Yes, one definitely need some kind of a low latency network congestion control, I guess today the lowest hanging fruit is BBRv1 or v2

> list, but there is only so much you can do at time :-)
[IJ] OK, understand the problem 😊

> as a first step of a more comprehensive evaluation of where we are.
[IJ] OK
> that turns out to be useful).
[IJ] OK, sounds good, 

> surprised that scheduling would turn out to be one of the harder nuts to
[IJ] I believe one can find some evidence of the problem in the SCReAM code. The stream prioritization is implemented as a WRR scheduler and works so-so (https://github.com/EricssonResearch/scream/blob/master/code/ScreamTx.cpp#L1682).. Still more code is needed to ensure the given priority (https://github.com/EricssonResearch/scream/blob/master/code/ScreamTx.cpp#L1651), the latter code is run every 1s when the link is congested. Without this extra adjustment I had the problem that the rear camera in our 5G toy car dropped down to real low bitrates. It is possible that one could do this smarter.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 23 Nov 2021 10:53:49 -0600

Just to echo what Justin said ...

> On Mon, Nov 15, 2021 at 12:35 PM Joerg Ott <[email-masked]> wrote:
snip

> 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

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 23 Nov 2021 14:48:24 -0500

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 <
[email-masked]> wrote:

> 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.
>