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

[Spencer Dawkins at IETF <[e-mail]>]

Just following up ...

On Sun, Feb 17, 2019, 11:24 Benjamin Kaduk <[e-mail] 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 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.
>

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.

Spencer