Subject: [AVTCORE] Comments on draft-petithuguenin-avtcore-rfc5764-mux-fixes

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 20 Dec 2014 02:17:05 +0000

AVT,

While the issues raised in the rfc5764-mix-fixes draft are valid, I'm 
curious if consideration has been given to address multiplexing more 
generally?  Years ago, if anyone suggested multiplexing STUN, DTLS, 
TURN, along with RTP and RTCP, it wouldn't have been met with much 
enthusiasm.  Now, we are multiplexing everything over a single port.  I 
appreciate the reason, but it feel like this is a delicate balancing act 
and it imposes restrictions on existing protocols and will impose 
restrictions on future protocols to allow this model to continue as-is.

Since multiplexing over a single port is now considered legitimate, why 
not allocate a code point (e.g., 0x04) to be one dedicated for 
multiplexing?  I'm not suggesting we change what is already defined, but 
rather to introduce a new code point explicitly intended to facilitate 
multiplexing in such a way as to avoid having the delicate balancing act 
of ensuring that values do not conflict.  Such a scheme could also be 
used to allow for multiple instances of the same protocol (e.g., 
multiple DTLS connections) to be multiplexed over the same port.  Taken 
to an extreme, it might be possible to allow multiple RTP sessions to be 
multiplexed over the same port.  (I'm not suggesting we go that far, but 
having that kind of flexibility would not hurt.)

My thinking is that if the first octet is 0x04, the receiver will then 
look at the following two octets to determine how to handle the packet.  
These two octets could be sub-divided into IANA-assigned protocol 
identifiers and dynamically allocated values.  Basically, we would have 
this:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      0x04     |      protocol_identifier      | muxed data 
follows  ...
      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

When the next protocol to be multiplexed is defined, we could statically 
allocate a protocol_identifier value for the protocol.  We could also 
define SDP syntax that would allow these values to by advertised so that 
protocols could be safely muxed even without a static allocation.  So, 
if there was a desire to have two WebRTC Data Channels, for example, one 
(or both) might be multiplexed using this scheme.  Perhaps all packets 
related to the first might be identified by 0x048001 and the other might 
be identified by 0x048002.  You can imagine how the protocol_identifiers 
0x8001 and 0x8002 could be advertised in SDP easily enough.  DTLS is 
already used for two entirely different purposes (DTLS-SRTP and WebRTC 
Data Channels), which forces a violation of RFC 5764 Section 5.1.1.  For 
that and other reasons, I can see benefit in multiplexing DTLS-SRTP and 
the WebRTC Data Channel (SCTP/DTLS) as two DTLS sessions.

Has there been discussion on this or is there interest in this approach?

Paul

---

From: Colin Perkins <[email-masked]>
Date: Tue, 23 Dec 2014 09:45:38 +0000

Paul,

I agree that some sort of explicit demultiplexing shim would solve a lot of problems, and would have addressed many of the signalling issues WebRTC has exposed in this space. Our proposal was draft-westerlund-avtcore-transport-multiplexing-07. The working group didn’t seem keen on the idea, however. 

Colin

On 20 Dec 2014, at 02:17, Paul E. Jones <[email-masked]> wrote:

> AVT,
> 
> While the issues raised in the rfc5764-mix-fixes draft are valid, I'm curious if consideration has been given to address multiplexing more generally?  Years ago, if anyone suggested multiplexing STUN, DTLS, TURN, along with RTP and RTCP, it wouldn't have been met with much enthusiasm.  Now, we are multiplexing everything over a single port.  I appreciate the reason, but it feel like this is a delicate balancing act and it imposes restrictions on existing protocols and will impose restrictions on future protocols to allow this model to continue as-is.
> 
> Since multiplexing over a single port is now considered legitimate, why not allocate a code point (e.g., 0x04) to be one dedicated for multiplexing?  I'm not suggesting we change what is already defined, but rather to introduce a new code point explicitly intended to facilitate multiplexing in such a way as to avoid having the delicate balancing act of ensuring that values do not conflict.  Such a scheme could also be used to allow for multiple instances of the same protocol (e.g., multiple DTLS connections) to be multiplexed over the same port.  Taken to an extreme, it might be possible to allow multiple RTP sessions to be multiplexed over the same port.  (I'm not suggesting we go that far, but having that kind of flexibility would not hurt.)
> 
> My thinking is that if the first octet is 0x04, the receiver will then look at the following two octets to determine how to handle the packet.  These two octets could be sub-divided into IANA-assigned protocol identifiers and dynamically allocated values.  Basically, we would have this:
> 
>     |      0x04     |      protocol_identifier      | muxed data follows  ...
> When the next protocol to be multiplexed is defined, we could statically allocate a protocol_identifier value for the protocol.  We could also define SDP syntax that would allow these values to by advertised so that protocols could be safely muxed even without a static allocation.  So, if there was a desire to have two WebRTC Data Channels, for example, one (or both) might be multiplexed using this scheme.  Perhaps all packets related to the first might be identified by 0x048001 and the other might be identified by 0x048002.  You can imagine how the protocol_identifiers 0x8001 and 0x8002 could be advertised in SDP easily enough.  DTLS is already used for two entirely different purposes (DTLS-SRTP and WebRTC Data Channels), which forces a violation of RFC 5764 Section 5.1.1.  For that and other reasons, I can see benefit in multiplexing DTLS-SRTP and the WebRTC Data Channel (SCTP/DTLS) as two DTLS sessions.
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
https://csperkins.org/