Re: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-le-phb-09: (with COMMENT)

Spencer Dawkins at IETF <> Tue, 19 February 2019 13:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 139BD130EEB; Tue, 19 Feb 2019 05:53:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jb9oIH0sj-z1; Tue, 19 Feb 2019 05:53:49 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 162A3130EE9; Tue, 19 Feb 2019 05:53:49 -0800 (PST)
Received: by with SMTP id z20so16454788ljj.10; Tue, 19 Feb 2019 05:53:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SLrYumHVXbB5aEmTbYbHORU5A/IYHCAGnHncsxoLDlc=; b=gtWusSGjmYl+7VOnwenTypy6KJYc/MTWaDxIy4BjUCdWH0ylLUmwbQ8FcGnok2WMHl aUzcF/FhWTUYBEdBuyXa2vn3OIrrRJZ7F3Q+oIkLqRyqU/c4Tu3mRFfBBG/PZ3cahuLY cVrzLFhYnxWGdgoYJNSTV+rEri47Rm5d4ZLecjylchEt94dFbfLknHkzRmNHaDgsBEIy m7BsSip7RowOUXY8baJ2tAhhV9uTUKsO8p76zgdU6urlGH0yGxG2BLE6FeHfAOjd6oTw c+cb2Z9zVc4k2TOp2BmzCfe4SUt8UQSeSUjMOtt8wDTEEZ89zgQtvvSPOq9mOfWxFnxA RlDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SLrYumHVXbB5aEmTbYbHORU5A/IYHCAGnHncsxoLDlc=; b=DtmmxX08WQana3Hsz9xedT9XohuTsrFrWsXIoEwhfUIjvX9CeSvyc5zieCt4UUD8B1 kC6dDrLbMNSgnKezWGUPmQxuewzC5vsENh6D5lgpQRy3lp30Y4uOx4YoQzO6v4QChsyK v2GB7dY+X3PPsjT2YvqNNgVHb+JrBtMOi0JgOEQiLBHRgnVDwlIDAYlPP1lVwgcye3kR r86dTxsfmYPs/zUT8Z6IaxVSv17cajqYcOdSLiASfDXUlPdnRahc9kqzFikvvzpgL9Io PpocSmuucsGh7EQpj2avJWzWwe74HnF4P8dbYvYI56Nr+dfh7qTUuGLdrthd8AJi4tyk vyVg==
X-Gm-Message-State: AHQUAuaTQUMZ/6H8ctpMe3QLt7j0uFU6mKadHi6i7nEpUIc5VdyJFIcG mZoULjo/csIra4VYK+3Yjm+TBKonGXNe9Ar/af0=
X-Google-Smtp-Source: AHgI3IaBG4/3bttQB8zns5Qx4R4cVpghmLk/INsssYt3CQJotwp7eEw4ZCpft1w2HsD8y4K1SKMNNCyhtaPEKEsX+qI=
X-Received: by 2002:a2e:9204:: with SMTP id k4mr40641ljg.0.1550584427088; Tue, 19 Feb 2019 05:53:47 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Tue, 19 Feb 2019 05:53:35 -0800
Message-ID: <>
To: Benjamin Kaduk <>
Cc: IESG <>,,,,
Content-Type: multipart/alternative; boundary="000000000000f88e1705823f914c"
Archived-At: <>
Subject: Re: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-le-phb-09: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Feb 2019 13:53:52 -0000

Just following up ...

On Sun, Feb 17, 2019, 11:24 Benjamin Kaduk < wrote:

> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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.

I do have an RFC Editor Note that points this out, added after the GenART
review. So we should be good to go on that point.