Re: [AVTCORE] Comments on draft-lennox-rtcweb-rtp-media-type-mux-00

[Harald Alvestrand <[e-mail]>]

This response has two parts:

- One discussion about the scenarios Magnus is positing in his note 
(first half)
- One discussion about evaluating the approaches proposed (second half)

People who want to comment on just one of them may want to fork the 
discussion.

On 11/10/2011 11:56 AM, Magnus Westerlund wrote:
> Harald,
>
> Inline
>
> On 2011-11-07 11:37, Harald Alvestrand wrote:
>
>>
>> why would such a gateway want to offer the BUNDLE extension in its SDP
>> negotiation?
>> (I'm assuming support for draft-holmberg-mmusic-sdp-bundle-negotiation
>> as the way to negotiate multiple media types in a single session here.)
>>
>> An assumption in the deployment of extensions is that one is able to
>> negotiate their non-use where some participant does not support the
>> feature. I find your arguments compelling if (and only if) I accept the
>> premises that:
>>
>> 1) Gateways between RTCWEB deployments and non-RTCWEB deployments will
>> want to relay RTP sessions rather than terminate them (something which I
>> do not believe, but that's another debate)
>>
>> 2) Gateways between RTCWEB deployments and non-RTCWEB deployments can't
>> negotiatiate non-support for the BUNDLE extension with the RTCWEB 
>> deployment
>>
>> Given that I believe 2) is false, I don't agree with your conclusion.
>
> I will follow up one below. But regarding 2) that is not the reason. 
> Even if one can negotiate that the one bundles multiple media types in 
> a single RTP session, there is going to be gateways/conference nodes 
> that are going to turn on this feature anyway.
>
> The reason for that behavior is that they will think this issue is a 
> non-issue. Short term thinking rather than long term implications. 
> They will like to avoid the small but existing risk of establishing 
> more NAT pinholes. Also, to be certain that this not occurs, you 
> either have zero possibility to use the non bundled session to a 
> central node, or you configure your central node to never use bundling 
> to avoid this. I think more than one developer will look at this and 
> ignore the issue. Because if you don't think it through it do look 
> simple on the surface. You simply translate the SSRCs if you end up in 
> a collision.

I still don't get this argument. Can you describe in more detail a 
situation where you think trouble will occur, which does not involve a 
transport translator?

>
> When it comes to using a common session. I agree that for media mixing 
> central nodes (RTP mixer), the RTP session is anyway almost individual 
> between each end-point and end-point. The only information you forward 
> between the legs are the CSRC CNAMEs to ensure the possibility to bind 
> the information to the right sources.
Not even that, for the case of central nodes that don't do source mixing.
>
> But, when looking at the cheapest central node solution, the transport 
> relay (transport translator) the common RTP session becomes 
> interesting as it limits the central nodes processing to bascially a 
> packet forwarder. This gives you on the order of 1000 times higher 
> capacity in the number of streams the central node can handle compared 
> to one that performs media operations given the same general purpose 
> hardware. Thus having a common RTP session and not having to change 
> anything within the packets, not even having to perform decryption and 
> encryption cycles in the relay is a big bonus.
Can you give some reference for the claim of "1000 times higher capacity"?
In particular, there are 3 cases:

- Pure packet forwarder ("transport translator")
- RTP session terminator, non-media-mixing
- RTP session terminator, media-mixing

I think it's reasonable to assume that the RTP session terminator will 
always do decrypt/encrypt, since not doing so requires using key 
handling schemes that are no more secure than the transport translator case.

Still, I think we may be talking about CPU time per packet well below a 
millisecond for the middle case.
>
>
>> The 3 viable approaches I see for gateways are:
>>
>> - The gateway refuses to negotiate BUNDLE with anyone
>> - The gateway terminates RTP sessions
>> - The gateway refuses to establish non-BUNDLE sessions at all
>>
>> In neither of these 3 scenarios do I see the issue you posit.
>>
>>
> Agreed, these do avoid the issue of having to translate. From my 
> perspective, they should be documented and considered if they will be 
> followed.
>
> Raising this issue had two goals.
>
> 1) Ensure that the issue and the implications on what one need to do 
> is clearly documented in the draft.
>
> 2) Raise discussion if those are acceptable
>
> So I hope the authors at least will agree to perform 1). Regarding the 
> outcome of 2) that is very much open.
>
> When it comes to 2) I think we need to take into account the 
> alternative. Is any of the evaluated alternatives in 
> https://datatracker.ietf.org/doc/draft-westerlund-avtcore-transport-multiplexing/ 
> actually less problematic?

I have serious problems with evaluating 
draft-westerlund-avtcore-transport-multiplexing, because I still 
disagree with its problem description.

That problem description is described in section 3.1 as "allow 
separation of streams that have different purposes, for example 
different media types".

I agree fully with the part before the comma; I disagree fully with the 
part after the comma. The idea that the *infrastructure needs to 
dictate* that different media types have different purposes is very far 
from self-evident, and I believe it to be false.

I believe that the user of RTP functionality is the only one who's in a 
position to decide when "different purposes" are appropriate.

This means that I think the solutions described in section 4.2 
(multiplexing shim) and section 4.3 (single session) are *both* 
appropriate to pursue, because I believe that there are situations where 
differing RTP sessions that need differential treatment in some way is 
important. Thus, the dichtonomy is false.

> And I think it is important we do consider what happens when WebRTC is 
> successful. I fear the desire to interoperate will kill of the RTP 
> session completely as a useful tool. Instead all RTP users will end up 
> with a single RTP session and we have to re-invent mechanisms for 
> separation when the short-coming of not having an layer of 
> multiplexing for media stream purposes.
>
> I know that the window for this is closing, but I think we should at 
> least have some reconsideration if the direction proposed in Quebec 
> really was the most appropriate.

In summary: I believe that pursuing multiplexing of RTP sessions across 
a single transport connection is a worthwhile pursuit, and the 
multiplexing shim seems a reasonable approach to make this work.

I believe that the RTP users are capable of evaluting for themselves 
when using multiple RTP sessions is appropriate, and that the current 
shortcoming of SDP that forces them to use multiple RTP sessions when 
the media they are sending is classified under different top level MIME 
types should be addressed - and that 
draft-homberg-mmusic-sdp-bundle-negotiation addresses this in a fashion 
that does not do damage to the rest of the SDP/RTP ecosystem.

                         Harald