Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field
RFC 4774
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14 |
02 | (System) | Notify list changed from floyd@icir.org, tsvwg-chairs@ietf.org to (None) |
2012-08-22 |
02 | (System) | post-migration administrative database adjustment to the Yes position for Jari Arkko |
2012-08-22 |
02 | (System) | post-migration administrative database adjustment to the Yes position for Sam Hartman |
2012-08-22 |
02 | (System) | post-migration administrative database adjustment to the No Objection position for Mark Townsley |
2012-08-22 |
02 | (System) | post-migration administrative database adjustment to the No Objection position for Ross Callon |
2006-12-05 |
02 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2006-12-05 |
02 | Amy Vezza | [Note]: 'RFC 4774 BCP 124' added by Amy Vezza |
2006-11-28 |
02 | (System) | RFC published |
2006-11-08 |
02 | (System) | Request for Early review by SECDIR is assigned to Hilarie Orman |
2006-11-08 |
02 | (System) | Request for Early review by SECDIR is assigned to Hilarie Orman |
2006-09-24 |
02 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2006-09-14 |
02 | Amy Vezza | IESG state changed to Approved-announcement sent |
2006-09-14 |
02 | Amy Vezza | IESG has approved the document |
2006-09-14 |
02 | Amy Vezza | Closed "Approve" ballot |
2006-09-14 |
02 | Lars Eggert | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Lars Eggert |
2006-09-14 |
02 | Lars Eggert | All DISCUSSES cleared on -02. |
2006-09-14 |
02 | Mark Townsley | [Ballot Position Update] Position for Mark Townsley has been changed to No Objection from Discuss by Mark Townsley |
2006-09-13 |
02 | Ross Callon | [Ballot Position Update] Position for Ross Callon has been changed to No Objection from Discuss by Ross Callon |
2006-09-13 |
02 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2006-09-13 |
02 | (System) | New version available: draft-ietf-tsvwg-ecn-alternates-02.txt |
2006-09-12 |
02 | Lars Eggert | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Lars Eggert |
2006-09-12 |
02 | Lars Eggert | Sally to update the document to address IESG DISCUSSes and incorporate current RFC Editor Note. |
2006-09-01 |
02 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko |
2006-09-01 |
02 | (System) | Removed from agenda for telechat - 2006-08-31 |
2006-08-31 |
02 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2006-08-31 |
02 | Ross Callon | [Ballot discuss] This document is quite scary, which I think is good: The idea of having several different semantics for the ECN fields in the ... [Ballot discuss] This document is quite scary, which I think is good: The idea of having several different semantics for the ECN fields in the IP header *should* be scary. That said, I think that a bit more discussion is needed regarding the implications on router implementations of having multiple ways to use the ECN fields (which may make the document even scarier). In particular, there is a huge base of installed routers in the world, and updating these to support new forwarding details is a huge and potentially enormously expensive undertaking. For some existing routers, it would require hardware upgrade to update them (possibly with new ASICs, which is inherently a slow thing to update in deployed products). Some existing routers might be able to support the new forwarding details without significant degradation in performance. Some might be able to support it, but with a degradation in performance (which could range from trivial to catastrophic). We should expect that any significant change in the forwarding plane would take many years and at least many millions of dollars (perhaps hundreds of millions in total?) to get universally deployed. I also agree with Mark's discuss comment about the fact that using an IP option could also have serious performance implications. |
2006-08-31 |
02 | Ross Callon | [Ballot Position Update] New position, Discuss, has been recorded by Ross Callon |
2006-08-31 |
02 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2006-08-31 |
02 | Sam Hartman | [Ballot Position Update] Position for Sam Hartman has been changed to Yes from Discuss by Sam Hartman |
2006-08-31 |
02 | Mark Townsley | [Ballot comment] With statements like: This document doesn't comment on whether a mechanism would be required to ensure that ... [Ballot comment] With statements like: This document doesn't comment on whether a mechanism would be required to ensure that the alternate-ECN semantics would not be let loose on the global Internet. This document also doesn't comment on the chances that this scenario would be considered acceptable for standardization by the IETF community. This document, at best, should be Informational or Experimental. I think statements like this are well in violation of principals in BCP 61 also. This is not part of my discuss only because Sam is holding a similar discuss for this. Grammer nit: Section 4.1 s/don't/doesn't |
2006-08-31 |
02 | Mark Townsley | [Ballot discuss] Section 4.2: "As an example, such a mechanism could consist of a field in an IP option that all routers along the path ... [Ballot discuss] Section 4.2: "As an example, such a mechanism could consist of a field in an IP option that all routers along the path decrement if they agree to use the alternate ECN semantics with this traffic." This is nice in theory, but most forwarding hardware in the Internet is optimized for IP packets with no options (or in some very enlightened implementations, fast processing of some very well-known and simple options). Recommendation of any new IP option processing by routers must be VERY carefully considered, as today this likely means immediate punting to a slow path (if not outright dropping, particularly if the set of packets with IP options becomes the source of a DOS attack on the CPU). I suggest at the very least more substantial warning against this particular alternative. |
2006-08-31 |
02 | Mark Townsley | [Ballot Position Update] New position, Discuss, has been recorded by Mark Townsley |
2006-08-31 |
02 | Mark Townsley | [Ballot comment] With statements like: This document doesn't comment on whether a mechanism would be required to ensure that ... [Ballot comment] With statements like: This document doesn't comment on whether a mechanism would be required to ensure that the alternate-ECN semantics would not be let loose on the global Internet. This document also doesn't comment on the chances that this scenario would be considered acceptable for standardization by the IETF community. This document, at best, should be Informational or Experimental. I think statements like this are well in violation of principals in BCP 61 as well. This is not a discuss only because Sam is holding a similar discuss. Grammer nit: Section 4.1 s/don't/doesn't |
2006-08-31 |
02 | Jari Arkko | [Ballot discuss] This Discuss is really a question, and I expect that the answer quickly resolves the Discuss. The document discusses the implications of alternate ... [Ballot discuss] This Discuss is really a question, and I expect that the answer quickly resolves the Discuss. The document discusses the implications of alternate semantics for the ECN bits and processing. I recall that IPsec (RFC 4301) has some specific rules about how to deal with ECN. Its possible that there are other tunnel technologies that do the same. Would the alternate semantics affect the processing in the context of IPsec or other tunneling? If not, there's no problem. If yes, perhaps you should add another issue that the designers of alternate semantics should consider. |
2006-08-31 |
02 | Jari Arkko | [Ballot comment] |
2006-08-31 |
02 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2006-08-31 |
02 | Jari Arkko | [Ballot comment] A question. The document discusses the implications of alternate semantics for the ECN bits and processing. I recall that IPsec (RFC 4301) has ... [Ballot comment] A question. The document discusses the implications of alternate semantics for the ECN bits and processing. I recall that IPsec (RFC 4301) has some specific rules about how to deal with ECN. Its possible that there are other tunnel technologies that do the same. Would the alternate semantics affect the processing in the context of IPsec or other tunneling? If not, please ignore this comment. If yes, perhaps you should add another issue that the designers of alternate semantics should consider. |
2006-08-31 |
02 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2006-08-31 |
02 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded by David Kessens |
2006-08-30 |
02 | Bill Fenner | [Ballot Position Update] Position for Bill Fenner has been changed to No Objection from Undefined by Bill Fenner |
2006-08-30 |
02 | Ted Hardie | [Ballot comment] So, my reading of the BCP here is "Think about these issues before mucking with ECN alternate semantics". I'm a shrug as to ... [Ballot comment] So, my reading of the BCP here is "Think about these issues before mucking with ECN alternate semantics". I'm a shrug as to whether that is a BCP, but I can see the confusion. |
2006-08-30 |
02 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded by Ted Hardie |
2006-08-30 |
02 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2006-08-30 |
02 | Cullen Jennings | [Ballot comment] I think this should be informational not BCP. |
2006-08-30 |
02 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2006-08-30 |
02 | Magnus Westerlund | [Ballot Position Update] New position, Yes, has been recorded by Magnus Westerlund |
2006-08-29 |
02 | Sam Hartman | [Ballot discuss] How is this a BCP? What requirements does it place? It seems much more an informational analysis document. I think a BCP would ... [Ballot discuss] How is this a BCP? What requirements does it place? It seems much more an informational analysis document. I think a BCP would be useful, but I don't think this document actually fills that role. |
2006-08-29 |
02 | Sam Hartman | [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman |
2006-08-28 |
02 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2006-08-28 |
02 | Brian Carpenter | [Ballot comment] Change to caption agreed by author after Gen-ART review: OLD: Figure 1: Alternate-ECN traffic, an old router using RFC-3168 ECN. NEW: ... [Ballot comment] Change to caption agreed by author after Gen-ART review: OLD: Figure 1: Alternate-ECN traffic, an old router using RFC-3168 ECN. NEW: Figure 1: Alternate-ECN traffic, an old router, using RFC-3168 ECN, that is congested and ready to drop or mark the arriving packet. |
2006-08-28 |
02 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter |
2006-08-16 |
02 | Yoshiko Fong | IANA Last Call Comment: As described iin the IANA Considerations section, we understand this document to have no IANA Actions. |
2006-08-15 |
02 | Lars Eggert | Placed on agenda for telechat - 2006-08-31 by Lars Eggert |
2006-08-15 |
02 | Lars Eggert | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Lars Eggert |
2006-08-15 |
02 | Lars Eggert | State Changes to Waiting for AD Go-Ahead from Waiting for Writeup by Lars Eggert |
2006-08-15 |
02 | Lars Eggert | [Ballot Position Update] New position, Yes, has been recorded for Lars Eggert |
2006-08-15 |
02 | Lars Eggert | Ballot has been issued by Lars Eggert |
2006-08-15 |
02 | Lars Eggert | Created "Approve" ballot |
2006-08-14 |
02 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2006-07-31 |
02 | Amy Vezza | Last call sent |
2006-07-31 |
02 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2006-07-29 |
02 | Lars Eggert | Last Call was requested by Lars Eggert |
2006-07-29 |
02 | (System) | Ballot writeup text was added |
2006-07-29 |
02 | (System) | Last call text was added |
2006-07-29 |
02 | (System) | Ballot approval text was added |
2006-07-29 |
02 | Lars Eggert | State Changes to Last Call Requested from AD Evaluation::AD Followup by Lars Eggert |
2006-07-28 |
02 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2006-07-28 |
01 | (System) | New version available: draft-ietf-tsvwg-ecn-alternates-01.txt |
2006-07-26 |
02 | Lars Eggert | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Lars Eggert |
2006-07-25 |
02 | Lars Eggert | State Changes to AD Evaluation from Publication Requested by Lars Eggert |
2006-07-21 |
02 | Lars Eggert | State Change Notice email list have been change to floyd@icir.org, tsvwg-chairs@tools.ietf.org from floyd@icir.org, jmpolk@cisco.com, jon.peterson@neustar.biz, jon@unreason.com, magnus.westerlund@ericsson.com, jmpolk@cisco.com |
2006-07-21 |
02 | Lars Eggert | [Note]: 'PROTO Shepherd: James Polk (jmpolk@cisco.com)' added by Lars Eggert |
2006-07-21 |
02 | Dinara Suleymanova | PROTO Write-up 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready ... PROTO Write-up 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Which chair is the WG Chair Shepherd for this document? Yes, Shepherd is James Polk (jmpolk@cisco.com), TSVWG co-chair 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes. no concerns 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, internationalization, XML, etc.)? No. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No. 1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is solid WG consensus backing this document's progression. . 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email to the Responsible Area Director. (It should be separate email because this questionnaire will be entered into the tracker). No appeal threats have been raised, nor have there been any extreme discontent wrt this document. 1.g) Have the chairs verified that the document checks out against all the ID nits? (see http://www.ietf.org/ID-Checklist.html). Boilerplate checks are not enough; this check needs to be thorough. Yes, there are zero nits. 1.h) Has the document split its references into normative and informative? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? The RFC Editor will not publish an RFC with normative references to IDs (will delay the publication until all such IDs are also ready for RFC publication). If the normative references are behind, what is the strategy for their completion? On a related matter, are there normative references that are downward references, as described in BCP 97, RFC 3967 RFC 3967 [RFC3967]? Listing these supports the Area Director in the Last Call downref procedure specified in RFC 3967. References split. There are no normative references in this draft. 1.i) For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary This document discusses how alternate semantics of the ECN field can co-exist where not all routers in a network are configured for a single interpretation of codepoints. Also discussed are the issues raised by nodes, including endsystems, configured for alternate-ECN usages. This document can be used as a means of migration from one alternate-ECN to another, where not all nodes can be configured to change at the same time. Additionally, means for a node (router) to determine which alternate to use with which packet is specified. And finally, this document discusses how well alternate-ECN traffic performs where it co-exists with competing traffic on a path. * Working Group Summary There is strong consensus in the WG to publish this document. It has been reviewed by several people prior to the WG last call. Comments raised earlier have all been addressed. There are no outstanding open issues wrt this document. * Protocol Quality This document has been well reviewed in the WG and comments raised have been addressed. Cheers, James IETF TSVWG co-chair |
2006-07-21 |
02 | Dinara Suleymanova | State Changes to Publication Requested from AD is watching by Dinara Suleymanova |
2006-07-21 |
02 | Dinara Suleymanova | Shepherding AD has been changed to Lars Eggert from Magnus Westerlund |
2006-04-03 |
02 | Magnus Westerlund | Shepherding AD has been changed to Magnus Westerlund from Allison Mankin |
2006-02-28 |
02 | Allison Mankin | State Change Notice email list have been change to floyd@icir.org, jmpolk@cisco.com, jon.peterson@neustar.biz, jon@unreason.com, magnus.westerlund@ericsson.com, jmpolk@cisco.com from mankin@psg.com, jmpolk@cisco.com, jon.peterson@neustar.biz, jon@unreason.com |
2006-02-28 |
02 | Allison Mankin | [Note]: 'Entered WGLC - to end 15 March 2006 PROTO shepherd James Polk jmpolk@cisco.com' added by Allison Mankin |
2006-02-10 |
02 | Allison Mankin | We are starting a WGLC as agreed in Vancouver |
2006-02-10 |
02 | Allison Mankin | Draft Added by Allison Mankin in state AD is watching |
2006-01-17 |
00 | (System) | New version available: draft-ietf-tsvwg-ecn-alternates-00.txt |