Re: [AVTCORE] Running multiple quic sessions over the same address/port pair

[Roman Shpount <[e-mail]>]

I want to be clear about what I am asking: I am asking about multiplexing
multiple QUIC connections as a whole over the same transport (address/port
pairs).

In P2P, it is possible for one party to etsablish a new connection over the
same address/port pairs when the previous connection is still used to send
data. Most commonly, this happens due to races between signaling and media.
_____________
Roman Shpount


On Sun, Feb 27, 2022 at 11:15 PM Bernard Aboba <[e-mail]>
wrote:

> In P2P there is the potential need to multiplex/demultiplex:
> 1. RTP/RTCP over QUIC datagrams,
> 2. Data over QUIC datagrams, (unreliable/unordered)
> 3. Data over a QUIC reliable stream (reliable/ordered),
> 4. Message per stream (reliable/unordered)
>
> Cases 3/4 could be either data or media (e.g. case 3 could be GoP per
> stream, 4 could be encoded frame per stream).
>
> On Sun, Feb 27, 2022, 7:54 PM Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>> I should add one more point.
>>
>> On Sat, Feb 26, 2022 at 11:37 PM Roman Shpount <[e-mail]> wrote:
>>
>>> On Sun, Feb 27, 2022 at 12:18 AM Bernard Aboba <[e-mail]>
>>> wrote:
>>>
>>>> On Feb 26, 2022, at 20:50, Roman Shpount <[e-mail]> wrote:
>>>> [BA] This should be possible. The means will differ depending on
>>>> whether we are talking about P2P QUIC (where you could use Connection-Id)
>>>> or something higher up the stack. Multiplexing as defined in rfc7983bis
>>>> wasn’t implemented in the P2P (g)QUIC Origin trial since the QUIC
>>>> implementation was pre-standard and lacked the capability. So only one
>>>> connection was allowed. At the time the focus was on P2P data not media,
>>>> but in the absence of priority support, it seemed desirable to allow
>>>> distinct data and media connections that might be constructed to use
>>>> different cc algorithms.
>>>>
>>>>
>>> This is very interesting and can be one more reason to use QUICK instead
>>> of DTLS. The problem would be to map a pair of tls-id to a Connection-Id.
>>>
>>
>> (After agreeing with Bernard's points)
>>
>> Within the "Media Over QUIC" conspiracy, we have some folks that are
>> assuming they would use datagrams ("because datagrams"), and other folks
>> assuming they would use streams ("because multiplexing"). One of the things
>> that I'm finding in conversations on that side of the fence is that the
>> choice isn't obvious (even though it's obvious to everyone, it's not the
>> same obvious answer).
>>
>> The QUIC working group started out thinking that they obviously needed
>> some way to multiplex datagrams, but then discovered that there were a lot
>> of (potentially conflicting) reasons to want to multiplex datagrams, so
>> they punted that to the application, in
>> https://www.ietf.org/archive/id/draft-ietf-quic-datagram-10.html#name-multiplexing-datagrams
>> .
>>
>> I wrote about this in more detail, in
>> https://spencerdawkins.github.io/sdp-rtp-quic-questions/draft-dawkins-sdp-rtp-quic-questions.html#name-quic-datagram-multiplexing
>> .
>>
>> (I *really *need to update my sdp-rtp-quic*-questions* draft - I wasn't
>> expecting that, but I'm happy to do it)
>>
>> Best,
>>
>> Spencer
>>
>>
>>> _____________
>>> Roman Shpount
>>>
>>>
>>