Re: [Dart] Treatment of RTCP - proposed text

"Paul E. Jones" <paulej@packetizer.com> Thu, 28 August 2014 03:20 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 60C631A0307; Wed, 27 Aug 2014 20:20:52 -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 ZSOnnmZ2suxk; Wed, 27 Aug 2014 20:20:51 -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 009231A030B; Wed, 27 Aug 2014 20:20:50 -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 s7S3Kijg003277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Aug 2014 23:20:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1409196044; bh=c545PER2LlmyNwPZamqivmOmFXeq5F51xWjDCn6YMNc=; h=From:To:Subject:Cc:Date:Message-Id:In-Reply-To:Reply-To: Mime-Version:Content-Type:Content-Transfer-Encoding; b=l6Rn9v/Ux1K57vqV6ogQYJYnV/2Su4DWRG5Iboaf6Eu9DvSGDb0x1196DYYrENCZX CCruRtItsUF5MhQQPwylHqgMDwhibjhmFn3xYmsV/Cr4NpiYN6xTQKEhOvkH0L9wHL NFWvDD2dSqhpIQGMWdFuDRvxpZj0SHU3geb5arhs=
From: "Paul E. Jones" <paulej@packetizer.com>
To: "Ben Campbell" <ben@nostrum.com>, "Black, David" <david.black@emc.com>
Date: Thu, 28 Aug 2014 03:21:13 +0000
Message-Id: <em14e0cabb-7036-4655-aa40-a3f72b83f433@sydney>
In-Reply-To: <B6DC0D42-4F86-4BCA-BD76-48C3A0FFBB83@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/s4M7eVhu3E5J_e5aAvc8fGmDbSw
Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" <draft-ietf-dart-dscp-rtp.all@tools.ietf.org>, "dart@ietf.org" <dart@ietf.org>, Colin Perkins <csp@csperkins.org>, Michael Welzl <michawe@ifi.uio.no>, "avt@ietf.org WG" <avt@ietf.org>
Subject: Re: [Dart] Treatment of RTCP - proposed text
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: Thu, 28 Aug 2014 03:20:52 -0000

Ben,

I think the answer is really whether we can quickly reach consensus.  I 
have an idea how I'd implement it if I didn't have guidance otherwise, 
which I explained in my last email.

I think this can be resolved pretty quickly.  If not, we can certainly 
leave it open.

Paul

------ Original Message ------
From: "Ben Campbell" <ben@nostrum.com>
To: "Black, David" <david.black@emc.com>
Cc: "Paul E. Jones" <paulej@packetizer.com>om>; "Michael Welzl" 
<michawe@ifi.uio.no>no>; "Colin Perkins" <csp@csperkins.org>rg>; 
"draft-ietf-dart-dscp-rtp.all@tools.ietf.org" 
<draft-ietf-dart-dscp-rtp.all@tools.ietf.org>rg>; "dart@ietf.org" 
<dart@ietf.org>rg>; "avt@ietf.org WG" <avt@ietf.org>
Sent: 8/27/2014 10:28:07 PM
Subject: Re: Treatment of RTCP - proposed text

