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

David Schinazi <dschinazi.ietf@gmail.com> Tue, 31 May 2022 22:14 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 8958CC15AAF0 for <avt@ietfa.amsl.com>; Tue, 31 May 2022 15:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, T_SCC_BODY_TEXT_LINE=-0.01, 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U2JYyrkhw3y for <avt@ietfa.amsl.com>; Tue, 31 May 2022 15:14:33 -0700 (PDT)
Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 5AABCC15AAD3 for <avt@ietf.org>; Tue, 31 May 2022 15:14:33 -0700 (PDT)
Received: by mail-pg1-x52d.google.com with SMTP id s68so64017pgs.10 for <avt@ietf.org>; Tue, 31 May 2022 15:14:33 -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=jJKM7O+5MPygUc+MxSbcZtqW+8yLea+BGJXDJM02JgI=; b=aAvPIRPcFJaZ65uwVyFzMvpR9AcMLmC0+ho9mXszFI2OhBMHyAWEoP3riSP7bZqFV6 zugOXlUiNq7xAhk8ZLgM0byhzuF0CtBOMbbS0fcGHRCtfTCCgvvYmWcy8jGthel6UsSc g+CCYRWMpd/lVXjB+iMLuBzM7H7oCXY9QUXjqgpoPbWfyLzcyBI1q6+IAlmVS/z7+zeN Z4kEqDnX/UxtBVQ4XEx3sX2Ca7OTA13M51j7aXPdCRDtOfFGe/LFzfOd74aSxTasiRyD cMtBbipvjh/Q/s+PtwzKShZiCJu63LIMWMtpU/MK71Wjv+HZfJK52IRt14E2WoL/6k6Z oL9g==
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=jJKM7O+5MPygUc+MxSbcZtqW+8yLea+BGJXDJM02JgI=; b=2+Nb0taTSfi2b7O1uJrLvpVIm9NbLXmPzdav8YbE+jSCu0nbyWq52CSL3NL3y+NLp0 NYSNdVdV7C0Tr13DQBH8rYUuX8gJ2JfNO9lFB+z8SuPixzjUA/vbC9yx8hfvKfVc6zVs E1hmCIAHKVtdUf/250KCG83bUYo8mB+nMj2hqziTq8tymsia9NfSRCAL6RUOY3RxIr8g 1s9teWUKcVDrlCx4plUAt/AhlhPp8EAeqxF95LAmEG83q7r2J1WN4fezfuBef4LnrT8q 11VbXj4SM0DXKXhqfP94q/gVz1wYP4CXx9b5Ko9FclYCD1KURzjO602Z8lP9iVtsWVrv Ot4A==
X-Gm-Message-State: AOAM5305m9luQvDKhGQ99NFYfJvfqOEe3Rd6FSThtcjW6BIJnJ4xAtDO yiVU3zp6M1MZsXrpmxd452r8n29T1DUEMK81DRs=
X-Google-Smtp-Source: ABdhPJyqEB889OA/5ui7/1oxo7YCMkgALlf+5Us2tR9rnL9D9q55lJw8ISwXIsz1bAk1G4kAFyOT6aL5tLOZRnkEFck=
X-Received: by 2002:a63:2360:0:b0:3fb:ee61:82cf with SMTP id u32-20020a632360000000b003fbee6182cfmr13211851pgm.574.1654035272737; Tue, 31 May 2022 15:14:32 -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> <CAPDSy+4hvJ7icFtT3sgjAs4SBEKQ9E1LEDOYZ2fLbi60W_=+sg@mail.gmail.com> <CAOW+2dui5pBbyvxW+Af9AWjbKc7ROyZSBmt0MuKGSk0-oYzg6Q@mail.gmail.com>
In-Reply-To: <CAOW+2dui5pBbyvxW+Af9AWjbKc7ROyZSBmt0MuKGSk0-oYzg6Q@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Tue, 31 May 2022 15:14:21 -0700
Message-ID: <CAPDSy+4COC-yyn0eDrYKYiDD6nCFUHA6kR+8FRzcKT82xA-8Og@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="000000000000e0a79a05e05618b6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/pd5KVgCPIPvb67kKPHEr3U1YL48>
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 22:14:37 -0000

Understood. However this "tight integration" does not impact the choice of
ALPN. There's nothing preventing a higher layer protocol from reaching into
the depths of its underlying transport, no matter what state of affairs
might be prefered by OSI :-)

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

> David said:
>
> "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."
>
> [BA] Correct - but draft-engelbart-rtp-over-quic seems to be assuming
> "tight integration" between QUIC and the RTP stack (e.g. so that QUIC ACK
> info can be used rather than RTCP messages). The WebTransport API
> (regardless of what protocol might run underneath) doesn't provide that ACK
> info because in a browser an ACK at the QUIC layer wouldn't necessarily
> imply reception by the application.
>
> On Tue, May 31, 2022 at 5:53 PM David Schinazi <dschinazi.ietf@gmail.com>
> wrote:
>
>> 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
>>>>
>>>