Skip to main content

A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services
draft-ietf-tsvwg-le-phb-10

Revision differences

Document history

Date Rev. By Action
2019-06-18
10 (System) RFC Editor state changed to AUTH48-DONE
2019-06-13
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-06-10
10 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-06-04
10 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-05-23
10 (System) RFC Editor state changed to EDIT from MISSREF
2019-05-08
10 Magnus Westerlund Shepherding AD changed to Magnus Westerlund
2019-04-15
10 (System) RFC Editor state changed to MISSREF from EDIT
2019-03-18
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2019-03-18
10 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2019-03-18
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2019-03-18
10 (System) RFC Editor state changed to EDIT
2019-03-18
10 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-03-18
10 (System) Announcement was received by RFC Editor
2019-03-15
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2019-03-15
10 (System) IANA Action state changed to In Progress
2019-03-15
10 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2019-03-15
10 Cindy Morgan IESG has approved the document
2019-03-15
10 Cindy Morgan Closed "Approve" ballot
2019-03-15
10 Spencer Dawkins Ballot approval text was generated
2019-03-15
10 Spencer Dawkins Ballot approval text was generated
2019-03-11
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-03-11
10 Roland Bless New version available: draft-ietf-tsvwg-le-phb-10.txt
2019-03-11
10 (System) New version approved
2019-03-11
10 (System) Request for posting confirmation emailed to previous authors: Roland Bless
2019-03-11
10 Roland Bless Uploaded new revision
2019-02-21
09 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2019-02-21
09 Mirja Kühlewind
[Ballot comment]
Thanks for addressing the TSV-ART comments (and thanks Olivier for the review)!

Two mostly editorial comments from my side:

1) In sec 3: …
[Ballot comment]
Thanks for addressing the TSV-ART comments (and thanks Olivier for the review)!

Two mostly editorial comments from my side:

1) In sec 3: "nor should packets be "downgraded" to the LE PHB  instead of being dropped"
I would suggest to use proper normative language here, e.g. "and packets SHOULD NOT be "downgraded" to the LE PHB instead of being dropped".

