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

Colin Perkins <csp@csperkins.org> Thu, 28 August 2014 11:05 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: dart@ietfa.amsl.com
Delivered-To: dart@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9791A0503; Thu, 28 Aug 2014 04:05:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ia_NNxlm2LTg; Thu, 28 Aug 2014 04:05:52 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB631A0515; Thu, 28 Aug 2014 04:05:52 -0700 (PDT)
Received: from [130.209.247.112] (port=58615 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1XMxWS-00056W-C1; Thu, 28 Aug 2014 12:05:47 +0100
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <emf4f049e5-ba65-402f-b973-942799115a84@sydney>
Date: Thu, 28 Aug 2014 12:05:43 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D21A1CB2-11A2-4C8A-929B-CAB9586A7953@csperkins.org>
References: <emf4f049e5-ba65-402f-b973-942799115a84@sydney>
To: "Paul E. Jones" <paulej@packetizer.com>
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/ey-jNqh8yhESkymadGcpo301iSg
Cc: Ben Campbell <ben@nostrum.com>, "Black, David" <david.black@emc.com>, "dart@ietf.org" <dart@ietf.org>, "avt@ietf.org WG" <avt@ietf.org>, "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" <draft-ietf-dart-dscp-rtp.all@tools.ietf.org>
Subject: Re: [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02)
X-BeenThere: dart@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <dart.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dart>, <mailto:dart-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dart/>
List-Post: <mailto:dart@ietf.org>
List-Help: <mailto:dart-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dart>, <mailto:dart-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Aug 2014 11:05:54 -0000

Paul,

On 27 Aug 2014, at 22:41, Paul E. Jones <paulej@packetizer.com> wrote:
>>>>> 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 straight-forward.
>>> 
>>> 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.

Yes.

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

RFC 3550 does require that, and it is redundant (except that it indicates that the SSRCs are co-located); draft-ietf-avtcore-rtp-multi-stream-optimisation-04 offers an extension to avoid it in some cases.

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

Makes sense.

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