[Dart] Commentary on draft-york-00

Harald Alvestrand <harald@alvestrand.no> Thu, 12 June 2014 12:49 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 []) by ietfa.amsl.com (Postfix) with ESMTP id DE0681B2A02 for <dart@ietfa.amsl.com>; Thu, 12 Jun 2014 05:49:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kn23kZt9kXze for <dart@ietfa.amsl.com>; Thu, 12 Jun 2014 05:49:17 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id AB3ED1B29FA for <dart@ietf.org>; Thu, 12 Jun 2014 05:49:16 -0700 (PDT)
Received: from localhost (localhost []) by mork.alvestrand.no (Postfix) with ESMTP id B88F97C3810 for <dart@ietf.org>; Thu, 12 Jun 2014 14:49:15 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([]) by localhost (mork.alvestrand.no []) (amavisd-new, port 10024) with ESMTP id JxLysp7WooDv for <dart@ietf.org>; Thu, 12 Jun 2014 14:49:14 +0200 (CEST)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 8B4CE7C380B for <dart@ietf.org>; Thu, 12 Jun 2014 14:49:14 +0200 (CEST)
Message-ID: <5399A1C8.7080407@alvestrand.no>
Date: Thu, 12 Jun 2014 14:49:12 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: dart@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/E0PsU9zyly41Uwg56pbJzr559Lk
Subject: [Dart] Commentary on draft-york-00
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: Thu, 12 Jun 2014 12:49:20 -0000

This message contains running notes made during my initial review of 
Apologies for lack of organization; it seems better to get them out soon 
than to polish them.

2 Background

"any one or more modalities" -> "one or more modalities" would read better.

"RTP defines the mechanism by which real-time data is transmitted" seems 
like an overreach. "RTP defines a common encapsulation format and 
handling rules for real-time data transmitted over the Internet" would 
be more appropriate.

"With most applications, a single..." - this is true for legacy. It 
seems likely not to remain true.

The definition of "media flow" needs to be in a "definitions" section. 
It's too important to be hiding in the "background" section - see much 
other mail.

"SCTP ... can be multiplexed with one or more RTP sessions". Actually we 
can only multiplex SCTP with a single RTP session. There have been 
proposals that would allow multiplexing of multiple RTP sessions (each 
containing multiple media flows) over a single 5-tuple, but these were 
not accepted.

The mention of MediaStream should be removed from bullet 1. It just 

In bullet 2, only one RTP session can be multiplexed with another 
transport protocol (again).

The last paragraph is where distinguishing between <some kind of media 
related name> and <RTP packet flow> is very desirable. As it stands now, 
it seems simple, but when you start asking what all these flows "are", 
more precisely, it gets very confusing.

2.1 DiffServ

bullet 1, first list: grammar nit - "classify traffic and setting bits" 
-> "classify traffic and set bits"

"In this context, "forwarding behavior" is a general - for example" .... 
is a general what, exactly?

"to allocates resources" -> "to allocate resources"

Nit: the all-zero DSCP seems to have only five zeroes.

2.2 Diffserv PHBs

do you want to mention what the difference between the 4 AF classes is? 
Is it just isolation, or is there a ranking between them (in theory or 
in practice)?

2.3 Diffserv and transport protocols

The last paragraph is true but irrelevant - we're not using UDP here, 
we're using other protocols carried inside UDP. And the stuff that's 
carried inside UDP may be sensitive to reordering or may be insensitive 
to reordering - we just can't tell purely from the fact that it's UDP.

Suggest deleting the paragraph.

IMPORTANT: There is a huge missing section here - which is about 
sensitivity of real time communications to packet reordering.

I'm not sure how much can be said here, but I think this is quite complex:

- Packet reordering may lead to spurious NACK generation and unneeded 
retransmission, just as for the data flow case. How sensitive it is to 
that depends on timers.

- Packet reordering that can be accomodated within an existing jitter 
buffer will not lead to any quality issues.

- Packet reordering that causes jitter buffers to extend is bad news for 
delay sensitive communication, such as interactive conversations. 
Interactive implementations may choose to discard late data - but this 
is a matter of meeting the deadline, not a matter of whether it's reordered.
For replay of recorded media, it doesn't matter much.

- Packet loss is dealt with differently on interactive media than on 
reliable data delivery: Instead of retransmissing all lost data, one 
finds a reference point that new data can be based on, and continues to 
transmit media relative to that. One does not attempt to recover lost 
frames that are history.
How that affects this discussion ... I'm not too sure.

2.4 DSCP remarking

The discussion of token-bucket-based remarkers leaves me a bit confused.
To me, it's obvious (?) that token-bucket-based remarkers would operate 
in color-blind mode on a network boundary, and in color-sensitive mode 
only when they had assurance that incoming markings were already 
indicating color. Thus, flows from an end-user system should only hit 
color-blind remarkers; the real question is: will a color-blind remarker 
use the incoming DSCP codepoint to decide which of a group of remarking 
treatments it chooses for the packets?

It seems to me that the section should tell me, and it doesn't.

3 RTP Multiplexing Background

Repeating the story about "only one RTP session per 5-tuple, please"....

4 Recommendations

As discussed above, the first SHOULD NOT (reordering within a media 
flow) is not sufficiently founded in discussion of media properties. 
Reordering may be a problem, or it may not be a problem.

I don't see any issues with the other recommendations (the second seems 
like an obvious thing to say, for well documented reasons; the three 
others seem like no-ops from a practical standpoint).

Thanks for getting this out the door!