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

"Black, David" <> Wed, 24 September 2014 13:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7BA891A00D0 for <>; Wed, 24 Sep 2014 06:11:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.086
X-Spam-Status: No, score=-5.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a6dfwTeez8ZU for <>; Wed, 24 Sep 2014 06:11:14 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1C041A00D1 for <>; Wed, 24 Sep 2014 06:11:13 -0700 (PDT)
Received: from ( []) by (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s8ODBBWf030234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2014 09:11:11 -0400
X-DKIM: OpenDKIM Filter v2.4.3 s8ODBBWf030234
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=jan2013; t=1411564271; bh=4Br+M2TCJ3U9c3IKXlujVLl8XJQ=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=U32aQzbFKqAiujMn6MNiyuIM0uUJRyUNPcqf7aMOYY5PVD1sY5DrrkBi/Imfd8Tjz CGorWj1S3URkZOy8l2bT0Zg91UCL/iuKspZhC2yoTK469YOJ8YnLaZtgZcAt1Ymnjn 8OFYf+2ccbACPZH4ZLNQUFbDDCQL1TMDVcedd5j0=
X-DKIM: OpenDKIM Filter v2.4.3 s8ODBBWf030234
Received: from ( []) by (RSA Interceptor); Wed, 24 Sep 2014 09:10:43 -0400
Received: from ( []) by (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s8ODApfO027977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Sep 2014 09:10:52 -0400
Received: from ([]) by ([]) with mapi; Wed, 24 Sep 2014 09:10:51 -0400
From: "Black, David" <>
To: Richard Barnes <>, "" <>
Date: Wed, 24 Sep 2014 09:10:50 -0400
Thread-Topic: [Dart] AD review of draft-ietf-dart-dscp-rtp-06
Thread-Index: Ac/Xnk+srrg/DWDDR8+KDhy2wVBldgAWJbqg
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE712077D725B83MX15Acorpemcc_"
MIME-Version: 1.0
X-RSA-Classifications: public
Subject: Re: [Dart] AD review of draft-ietf-dart-dscp-rtp-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Sep 2014 13:11:18 -0000


Thank you for the review, and I’m pleased that the draft provides a helpful introduction to DiffServ.

Comments inline @ David>

I’ll submit a -07 with these changes plus a version of Colin’s suggested change to the 5.4 text on RTCP RTT behavior.


From: Dart [] On Behalf Of Richard Barnes
Sent: Tuesday, September 23, 2014 10:22 PM
Subject: [Dart] AD review of draft-ietf-dart-dscp-rtp-06

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

David> Will change “prevents” -> “does not enable” and change “allow” -> “enable”
   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.
David> Oh dear, I’ve clearly been staring at the same text for too long :-(.  Will rephrase to:
   The results of using multiple DSCPs
   to obtain different QoS treatments within a single network 5-tuple (e.g., reordering), have transport protocol
   interactions, particularly with congestion control functionality.
   (Section 7 is an empty IANA Considerations section)
Note to future self: Remove this parenthetical and renumber once this hits the RFC Editor.
David> I’ll swap the order of sections 7 and 8, then delete this parenthetical remark now ;-).
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.)
David> “possible” -> “very likely”