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

"Paul E. Jones" <> Wed, 27 August 2014 05:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A388B1A03ED; Tue, 26 Aug 2014 22:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.66
X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HG0ZJLQpNEEv; Tue, 26 Aug 2014 22:17:20 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7CD651A03E9; Tue, 26 Aug 2014 22:17:20 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id s7R5HAXQ015918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Aug 2014 01:17:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=dublin; t=1409116633; bh=3Qbw78wGdrCvBCpvG75oy5V1+TpbUWYlTxffbhhdvJ0=; h=From:To:Subject:Cc:Date:Message-Id:In-Reply-To:Reply-To: Mime-Version:Content-Type:Content-Transfer-Encoding; b=D1K0siknZIS+89+IAfhzwibUHuAdSJvs4g7eN4jeUaGuQyTHsTyaxkKVE8vVFGsjY 3sYM26zcFpqc6qu2c0qZx8sSb0f5/QsNMkzWxjuFiVXn/7lfeNpOT47fF6S+IeLk8p 9rcI2MJ1el3oaY0j7sHj80/uZx+oMRWExOBzJIGU=
From: "Paul E. Jones" <>
To: "Colin Perkins" <>
Date: Wed, 27 Aug 2014 05:17:38 +0000
Message-Id: <em514a8c54-53b8-4b3f-9c62-e4bf8427f437@sydney>
In-Reply-To: <>
User-Agent: eM_Client/6.0.20617.0
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Ben Campbell <>, "Black, David" <>, "" <>, " WG" <>, "" <>
Subject: Re: [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02)
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <>
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Aug 2014 05:17:21 -0000


>On 26 Aug 2014, at 16:52, Paul E. Jones <> 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 
>>>>>  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 
>>>>  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 

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.