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

["Paul E. Jones" <[e-mail]>]

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