Subject: [tsvwg] [Editorial Errata Reported] RFC3168 (3636)

From: RFC Errata System <[email-masked]>
Date: Tue, 4 Jun 2013 06:30:09 -0700 (PDT)

The following errata report has been submitted for RFC3168,
"The Addition of Explicit Congestion Notification (ECN) to IP".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3168&eid=3636

--------------------------------------
Type: Editorial
Reported by: Mirja Kühlewind <[email-masked]>

Section: 6.1.1.

Original Text
-------------
If the TCP connection does not
   wish to use ECN notification for a particular packet, the sending TCP
   sets the ECN codepoint to not-ECT, and the TCP receiver ignores the
   CE codepoint in the received packet.

Corrected Text
--------------
If the TCP connection does not
   wish to use ECN notification for a particular packet, the sending TCP
   sets the ECN codepoint to not-ECT.

Notes
-----
CE should not be set on not-ECT capable packets. If this happens anyway, the CE codepoint would overwrite the ECT codepoint. Thus there is no way for the receiver to know it should ignore the CE codepoint; the sentence is therefore nonsensical.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC3168 (draft-ietf-tsvwg-ecn-04)
--------------------------------------
Title               : The Addition of Explicit Congestion Notification (ECN) to IP
Publication Date    : September 2001
Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
Category            : PROPOSED STANDARD
Source              : Transport Area Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: "Black, David" <[email-masked]>
Date: Tue, 4 Jun 2013 09:49:48 -0400

While the basic facts are correct, specifically that the receiver cannot
determine whether CE has been erroneously set on a not-ECT-marked packet,
I don't think this errata should be applied.

The original sentence was intended to refer to independent actions by
the sender and receiver, and was not supposed to imply that the receiver
would ignore a received CE marking as a consequence of a not-ECT being
applied by the sender.

The following editorial clarification would improve the text (add
"endpoint", and insert the word "independently"):

Original Text
-------------

Corrected Text
--------------
If either endpoint of the TCP connection does not
   wish to use ECN notification for a particular packet, the sending TCP
   sets the ECN codepoint to not-ECT, and the TCP receiver independently
   ignores a CE codepoint in the received packet.

Thanks,
--David

> -----Original Message-----
> From: RFC Errata System [mailto:[email-masked]]
> Sent: Tuesday, June 04, 2013 9:30 AM
> To: [email-masked]; [email-masked]; Black, David;
> [email-masked]; [email-masked];
> [email-masked]; Black, David; [email-masked]
> Cc: [email-masked]; [email-masked]; rfc-editor@rfc-
> editor.org
> Subject: [Editorial Errata Reported] RFC3168 (3636)
> 
> CE should not be set on not-ECT capable packets. If this happens anyway, the
> CE codepoint would overwrite the ECT codepoint. Thus there is no way for the
> receiver to know it should ignore the CE codepoint; the sentence is therefore
> nonsensical.
> 
> Instructions:
> -------------

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 4 Jun 2013 16:21:58 +0200

That means the sentence should say that an ECN receiver can choose for every 
received CE to ignore it? What's the sense behind this? (Maybe this is a 
technical erratum then, as e.g. ECN Nonce was designed to prevent exactly 
this behavior.)

If not, the sentence is still not very clear. Maybe splitting it up into two 
sentences would help:

Original Text
-------------

Corrected Text
--------------
If the sending TCP does not
   wish to use ECN notification for a particular packet, it
   sets the ECN codepoint to not-ECT. If the TCP receiver independently does 	
   not wish to use ECN notification for a particular packet, it ignores a CE
   codepoint in the received packet.

Mirja 

On Tuesday 04 June 2013 15:49:48 Black, David wrote:
> > Cc: [email-masked]; [email-masked];
> > rfc-editor@rfc- editor.org
> > CE should not be set on not-ECT capable packets. If this happens anyway,
> > the CE codepoint would overwrite the ECT codepoint. Thus there is no way
> > for the receiver to know it should ignore the CE codepoint; the sentence
> > is therefore nonsensical.
> >
> > Instructions:
> > -------------

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: "Black, David" <[email-masked]>
Date: Tue, 4 Jun 2013 15:00:14 -0400

For more context, here's the entire paragraph that contains the sentence
in question:

6.1.1  TCP Initialization

   In the TCP connection setup phase, the source and destination TCPs
   exchange information about their willingness to use ECN.  Subsequent
   to the completion of this negotiation, the TCP sender sets an ECT
   codepoint in the IP header of data packets to indicate to the network
   that the transport is capable and willing to participate in ECN for
   this packet. This indicates to the routers that they may mark this
   packet with the CE codepoint, if they would like to use that as a
   method of congestion notification. If the TCP connection does not
   wish to use ECN notification for a particular packet, the sending TCP
   sets the ECN codepoint to not-ECT, and the TCP receiver ignores the
   CE codepoint in the received packet.

