Re: [Dart] draft-dart-dscp-rtp - way forward

Harald Alvestrand <harald@alvestrand.no> Mon, 01 September 2014 11:16 UTC

Return-Path: <harald@alvestrand.no>
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 50DF41A038E for <dart@ietfa.amsl.com>; Mon, 1 Sep 2014 04:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level:
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] autolearn=ham
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 Wxr4PiresVvp for <dart@ietfa.amsl.com>; Mon, 1 Sep 2014 04:16:53 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE4D1A038F for <dart@ietf.org>; Mon, 1 Sep 2014 04:16:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 1EB437C3F9C; Mon, 1 Sep 2014 13:16:47 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gm-hhB8yQUEW; Mon, 1 Sep 2014 13:16:44 +0200 (CEST)
Received: from android-b42137fce5d2e3ef.homenet.telecomitalia.it (host26-139-static.241-95-b.business.telecomitalia.it [95.241.139.26]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0BC5B7C3E10; Mon, 1 Sep 2014 13:16:43 +0200 (CEST)
User-Agent: K-9 Mail for Android
In-Reply-To: <90176521-2804-4F23-908E-29827FADE1A6@csperkins.org>
References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66841@MX15A.corp.emc.com> <EF7D019B-08CF-4C0B-BF89-0F37A0AD3FFB@nostrum.com> <54005A89.1030606@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6691C@MX15A.corp.emc.com> <5400A1AB.6000600@alvestrand.no> <6521A08A-30A9-4805-9B84-41EC4376BDF6@csperkins.org> <5400D48A.30306@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6699A@MX15A.corp.emc.com> <66D9B374-9647-4399-8467-71258705B525@nostrum.com> <5D845428-3E6D-43AC-978E-4754C627FD69@csperkins.org> <CDE97A4C-C467-40B6-8476-9432EC2B6A27@nostrum.com> <90176521-2804-4F23-908E-29827FADE1A6@csperkins.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----8B8INSR2OAD19YE3272JSYWPYO2VKW"
Content-Transfer-Encoding: 8bit
From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 01 Sep 2014 13:16:39 +0200
To: Colin Perkins <csp@csperkins.org>,Ben Campbell <ben@nostrum.com>
Message-ID: <48683577-c891-4904-aaf9-7a17546d4231@email.android.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/FsmlSnHFDQ74D7Jg6Vj9vMEQhao
Cc: "Black, David" <david.black@emc.com>, "dart@ietf.org" <dart@ietf.org>
Subject: Re: [Dart] draft-dart-dscp-rtp - way forward
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: Mon, 01 Sep 2014 11:16:57 -0000

This illustrates well the thought that media RTT is not a good concept - each media stream goes only one way....

On 1. september 2014 13:10:41 CEST, Colin Perkins <csp@csperkins.org>; wrote:
>Ben,
>
>The guidance looks fine to me, but the explanatory text in the last
>paragraph of Section 5.4 is perhaps not quite right. The text:
>
>   This guidance may result in different DSCP markings for RTP streams
>   and RTCP receiver reports about those RTP streams.  The resulting
>   variation in network QoS treatment by traffic direction could result
>   in unrepresentative round trip time (RTT) estimates that don't
>   correspond to consistent network QoS treatment in both directions.
>  RTCP receiver reports may be relatively infrequent (e.g., may be sent
>   only once per video frame rendered) and hence the resulting RTT
>   estimates are of limited utility for congestion control (although
>   they have other important uses, see [RFC3550]).  For this reason, it
>   is not important that RTCP receiver reports receive the same network
>   QoS treatment as the RTP stream or streams being reported on.
>
>suggests that the RTT estimate derived from RTCP will be
>unrepresentative, since it may not have consistent network QoS in each
>direction. However, since the RTP media packets can use different QoS
>in each direction, the RTCP also needs to do so, to be representative!
>If the media used different QoS markings for different directions and
>the RTCP used the same marking, the RTT estimate wouldn’t match that of
>the media. 
>
>I suggest the paragraph be changed to:
>
>   This guidance may result in different DSCP markings for RTP streams
>   and the RTCP packets reporting on those RTP streams.  The resulting
>   variation in network QoS treatment by traffic direction is necessary
> to get representative round trip time (RTT) estimates that correspond 
>to the media path RTT. RTCP receiver reports may be relatively
>infrequent 
>and hence the resulting RTT estimates are of limited utility for
>congestion 
>control (although they have other important uses, see [RFC3550]).  For
>this 
>reason, it is important that RTCP receiver reports sent by an SSRC
>receive 
>the same network QoS treatment as the RTP stream being sent by that
>SSRC.
>
>Colin
>
>
>
>
>On 31 Aug 2014, at 01:26, Ben Campbell <ben@nostrum.com>; wrote:
>> Colin and Harald,
>> 
>> I see David has submitted version 06. Can you verify that you are
>okay with the language in this version? 
>> 
>> Thanks!
>> 
>> Ben.
>> 
>> On Aug 29, 2014, at 4:55 PM, Colin Perkins <csp@csperkins.org>; wrote:
>> 
>>> Without having seen the submitted version, this sounds okay.
>>> 
>>> -- 
>>> Colin Perkins
>>> http://csperkins.org/
>>> 
>>> 
>>> 
>>>> On 29 Aug 2014, at 21:16, Ben Campbell <ben@nostrum.com>; wrote:
>>>> 
>>>> Thanks, David!
>>>> 
>>>> Am I counting correctly that this would close the last substantive
>open issue? If so, and if Harald and Colin confirm they are okay with
>the change, we should be able to request publication for the upcoming
>version, correct?
>>>> 
>>>> (I see that Harald expressed support as I am typing this...)
>>>> 
>>>> Thanks!
>>>> 
>>>> Ben.
>>>> 
>>>>> On Aug 29, 2014, at 3:09 PM, Black, David <david.black@emc.com>;
>wrote:
>>>>> 
>>>>> Ok, I see a range of views from skepticism to outright opposition
>...
>>>>> 
>>>>> I'll delete the paragraph and reference to the multi-stream
>optimization
>>>>> draft and submit the resulting -06 version w/a change note that
>any interaction
>>>>> of DiffServ and RTCP multi-stream optimization will be dealt with
>in the draft
>>>>> about the latter.
>>>>> 
>>>>> That submission won't happen tonight, as the network in the SAS
>Lounge in
>>>>> EWR isn't even close to what we're used to at IETF meetings :-).
>>>>> 
>>>>> Thanks,
>>>>> --David
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
>>>>>> Sent: Friday, August 29, 2014 3:29 PM
>>>>>> To: Colin Perkins
>>>>>> Cc: Ben Campbell; Black, David; dart@ietf.org
>>>>>> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward
>>>>>> 
>>>>>>> On 08/29/2014 06:04 PM, Colin Perkins wrote:
>>>>>>>> On 29 Aug 2014, at 16:52, Harald Alvestrand
><harald@alvestrand.no>; wrote:
>>>>>>>>> On 08/29/2014 05:14 PM, Black, David wrote:
>>>>>>>>> Harald,
>>>>>>>>> 
>>>>>>>>> I'm about to submit a -05 with the indication that the single
>DSCP
>>>>>> recommendation for SCTP and DCCP may be revised.  The RTCP
>multi-stream
>>>>>> optimisation text will still be in there with Colin's
>clarification about
>>>>>> "received" streams.  I'm about to vanish for about 3 weeks, but
>could put in a
>>>>>> revised -06 over the weekend if you can quickly convince Colin.
>>>>>>>> Explicitly pinging Colin - Colin, are you arguing that the
>sentence
>>>>>>>> 
>>>>>>>> RTCP multi-stream reporting optimizations for an RTP session
>>>>>>>> [I-D.ietf-avtcore-rtp-multi-stream-optimisation] assume that
>the RTP
>>>>>>>> streams involved experience the same packet loss behavior. 
>This
>>>>>>>> mechanism is highly inappropriate when the RTP streams involved
>use
>>>>>>>> different PHBs, even if those PHBs differ solely in drop
>precedence.
>>>>>>>> 
>>>>>>>> should stay in the draft?
>>>>>>> I was, but thinking again, I'm not so sure.
>>>>>>> 
>>>>>>>> I think this recommendation is wrong.
>>>>>>>> 
>>>>>>>> I can't find anything in your latest messages that speak to
>this particular
>>>>>> point.
>>>>>>>> You're one of the authors of -multi-stream, so you should be
>able to speak
>>>>>> clearly to the point.
>>>>>>>> 
>>>>>>>> Can you clarify?
>>>>>>> If I have several SSRCs, and receive several media streams, then
>provided
>>>>>> each of my SSRCs sees the exact same quality for each received
>stream, then  I
>>>>>> can use the multi-stream-optimisation to reduce the number of
>RTCP cross
>>>>>> reports I send. The multi-stream-optimisation draft says that
>already, and
>>>>>> it's not clear that the DART drafts needs to say anything further
>on the
>>>>>> topic.
>>>>>>> 
>>>>>>> Whether I use the same DSCP for all RTCP reports I send is, I
>think,
>>>>>> orthogonal to whether I use the multi-stream-optimisation. The
>dart draft
>>>>>> should possibly say that, but I'm not sure that's the sentence we
>have above.
>>>>>> I read the sentence above as saying flatly and unconditionally
>"don't
>>>>>> use multi-stream-optimization when the RTP streams have different
>PHBs"
>>>>>> - which means that if I want to use one PHB for audio and another
>PHB
>>>>>> for video, I can't use multi-stream-optimization.
>>>>>> 
>>>>>> I'd be sad if that was the case, *especially* if we can't figure
>out any
>>>>>> reason to make that recommendation.
>>>> 
>>> 
>>> _______________________________________________
>>> Dart mailing list
>>> Dart@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dart
>> 
>
>
>
>-- 
>Colin Perkins
>http://csperkins.org/

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.