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 |