Subject: [Tsvwg] One more round on the ECN draft

From: Sally Floyd <[email-masked]>
Date: Tue, 27 Feb 2001 11:47:32 -0800

As a result of the IETF Last Call on the ECN draft,
draft-ietf-tsvwg-ecn-01.txt, the IESG has requested that we add a
modification to the draft defining the fourth codepoint in the ECN
field in the IP header to also mean ECN-Capable Transport.  The
motivation for this is to allow the later development of mechanisms
for the data sender to verify that network elements are not erasing
the CE codepoint, and that data receivers are properly reporting
to the sender the receipt of packets with the CE codepoint set, as
required by the transport protocol.

We have essentially finished the revision of the ECN draft, defining
the fourth ECN codepoint as also meaning ECT, and have put the
current version at:
http://www.aciri.org/floyd/papers/draft-ietf-tsvwg-ecn-02.ps
and
http://www.aciri.org/floyd/papers/draft-ietf-tsvwg-ecn-02.txt

We will submit this officially as a draft in a day or two.

In addition to adding the fourth ECN codepoint for the ECN field
in the IP header, we added two other things, as described in the
list of changes on p. 4.  We added a paragraph to Section 5 saying
that by default, the discussion of setting the CE codepoint applies
to all Differentiated Services Per-Hop Behaviors, and we added
Section 5.3 on fragmentation.

I am appending them below, since they were the only changes
we made that were not at the specific suggestion of the IESG.
They both resulted from a long email exchange with Bob Briscoe and
Jon Crowcroft.

My understanding is that after we submit the draft,
it will receive another short one-week Last Call in TSVWG
for feedback.

Many thanks,
- Sally, David, and KK.

-------------------------------------------------------------

Section 5, next to last paragraph:

   The above discussion of when CE may be set instead of dropping a
   packet applies by default to all Differentiated Services Per-Hop
   Behaviors (PHBs) [RFC 2475].  Specifications for PHBs MAY provide
   more specifics on how a compliant implementation is to choose between
   setting CE and dropping a packet, but this is NOT REQUIRED.  A router
   MUST NOT set CE instead of dropping a packet when the drop that would
   occur is caused by reasons other than congestion or the desire to   
   indicate incipient congestion to end nodes (e.g., a diffserv edge
   node may be configured to unconditionally drop certain classes of
   traffic to prevent them from entering its diffserv domain).

--------------------------------------------------------------

5.3.  Fragmentation
     
   All ECN-capable packets SHOULD have the DF (Don't Fragment) bit set.
   Reassembly of a fragmented packet MUST NOT lose indications of
   congestion.  In other words, if any fragment of an IP packet to be  
   reassembled has the CE codepoint set, then one of two actions MUST be
   taken:
      * The reassembled packet has the CE codepoint set.  This MUST NOT
      occur if any of the other fragments contributing to this
      reassembly carries the Not-ECT codepoint.
      * The packet is dropped instead of being reassmembled.
   If both actions are applicable, either MAY be chosen.  Reassembly of
   a fragmented packet MUST NOT change the ECN codepoint when all of the
   fragments carry the same codepoint.
     
   Situations may arise in which the above specification is
   insufficiently precise.  For example, it does not place requirements
   on reassembly of fragments that carry a mixture of ECT(0), ECT(1)
   and/or Not-ECT.  In situations where more precise reassembly behavior
   would be required, protocol specifications SHOULD instead specify
   that DF MUST be set in all packets sent by the protocol.

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg