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

[Ben Campbell <[e-mail]>]

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?


On Aug 25, 2014, at 2:52 PM, Paul E. Jones <[e-mail]> wrote:

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

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

> There are several options we could consider:
> * Mark all RTCP packets as CS0
> * Mark RTCP packets using a locally-defined "highest priority" marking
> * Mark RTCP packets the same as media flow for the first (active) SDP line (thus, if audio is the first m= line in SDP and that flow is active, all RTCP packets will be marked the same as audio)
> * Specify a value for all RTCP packets irrespective of any value used in RTP flows
> 
> I think the right folks on the thread and on the list are present to help make that choice.  We just need to decide if that is something we want to specify.
> 
> Paul
> 
> ------ Original Message ------
> From: "Ben Campbell" <[e-mail]>
> To: "Colin Perkins" <[e-mail]>
> Cc: "Black, David" <[e-mail]>; "[e-mail]" <[e-mail]>; "[e-mail] WG" <[e-mail]>; "Paul E. Jones ([e-mail])" <[e-mail]>; "[e-mail]" <[e-mail]>
> Sent: 8/25/2014 2:12:01 PM
> Subject: Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02
> 
>> 
>> On Aug 25, 2014, at 6:19 AM, Colin Perkins <[e-mail]> wrote:
>> 
>>>> (2) PHBs and DSCPs for RTCP.
>>>> 
>>>> I'm not sure what to say about this, as it looks like I need to set
>>>> off a discussion (debate?) between you and my co-author, Paul Jones.
>>>> 
>>>> Colin (from WGLC comments):
>>>> 
>>>>> Rather, within a single RTP session there are RTCP packets sent
>>>>> that give information about the RTP streams that are being sent, and that
>>>>> report on the reception quality of RTP streams being received. Using a single
>>>>> PHB and DSCP for all RTCP packets within an RTP session might make sense, but
>>>>> it's important to note that one role of RTCP is to provide an estimate of the
>>>>> round-trip time seen by the media, so the PHB/DSCP will have to be chosen with
>>>>> care to avoid biasing that estimate too much.
>>>> 
>>>> Paul (from shortly after the Toronto meeting:
>>>> 
>>>>> During the meeting, there was discussion of marking RTCP packets. Some
>>>>> notes I received on this topic suggested that it was proposed that RTCP
>>>>> should be marked the same as for RTP. The argument was that this is used
>>>>> for RTT calculations. If that is what was said, I'd like to state my
>>>>> disagreement. :-)
>>>>> 
>>>>> The forward and reverse paths are not necessarily the same and there is
>>>>> nothing one should assume about the reverse path to provide guidance about
>>>>> the forward path (or vice versa). As perhaps a gross example, I have the
>>>>> ability to download far faster on my home Internet connection than I can
>>>>> upload. Other important traffic characteristics differ in each direction.
>>>>> 
>>>>> Further, an RTCP packet might provide information related to several different
>>>>> RTP packets. I certainly would not want to see one RTCP packet per RTP packet.
>>>> 
>>>> I'll watch where that discussion goes before proposing text.
>>> 
>>> One of the uses of RTCP is certainly to estimate the round-trip time, as described in Section 6.4.1 (page 41) of RFC 3550. The DSCP marking used for RTCP does need to take this use into account. Ideally, this would mean RTCP packets were marked the same as the corresponding RTP packets, as I suggested in the meeting. However, Paul is correct that this only works when all RTP packets have the same marking.
>>> 
>>> Accordingly, I’m not sure what the right marking is for RTCP. One approach might be to say that an SSRC that sends RTP packets with different marking should use marking with the highest(lowest?) precedence of those is uses for RTCP, so the RTT estimate calculated from RTCP is representative of some RTP packets. I’m not sure that using a single DSCP for all RTCP packets would achieve that.
>> 
>> Can this working group reasonably answer this question? If not, we could list it as something implementors need to think about, and note that we do not have generic guidance.
>> 
>