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

"Paul E. Jones" <> Mon, 25 August 2014 21:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5FF8B1A03C0; Mon, 25 Aug 2014 14:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.26
X-Spam-Status: No, score=-0.26 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 0hqoTa5zlb8d; Mon, 25 Aug 2014 14:59:10 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 36EB71A03BD; Mon, 25 Aug 2014 14:59:10 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id s7PLwvZI022051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2014 17:58:57 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=dublin; t=1409003938; bh=c8TQR4nWIS5LOs0EvnO1BzAkEoKoDwQw3B3ppwnIecg=; h=From:To:Subject:Cc:Date:Message-Id:In-Reply-To:Reply-To: Mime-Version:Content-Type:Content-Transfer-Encoding; b=BB6q3QrRqIgdI96wJaGXnFPjn4Ak5Y/6p1eAVse/Baxx8/1g8e3CPkAwmxTw+g4MI UNyD2TsYsoL9lX0MuRstk/NnkoGBoRbGtZYPhMHv6yyv3q7rdI49DE3HMqgBUiA7/+ gN1vprUXce/uAC27tOgCZjP+Vvuo8U7fvypeOQT8=
From: "Paul E. Jones" <>
To: "Ben Campbell" <>
Date: Mon, 25 Aug 2014 21:59:22 +0000
Message-Id: <em0263d12c-c65b-4a0c-b34d-369b21415bc4@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: "" <>, "Black, David" <>, "" <>, Colin Perkins <>, " WG" <>
Subject: Re: [Dart] 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: Mon, 25 Aug 2014 21:59:13 -0000


>Our charter is not to improve QoS or solve congestion issues. It's just 
>to give guidance on DSCP choices for multiplexed media. So I think the 
>question becomes, has RMCAT made decisions (or looks very likely to 
>make decisions) to use RTCP in a way that would be impacted by our DSCP 

I'm not aware of whether such a decision has been made.

>>  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.
>If so, then we should document the potential impact. If _not_, then it 
>seems to me the best we could do is mention that RTCP treatments may or 
>may not have an impact on RTT estimates, and that the implementer 
>should think about it.

If accurate RTT measurements could be made, they could be useful.  The 
problem is that in some environments, we know that RTTs will not be 
accurate.  Sometimes they are, of course.

We could have some text as you suggest, but I would personally prefer we 
not encourage use of RTT values for any particular purpose. :-)

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

David? :-)