Re: [tsvwg] Mirja Kühlewind's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)

["C. M. Heard" <[e-mail]>]

On Tue, Apr 18, 2017 at 11:49 PM, Mirja Kuehlewind (IETF) wrote:
> Yes and no. Of course if ECN is not supported, packet should not be
> ECN marked. However, the IP layer might actually not know if is
> supported or not (e.g. a UDP based protocol that is implemented in
> user-spaces that uses ECN) and therefore my thinking is that it should
> reassemble the ECN field correctly if ECN was set not matter what.

A packet will not be ECN marked (i.e., will contain the not-ECT
codepoint) if the **source flow** does not support ECN. That has
nothing to do with whether the **destination node** supports ECN.

If any of the transport protocols in the destination node are to
support ECN in conformance with RFC 3168 -- including, of course,
UDP-based protocols implemented in user space -- then of course the
IPv6 module in that node must implement fragment reassembly in
accordance with RFC 3168. No argument there. In that case the node
would "support Explicit Congestion Notification [RFC3168]" and,
under the text proposed by Bob Hinden (as modified by David Black),
would "use information in the Traffic Class field from all fragment
packets to reconstruct the Traffic Class field in the reassembled
packet" as specified in RFC 3168 Section 5.3.

You seem to want the requirements of RFC 3168 Section 5.3 to apply
to **all** IPv6 stacks, even those in nodes that have no ECN-capable
transport modules. That might be a good thing for implementors to do
in order to to ensure future extensibility, but those requirements are
not part of RFC 2460 and so are out of scope for 2460bis, if it is to
be eligible for Internet Standard status. In order to insist that those
requirements go into 2460bis you would need to prove that there is an
essential technical omission without them, and I don't think you can
make that case. If you are able to make that case, the implication
would be that 2460 does not meet the requirements for promotion to IS.

Mike Heard

>> Am 19.04.2017 um 05:04 schrieb C. M. Heard <[e-mail]>:
>>
>> On Tue, Apr 18, 2017 at 12:42 PM, Mirja Kuehlewind (IETF) wrote:
>>> sorry but this is wrong… if the actually sender indicates ECN support,
>>> the reassembled packet should also do that correctly, no matter if
>>> the nodes support ECN or not. Handling these fields correctly with
>>> fragmentation does not mean that the nodes supports ECN. So this is
>>> not optional…
>>
>> This seems confused (or else I am confused). We are discussing issues
>> related to reassembly of fragmented packets, and that is a process that
>> takes place in end systems only, not in forwarding nodes.
>>
>> It is true that if an end system (aka host) supports ECN per RFC 3168,
>> then received packets that it reassembles must have the CE bit pattern
>> set if any fragment has the CE bit pattern set, provided that all
>> fragments contain either CE or ECT(0)/ECT(1). The text that we are
>> working on is intended to say that -- indirectly, by referring to the
>> Section 5.3 of RFC 3168.
>>
>> But, unless ECN is mandatory-to-implement for all IPv6 nodes, end
>> systems are not obliged to support it -- and I see no such mandate
>> in the IPv6 node requirements document. In that case ECN indications
>> will simply be ignored. No purpose is served by levying a requirement
>> on the IPv6 module to preserve an indication that will not be used.
>>
>> Mike Heard
>>
>