Re: [Dart] draft-ietf-dart-dscp-rtp-02 - Section 4 data channel text

Ben Campbell <ben@nostrum.com> Tue, 26 August 2014 14:38 UTC

Return-Path: <ben@nostrum.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 043911A86EF for <dart@ietfa.amsl.com>; Tue, 26 Aug 2014 07:38:45 -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 S_xjcCKGQUPP for <dart@ietfa.amsl.com>; Tue, 26 Aug 2014 07:38:43 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685AF1A86F2 for <dart@ietf.org>; Tue, 26 Aug 2014 07:38:43 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7QEcKZQ087667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Aug 2014 09:38:21 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BB42CEA@MX15A.corp.emc.com>
Date: Tue, 26 Aug 2014 09:38:19 -0500
X-Mao-Original-Outgoing-Id: 430756699.809075-fdac62a0b9e17126b4d199066d878588
Content-Transfer-Encoding: quoted-printable
Message-Id: <289B2FA8-457F-4CF2-BA72-CF0DA947CE11@nostrum.com>
References: <8D3D17ACE214DC429325B2B98F3AE712077BB42CEA@MX15A.corp.emc.com>
To: "Black, David" <david.black@emc.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/mvvpZwMo5GrRunftILt5tSRcZw4
Cc: Harald Tveit Alvestrand <harald@alvestrand.no>, "dart@ietf.org" <dart@ietf.org>
Subject: Re: [Dart] draft-ietf-dart-dscp-rtp-02 - Section 4 data channel text
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: Tue, 26 Aug 2014 14:38:45 -0000

On Aug 26, 2014, at 1:07 AM, Black, David <david.black@emc.com> wrote:

>>>>> -- section 4:
>>>>> 
>>>>> It might be nice to have a more WebRTC-ish example. For example an audio
>>>>> stream, video stream, and a data channel carrying something like a shared
>>>>> white board or game.
>>>> Sure, please send text.
>>>> 
>>> Okay, how about something like the following, added to the end of section 4:
>>> 
>>> "A WebRTC application may carry one or more RTP streams, as discussed above.
>> In addition, it might carry an SCTP data channel. The treatment of the data
>> channel would depend on the nature of the application. For example, messaging
>> applications, shared white board, or guided browsing applications might be
>> best effort, while a latency-sensitive game application might require a higher
>> priority PHB."
>> 
>> I would prefer to say "A WebRTC application may use...." - an
>> application is something that lives in a browser at one end of a
>> connection, talking to something at the other end of the connection
>> (might be an instance of the same application, might be something
>> completely different).
>> 
>> I would also prefer "might desire" to "might require" - games are
>> unlikely to refuse to operate if they don't get a higher priority PHB,
>> they'll just work with degraded performance. That's nits.
> 
> Done, plus some more editing, here's the result in my working draft:
> 
>   A WebRTC application may use one or more RTP streams, as discussed
>   above.  In addition, it may include an SCTP-based data channel
>   [I-D.ietf-rtcweb-data-channel] whose QoS treatment depends on the
>   nature of the application.  For example, best effort treatment of
>   data channels is likely to suffice for messaging, shared white board,
>   and guided browsing applications, whereas latency-sensitive games
>   might desire better QoS for their data channels.
> 

WFM.