[tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-le-phb-09: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Sun, 17 February 2019 19:24 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 226AF12D4EC; Sun, 17 Feb 2019 11:24:35 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tsvwg-le-phb@ietf.org, David Black <david.black@dell.com>, tsvwg-chairs@ietf.org, david.black@dell.com, tsvwg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155043147510.3948.12077924366429728303.idtracker@ietfa.amsl.com>
Date: Sun, 17 Feb 2019 11:24:35 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/TntlfMAIXf7_0baUHtknxVy_yWs>
Subject: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-le-phb-09: (with COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Feb 2019 19:24:35 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-tsvwg-le-phb-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document is generally in fine shape, and has some good discussion in it. I basically just have some editorial suggestions. As one general note, the text sometimes seems to present a mixed story, for example in the case of "downgrading" traffic from other PHBs. We're told to in general not do this instead of dropping traffic, but on the other hand an example use of the LE PHB is for downgrading traffic from some other PHB (but only when it does not violate the operational objectives of that other PHB). Greater clarity on who is authorized to decide to downgrade, and in what cases it makes sense, could be useful. In a similar vein, the text sometimes suggests a dichotomy between use of the LE PHB for "preemptable" traffic vs. as a "scavenger" service class, and at other times suggests that these usages are identical. But those are, of course, editorial matters. Abstract The primary objective of this LE PHB is to protect best-effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, best-effort traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise unused resources only. [...] It seems like "preemptable" and "scavenger" are being deliberately conflated, but are not necessarily the same. Section 3 (e.g., if a transport connection fails due to timing out, the application may try several times to re-establish the transport connection in order to resume the application session before finally There was some directorate review traffic suggesting that further qualifications about the retries; I do see such qualifying statemnets in the next paragraph, so maybe there is no big need to do so here as well.. Use of the LE PHB might assist a network operator in moving certain kinds of traffic or users to off-peak times. Alternatively, or in addition, packets can be designated for the LE PHB when the goal is to protect all other packet traffic from competition with the LE Is it "alternatively" or "in addition" -- can it really be both at the same time? (I suppose the intent is that different operators could apply different policies?) Section 9 Is there a section reference in RFC 3754 to point us to? (Also, the RFC Editor will probably put a comma after "Basically".) Several forwarding error correction coding schemes such as fountain codes (e.g., [RFC5053]) allow reliable data delivery even in I'm used to seeing "forward error correction"; is "forwarding error correction" also an acceptabale usage? While the resource contention problem caused by multicast packet replication is also true for other Diffserv PHBs, LE forwarding is special, because often it is assumed that LE packets get only nit: s/get only/only get/ forwarded in case of available resources at the output ports. The previously mentioned redundancy data traffic could nicely use the varying available residual bandwidth being utilized the by LE PHB, but only if the previously specific requirements in the internal implementation of the network devices are considered. I'm not sure how to interpret "previously specific requirements", here. Was it intended to be "previously specified requirements"? Section 12 As per the GenART review, updating the draft in missref is a bit weird, but we can probably leave it to the responsible AD and RFC Editor to decide whether to retain the "Updates" relationship or directly effect the needed changes.
- [tsvwg] Benjamin Kaduk's No Objection on draft-ie… Benjamin Kaduk
- Re: [tsvwg] Benjamin Kaduk's No Objection on draf… Spencer Dawkins at IETF
- Re: [tsvwg] Benjamin Kaduk's No Objection on draf… Roland Bless
- Re: [tsvwg] Benjamin Kaduk's No Objection on draf… Benjamin Kaduk