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