Re: Last Call: <draft-ietf-tsvwg-le-phb-07.txt> (A Lower Effort Per-Hop Behavior (LE PHB)) to Proposed Standard

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

I requested Last Call for this draft because we're approaching IETF 104 and
my handoff to Magnus, and I'd like to leave a clean slate for him, but I
did spot two editorial changes I'm suggesting during Last Call.

On Tue, Jan 29, 2019 at 3:43 PM The IESG <[e-mail]> wrote:

>
> The IESG has received a request from the Transport Area Working Group WG
> (tsvwg) to consider the following document: - 'A Lower Effort Per-Hop
> Behavior (LE PHB)'
>   <draft-ietf-tsvwg-le-phb-07.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [e-mail] mailing lists by 2019-02-12. Exceptionally, comments may be
> sent to [e-mail] instead. In either case, please retain the
> beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document specifies properties and characteristics of a Lower
>    Effort (LE) per-hop behavior (PHB).  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.  There are numerous uses
>    for this PHB, e.g., for background traffic of low precedence, such as
>    bulk data transfers with low priority in time, non time-critical
>    backups, larger software updates, web search engines while gathering
>    information from web servers and so on.  This document recommends a
>    standard DSCP value for the LE PHB.  This specification obsoletes RFC
>    3662 and updates the DSCP recommended in RFC 4594 and RFC 8325 to use
>    the DSCP assigned in this specification.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>     rfc2475: An Architecture for Differentiated Services (Informational -
> IETF stream)
>

I do see a couple of things that I'd question, but am happy to send them as
Last Call comments if you'd like to get this in front of the IESG before
IETF 104. Just let me know what you prefer.

I think either "other" or "otherwise" can go away in this new text:

Some networks carry packets that ought to consume network resources only
when no other traffic is demanding them otherwise


and the longer I'm looking at this text, which hasn't changed, and sorry
for not noticing it earlier, during AD Evaluation,

Ideally, LE packets SHOULD be forwarded only if no packet with any other
PHB is awaiting transmission.


the more I'm thinking that "Ideally, SHOULD" isn't great BCP 14 usage,
especially with the following text, which is new in this version.

           This means
     that in case of link resource contention LE traffic can be starved
     completely, which may not be always desired by the network operator's
     policy.  The used scheduler to implement the LE PHB may reflect this
     policy accordingly.

If it was me - and this is not my draft - I'd say

Ideally, LE packets would be forwarded only when no packet with any other
PHB is awaiting transmission.

                   ^ text changes here to here  ^

      This means
      that in case of link resource contention LE traffic can be starved
      completely, which may not be always desired by the network operator's
      policy.  The used scheduler to implement the LE PHB may reflect this
      policy accordingly.

but do the right thing, because that will make your new AD happy, if Magnus
ends up with this document after I step down ...

Spencer