Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02

[Colin Perkins <[e-mail]>]

On 25 Aug 2014, at 22:59, Paul E. Jones <[e-mail]> wrote:
> Ben,
> 
>> Our charter is not to improve QoS or solve congestion issues. It's just to give guidance on DSCP choices for multiplexed media. So I think the question becomes, has RMCAT made decisions (or looks very likely to make decisions) to use RTCP in a way that would be impacted by our DSCP recommendations?
> 
> I’m not aware of whether such a decision has been made.

I don’t believe RMCAT has considered this issue.

>>> Ben, Colin,
>>> 
>>> On (2) below, it might be a challenge to get agreement quickly, but it might be nice if we could. As this work relates to RMCAT, determining one-way delay or changes thereto will likely prove important. In general, I would expect perceived quality to be important and conveying quality metrics and/or providing feedback to the sender so that perceived quality improves (in whatever form) will be important. I'm suspicious of use of any RTT calculation for any mechanism that might be used to improve QoE.
>>> 
>> 
>> If so, then we should document the potential impact. If _not_, then it seems to me the best we could do is mention that RTCP treatments may or may not have an impact on RTT estimates, and that the implementer should think about it.
> 
> If accurate RTT measurements could be made, they could be useful.  The problem is that in some environments, we know that RTTs will not be accurate.  Sometimes they are, of course.
> 
> We could have some text as you suggest, but I would personally prefer we not encourage use of RTT values for any particular purpose. :-)
> 
> 
>>> 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.

-- 
Colin Perkins
http://csperkins.org/