That's not stating that "an ECN receiver can choose for every received
CE to ignore it" - rather (at least as I read the text), it's stating that
for a small specific fraction of the packets ("particular") the sender and
receiver somehow know or have agreed in advance that ECN is not to be used,
and such packets are sent as not-ECT with CE ignored on receipt.

This is all rather hypothetical, as I agree with Mirja's underlying sense
that once ECN is enabled on a TCP connection, it SHOULD be used with every
packet.  All in all, it may be better to pursue some sort of technical
that as opposed to trying to clean up this text editorially.

It is dangerous for receivers to ignore CE markings if there is any
possibility that the CE marking was applied as a congestion indication,
and the original sentence can be read as allowing that dangerous behavior.
The simplest way out of this may be to re-classify the errata (which
removes the text that refers to that receiver behavior) as technical,
and proceed from there.

Thanks,
--David

> From: Mirja Kuehlewind [mailto:[email-masked]]
> Sent: Tuesday, June 04, 2013 10:22 AM
> To: Black, David
> Cc: RFC Errata System; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Editorial Errata Reported] RFC3168 (3636)
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 5 Jun 2013 10:31:55 +0000

Hi David,

While we are at it - 3168 is also missing another aspect:

The receipt of a CE-marked CWR TCP segment...

In 3168 the exact TCP interaction behavior is not described sufficiently; when I investigated this aspect, I found that all derivatives of BSD used to 

First, set ECE because of CE
Second, reset ECE because of CWR

While the NS2 "sample" code, Sally's TBIT tool, Windows, Solaris and Linux would

First, reset ECE because of CWR
Second, set ECE because of CE.

It appeared to be, that the latter approach is the sensible one, and it was quickly fixed.

http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039450.html

I guess I'm asking if that clarification should be filed against 3168 to be eventually included in an update?

Best regards,

Richard Scheffenegger

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Black, David
> Sent: Dienstag, 04. Juni 2013 21:00
> To: Mirja Kuehlewind
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; RFC Errata System
> Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (3636)
> 
> That's not stating that "an ECN receiver can choose for every received CE
> to ignore it" - rather (at least as I read the text), it's stating that
> receiver somehow know or have agreed in advance that ECN is not to be
> used, and such packets are sent as not-ECT with CE ignored on receipt.
> 
> removes the text that refers to that receiver behavior) as technical, and
> proceed from there.
> 
> Thanks,
> --David
> 
> > That means the sentence should say that an ECN receiver can choose for
> > every received CE to ignore it? What's the sense behind this? (Maybe
> > this is a technical erratum then, as e.g. ECN Nonce was designed to
> > prevent exactly this behavior.)
> >
> > If not, the sentence is still not very clear. Maybe splitting it up
> > into two sentences would help:
> >
> > Original Text
> > -------------
> > > While the basic facts are correct, specifically that the receiver
> > > cannot determine whether CE has been erroneously set on a
> > > not-ECT-marked packet, I don't think this errata should be applied.
> > >
> > > The original sentence was intended to refer to independent actions
> > > by the sender and receiver, and was not supposed to imply that the
> > > receiver would ignore a received CE marking as a consequence of a
> > > not-ECT being applied by the sender.
> > >
> > > > The following errata report has been submitted for RFC3168, "The
> > > > Addition of Explicit Congestion Notification (ECN) to IP".
> > > >
> > > > CE should not be set on not-ECT capable packets. If this happens
> > > > anyway, the CE codepoint would overwrite the ECT codepoint. Thus
> > > > there is no way for the receiver to know it should ignore the CE
> > > > codepoint; the sentence is therefore nonsensical.
> > > >
> > > > Instructions:
> > > > -------------
> > > > This errata is currently posted as "Reported". If necessary,
> > > > please use "Reply All" to discuss whether it should be verified or
> > > > Title               : The Addition of Explicit Congestion
> Notification
> > > > (ECN) to IP
> > University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart
> >
> > tel: +49(0)711/685-67973

---

From: "Black, David" <[email-masked]>
Date: Wed, 5 Jun 2013 09:39:47 -0400

Yes, filing this as an errata would be a good thing to do.

Thanks,
--David

> From: Scheffenegger, Richard [mailto:[email-masked]]
> Sent: Wednesday, June 05, 2013 6:32 AM
> To: Black, David; Mirja Kuehlewind
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; RFC Errata System
> Subject: RE: [Editorial Errata Reported] RFC3168 (3636)
> 
> Hi David,
> 
> 
> In 3168 the exact TCP interaction behavior is not described sufficiently; when
> I investigated this aspect, I found that all derivatives of BSD used to
>

---

From: Gorry <[email-masked]>
Date: Wed, 5 Jun 2013 15:24:49 +0100

I agree it would be good to propose an Erata, this seems like a small, but significant clarification.

Gorry

Sent from my iPad

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 5 Jun 2013 20:13:06 +0000

Done,

Richard Scheffenegger

> From: Black, David [mailto:[email-masked]]
> Sent: Mittwoch, 05. Juni 2013 15:40
> To: Scheffenegger, Richard; Mirja Kuehlewind
> [email-masked]; [email-masked]; RFC Errata System; Black, David
> > In 3168 the exact TCP interaction behavior is not described
> > sufficiently; when I investigated this aspect, I found that all
> > derivatives of BSD used to
> >
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Black, David
> > > For more context, here's the entire paragraph that contains the
> > > sentence in question:
> > >
> > > 6.1.1  TCP Initialization
> > >
> > > That's not stating that "an ECN receiver can choose for every
> > > received CE to ignore it" - rather (at least as I read the text),
> > > it's stating that for a small specific fraction of the packets
> > > ("particular") the sender and receiver somehow know or have agreed
> > > in advance that ECN is not to be used, and such packets are sent as
> not-ECT with CE ignored on receipt.
> > >
> > > This is all rather hypothetical, as I agree with Mirja's underlying
> > > sense that once ECN is enabled on a TCP connection, it SHOULD be
> > > used with every packet.  All in all, it may be better to pursue some
> > > sort of technical that as opposed to trying to clean up this text
> editorially.
> > >
> > > possibility that the CE marking was applied as a congestion
> > > indication, and the original sentence can be read as allowing that
> dangerous behavior.
> > > removes the text that refers to that receiver behavior) as
> > > technical, and proceed from there.
> > >
> > > Thanks,
> > > --David
> > >
> > > > From: Mirja Kuehlewind
> > > > [mailto:[email-masked]]
> > > > That means the sentence should say that an ECN receiver can choose
> > > > for every received CE to ignore it? What's the sense behind this?
> > > > (Maybe this is a technical erratum then, as e.g. ECN Nonce was
> > > > designed to prevent exactly this behavior.)
> > > >
> > > > If not, the sentence is still not very clear. Maybe splitting it
> > > > up into two sentences would help:
> > > >
> > > > Original Text
> > > > -------------
> > > >    sets the ECN codepoint to not-ECT. If the TCP receiver
> > > > independently
> > > does
> > > >    not wish to use ECN notification for a particular packet, it
> > > > ignores
> > > a CE
> > > > > While the basic facts are correct, specifically that the
> > > > > receiver cannot determine whether CE has been erroneously set on
> > > > > a not-ECT-marked packet, I don't think this errata should be
> applied.
> > > > >
> > > > > The original sentence was intended to refer to independent
> > > > > actions by the sender and receiver, and was not supposed to
> > > > > imply that the receiver would ignore a received CE marking as a
> > > > > consequence of a not-ECT being applied by the sender.
> > > > >
> > > > > The following editorial clarification would improve the text
> > > > > (add "endpoint", and insert the word "independently"):
> > > > >
> > > > > Original Text
> > > > > -------------
> > > > >    wish to use ECN notification for a particular packet, the
> > > > > sending
> > > TCP
> > > > >    wish to use ECN notification for a particular packet, the
> > > > > sending
> > > TCP
> > > > > >    wish to use ECN notification for a particular packet, the
> > > > > > sending
> > > TCP
> > > > > >    sets the ECN codepoint to not-ECT, and the TCP receiver
> > > > > > ignores
> > > the
> > > > > >    wish to use ECN notification for a particular packet, the
> > > > > > sending
> > > TCP
> > > > > > CE should not be set on not-ECT capable packets. If this
> > > > > > happens anyway, the CE codepoint would overwrite the ECT
> > > > > > codepoint. Thus there is no way for the receiver to know it
> > > > > > should ignore the CE codepoint; the sentence is therefore
> nonsensical.
> > > > > >
> > > > > > Instructions:
> > > > > > -------------
> > > > > > please use "Reply All" to discuss whether it should be
> > > > > > verified or rejected. When a decision is reached, the
> > > > > > verifying party (IESG) can log in to change the status and edit
> the report, if necessary.
> > > > > >