[Dart] WGLC Comments on draft-ietf-dart-dscp-rtp-02

Ben Campbell <ben@nostrum.com> Mon, 18 August 2014 21:49 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 61EBB1A7018 for <dart@ietfa.amsl.com>; Mon, 18 Aug 2014 14:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NSmMrBeW9ePI for <dart@ietfa.amsl.com>; Mon, 18 Aug 2014 14:49:30 -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 B661F1A0020 for <dart@ietf.org>; Mon, 18 Aug 2014 14:49:30 -0700 (PDT)
Received: from [] (cpe-173-172-146-58.tx.res.rr.com []) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7ILnRvQ024002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Aug 2014 16:49:29 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [] claimed to be []
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>
Date: Mon, 18 Aug 2014 16:49:27 -0500
X-Mao-Original-Outgoing-Id: 430091367.393255-ed1b2af09bffb257f26a65032f94c2f2
Content-Transfer-Encoding: quoted-printable
Message-Id: <62D70F5C-C6CF-48C7-AE9F-55B17172555D@nostrum.com>
To: draft-ietf-dart-dscp-rtp.all@tools.ietf.org
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/u1FWMEiB2rf6iZRxfAY-ihiDROc
Cc: dart@ietf.org
Subject: [Dart] WGLC Comments on draft-ietf-dart-dscp-rtp-02
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, 18 Aug 2014 21:49:32 -0000

(As individual)


Here are some WGLC comments on draft-ietf-dart-dscp-rtp-02.




**** Substantive:

-- General: 

I was going to ask if we can be more precise on what sort of layering (and muxing?) we expect to really happen on top of DTLS, especially for WebRTC use cases. But I think Colin's comments are on the right track, so I will comment in that thread.

-- Abstract (and intro)

It's probably worth mentioning that, other than mixing RTP/RTCP,  RTP multiplexing is a relatively new thing. It's needed by new work such as WebRTC and clue, and it is enabled by bundle. The point being, this wasn't something we really needed to worry about until now.

-- Section 2.1, list item 3: "An RTP session could be multiplexed with other protocols ... "

What is likely to really happen here? I don't think we will see an arbitrary mixing of other protocols in the immediate future. What are the realistic constraints, and likely layerings?  For example, with WebRTC, we are likely to see some number of RTP/RTCP streams, stun, turn, and dtls, with dtls carrying one or more SCTP associations (i.e. data channels) right? Do we have ways to signal more than that in sdp-bundle?

OTOH, I guess one could argue that people might try to mix in more things in the future.

-- 2.1, 2nd to last paragraph, last sentence (starting with "In contrast..."

Is this specific to SCTP associations carried over DTLS packets a la RFC5764, or are we talking about SCTP/UDP in general?

-- 2.2, third paragraph:

Are we talking about TCP as the outer transport protocol, and muxing things on the TCP 5-tuple? Or are we considering TCP as something that might get multiplexed on the UDP 5-tuple? Where do Jonathan Lennox's comments about potentially falling back to an ICE TCP candidate fit?

-- section 3, paragraph 5:

Does the term "network node" include application endpoints that might do initial DiffServ marking?

-- section 3, paragraph 12: "... observable forwarding behavior (e.g., loss, delay, jitter) will often depend only on the relative loading of the link"

Relative to what? Other links? Relative load to the capacity of the link?

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

-- section 6, last bullet:

Is there a such thing as "less than best effort traffic" where "best effort" treatments would be unacceptable?

Actually, it's not clear to me from this paragraph if CS1 is ever appropriate, at least from the application endpoint perspective, as it seem to give completely unpredictable results.

-- Normative References:

Are these first two references both "normative" enough to block on them?

**** Editorial:

-- section 1, paragraph 1: "As a result use of different DSCPs..."

Missing comma after "result".

-- 3.2, paragraph 1: "... and such nodes remark traffic ..."

May remark? Always remark?

-- 3.2, paragraph 3, last sentence:

Is this sentence redundant to the previous paragraph?

-- 4, paragraph 1: 2nd and 3rd sentence

These sentences seem to contradict. The first says that receiving audio early is not useful, but the second says it may be useful.

-- 4, 2nd paragraph: "... e.g., are in an AF class ..."

in the _same_ AF class?

-- 5.1, 7th paragraph

Is this paragraph redundant with previous discussions of AF classes?

-- 5.2, third paragraph:

Can you elaborate on what it means to be "contained in a buffer"?

-- 5.2, around paragraph 5:

There are words about why non-interactive media is likely to have larger jitter buffers, but the fact that interactive media may have smaller buffers us left to implication.

-- 5.3, 1st and 2nd sentence:

These seem redundant to previous discussions about AF classes.

-- 5.3, 2nd paragraph:

It's not clear to me what this paragraph means. Is drop likelihood the likelihood that anything is dropped in a session, or the chance of any given packet being dropped? I assume drop likelihood is relative to that of other sessions crossing the same path? And that under non congested conditions none of this will matter?

-- 6, 1st paragraph: " ... the following requirements ..."

Are these requirements per se, or guidelines?

-- 6, bullet list

Each bullet starts with a verb, but ommits the subject. E.g., in the first bullet, what is the actor that should not use different DSCPs within a different stream?

-- 6, 1st bullet:

The double negation is confusing  ("should not use", "If this is not done..."). Also,

2nd bullet:

Is "use a single PHB and DSCP" different than just saying "use a single DSCP"?

3rd bullet: 

Am I correct in assuming SCTP multihoming is not an issue here? Should we mention that explicitly?