|
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.
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
ietf@xxxxxxxx mailing lists by
2019-02-12. Exceptionally, comments may be
sent to iesg@xxxxxxxx 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
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
|
