Re: [AVTCORE] [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02

"Paul E. Jones" <paulej@packetizer.com> Mon, 25 August 2014 19:52 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7860D1A0308; Mon, 25 Aug 2014 12:52:00 -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 Uld6W4VHhW24; Mon, 25 Aug 2014 12:51:59 -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 36A941A02F5; Mon, 25 Aug 2014 12:51:59 -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 s7PJphKT013463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2014 15:51:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1408996306; bh=fBmirMF6f4yVVW3DXovZI5IVY1m6cK4uJ+BvWgokgVI=; h=From:To:Subject:Cc:Date:Message-Id:In-Reply-To:Reply-To: Mime-Version:Content-Type:Content-Transfer-Encoding; b=qkmkZ2iTA4dP6+WN7Y1I6fHPPrbAZWOAWHggpkokfftzHbCAsQSHjZg2me0pBW2k0 FcesIaMgZCPkHn5R1BJroAGV+yWnNdfe9bKej/LDQj0sSGnZhYrGbMn5Azj3IOnDW6 hlu2e0kl4rClMbASSbrJ2zbTvfC29jyk+O94Y08g=
From: "Paul E. Jones" <paulej@packetizer.com>
To: Ben Campbell <ben@nostrum.com>, Colin Perkins <csp@csperkins.org>
Date: Mon, 25 Aug 2014 19:52:08 +0000
Message-Id: <em58ad1cb1-ee21-4cf8-909c-6ff0b2852e60@sydney>
In-Reply-To: <79D2AC8C-4821-4CDA-A39A-7D460DD18A41@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/avt/kfz6yay1RQpcITsx8HqsKbrZ6bI
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: [AVTCORE] [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Aug 2014 19:52:00 -0000

Ben, Colin,

On (2) below, it might be a challenge to get agreement quickly, but it 
might be nice if we could.  As this work relates to RMCAT, determining 
one-way delay or changes thereto will likely prove important.  In 
general, I would expect perceived quality to be important and conveying 
quality metrics and/or providing feedback to the sender so that 
perceived quality improves (in whatever form) will be important.  I'm 
suspicious of use of any RTT calculation for any mechanism that might be 
used to improve QoE.

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.

There are several options we could consider:
* Mark all RTCP packets as CS0
* Mark RTCP packets using a locally-defined "highest priority" marking
* Mark RTCP packets the same as media flow for the first (active) SDP 
line (thus, if audio is the first m= line in SDP and that flow is 
active, all RTCP packets will be marked the same as audio)
* Specify a value for all RTCP packets irrespective of any value used in 
RTP flows

I think the right folks on the thread and on the list are present to 
help make that choice.  We just need to decide if that is something we 
want to specify.

Paul

------ Original Message ------
From: "Ben Campbell" <ben@nostrum.com>
To: "Colin Perkins" <csp@csperkins.org>
Cc: "Black, David" <david.black@emc.com>; "dart@ietf.org" 
<dart@ietf.org>; "avt@ietf.org WG" <avt@ietf.org>; "Paul E. Jones 
(paulej@packetizer.com)" <paulej@packetizer.com>; 
"draft-ietf-dart-dscp-rtp.all@tools.ietf.org" 
<draft-ietf-dart-dscp-rtp.all@tools.ietf.org>
Sent: 8/25/2014 2:12:01 PM
Subject: Re: [Dart] Colin Perkins comments - WGLC: 
draft-ietf-dart-dscp-rtp-02

>
>On Aug 25, 2014, at 6:19 AM, Colin Perkins <csp@csperkins.org> wrote:
>
>>>  (2) PHBs and DSCPs for RTCP.
>>>
>>>  I'm not sure what to say about this, as it looks like I need to set
>>>  off a discussion (debate?) between you and my co-author, Paul Jones.
>>>
>>>  Colin (from WGLC comments):
>>>
>>>>  Rather, within a single RTP session there are RTCP packets sent
>>>>  that give information about the RTP streams that are being sent, 
>>>>and that
>>>>  report on the reception quality of RTP streams being received. 
>>>>Using a single
>>>>  PHB and DSCP for all RTCP packets within an RTP session might make 
>>>>sense, but
>>>>  it's important to note that one role of RTCP is to provide an 
>>>>estimate of the
>>>>  round-trip time seen by the media, so the PHB/DSCP will have to be 
>>>>chosen with
>>>>  care to avoid biasing that estimate too much.
>>>
>>>  Paul (from shortly after the Toronto meeting:
>>>
>>>>  During the meeting, there was discussion of marking RTCP packets. 
>>>>Some
>>>>  notes I received on this topic suggested that it was proposed that 
>>>>RTCP
>>>>  should be marked the same as for RTP. The argument was that this is 
>>>>used
>>>>  for RTT calculations. If that is what was said, I'd like to state 
>>>>my
>>>>  disagreement. :-)
>>>>
>>>>  The forward and reverse paths are not necessarily the same and 
>>>>there is
>>>>  nothing one should assume about the reverse path to provide 
>>>>guidance about
>>>>  the forward path (or vice versa). As perhaps a gross example, I 
>>>>have the
>>>>  ability to download far faster on my home Internet connection than 
>>>>I can
>>>>  upload. Other important traffic characteristics differ in each 
>>>>direction.
>>>>
>>>>  Further, an RTCP packet might provide information related to 
>>>>several different
>>>>  RTP packets. I certainly would not want to see one RTCP packet per 
>>>>RTP packet.
>>>
>>>  I'll watch where that discussion goes before proposing text.
>>
>>  One of the uses of RTCP is certainly to estimate the round-trip time, 
>>as described in Section 6.4.1 (page 41) of RFC 3550. The DSCP marking 
>>used for RTCP does need to take this use into account. Ideally, this 
>>would mean RTCP packets were marked the same as the corresponding RTP 
>>packets, as I suggested in the meeting. However, Paul is correct that 
>>this only works when all RTP packets have the same marking.
>>
>>  Accordingly, I’m not sure what the right marking is for RTCP. One 
>>approach might be to say that an SSRC that sends RTP packets with 
>>different marking should use marking with the highest(lowest?) 
>>precedence of those is uses for RTCP, so the RTT estimate calculated 
>>from RTCP is representative of some RTP packets. I’m not sure that 
>>using a single DSCP for all RTCP packets would achieve that.
>
>Can this working group reasonably answer this question? If not, we 
>could list it as something implementors need to think about, and note 
>that we do not have generic guidance.
>