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

Harald Alvestrand <harald@alvestrand.no> Fri, 29 August 2014 20:14 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 C30C41A056D for <dart@ietfa.amsl.com>; Fri, 29 Aug 2014 13:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level:
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QNIQnItgs-Gx for <dart@ietfa.amsl.com>; Fri, 29 Aug 2014 13:14:11 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 01C121A0537 for <dart@ietf.org>; Fri, 29 Aug 2014 13:14:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 3D6047C3F89; Fri, 29 Aug 2014 22:14:10 +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 ZmSw1AT98Yuj; Fri, 29 Aug 2014 22:14:09 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:1965:7d1f:23fa:58ce] (unknown [IPv6:2001:470:de0a:27:1965:7d1f:23fa:58ce]) by mork.alvestrand.no (Postfix) with ESMTPSA id BEF297C3E1F; Fri, 29 Aug 2014 22:14:08 +0200 (CEST)
Message-ID: <5400DF0F.6060704@alvestrand.no>
Date: Fri, 29 Aug 2014 22:14:07 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "Black, David" <david.black@emc.com>, Colin Perkins <csp@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>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BC6699A@MX15A.corp.emc.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/j7E6VXIQ8mjbjfxm-ER0tN-a9Mc
Cc: Ben Campbell <ben@nostrum.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: Fri, 29 Aug 2014 20:14:13 -0000

On 08/29/2014 10:09 PM, Black, David 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 :-).

Looks good to me!

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


-- 
Surveillance is pervasive. Go Dark.