>I do not object to the text per se.
>
>But I do have a bit of a nagging concern that we may be offering too 
>strong of guidance, given the thought process so far. Do we believe we 
>understand this well enough to say the sender should to this or that, 
>as opposed to say that these are things the implementer should think 
>about, and that these are probably reasonable choices?
>
>Is this an area where we need more deployment experience to offer real 
>guidance? (I think it's okay for the doc to say that, if needed.)
>
>But in any case, I will defer to Colin, Paul, and David.
>
>On Aug 27, 2014, at 8:58 PM, Black, David <david.black@emc.com> wrote:
>
>>  Trying to propose some text here:
>>
>>  OLD
>>    o Should use a single DSCP for an RTCP session, primarily to avoid
>>       RTCP reordering (and because there is no compelling reason for 
>>use
>>       of different drop precedences). One of the PHBs and associated
>>       DSCP used for the associated RTP traffic would be an appropriate
>>       choice. [Editor's note: This bullet is an open technical issue.]
>>  NEW
>>    o Should use the same DSCP for RTCP reports as used for the RTP 
>>stream
>>       that is being reported on when that DSCP is known by the RTCP 
>>sender.
>>       When an RTP stream uses multiple DSCPs that differ only in drop
>>       precedence, RTCP reports on that RTP stream should use the DSCP 
>>with
>>       the least likelihood of drop to favor delivery of the RTCP 
>>reports.
>>       When a single RTCP message reports on multiple RTP streams that
>>       are sent with different DSCPs, the RTCP sender should choose one
>>       of those DSCPs. When the RTCP sender does not know what
>>   DSCP or DSCPs were used to send an RTP stream, it should choose
>>   a DSCP that it would use to send a similar RTP stream.
>>
>>  The latter sentence is courtesy of the fact that there will be cases
>>  where the RTCP sender will not know what DSCP or DSCPs were used to 
>>send
>>  the RTP stream, due to en-route remarking.
>>
>>  If that text looks close, I'll edit further and try to get the -05 
>>submitted
>>  by the end of this week.
>>
>>  Thanks,
>>  --David
>>
>>>  -----Original Message-----
>>>  From: Paul E. Jones [mailto:paulej@packetizer.com]
>>>  Sent: Wednesday, August 27, 2014 6:53 PM
>>>  To: Ben Campbell; Michael Welzl; Colin Perkins; Black, David
>>>  Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org; dart@ietf.org; 
>>>avt@ietf.org
>>>  WG
>>>  Subject: Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin 
>>>Perkins
>>>  comments - WGLC: draft-ietf-dart-dscp-rtp-02)
>>>
>>>  RTCP might not be used for RTT calculations (it might; I just doubt 
>>>it's
>>>  terribly useful), but RTCP might be used to convey QoE measurements 
>>>or
>>>  one-way delay information useful for RMCAT.
>>>
>>>  I think there is agreement that the DSCP value applied to the RTCP
>>>  packet for a given SSRC sender should align with the DSCP value used 
>>>for
>>>  the corresponding RTP packets of that sender. In the case where an 
>>>AFxx
>>>  class is used, I'm not sure there is agreement (though no 
>>>disagreement).
>>>   I stated my view that we should use the lowest drop precedence in 
>>>that
>>>  case, but others should weigh in.
>>>
>>>  Paul
>>>
>>>  ------ Original Message ------
>>>  From: "Ben Campbell" <ben@nostrum.com>
>>>  To: "Michael Welzl" <michawe@ifi.uio.no>no>; "Colin Perkins"
>>>  <csp@csperkins.org>rg>; "Paul E. Jones" <paulej@packetizer.com>om>; 
>>>"Black,
>>>  David" <david.black@emc.com>
>>>  Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org"
>>>  <draft-ietf-dart-dscp-rtp.all@tools.ietf.org>rg>; "dart@ietf.org"
>>>  <dart@ietf.org>rg>; "avt@ietf.org WG" <avt@ietf.org>
>>>  Sent: 8/27/2014 4:48:37 PM
>>>  Subject: Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin 
>>>Perkins
>>>  comments - WGLC: draft-ietf-dart-dscp-rtp-02)
>>>
>>>>  On Aug 27, 2014, at 3:45 PM, Michael Welzl <michawe@ifi.uio.no> 
>>>>wrote:
>>>>
>>>>>  I don't know the beginning of this but I can help go up the stack:
>>>>>
>>>>>  for the short dialogue between Colin and me, the conclusion is: 
>>>>>Colin
>>>>>  is right. RTCP probably won't be used by congestion control to
>>>>>  estimate the RTT.
>>>>>
>>>>
>>>>  Thanks, Michael, I think that fits with some earlier conversations 
>>>>as
>>>>  well.
>>>>
>>>>  Colin and Paul (and David):
>>>>
>>>>  Are we converging on what guidance to put into the DART draft?
>>>>
>>>>  Thanks!
>>>>
>>>>  Ben.
>>>>
>>>>
>>>>  _______________________________________________
>>>>  Dart mailing list
>>>>  Dart@ietf.org
>>>>  https://www.ietf.org/mailman/listinfo/dart
>>
>