Re: [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02)

["Paul E. Jones" <[e-mail]>]

Colin,

>On 26 Aug 2014, at 16:52, Paul E. Jones <[e-mail]> wrote:
>>  Ben,
>>>>>>>  Getting feedback to the sender is important, though. In an ideal 
>>>>>>>world, I would argue that RTCP packets should be marked with 
>>>>>>>whatever DSCP value will deliver RTCP packets in the most 
>>>>>>>expedient way. Since we don't have an ideal world, I don't know 
>>>>>>>which DSCP value that would be.
>>>>>>
>>>>>>  Would the starting positions of "getting feedback is important, 
>>>>>>even of not for RTT estimates" and "we need RTCP for RTT 
>>>>>>estimates" likely land on the same guidance for DSCP values?
>>>>>>
>>>>>>  The argument to send RTCP packets in the most expedient way 
>>>>>>sounds reasonable. I don't know if we need to recommend a 
>>>>>>particular DSCP, since we already have quite a bit of text on how 
>>>>>>DSCPs might (or might not) map into some predictable PHB 
>>>>>>treatment.
>>>>>
>>>>>  Good question and valid point. Nowhere in the document do we 
>>>>>recommend the use of a particular DSCP value for any particular 
>>>>>thing, and we should not recommend a particular value for RTCP in 
>>>>>this document. I'm just not sure what statements should be made.
>>>>>
>>>>>  I suspect we can all agree that RTCP information is important. 
>>>>>It's just the DSCP-related guidance that goes with that that is 
>>>>>challenging.
>>>>
>>>>  I don’t agree that RTCP information should be sent as higher 
>>>>priority than the media. Ideally, it should be sent with the same 
>>>>priority as the media, so it can be used to sample the RTT. This RTT 
>>>>sample is independent of RMCAT. It’s in base RTP specification, and 
>>>>so is something we need to support to the extent possible.
>>>>
>>>>  Since not all the media sent by a single SSRC has the same marking, 
>>>>my suggestion would be that each SSRC mark the RTCP packets it sends 
>>>>with one of the same code points as it uses to mark the media. Since 
>>>>RTCP is somewhat important, it would make sense for each SSRC to 
>>>>mark the RTCP packets it sends using the highest priority code point 
>>>>it uses to mark the RTP media packets it sends.
>>>
>>>  That makes sense to me. Paul, and others, do you agree with that 
>>>last paragraph?
>>
>>  I agree that the value should be one of the values used for media, 
>>but the challenge is specifying which DSCP value to use. If audio is 
>>sent using EF, video as AF41, app sharing video as AF31, etc., which 
>>of these does the endpoint choose to use for RTCP?
>
>Such an endpoint will have three SSRC values, and will mark the RTCP 
>packets sent by each SSRC in the same way as the media packets sent by 
>that SSRC. That is, the RTCP relating to the audio will be marked EF, 
>the RTCP relating to the video will be marked AF41, and the RTCP 
>relating to the application sharing video will be marked AF31. The RTCP 
>packets for each stream are sent separately, so this case seems 
>straight-forward.

I'm a little confused here.  These are separate SSRCs, but all part of a 
single RTP session.  So, wouldn't the three SSRCs be reported in 
different report blocks in the sender report?


>The more difficult case is when an SSRC is sending video using 
>different markings for RTP packets carrying the I- and P-frames. Should 
>that SSRC then mark its RTCP packets like the RTP packets carrying 
>I-frames, like the RTP packets carrying P-frames, or what?

For this, I would argue it should be whatever DSCP that has the lower 
drop precedence (in the case of assured forwarding).  Otherwise, it 
should be the same as the media, I'd think.

Paul