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

"Paul E. Jones" <> Wed, 27 August 2014 21:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 914EA1A0052; Wed, 27 Aug 2014 14:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.06
X-Spam-Status: No, score=-1.06 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, J_CHICKENPOX_21=0.6, 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 gepPyyz--V8j; Wed, 27 Aug 2014 14:41:37 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD55C1A003B; Wed, 27 Aug 2014 14:41:36 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id s7RLfOBq014606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Aug 2014 17:41:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=dublin; t=1409175685; bh=HPrK2AO2j7hypRTgQ+tlOnJz0GIQ+skB4ThnZmxSiz0=; h=From:To:Subject:Cc:Date:Message-Id:In-Reply-To:Reply-To: Mime-Version:Content-Type:Content-Transfer-Encoding; b=cpWboXhne69DXsR8fyeGJGtjvM5iO8nykL9ugjQGWUtmfsl/S7wtR8nRkOTrlmegJ 6+1wxCp5J/pIU9Gm+HBgjov5Nl0Y6l/Jr9bL4nf8/jDma6Bm7cVxilUAuci5DogwgP yBLHj5QjTxDY2/Ync6w70+le9AF+Bq6pZe0NBNsk=
From: "Paul E. Jones" <>
To: "Colin Perkins" <>
Date: Wed, 27 Aug 2014 21:41:53 +0000
Message-Id: <emf4f049e5-ba65-402f-b973-942799115a84@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 21:41:39 -0000


>>>>  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?
>Each of the SSRCs will report on all the others, unless the 
>rtp-multi-stream-optimisation draft is used, but so what?

Oh, I think I understand what you are saying.  You're saying that each 
media flow (SSRC) would be responsible for sending its own RTCP packets 
and those packets would be marked in the same way as that media flow.  
In that case, I agree with you.

That said, would we really require the sending SSRC to include any data 
for the other SSRCs if they're each sending RTCP packets separately?  
That seems redundant.  Does RFC 3550 require that?  (It's been a 

>>>  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.
>You mean the RTCP for each SSRC should use the DSCP with the lowest 
>drop preference of those used for the media sent by that SSRC?

That's what I'm suggesting. So, a video flow using AF4x would use AF41 
for RTCP.  I suggest that, since I assume we don't want to lose feedback 
information if we can avoid it.