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

From: Martin Stiemerling <[email-masked]>
Date: Thu, 11 Jul 2013 12:23:00 +0200

Hi all,

On 06/04/2013 09:00 PM, Black, David wrote:
> 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.

I will reject the errata no. 3636.

Either Mirja or David, or someone else, should submit a new errata. 
Process-wise it is the better way forward.

Thanks,

   Martin

>
> Thanks,
> --David
>
>> -----Original Message-----
>> 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]; [email-masked]; [email-masked]
>> Subject: Re: [Editorial Errata Reported] RFC3168 (3636)
>>
>> 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
>> -------------
>> 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 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:
>>> 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
>>> -------------
>>> 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 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)
>>>>
>>>> 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
>>
>>
>>
>> --
>> -------------------------------------------------------------------
>> 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
>> -------------------------------------------------------------------
>

-- 
[email-masked]

NEC Laboratories Europe
NEC Europe Limited
Registered Office:
Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB
Registered in England 2832014