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

  Colin,

Thanks for informing me of that. There is a difference in what is 
proposed there vs. what I propose below. The shim in the draft makes 
that first word ("Session ID Layer") look like an RTP packet. Depending 
on the value of the "reserved" bits, this could cause a conflict with 
other protocols already multiplexed. But, I can appreciate that this 
could be addressed easily.

Clearly, I wasn't aiming to have something that resembles an RTP packet, 
since other protocols being multiplexed don't look like them, either. 
There is already a multiplexing layer in stacks to handle DTLS, STUN, 
and RTP packets. I wanted something that would be one more addition that 
could be more generic.

I guess the important question is why the WG wasn't keen on the idea? 
Was this perhaps presented just a little early? I can already see some 
utility in multiplexing multiple DTLS connections, which is presently 
not possible. And, I'm sure there will be other protocols in the future. 
So, I'm wondering if we ought to revisit this topic. Is that even an 
option or is the door closed on this topic?

Paul

------ Original Message ------
From: "Colin Perkins" <csp@csperkins.org>
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: "avt@ietf.org WG" <avt@ietf.org>; marcph@getjive.com
Sent: 12/23/2014 4:45:38 AM
Subject: Re: [AVTCORE] Comments on 
draft-petithuguenin-avtcore-rfc5764-mux-fixes

>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 <paulej@packetizer.com> 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.
>>
>>  Has there been discussion on this or is there interest in this 
>>approach?
>>
>>  Paul
>>
>>  _______________________________________________
>>  Audio/Video Transport Core Maintenance
>>  avt@ietf.org
>>  https://www.ietf.org/mailman/listinfo/avt
>
>
>
>--
>Colin Perkins
>https://csperkins.org/
>
>
>
>