Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field
RFC 4774

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

[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

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

[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

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

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

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

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

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

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

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