Subject: [Tsvwg] a clarification about draft-ietf-tsvwg-ecn-ip-00.txt

From: Sally Floyd <[email-masked]>
Date: Wed, 28 Feb 2001 11:44:45 -0800

An announcement was sent to this list recently about a
new internet-draft, "An Open ECN Service in the IP layer",
draft-ietf-tsvwg-ecn-ip-00.txt.  The Introduction of that
draft says the following:

>It is intended to complement the existing Internet Draft on addition
>of ECN to TCP/IP [6] in order to hasten the proposal to the IETF
>standards track. We envisage the current document being absorbed
>into that I-D where agreement is reached on the issues discussed.

This is just to clarify that we (the authors of [6], "The Addition
of Explicit Congestion Notification (ECN) to IP"), have had a long
email exchange with the authors of draft-ietf-tsvwg-ecn-ip-00.txt,
and this has resulting in our adding to our draft the text appended
below (from yesterday's email message to this list about the
upcoming revised version of our draft).  We do not intend to append
any material from draft-ietf-tsvwg-ecn-ip-00.txt to our draft.

- Sally
--------------------------------
http://www.aciri.org/floyd/
--------------------------------

>To: [email-masked]
>cc: "K. K. Ramakrishnan" <[email-masked]>, David Black <[email-masked]>
>From: Sally Floyd <[email-masked]>
>Date: Tue, 27 Feb 2001 11:47:32 -0800
>Subject: [Tsvwg] One more round on the ECN draft
>
>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

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