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

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

Harald Alvestrand wrote:
> 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.

My position is that differential treatment aligns with different media lines rather than different media types. It seems natural to assign the same treatment to the RTP streams associated with a media line based on the negotiated payload types. Are you suggesting that different RTP streams associated with a media line may be selected for further differentiation? An application may enable/disable individual streams, but on what basis could the network assign different treatment to individual streams associated with a single media line? Or are you suggesting that multiplexing of media lines on a single transport connection be disabled when differential treatment is needed? I would prefer to have a solution where we can assign differential treatment to flows within a transport connection.

> 
> 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.

I'm afraid I don't follow your argument here. Let me just ask a simple question. Should RTCP packets get the same QoS treatment in the network as their corresponding RTP streams, or is it ok for them to be treated with some arbitrary other QoS?

> >   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.

I did not intend to say anything different; I just said it less precisely than you did. For the near future, diffserv markings will not generally survive transport through the internet. Depending on policy they may be remarked in a meaningful way or they may simply be remarked for best effort handling.

The situation is not as bad as it sounds since differential treatment in the access network (be it cable, DSL, or wireless access, but particularly for wireless access), is generally more important than treatment in the backbone. The access network will need to ensure that packets (flowing in either direction) are marked correctly to get the right treatment (or the access network will need to assign the treatment directly based on filtering without remarking).

The only way to intelligently remark packets for correct treatment in the access network (or to just identify them) is to define a simple filter that can be used to separate them from other packets sharing the transport connection (and 5-tuple). The filter has to be based on some characteristic of the IP packet payload since the TOS can't be trusted to have the right value.

Even if we assume your "common current practice" scenario, where the first router performs the diffserv classification, and subsequent routers remark so as to retain the assigned treatment end-to-end, the first router still needs to be told how to identify the packets associated with each assigned treatment.

Richard