2) I would recommend to add a reference to rfc8087 at the end of section 4.
2019-02-21
09 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2019-02-20
09 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2019-02-20
09 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2019-02-20
09 Ben Campbell [Ballot comment]
Thank you for addressing my DISCUSS
2019-02-20
09 Ben Campbell [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from Discuss
2019-02-20
09 Suresh Krishnan
[Ballot comment]
I was not sure how this behavior in Section 8 is expected to be deployed and used.

"  A DS domain that still …
[Ballot comment]
I was not sure how this behavior in Section 8 is expected to be deployed and used.

"  A DS domain that still uses DSCP CS1 for marking LE traffic
  (including Low Priority-Data as defined in [RFC4594] or the old
  definition in [RFC3662]) SHOULD remark traffic to the LE DSCP
  '000001' at the egress to the next DS domain."

Is the expectation that even on a domain that has not been updated to use the new DSCP there will be some node at the edge that will have been updated? If so, it might be good to explicitly note this. If not, I cannot see how a legacy node will follow this recommendation.
2019-02-20
09 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-02-20
09 Spencer Dawkins RFC Editor Note was changed
2019-02-20
09 Warren Kumari
[Ballot comment]
--- Original DISCUSS position for hysterical raisins ---
I believe that this should be trivial DISCUSS to address, but I thought it important …
[Ballot comment]
--- Original DISCUSS position for hysterical raisins ---
I believe that this should be trivial DISCUSS to address, but I thought it important enough to warrant it. I'm OK with basically whatever you answer, I just wanted to make sure this had been seen and considered.

"An LE PHB SHOULD NOT be used for a customer’s "normal Internet"
  traffic nor should packets be "downgraded" to the LE PHB instead of
  being dropped, particularly when the packets are unauthorized
  traffic.  "

Great, sounds good to me -- but in the USA at least, there is are many cell phone plans which are "unlimited", but after some amount of traffic (e.g 22GB) your connection gets throttled to a lower data rate. Is this traffic still 'a customer's "normal Internet" traffic"? Is it appropriate (whatever that means) to downgrade this traffic to the LE PHB?
I understand not wanting to touch this issue with  a 10 foot pole (and I don't know what the right answer is!), but you *did* open this can of worms by talking about what classification user traffic should have.

Note: I'm happy to clear my DISCUSS no matter what the answer is, I just want to make sure it has been considered / discussed.

---------

Major:
"Some network providers keep link utilization below 50% to ensure that all traffic is forwarded without loss after rerouting caused by a link failure (cf.Section 6 of [RFC3439]).  LE marked traffic can utilize the normally unused capacity and will be preempted automatically in case of link failure when 100% of the link capacity is required for all other traffic. "
Yup - very true. But I think it needs to be mentioned that the provider will need to upgrade their monitoring / management system so that they can see the traffic lass. If they monitoring circuit utilization using e.g interface counters (and not by traffic class), a link may have 1% "real" traffic and 90% LE traffic, and it will look like it it 91% "full". I don't have any suggested text to address this (and this is just a comment, so "well, duh, they should know that anyway!" is a fine answer.)


Nits:
"A main problem is that multicast" -- I'm not sure you can say "A main" - main implies singular.; I'd suggest "The main" or "A major".

"However,using the Lower Effort PHB for multicast requires to pay special" -- "requires paying"...
2019-02-20
09 Warren Kumari [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss
2019-02-20
09 Spencer Dawkins RFC Editor Note was changed
2019-02-20
09 Deborah Brungard
[Ballot comment]
I think Warren hit on my concern. There seems to be mixed concepts regarding
how the markings are done. E.g.:
"However, non-LE traffic …
[Ballot comment]
I think Warren hit on my concern. There seems to be mixed concepts regarding
how the markings are done. E.g.:
"However, non-LE traffic (e.g., BE traffic) SHOULD NOT be
remarked to LE on a regular basis without consent or knowledge of the user."

Maybe for some users, an operator informs the "user" how their traffic is
marked, but I think it is more of a service contract, doesn't spell out this
detail. Especially if multi-domain. And traffic can be re-marked
(RFC7657/section 3.2). This is really per operator implementation.

Suggest remove this sentence, especially RC2119 language. Agree
also with Warren's examples to fix.
2019-02-20
09 Deborah Brungard Ballot comment text updated for Deborah Brungard
2019-02-20
09 Deborah Brungard
[Ballot comment]
I think Warren hit on my concern. There seems to be mixed concepts regarding
how the markings are done. E.g.:
"However, non-LE traffic …
[Ballot comment]
I think Warren hit on my concern. There seems to be mixed concepts regarding
how the markings are done. E.g.:
"However, non-LE traffic (e.g., BE traffic) SHOULD NOT be
remarked to LE on a regular basis without consent or knowledge of the user."

Maybe for some users, an operator informs the "user" how their traffic is
marked, but I think it is more of a service contract, doesn't spell out this
detail. Especially if multi-domain. And traffic can be re-marked
(RFC7657/section 3.2).

Suggest remove this sentence, especially RC2119 language. Agree
also with Warren's examples to fix.
2019-02-20
09 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-02-20
09 Alissa Cooper
[Ballot comment]
= Section 3 =

"An LE PHB SHOULD NOT be used for a customer's "normal Internet"
  traffic nor should packets be "downgraded" …
[Ballot comment]
= Section 3 =

"An LE PHB SHOULD NOT be used for a customer's "normal Internet"
  traffic nor should packets be "downgraded" to the LE PHB instead of
  being dropped, particularly when the packets are unauthorized
  traffic."

I would recommend against mixing normative and non-normative keywords for a sequence of behaviors listed in the same sentence. I can't determine why one of these is normative and the other not.

"There is no intrinsic reason to limit the applicability of the LE PHB
  to any particular application or type of traffic."

I get the idea of not wanting to imply any kind of limitation, but wouldn't use cases of applying this to real-time traffic be pretty rare? That seems like a caveat worth explaining.

= Section 15 =

RFC 8174 should be a normative reference.
2019-02-20
09 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-02-20
09 Alexey Melnikov
[Ballot comment]
Thank you for a well written document.

I only have one nit about the document title:

  A Lower Effort Per-Hop Behavior (LE …
[Ballot comment]
Thank you for a well written document.

I only have one nit about the document title:

  A Lower Effort Per-Hop Behavior (LE PHB)

Please use a better title that makes it clearer to readers what are you talking about. Looking at RFC 3662 I see:

  A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services

I think the part "for Differentiated Services" would be very helpful.
2019-02-20
09 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2019-02-20
09 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2019-02-20
09 Ben Campbell
[Ballot discuss]
Thanks for this effort. The draft appears to be in good shape overall; I just have one process point I would like to …
[Ballot discuss]
Thanks for this effort. The draft appears to be in good shape overall; I just have one process point I would like to DISCUSS before approval:

Section 12 appears to be an update to draft-ietf-tsvwg-rtcweb-qos, which is currently in the RFC Editor queue in the MISSREF state. It's not clear to me what the intent of this section is, but if the idea is to formally update a _draft_, then please do not do that. The right way to proceed would be to pull draft-ietf-tsvwg-rtcweb-qos from the RFC editor queue and make the changes there.

The UPDATES relationship is intended for updating RFCs, which are otherwise immutable. Drafts, even post-IESG approval and in the RFC editor queue can still be changed. Making readers figure out the update between two different RFCs when there is an option to just fix the draft would be a disservice to readers.
2019-02-20
09 Ben Campbell [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell
2019-02-20
09 Warren Kumari
[Ballot discuss]
I believe that this should be trivial DISCUSS to address, but I thought it important enough to warrant it. I'm OK with basically …
[Ballot discuss]
I believe that this should be trivial DISCUSS to address, but I thought it important enough to warrant it. I'm OK with basically whatever you answer, I just wanted to make sure this had been seen and considered.

"An LE PHB SHOULD NOT be used for a customer’s "normal Internet"
  traffic nor should packets be "downgraded" to the LE PHB instead of
  being dropped, particularly when the packets are unauthorized
  traffic.  "

Great, sounds good to me -- but in the USA at least, there is are many cell phone plans which are "unlimited", but after some amount of traffic (e.g 22GB) your connection gets throttled to a lower data rate. Is this traffic still 'a customer's "normal Internet" traffic"? Is it appropriate (whatever that means) to downgrade this traffic to the LE PHB?
I understand not wanting to touch this issue with  a 10 foot pole (and I don't know what the right answer is!), but you *did* open this can of worms by talking about what classification user traffic should have.

Note: I'm happy to clear my DISCUSS no matter what the answer is, I just want to make sure it has been considered / discussed.
2019-02-20
09 Warren Kumari
[Ballot comment]
Major:
"Some network providers keep link utilization below 50% to ensure that all traffic is forwarded without loss after rerouting caused by a …
[Ballot comment]
Major:
"Some network providers keep link utilization below 50% to ensure that all traffic is forwarded without loss after rerouting caused by a link failure (cf.Section 6 of [RFC3439]).  LE marked traffic can utilize the normally unused capacity and will be preempted automatically in case of link failure when 100% of the link capacity is required for all other traffic. "
Yup - very true. But I think it needs to be mentioned that the provider will need to upgrade their monitoring / management system so that they can see the traffic lass. If they monitoring circuit utilization using e.g interface counters (and not by traffic class), a link may have 1% "real" traffic and 90% LE traffic, and it will look like it it 91% "full". I don't have any suggested text to address this (and this is just a comment, so "well, duh, they should know that anyway!" is a fine answer.)


Nits:
"A main problem is that multicast" -- I'm not sure you can say "A main" - main implies singular.; I'd suggest "The main" or "A major".

"However,using the Lower Effort PHB for multicast requires to pay special" -- "requires paying"...
2019-02-20
09 Warren Kumari [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari
2019-02-19
09 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2019-02-19
09 Mirja Kühlewind
[Ballot comment]
Two mostly editorial comments:

1) In sec 3: "nor should packets be "downgraded" to the LE PHB  instead of being dropped"
I would …
[Ballot comment]
Two mostly editorial comments:

1) In sec 3: "nor should packets be "downgraded" to the LE PHB  instead of being dropped"
I would suggest to use proper normative language here, e.g. "and packets SHOULD NOT be "downgraded" to the LE PHB instead of being dropped".

2) I would recommend to add a reference to rfc8087 at the end of section 4.
2019-02-19
09 Mirja Kühlewind [Ballot Position Update] New position, Yes, has been recorded for Mirja Kühlewind
2019-02-17
09 Benjamin Kaduk
[Ballot comment]
This document is generally in fine shape, and has some good discussion
in it.  I basically just have some editorial suggestions.

As one …
[Ballot 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.
2019-02-17
09 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2019-02-17
09 Spencer Dawkins IESG state changed to IESG Evaluation from Waiting for Writeup
2019-02-15
09 Spencer Dawkins RFC Editor Note was changed
2019-02-15
09 Spencer Dawkins RFC Editor Note was changed
2019-02-15
09 Spencer Dawkins RFC Editor Note for ballot was generated
2019-02-15
09 Spencer Dawkins RFC Editor Note for ballot was generated
2019-02-15
09 Spencer Dawkins Ballot has been issued
2019-02-15
09 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2019-02-15
09 Spencer Dawkins Created "Approve" ballot
2019-02-15
09 Spencer Dawkins Ballot writeup was changed
2019-02-15
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-02-15
09 Roland Bless New version available: draft-ietf-tsvwg-le-phb-09.txt
2019-02-15
09 (System) New version approved
2019-02-15
09 (System) Request for posting confirmation emailed to previous authors: Roland Bless
2019-02-15
09 Roland Bless Uploaded new revision
2019-02-12
08 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-02-11
08 Kyle Rose Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Kyle Rose. Sent review to list.
2019-02-11
08 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2019-02-11
08 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tsvwg-le-phb-07. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tsvwg-le-phb-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Differentiated Services Field Codepoints (DSCP) registry located at:

https://www.iana.org/assignments/dscp-registry/

a single, new registration from Pool 3, as follows:

Name: LE
Value (Binary): 000001
Value (Decimal): 1
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-02-09
08 Olivier Bonaventure Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Olivier Bonaventure. Sent review to list.
2019-02-07
08 Amy Vezza Placed on agenda for telechat - 2019-02-21
2019-02-05
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2019-02-05
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2019-02-01
08 Brian Carpenter Request for Last Call review by GENART Completed: Ready. Reviewer: Brian Carpenter. Sent review to list.
2019-01-31
08 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2019-01-31
08 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2019-01-31
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Kyle Rose
2019-01-31
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Kyle Rose
2019-01-30
08 Roland Bless New version available: draft-ietf-tsvwg-le-phb-08.txt
2019-01-30
08 (System) New version approved
2019-01-30
08 (System) Request for posting confirmation emailed to previous authors: Roland Bless
2019-01-30
08 Roland Bless Uploaded new revision
2019-01-30
07 Magnus Westerlund Request for Last Call review by TSVART is assigned to Olivier Bonaventure
2019-01-30
07 Magnus Westerlund Request for Last Call review by TSVART is assigned to Olivier Bonaventure
2019-01-29
07 Amy Vezza IANA Review state changed to IANA - Review Needed
2019-01-29
07 Amy Vezza
The following Last Call announcement was sent out (ends 2019-02-12):

From: The IESG
To: IETF-Announce
CC: tsvwg@ietf.org, draft-ietf-tsvwg-le-phb@ietf.org, david.black@dell.com, tsvwg-chairs@ietf.org, David …
The following Last Call announcement was sent out (ends 2019-02-12):

From: The IESG
To: IETF-Announce
CC: tsvwg@ietf.org, draft-ietf-tsvwg-le-phb@ietf.org, david.black@dell.com, tsvwg-chairs@ietf.org, David Black , spencerdawkins.ietf@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Lower Effort Per-Hop Behavior (LE PHB)) to Proposed Standard


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



2019-01-29
07 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2019-01-29
07 Spencer Dawkins Last call was requested
2019-01-29
07 Spencer Dawkins Last call announcement was generated
2019-01-29
07 Spencer Dawkins Ballot approval text was generated
2019-01-29
07 Spencer Dawkins Ballot writeup was generated
2019-01-29
07 Spencer Dawkins IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2019-01-20
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-01-20
07 Roland Bless New version available: draft-ietf-tsvwg-le-phb-07.txt
2019-01-20
07 (System) New version approved
2019-01-20
07 (System) Request for posting confirmation emailed to previous authors: Roland Bless
2019-01-20
07 Roland Bless Uploaded new revision
2018-12-21
06 Spencer Dawkins IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2018-12-14
06 Spencer Dawkins IESG state changed to AD Evaluation from Publication Requested
2018-11-09
06 David Black
Document shepherd write-up:

                A Lower Effort Per-Hop Behavior (LE PHB)
              …
Document shepherd write-up:

                A Lower Effort Per-Hop Behavior (LE PHB)
                      draft-ietf-tsvwg-le-phb-06
1. Summary

Document Shepherd: David Black
Responsible AD: Spencer Dawkins

  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.

When Diffserv was originally designed, interest in less-than-best effort
(aka scavenger) forwarding behavior eventually resulted in publication of
RFC 3662 which specified the Diffserv Lower Effort (LE) PHB/PDB.

In 20/20 hindsight, RFC 3662 had a number of drawbacks, as it was not
a full PHB specification and in particular did not recommend a default
DSCP (Diffserv Codepoint) for Lower Effort traffic.  The default DSCP
recommendation eventually occurred in practice as a side effect of
publishing RFC 4594 on Diffserv Service Classes.  The recommended
DSCP, CS1, has turned out to be problematic in practice - e.g., see the
discussion of CS1 in RFC 7657 on Diffserv interaction with real time
communication.

This draft cleans up the LE PHB situation by providing a full PHB
specification of the Lower Effort PHB that obsoletes RFC 3662 and
recommends a newly chosen default DSCP, 000001, which is expected to
avoid the problems encountered with CS1 and provide a solid Diffserv
specification for lower effort/less-than-best-effort/scavenger traffic.
Proposed Standard is appropriate for this document in support of
consistent deployment of the updated LE PHB as part of Diffserv.

2. Review and Consensus

The Transport Area WG (tsvwg) is a collection of people with varied
interests that don't individually justify their own working groups.

Specifying the Lower Effort PHB was relatively straightforward in
the WG.  In contrast, determining which DSCP to recommend as the
default for that PHB was not.  The underlying problem is that a
non-negligible amount of deployed Internet equipment "bleaches"
the three most significant bits of the DSCP field in IP headers to
zero, even though that violates Diffserv requirements.  This made
it problematic to use the initially suggested 000010 value, as that
value can and does result from this three-bit bleaching of DSCP
values for higher priority traffic that should not be forwarded
as lower effort (LE) traffic.

After much discussion and evaluation of measurement results on Internet
traffic in both TSVWG and MAPRG, the TSVWG working group chose 000001
value as the recommended default DSCP.  This decision necessitated
publication of RFC 8436 to change the IANA procedures for managing the
DSCP registry so that this DSCP value 000001 could be assigned as the
default DSCP for the LE PHB in this document.

This draft is supported by the portion of the tsvwg working group that
is familiar with and interested in Diffserv.  The draft has received
significant review and critique from a number of Diffserv experts,
including the draft shepherd and Brian Carpenter who was one of the
original chairs of the Diffserv WG.  There is clear consensus in the
TSVWG WG on the need to update the LE PHB specification to replace
and obsolete RFC 3662.

3. Intellectual Property

The draft author has stated his direct, personal knowledge that any
IPR related to this document has already been disclosed, in conformance
with BCPs 78 and 79.

4. Other Points

The shepherd has checked the IANA Considerations.

idnits generated a number of comments that don't reflect actual problems,
plus three warnings about missing references and a Downref complaint.

The three warnings about missing references are all in quoted text
(existing or updated) for other documents - in each case the document
involved contains the necessary reference, so the warnings can be ignored.

This document contains a Downref to RFC 2475 on Diffserv Architecture.
In the shepherd's considered opinion, this Downref is justified because
an understanding of RFC 2475 is necessary to understand this document,
and RFC 2475's security considerations are explicitly referenced by
this document's security considerations.  That Downref will need to
be noted in the IETF Last Call announcement.

2018-11-09
06 David Black Responsible AD changed to Spencer Dawkins
2018-11-09
06 David Black IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2018-11-09
06 David Black IESG state changed to Publication Requested
2018-11-09
06 David Black IESG process started in state Publication Requested
2018-11-09
06 David Black Changed document writeup
2018-11-09
06 David Black Changed consensus to Yes from Unknown
2018-11-09
06 David Black Intended Status changed to Proposed Standard from None
2018-11-09
06 David Black Changed document writeup
2018-11-09
06 David Black Changed document writeup
2018-11-08
06 David Black IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2018-10-11
06 Roland Bless New version available: draft-ietf-tsvwg-le-phb-06.txt
2018-10-11
06 (System) New version approved
2018-10-11
06 (System) Request for posting confirmation emailed to previous authors: Roland Bless
2018-10-11
06 Roland Bless Uploaded new revision
2018-07-19
05 David Black Added to session: IETF-102: tsvwg  Thu-1550
2018-07-02
05 Roland Bless New version available: draft-ietf-tsvwg-le-phb-05.txt
2018-07-02
05 (System) New version approved
2018-07-02
05 (System) Request for posting confirmation emailed to previous authors: Roland Bless
2018-07-02
05 Roland Bless Uploaded new revision
2018-05-31
04 David Black IETF WG state changed to In WG Last Call from WG Document
2018-03-21
04 Gorry Fairhurst Added to session: IETF-101: tsvwg  Thu-1550
2018-03-05
04 Roland Bless New version available: draft-ietf-tsvwg-le-phb-04.txt
2018-03-05
04 (System) New version approved
2018-03-05
04 (System) Request for posting confirmation emailed to previous authors: Roland Bless
2018-03-05
04 Roland Bless Uploaded new revision
2018-02-05
03 Roland Bless New version available: draft-ietf-tsvwg-le-phb-03.txt
2018-02-05
03 (System) New version approved
2018-02-05
03 (System) Request for posting confirmation emailed to previous authors: Roland Bless
2018-02-05
03 Roland Bless Uploaded new revision
2018-01-01
02 (System) Document has expired
2017-07-18
02 David Black Added to session: IETF-99: tsvwg  Tue-1330
2017-06-30
02 Roland Bless New version available: draft-ietf-tsvwg-le-phb-02.txt
2017-06-30
02 (System) New version approved
2017-06-30
02 (System) Request for posting confirmation emailed to previous authors: Roland Bless
2017-06-30
02 Roland Bless Uploaded new revision
2017-02-06
01 Roland Bless New version available: draft-ietf-tsvwg-le-phb-01.txt
2017-02-06
01 (System) New version approved
2017-02-06
01 (System) Request for posting confirmation emailed to previous authors: "Roland Bless"
2017-02-06
01 Roland Bless Uploaded new revision
2016-11-23
00 David Black Added to session: IETF-97: tsvwg  Tue-1330
2016-11-22
00 David Black Notification list changed to "David Black" <david.black@dell.com>
2016-11-22
00 David Black Document shepherd changed to David L. Black
2016-11-14
00 (System) This document now replaces draft-bless-tsvwg-le-phb instead of None
2016-11-14
00 Roland Bless New version available: draft-ietf-tsvwg-le-phb-00.txt
2016-11-14
00 (System) New version approved
2016-11-14
00 Roland Bless Request for posting confirmation emailed  to submitter and authors: "Roland Bless"
2016-11-14
00 Roland Bless Uploaded new revision