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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 1 Mar 2022 12:49:40 -0500

Can I get a clarification on what the issue is here?

Is this about having multiple QUIC connections on the same 5-tuple the 
same way you can have have multiple TCP connections (and hence multiple 
HTTP connections) over the same 5-tuple?

IIUC, while multiple TCP connections on the same 5-tuple are possible, 
it isn't currently possible to negotiate this within a single SDP media 
session. But it would be possible to do so using multiple SDP media 
sessions.

I would expect the same to be true for QUIC. If there is a perceived 
need to "fix" SDP to fix this then hopefully it will be done in a way 
that works for both QUIC and TCP.

	Thanks,
	Paul

On 2/28/22 8:51 PM, Paul Kyzivat wrote:
> On 2/28/22 6:16 PM, Martin Thomson wrote:
>> On Tue, Mar 1, 2022, at 09:29, Roman Shpount wrote:
>>> Do you think it makes sense to expose QUIC connection IDs in SDP, such
>>> as tls-id or something similar?
>>
>> No.  Let the endpoints manage connection IDs.  Both QUIC and TLS have 
>> mechanisms that endpoints can use to avoid unnecessary collisions.  
>> Tying that into session negotiation would constrain those mechanisms.
> 
> Isn't this a lot like SCTP? We already worked out all the SDP for 
> connections there.
> 
>      Thanks,
>      Paul
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Roman Shpount <[email-masked]>
Date: Wed, 2 Mar 2022 01:26:13 -0500

Paul,

> that works for both QUIC and TCP.

The issue is that with offer/answer, it is possible to establish a new
connection over the same 5-tuple while packets for the old connection are
still being sent. This most often happens due to race conditions between
signaling and media. Some protocols, like DTLS, are bad at dealing with
demultiplexing packets for several associations running over the same
5-tuple. In RFC 8842, we needed to require that new 3-tuple is allocated
when the end-point creates a new DTLS association. I wanted to make sure
this is not a problem with QUIC. It seems it is not.

The other problem I am investigating is the client/server use case. The
server uses the same address and port for connections to multiple clients
to avoid being blocked by firewalls (i.e., sending offers to different
clients with server addresses and UDP port 443). This can mean sending
multiple offers to clients with the same address and port and getting
multiple connection requests from clients (different client
addresses/ports) simultaneously. I am trying to figure out if there is a
way to match those connections to SDP offers sent by the server.

Best Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Mar 2022 10:54:37 -0500

Roman,

Thanks for the explanation. I don't have any more to add at this point.

	Thanks,
	Paul

On 3/2/22 1:26 AM, Roman Shpount wrote:
> Paul,
> 
> On Tue, Mar 1, 2022 at 12:50 PM Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> connection over the same 5-tuple while packets for the old connection 
> are still being sent. This most often happens due to race conditions 
> between signaling and media. Some protocols, like DTLS, are bad at 
> dealing with demultiplexing packets for several associations running 
> over the same 5-tuple. In RFC 8842, we needed to require that new 
> 3-tuple is allocated when the end-point creates a new DTLS association. 
> I wanted to make sure this is not a problem with QUIC. It seems it is not.
> 
> server uses the same address and port for connections to multiple 
> clients to avoid being blocked by firewalls (i.e., sending offers to 
> different clients with server addresses and UDP port 443). This can mean 
> sending multiple offers to clients with the same address and port and 
> getting multiple connection requests from clients (different client