Re: [AVTCORE] RTP over QUIC experiments

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Tue, 23 November 2021 16:54 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868FB3A0598; Tue, 23 Nov 2021 08:54:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTtdmTsZIq3P; Tue, 23 Nov 2021 08:54:18 -0800 (PST)
Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E498B3A0541; Tue, 23 Nov 2021 08:54:17 -0800 (PST)
Received: by mail-vk1-xa2c.google.com with SMTP id 70so4393876vkx.7; Tue, 23 Nov 2021 08:54:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <AM8PR07MB8137AD430709AC54E6EA361CC2959@AM8PR07MB8137.eurprd07.prod.outlook.com> <236C1AB5-D0F5-4453-A4F3-DEAB5D7113CB@apple.com> <2c965999-21f8-9a62-e008-47094a47430f@in.tum.de> <CAOLzse0-7LGmH6zr6khbiby358GseeSTGTFRgTHHasJXd-Riqg@mail.gmail.com>
In-Reply-To: <CAOLzse0-7LGmH6zr6khbiby358GseeSTGTFRgTHHasJXd-Riqg@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 23 Nov 2021 10:53:49 -0600
Message-ID: <CAKKJt-c4M61cDTx7FK+mmUQuprmCyB+EwnZAqWufVpi66Eqv2g@mail.gmail.com>
Subject: Re: [AVTCORE] RTP over QUIC experiments
To: Justin Uberti <juberti@alphaexplorationco.com>
Cc: Joerg Ott <ott@in.tum.de>, "mathis.engelbart@gmail.com" <mathis.engelbart@gmail.com>, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>, "avt@ietf.org" <avt@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000075d71405d1779719"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/CPAtJYRiJ7jtAHvHVmuE9R65jZE>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=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 <
juberti@alphaexplorationco.com> wrote:

>
>
> On Mon, Nov 15, 2021 at 12:35 PM Joerg Ott <ott@in.tum.de> 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