Re: [Dart] DART dscp-rtp draft: Proposed RTCP text

[Ben Campbell <[e-mail]>]

That works for me, thanks!

On Aug 28, 2014, at 3:36 PM, Black, David <[e-mail]> wrote:

> Minor edit to proposed text below:
> 
> OLD
>    If an RTCP sender doesn't send any RTP
>    packets, it should mark its RTCP packets with the DSCP that it would
>    use if it did send RTP packets.
> NEW
>   If an RTCP sender doesn't send any RTP
>   packets, it should mark its RTCP packets with the DSCP that it would
>   use if it did send RTP packets with media similar to the RTP traffic
>   that it receives.
> 
> Thanks,
> --David
> 
> 
>> -----Original Message-----
>> From: Black, David
>> Sent: Thursday, August 28, 2014 3:45 PM
>> To: [e-mail]; [e-mail] WG ([e-mail])
>> Cc: Black, David; Colin Perkins ([e-mail]); [e-mail]
>> Subject: DART dscp-rtp draft: Proposed RTCP text
>> 
>> Here's the proposed new section 5.4, with the RTCP multi-stream reporting
>> optimizations text moved into that new section from its current location
>> at the end of 5.3, plus the rewritten Section 6 guideline bullet:
>> 
>> 5.4.  DiffServ and RTCP
>> 
>>   The RTP Control Protocol (RTCP) [RFC3550] is used with RTP to monitor
>>   quality of service and convey information about RTP session
>>   participants.  A sender of RTCP packets that also sends RTP packets
>>   (i.e., originates an RTP stream) should use the same DSCP marking for
>>   both types of packets.  If an RTCP sender doesn't send any RTP
>>   packets, it should mark its RTCP packets with the DSCP that it would
>>   use if it did send RTP packets.  If the RTCP sender uses or would use
>>   multiple DSCPs that differ only in drop precedence for RTP, then it
>>   should use the DSCP with the least likelihood of drop for RTCP to
>>   increase the likelihood of RTCP packet delivery.
>> 
>>   This guidance may result in different DSCP markings for RTP streams
>>   and RTCP receiver reports about those RTP streams.  The resulting
>>   variation in network QoS treatment by traffic direction could result
>>   in unrepresentative round trip time (RTT) estimates that don't
>>   correspond to consistent network QoS treatment in both directions.
>>   RTCP receiver reports may be relatively infrequent (e.g., may be sent
>>   only once per video frame rendered) and hence the resulting RTT
>>   estimates are of limited utility for congestion control (although
>>   they have other important uses, see [RFC3550]).  For this reason, it
>>   is not important that RTCP receiver reports receive the same network
>>   QoS treatment as the RTP stream or streams being reported on.
>> 
>>   RTCP multi-stream reporting optimizations for an RTP session
>>   [I-D.ietf-avtcore-rtp-multi-stream-optimisation] assume that the RTP
>>   streams involved experience the same network behavior, including
>>   packet loss.  This mechanism is highly inappropriate when the RTP
>>   streams involved use different DSCPs, even if the corresponding PHBs
>>   differ solely in drop precedence.
>> 
>> 6.  Guidelines
>> 
>> [... snip ...]
>> 
>>   o  Should use a single DSCP for RTCP packets, which should be a DSCP
>>      used for RTP packets that are or would be sent by the same sender,
>>      see Section 5.4.
>> 
>> Thanks,
>> --David
>> ----------------------------------------------------
>> David L. Black, Distinguished Engineer
>> EMC Corporation, 176 South St., Hopkinton, MA  01748
>> [phone]             FAX: [phone]
>> [e-mail]        Mobile: [phone]
>> ----------------------------------------------------
>> 
>