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

["Ejzak, Richard P (Richard)" <[e-mail]>]

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.

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.) 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! That is the purpose of my proposal.

So I agree with you that DSCP is required, but it is not sufficient.

Richard