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

[Bernard Aboba <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> 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 <[e-mail]>
>> 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 <
>>> [e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/avt
>>>>
>>> _______________________________________________
>>> Audio/Video Transport Core Maintenance
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/avt
>>>
>>