Re: [AVTCORE] Review of draft-engelbart-rtp-over-quic (David Schinazi)

David Schinazi <dschinazi.ietf@gmail.com> Tue, 31 May 2022 21:53 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD681C15AACA for <avt@ietfa.amsl.com>; Tue, 31 May 2022 14:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMM7Nch2Kwja for <avt@ietfa.amsl.com>; Tue, 31 May 2022 14:53:31 -0700 (PDT)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AB11C15AAC0 for <avt@ietf.org>; Tue, 31 May 2022 14:53:31 -0700 (PDT)
Received: by mail-pj1-x102c.google.com with SMTP id e24so193794pjt.0 for <avt@ietf.org>; Tue, 31 May 2022 14:53:31 -0700 (PDT)
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=kSEyBcmGp6dZtkKU1LUInN7uOSvyt4nluAlCjiHrdy0=; b=iJpQlyU771XuX5EsnHcAyEbvDSkOMF6O6VmjCHAB/hBacxVAiyRdAkxLZ2Xb4/U4d5 8+SW3UeMEXym6lpnSvLyd4yioofKUC5FBIQEGmL58TtthORZ0gcy09JFo9Tnzt07+OGe Kit7qnLmaywRVo/VZu3YVfmgxR8ycQ8VLB6jD8GNjptFofwjDEFFBOiYnG+xJ4A+9EJv YM/KpzVZDI93n+dzXeQs9W2R9edYhEgRfzXgNzIo4GWgUoX3hN+W9QF/J0vML3/UYgXg uBng7HerV2tLUl6tBmxa/OKgOlRN1jmYekYtkHo3s/uJIecDNmwGvLdlPo1pNeGIk7gl 3yCw==
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=kSEyBcmGp6dZtkKU1LUInN7uOSvyt4nluAlCjiHrdy0=; b=F/SNtqcoxIAPrkeOhOSE92FUEGoNEyYYtNDzM5S9ECk+3IWo7+74gLg7ULqLodNNxI WJQP0puaj+NW223Xy7j5E8+O5PPqGhfLnmgoK7QCxepT49flm0iODulEX6zbpbNnP6O6 tMC5y5WyfSaljTobVHS/0Atf7z+PIxF+OeQ51yrR5e0OYYzEr+IPFJYW2ue6RqxOZrw8 foy1ynOoI7itgGx/QUdIRsH+r+mLHFbCMjHY4FbZ0F2DT+6Z9ghEgaiD3Gg58L580nfP /EhlXJrdxM/CjAoQRTvtaq6IlKs1oKdcpOnzKTj985+xadCOkfQzRg1s78iRZwJ9BhcP llnQ==
X-Gm-Message-State: AOAM530WuuKndvGI2IrrV+a7bzte9Q/EabE8/05dICC0QlYlkhu8dHPQ sAAKImSIbF8HJjhR8ON1wmKhJfs/mxIavW6AZAEhLxDm
X-Google-Smtp-Source: ABdhPJxQ9QOQgGz/Sw+rvD+8XVQSrORAbEbECP+ZN/8CRMdBeUO4NzNbcfebCnrLfiwBsNoEiLxsDJ9hk3QZKoOQGfo=
X-Received: by 2002:a17:90b:1b07:b0:1e0:41c2:9e15 with SMTP id nu7-20020a17090b1b0700b001e041c29e15mr30484513pjb.20.1654034010431; Tue, 31 May 2022 14:53:30 -0700 (PDT)
MIME-Version: 1.0
References: <CAOW+2duZuSb_w2jAARmPYq0O0b4fYGtMtbPWAYxZDf8r-q=Cng@mail.gmail.com> <a75e4d70-b11e-d5a0-ce19-ce90bf8f2a84@in.tum.de> <CALGR9oY2jQuKvE_ES=_kb7XoQ6KCoxJtoyc0VdAZ4P-L4QT3Gg@mail.gmail.com> <CAPDSy+5Yud2rU4-0jA2UnuKwaX6TGiof6QHECDvaRosHd1sdsA@mail.gmail.com> <CAOW+2dsx-+jFiUgoAE3Rx1EB_f+=stXo9X2xeXw111jrR9Jn_Q@mail.gmail.com>
In-Reply-To: <CAOW+2dsx-+jFiUgoAE3Rx1EB_f+=stXo9X2xeXw111jrR9Jn_Q@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Tue, 31 May 2022 14:53:19 -0700
Message-ID: <CAPDSy+4hvJ7icFtT3sgjAs4SBEKQ9E1LEDOYZ2fLbi60W_=+sg@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, Mathis Engelbart <mathis.engelbart@tum.de>, IETF AVTCore WG <avt@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a3657405e055cd64"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/KAylfkSA1xFXRpbJfLrhUVkii4o>
Subject: Re: [AVTCORE] Review of draft-engelbart-rtp-over-quic (David Schinazi)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 May 2022 21:53:35 -0000

I think HTTP/3 vs P2P is a false dichotomy, there's nothing preventing a
browser from implementing a QUIC server stack and an HTTP/3 server stack.
David

