[Dart] AD review of draft-ietf-dart-dscp-rtp-06

Richard Barnes <rlb@ipv.sx> Wed, 24 September 2014 02:21 UTC

Return-Path: <rlb@ipv.sx>
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 E01221A8A3B for <dart@ietfa.amsl.com>; Tue, 23 Sep 2014 19:21:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.577
X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tnYL9WnJXVoE for <dart@ietfa.amsl.com>; Tue, 23 Sep 2014 19:21:42 -0700 (PDT)
Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB7981A8A3A for <dart@ietf.org>; Tue, 23 Sep 2014 19:21:41 -0700 (PDT)
Received: by mail-lb0-f175.google.com with SMTP id w7so4148550lbi.20 for <dart@ietf.org>; Tue, 23 Sep 2014 19:21:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=PgqCjQhxLiXf9Q8zSp+VE4JBL5qZ5FxpZTxeq2rYFQA=; b=kGL/IVtKY1UgMmUA36r21sfXP4uLd0g4iWkipjyXqGvaARJxCqaZA4LZFELb7oEnET bXvU541gPpma6iXbaUEOWEsZcK/XpQPL1/X1Jl7mDfijm0Gz0TKKVLuKWe5zSsQraL3c adD/xvSLhSVyNqLMmt2sccuDK4MOh6NNlq2WIPZU5GhErPGTOyw7MP7vqStKvuC3uugU o8zLVNs6ZUHfzw7boD8bgnl2pqG+T9Gq7UUfgd6K73xqCJObHpJjtDoQN6BNCl9VBbcM nydl90iujzpjlkna01K/xgHapvsoY/4rclHtqJEFbGjSBpvTtMm6WaE6CuSIrQS7QXpa OoDA==
X-Gm-Message-State: ALoCoQlk8B76BqR5JBa7U6ziiJOXjFTZpK0BLppoheWJm0M65GmXBIysWgDTRNWee8pijL14OKrK
MIME-Version: 1.0
X-Received: by with SMTP id wv2mr3207601lac.45.1411525299692; Tue, 23 Sep 2014 19:21:39 -0700 (PDT)
Received: by with HTTP; Tue, 23 Sep 2014 19:21:39 -0700 (PDT)
Date: Tue, 23 Sep 2014 22:21:39 -0400
Message-ID: <CAL02cgSDPRQ-M2+k+f3L0-J9qYkU4pD52ipM_kfk8TCQQ84Jdw@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: draft-ietf-dart-dscp-rtp@tools.ietf.org, dart@ietf.org
Content-Type: multipart/alternative; boundary=001a113434081478e70503c65854
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/5RGR-oGmjFSQhzXy5lWiIYyvVLs
Subject: [Dart] AD review of draft-ietf-dart-dscp-rtp-06
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: Wed, 24 Sep 2014 02:21:44 -0000

I have reviewed this draft in preparation for IETF LC.  Overall this looks
very good.  As someone who is not deeply familiar with DiffServ concepts,
the document provided a helpful introduction and clearly justified its
recommendations.  I'll go ahead and request last call.

Some minor comments are below.  My main concern is that this document is so
well populated with references that it will get stuck in MISSREF for years
while others catch up :)



Section 6:
   The only use of multiple standardized PHBs and DSCPs that prevents
   network reordering among packets marked with different DSCPs is use
   of PHBs within a single AF class.
It doesn't prevent reordering, right?  It just makes reordering much more
unlikely and more transient.  (Unless you're using a strict definition of
"network reordering" that ignores things like ECMP balancing.)  The "allow"
phrasing is used several times in this section.  It would be helpful to


   Use of different DSCPs
   to obtain different QoS treatments within a single network 5-tuple,
   the results (e.g., reordering) may cause transport protocol
   interactions, particularly with congestion control functionality.
This sentence doesn't really parse.  Maybe just delete "the results (e.g.,
reordering)"?  Likewise for the same phrase in the introduction.

   (Section 7 is an empty IANA Considerations section)
Note to future self: Remove this parenthetical and renumber once this hits
the RFC Editor.

Section 5.1:
   In general, marking packets with different DSCPs results in different
   PHBs being applied at nodes in the network, making reordering
   possible due to use of different pools of forwarding resources for
   each PHB.
This seems like a pretty import, so I would state it more strongly.  It
doesn't just make reordering possible, it makes it much more likely.  (This
is the flip side of the Section 6 comment above.)