Re: [AVTCORE] RTP over QUIC experiments

Phillip Hallam-Baker <> Tue, 23 November 2021 19:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0EC7F3A012C; Tue, 23 Nov 2021 11:48:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GsZ-4ZbzSFtP; Tue, 23 Nov 2021 11:48:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 35C803A0139; Tue, 23 Nov 2021 11:48:38 -0800 (PST)
Received: by with SMTP id f186so599465ybg.2; Tue, 23 Nov 2021 11:48:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ke8de3LdLTt6/hHTuQnSlRcj3MgcfaxgTcKsVcI/Wqc=; b=0Zea9dETpHpqmxkcvVtmOUvDJ0E+KgozMMBPgPgXTd3QivUPTB/dDqbB51XLwxnY5f 8GT7WXBoXxS9ll7kSqkmh1Clb2IReCPtkURpyrV0AHb6gG86DaOzCeYveT4ArIF5hBWM 1DuIR7yHAS1b5kt8xbOI9ANNMAmSP0pt1KHl46ADY0ZKbdNQEp49GdGQUny67NjvcqmC 6Pf9eQ4ymL7WhEZA4w+0W/a26p2c4ZMsK2ZefWSQn7jd63ohcrB6E4zP8LIgCxRAlV2H aYAZmHSyHmQlJeQAbmjaEnY9A1NZ+w/4Zz3/WokLFTboxs2pYEGCV6By+R1RjUNzTdMJ PJug==
X-Gm-Message-State: AOAM533jKfwYwa+J3i2oxj0CwLGqkjgLB07A8Nf0oCUnQQSw7Sp6sjn9 cpOp0Cr+RAZpYKbNfkpNW5zVoIGTXgjUwZIAwrs=
X-Google-Smtp-Source: ABdhPJzFkNxpQuo/l33k+A2Titfv74y0wRH8VcspTvcQajbx9PibDWDfd0eTGfv3IsJY0fMc79xU0Lg3mM4AENb2wzs=
X-Received: by 2002:a05:6902:1549:: with SMTP id r9mr9496063ybu.454.1637696917224; Tue, 23 Nov 2021 11:48:37 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Tue, 23 Nov 2021 14:48:24 -0500
Message-ID: <>
Subject: Re: [AVTCORE] RTP over QUIC experiments
To: Spencer Dawkins at IETF <>
Cc: Justin Uberti <>, "" <>, Ingemar Johansson S <>, "" <>, Ingemar Johansson S <>, Vidhi Goel <>, IETF QUIC WG <>, Joerg Ott <>
Content-Type: multipart/alternative; boundary="00000000000000413705d17a079f"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Nov 2021 19:48:43 -0000

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

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 <> wrote:

> Just to echo what Justin said ...
> On Mon, Nov 15, 2021 at 7:33 PM Justin Uberti <
>> wrote:
>> On Mon, Nov 15, 2021 at 12:35 PM Joerg Ott <> 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 (That's
> actually a pretty nuanced discussion of the topic - what you'd expect from
> a Gorry document - and well worth the read.
> does distinguish
> between applications intended for use within a managed domain and
> applications intended for use on the general Internet.
> 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