Re: [tsvwg] 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]>]

Hi, Roland,

On Wed, Jan 30, 2019, 01:45 Bless, Roland (TM) <[e-mail] wrote:

> 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.
>
Thanks for this note.

Your shepherd had agreed to these changes as well, so I think you can
submit an update before reviewers get started reviewing.

Spencer

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