[Dart] HTA's Last Call review - drart-dscp-rtp-02

Harald Alvestrand <harald@alvestrand.no> Fri, 22 August 2014 13:47 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 DFBF51A03F8 for <dart@ietfa.amsl.com>; Fri, 22 Aug 2014 06:47:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hmzuK91jWyE1 for <dart@ietfa.amsl.com>; Fri, 22 Aug 2014 06:47:02 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no []) by ietfa.amsl.com (Postfix) with ESMTP id 42A781A03E3 for <dart@ietf.org>; Fri, 22 Aug 2014 06:47:02 -0700 (PDT)
Received: from localhost (localhost []) by mork.alvestrand.no (Postfix) with ESMTP id 30BC37C3EE5 for <dart@ietf.org>; Fri, 22 Aug 2014 15:47:01 +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 zpL7YtSynGL8 for <dart@ietf.org>; Fri, 22 Aug 2014 15:46:59 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:1c79:5878:8b25:dce8] (unknown [IPv6:2001:470:de0a:27:1c79:5878:8b25:dce8]) by mork.alvestrand.no (Postfix) with ESMTPSA id 367447C3ED6 for <dart@ietf.org>; Fri, 22 Aug 2014 15:46:59 +0200 (CEST)
Message-ID: <53F749D1.7050407@alvestrand.no>
Date: Fri, 22 Aug 2014 15:46:57 +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: "dart@ietf.org" <dart@ietf.org>
Content-Type: multipart/alternative; boundary="------------000105040802050109070102"
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/AWXDhymTUkr7phy_RiQqx1o2BG8
Subject: [Dart] HTA's Last Call review - drart-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: Fri, 22 Aug 2014 13:47:06 -0000


Last Call review - drat-ietf-dart-dscp-rtp-02


Summary: This document is not ready for IETF Last Call, but close.

The recommendations are reasonable and reasonably argued, but the
precision and specificity of the language needs to be tightened up
before publication.

The below addresses some specific concerns.

Section 2

nit: “communication in real-time” -> “communication in real time”

nit: The complex example needs to mention that there may be non-media
streams; suggest “there may be multiple media and non-media streams”.


Reference to SSRC for reference clock is wrong - “an RTP stream may
contain multiple source streams that use the same reference clock
(SSRC)” - this should be “clock, identified by the same CNAME”. The SSRC
has to be different for each RTP stream in an RTP session. (The naming
choice here is confusing….)

The section needs to mention that RTP can be carried over a non-datagram
protocol such as TCP, but that this document does not say more about
this - just to show that its omission is deliberate, not accidental.

(In fact 5.3 discusses TCP-encapsulated RTP. So it’s appropriate to
mention it here.)

STUN is not an encapsulation protocol, so should be omitted from the
“encapsulated via STUN” sentence. TURN is. STUN packets are, however,
multiplexed with the RTP packets.

Agree that the UDP stream is not unidirectional.


STUN/TURN paragraph sits oddly here. It seems to belong outside the
“reasons for multiplexing” flow. Perhaps move it to the beginning of the

Again, STUN description needs tuning; STUN is used also for enabling
communication without a relay server, by exchanging publicly-visible IP
addresses and ports.


“receiving the audio packets ahead of the video is not useful” -> “is
not very useful” - the next sentence gives a reason why it is somewhat

5.1 Diffserv, Reordering and Transport Protocols

The paragraph “Reordering also affects other forms of congestion
control” is wrong. The content is OK, but the intro is not - it is the
differential treatment (including drop probability) that creates
problems for RMCAT, not (just) the reordering.

DCCP is sensitive to differential treatment, since it does congestion
control, so description of it as “problem free” is wrong.

I think there are considerations coming from reordering (which affect
protocols with immediate feedback, such as ACK-based protocols), and
there are consdierations from diferential treatment (guessing wrong
about what’s affected by a queue). The former applies to TCP; the latter
applies to TCP, SCTP, DCCP, and (probably) whatever RMCAT comes to.
These two should be separated.

5.2 DiffServ, reordering and real time communication

The last paragraph of the section is somewhat misleading - network
packet reordering done for *whatever* reason has no upper bound. If the
authors think that packet reordering is more likely to be problematic
with different DSCPs than with the same DSCP, that’s what they should say.

The reference to RTCP multi-stream optimization seems completely wrong.
The grouping into RTCP reporting groups is about receiver SSRCs that see
the same set of packets, not about grouping reports about different SSRC
together. (unless I’ve misunderstood something). When not using
multi-stream optimization, these SSRCs send duplicate reports.

6. Guidelines

The word “requirements” seems at odds with the headline “guidelines”.

The word “session” is used several times without explanation - “RTCP
session”, “reliable transport protoocol session”. From context, I guess
“flow” or “connection” would be more appropriate.

I wonder if the first requirement can be phrased in the positive? For

* Within a single RTP stream, should use a single PHB and DSCP, or a set
of PHBs and DSCPs that do not allow reordering, for instance a single AF

All in all, the document*'s recommendations are clear and reasonable, but the document can be improved.



Surveillance is pervasive. Go Dark.