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

["Bless, Roland (TM)" <[e-mail]>]

Hi Spencer and all,

Am 30.01.19 um 00:40 schrieb Spencer Dawkins at IETF:
> 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.

Yep, see below.

> On Tue, Jan 29, 2019 at 3:43 PM The IESG <[e-mail]
> <mailto:[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] <mailto:[e-mail]> mailing lists by 2019-02-12.
>     Exceptionally, comments may be
>     sent to [e-mail] <mailto:[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
>
>
Noted, will change accordingly.

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

You are right. This was a change introduced in -01 by someone suggesting
to make stronger
statements due to PS. However, in this case it is wrong. I'll remove the
BCP 14 usage.

>            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

Regards,
 Roland