Re: [AVTCORE] RTP over QUIC experiments

Spencer Dawkins at IETF <> Tue, 23 November 2021 16:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 868FB3A0598; Tue, 23 Nov 2021 08:54:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oTtdmTsZIq3P; Tue, 23 Nov 2021 08:54:18 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E498B3A0541; Tue, 23 Nov 2021 08:54:17 -0800 (PST)
Received: by with SMTP id 70so4393876vkx.7; Tue, 23 Nov 2021 08:54:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HjGm8gKIntRyb8kWOnAL4NBHrgdwBwMggXvFquRmPms=; b=Qt30asHKGggrRxs24t0Y/V4D+xWVu+733c2axJTrj8JE08uEG2g7F9uwV86APGFJ/6 8LAXAkLEpi7u2anakIejpR98+dioE5Z+xzcaT64E3gOrF3CVhnkZxfp2T5fSld48Men5 n6DCGIQazlZ8sjBM40yImZk1tlMPdWv2MtHWooALth42vOd+k1TucYNjSdm4fmiT1baT rwwCniuHUExQy44pgTecEMgBTHSM7K0+CUEBshf+TSnZsKzfjRWsWUDKX8N8X2iyKLBC zzSWKA0zGQZLSqlazg2SzM9/2G4jnAzolUvNia/KS0aDo9Vy0FJ7KEgtkFpXkGvAX6sV j6pg==
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=HjGm8gKIntRyb8kWOnAL4NBHrgdwBwMggXvFquRmPms=; b=wwB/NtVRGFs8KFB0OMXAmt/+T2RtcIhNrfA+m+jtprPP8y/mt/Vc/XSF9Y+aIxSo7g TRLrECyp9CkFtCS4d1zN4g2fOTlJVK5HIv30jIiJyyuC/jM0TqMLTSBFH3IVrXyR9aLy bxLWhGcvjHhbTXxS7bGEFkCWpsGaZbOonHXHsJNV2Olvu1i/WlP/3CmKJ3Pqg/0+H5mZ NsRkwFcWJ/nnFRf6StzgtH4sJANgYKYsR7WxNE2JY1nLHQqqcqFQLyGmsoWwBDClQ29X qrOKRg+DQnzOXB/RDB6WWPO2XQ2XsPqmHK8wBIeLe3/EehUKH6JGu8uJP2RdjQcj6vw6 hxsw==
X-Gm-Message-State: AOAM531utj4roWBmgIoHrtWYXW9mToM7vmcDd/poTioKrIRtIB98Z5Mq jeM/wuUjZBBn1rsnPxiNZaO09sCvgMDuOVgYzoA=
X-Google-Smtp-Source: ABdhPJwQSn33l/IsKGC+HqA4ah0eP3s82czkbj9fEH251Z8yUmj+F3wKEWZFPtqcgaMcGUJCU3U52EYode9LGhjX094=
X-Received: by 2002:a05:6122:1788:: with SMTP id o8mr12548893vkf.8.1637686455948; Tue, 23 Nov 2021 08:54:15 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Tue, 23 Nov 2021 10:53:49 -0600
Message-ID: <>
Subject: Re: [AVTCORE] RTP over QUIC experiments
To: Justin Uberti <>
Cc: Joerg Ott <>, "" <>, Ingemar Johansson S <>, "" <>, Ingemar Johansson S <>, Vidhi Goel <>, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="00000000000075d71405d1779719"
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 16:54:23 -0000

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:

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