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

"Paul E. Jones" <paulej@packetizer.com> Tue, 26 August 2014 15:52 UTC

Return-Path: <paulej@packetizer.com>
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 DA2E31A8716; Tue, 26 Aug 2014 08:52:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.66
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u0nJwFyaKLs; Tue, 26 Aug 2014 08:52:37 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54BD1A870A; Tue, 26 Aug 2014 08:52:37 -0700 (PDT)
Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s7QFqVYj027374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Aug 2014 11:52:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1409068351; bh=y97VtMDdq65PpFzPv+9GBxG2BQp9KptsVXLi5erMno4=; h=From:To:Subject:Cc:Date:Message-Id:In-Reply-To:Reply-To: Mime-Version:Content-Type:Content-Transfer-Encoding; b=NPDwZ45mbJTMui7O5mbr35a/fjvGjfSeJitdSxim8ok24SgN8vPuAzgudoCtnDEFI FI5fShbozM5Alq0d14G+MWvb5KdfYKb+VE0XuqzA+XXhqGyZ++tBEtn+pT/ICyQBR6 4hnCJzpZCyoHcjUiYqS1p0DcbE2B8lrtPqN9jYBY=
From: "Paul E. Jones" <paulej@packetizer.com>
To: "Ben Campbell" <ben@nostrum.com>, "Colin Perkins" <csp@csperkins.org>
Date: Tue, 26 Aug 2014 15:52:57 +0000
Message-Id: <embac59e09-6dad-42df-94b2-7daa46d31d5d@sydney>
In-Reply-To: <F6194F9F-701F-459B-8B4D-8FA10F0522FF@nostrum.com>
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/3cf5hSxC5F9orn49y9YY54sosLI
Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" <draft-ietf-dart-dscp-rtp.all@tools.ietf.org>, "Black, David" <david.black@emc.com>, "dart@ietf.org" <dart@ietf.org>, "avt@ietf.org WG" <avt@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
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
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: Tue, 26 Aug 2014 15:52:40 -0000

  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 treatment.
>>>
>>>  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 
>>>challenging.
>>
>>  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?

Since DSCP values cannot be assumed to any particular PHB behavior in 
the network, that makes answering that question challenging.

My personal preference in a voice/video conference would be to use the 
same marking as is used for those flows -- and I would use the same 
value for both voice and video.  However, if the app sharing video is 
considered more important by some applications, perhaps that's the value 
that should be used in those applications.

I can accept the suggestion, leaving the specific selection as an 
implementation matter.  I do wish there was something more concrete so 
that two devices would always follow the same approach to selecting a 
value, but I doubt we can get agreement very quickly.

Paul