Re: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

[Harald Alvestrand <[e-mail]>]

On 06/06/2012 01:34 AM, Ejzak, Richard P (Richard) wrote:
> On 06/05/2012 01:52 AM, Harald Alvestrand wrote:
>> Richard,
>> having scanned your draft:
>>
>> - I still fundamentally think that the partition of media types into
>> separate RTP sessions was a design mistake that we should seek to
>> rectify, not promulgate, and additional complexity like what you propose
>> for perpetuating the use of "separated" sessions is not helpful. See
>> draft-alvestrand-rtp-sess-neutral for details.
> There are two reasons why "separating" sessions can be helpful. Firstly, in more complex RTP session topologies with multiple systems, other systems will already consider each media line to identify a separate RTP session, so BUNDLE (in its current default mode) essentially merges these sessions together since they now have a common SSRC space. This has the potential to cause additional SSRC conflicts. I am not proposing to separate the sessions but instead suggesting a way to keep them separate as originally intended. I agree that there are many use cases in which this merging is not a problem.
>
> The more important reason for separating sessions is so that it is possible for the network to easily identify the IP packets associated with different media types for different QoS treatment. Blending of different media types into a single RTP session means that the corresponding compound RTCP packets will mix RTCP information for different media types into single IP packets. It is important to assign the same QoS to the RTCP packets as to the corresponding RTP streams and this will not be possible with these compound RTCP packets.
As I stated in draft-alvestrand-rtp-sess-neutral, I heartily agree that 
RTP session separation is a poweful tool for letting the network give 
differential treatment to packets. What I don't agree with is the idea 
that this need for differential treatment aligns with media types.

Sometimes we need to treat two different media types the same. Sometimes 
we need to treat two flows of the same media type differently. Forcing 
them to be always separated on media type is a bad idea.

I don't believe the compound-ness of RTCP packets is relevant to this 
argument; within a single RTP session (without muxing), all the RTCP 
packets will be treated the same, which is how it should be if one uses 
RTP sessions to indicate the need for differential treatment from the 
network.
>
> You made the following comment on the related rtcweb thread when I mentioned the need to support QoS:
>> Yes, some applications need that.
>>   In that case, the simplest way (allowing per-flow prioritization) is to
>> use different RTP sessions on different transport addresses.
>> The next simplest way (using DiffServ) is to apply different DSCP markings
>> on a per-packet basis. Both techniques are well established.
> If we use different transport connections then we lose the clear advantages of multiplexing. If we use DiffServ without "separating" the sessions in some way, we still have problems with compound RTCP packets.
>
> DSCP has two other problems. There is no current mechanism defined for the application to direct the browser and/or OS to correctly mark the transmitted packets. (We could fix this.)
That's actually a WEBRTC problem, not an AVTCORE problem.
>   And since there is no guarantee regarding the marking of packets from the remote endpoint and through intermediate networks towards the device, there still needs to be a way to identify each flow to correctly reassign the markings!
I believe that's not how diffserv is supposed to work; the diffserv 
marking from the endpoint is supposed to give enough information for 
intermediate hops to remark according to policy.
I think the most common current practice is that the source host is 
diffserv-ignorant, and the first router takes on the task of diffserv 
classification, based on flows - but if we want end-to-end diffserv, 
that has to change.
>   That is the purpose of my proposal.
>
> So I agree with you that DSCP is required, but it is not sufficient.
>
> Richard
>