On Tue, May 31, 2022 at 2:49 PM Bernard Aboba <bernard.aboba@gmail.com>
wrote:

> David said:
>
> "The considerations I wrote that Bernard forwarded above applied to any
> use of QUIC, be it client-to-server or p2p, as QUIC does not differentiate
> between the two. As Lucas points out, if you want to use QUIC you have to
> pick one ALPN per connection."
>
> [BA] Yes, there are ALPN considerations here.
>
> There are also some other considerations that could differ between
> client-to-server (WebTransport) and P2P QUIC scenario. The RTP over P2P
> QUIC use case enables tighter integration with the QUIC stack than would
> RTP over WebTransport, where WebTransport is natively implemented in the
> browser and RTP is provided in a Javascript or WASM library.  In the RTP
> over WebTransport case, QUIC internals (such as ACK info) might not be
> easily accessible, which might make it necessary to duplicate info at the
> QUIC and RTCP layers.
>
> David said:
>
> "If you want to simultaneously run RTP-over-QUIC and WebTransport, you
> have two options:
>
> 1) define RTP-over-HTTP/3. That way you have one QUIC connection with
> ALPN=h3 and then you can run
> as many RTP or WebTransport sessions on top.
> 2) use two distinct QUIC connections, one for RTP and one for
> WebTransport-over-HTTP/3.
> They can be on the same socket and demultiplexed using the QUIC connection
> ID
>
> If you go the RTP-over-QUIC route, then the document that defines it gets
> to define what the payload of
> datagram frames contains. They can choose to use a flow identifier and can
> define its semantics to
> be whatever they want. They can also skip flow identifiers and use
> something else instead."
>
> [BA] Within WebRTC, we have seen most applications choose to multiplex
> everything (STUN/TURN, DTLS, RTP, RTCP, audio, video, data) on a single
> port. So I suspect there will be interest in doing the same thing over QUIC
> (regardless of whether we are talking about P2P QUIC or WebTransport).
>
> There is a debate about how best to multiplex audio/video with data
> exchange (e.g. whether it is best to use two QUIC connections multiplexed
> by connection ID, possibly with distinct CC algorithms, or a single QUIC
> connection with one algorithm).  Having a single connection with an
> appropriate congestion control algorithms (e.g. SCReaM or Google CC) can
> provide greater fairness between file transfers and media. This would make
> a file transfer done simultaneously with audio/video take longer, but
> that's probably what you want, as opposed to having the file transfer using
> NewReno or BBR starving media using a low-latency CC algorithm.
>
> That seems to argue for defining RTP-over-HTTP/3 as well as RTP over P2P
> QUIC.  In the RTP-over-HTTP/3 case, RTP would be a JS library running in a
> browser over WebTransport and optimizations that might be
> possible with RTP over P2P QUIC (such as use of QUIC ACKs instead of RTP
> NACK) might not be possible.
>
> In either scenario, there is also the question of how you distinguish data
> from RTP/RTCP that arrives in a WebTransport Datagram or Message/Stream.
> One way to do this (for WebTransport or P2P QUIC) might be by looking at
> the first byte.
>
> On Tue, May 31, 2022 at 4:44 PM David Schinazi <dschinazi.ietf@gmail.com>
> wrote:
>
>> [ replacing my email address, as I left Apple more than 3 years ago :-) ]
>>
>> The considerations I wrote that Bernard forwarded above applied to any
>> use of QUIC, be it client-to-server or p2p, as QUIC does not differentiate
>> between the two. As Lucas points out, if you want to use QUIC you have to
>> pick one ALPN per connection.
>>
>> David
>>
>> On Wed, May 25, 2022 at 12:33 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
>> wrote:
>>
>>> Hi Joerg, David,
>>>
>>> I don't have a strong stake in the upper L7 matters but FWIW
>>>
>>> RFC 9000 section 7 says: "The cryptographic handshake MUST provide ..
>>> authenticated negotiation of an application protocol (TLS uses
>>> Application-Layer Protocol Negotiation (ALPN) [ALPN
>>> <https://www.rfc-editor.org/rfc/rfc9000.html#ALPN>] for this purpose)"
>>> RFC 9001 section 8.1 says: "QUIC requires that the cryptographic
>>> handshake provide authenticated protocol negotiation. TLS uses
>>> Application-Layer Protocol Negotiation [ALPN] to select an application
>>> protocol. Unless another mechanism is used for agreeing on an application
>>> protocol, endpoints MUST use ALPN for this purpose."
>>>
>>> The QUIC implementations I'm familiar with will enforce these
>>> requirements. So for anyone writing an application mapping that expects
>>> interop, that really do need to explicitly define _an_ ALPN identifier OR
>>> state what exactly the alternative mechanism is.
>>>
>>> Cheers,
>>> Lucas
>>>
>>> _______________________________________________
>>> Audio/Video Transport Core Maintenance
>>> avt@ietf.org
>>> https://www.ietf.org/mailman/listinfo/avt
>>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
>>
>