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 >>>> >>>
- [AVTCORE] Review of draft-engelbart-rtp-over-quic… Bernard Aboba
- Re: [AVTCORE] Review of draft-engelbart-rtp-over-… Joerg Ott
- Re: [AVTCORE] Review of draft-engelbart-rtp-over-… Lucas Pardue
- Re: [AVTCORE] Review of draft-engelbart-rtp-over-… David Schinazi
- Re: [AVTCORE] Review of draft-engelbart-rtp-over-… Bernard Aboba
- Re: [AVTCORE] Review of draft-engelbart-rtp-over-… David Schinazi
- Re: [AVTCORE] Review of draft-engelbart-rtp-over-… Bernard Aboba
- Re: [AVTCORE] Review of draft-engelbart-rtp-over-… David Schinazi
- Re: [AVTCORE] Review of draft-engelbart-rtp-over-… Joerg Ott
- Re: [AVTCORE] Review of draft-engelbart-rtp-over-… Lucas Pardue
- Re: [AVTCORE] Review of draft-engelbart-rtp-over-… David Schinazi
- Re: [AVTCORE] Review of draft-engelbart-rtp-over-… Joerg Ott
- Re: [AVTCORE] Review of draft-engelbart-rtp-over-… Lucas Pardue