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

From: "C. M. Heard" <[email-masked]>
Date: Wed, 19 Apr 2017 09:38:30 -0700

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 <[email-masked]>:
>>
>> 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
>>
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 19 Apr 2017 19:25:06 +0200

Hi Mike,

I think we use the word 'support' differently and that's were the confusion 
comes from. However, see below.

On 19.04.2017 18:38, C. M. Heard wrote:
 > transport modules.

Actually yes, because the IPv6 stack might not know anything about 
ECN-capable transport modules. So the only thing you can do is require it for 
all. But please see further below.

That might be a good thing for implementors to do
 > in order to to ensure future extensibility,

Yes :-)

but those requirements are
 > be eligible for Internet Standard status.

So, yes this is not part of RFC2460 but as you noted correctly RFC3168 should 
have updated RFC2460 and as such this could be incorporated into 2460bis (as 
done with other updates as well). But please see further below.

  In order to insist that those
 > make that case.

Not sure. Losing a congestion notification is a real problem. RFC3168 is 
standards track as well, and as you noted, probably should have updated 
RFC2460. But please see further below.

If you are able to make that case, the implication
 > would be that 2460 does not meet the requirements for promotion to IS.

I guess what we really need to check would be if most IPV6 stacks have 
implemented this behavior. If so it should be fine to add this to 2460bis, if 
not maybe not. But I just don't know...

And now the big BUT...

This is the text I proposed:

"The number and content of the headers preceding the Fragment
header of different fragments of the same original packet may
differ.  Whatever headers are present, preceding the Fragment
header in each fragment packet, are processed when the packets
arrive, prior to queueing the fragments for reassembly.  Only
those headers in the Offset zero fragment packet are retained in
the reassembled packet; however, the Traffic Class field from
any or all fragments may differ. Handling of Explicit
Congestion Notification [RFC3168] is described in Section 5.3 of
RFC 3168, ensuring that reassembly does not lose indications
of congestion."

This text does not make any normative statement on the question if the 
behavior specified in RFC3168 should be implemented or not. It only says 
please look at RFC3168 and make an informed decision if you want to confirm 
to the behavior that is specified in RFC3168 in addition to implementing the 
spec in this document. However, yes, this statement is true for all IPv6 
implementation. I don't see a problem here...

Mirja

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 19 Apr 2017 10:54:42 -0700

> implementation. I don't see a problem here...

Nor do I. As it happens I prefer the text proposed by Bob Hinden (with
David Black's modification) but I believe that the effect is essentially the
same as the text you proposed. So it seems that the discussion is boiling
down to editorial issues, and I am happy to leave that between you,
the shepherd, and the document editor.

Thanks

Mike Heard

---

From: Bob Hinden <[email-masked]>
Date: Wed, 19 Apr 2017 14:16:34 -0700

Mike,

> On Apr 19, 2017, at 10:54 AM, C. M. Heard <[email-masked]> wrote:
> 

The current text I have is:

         Nodes that support Explicit Congestion Notification [RFC3168]
         use information in the Traffic Class field from all fragment
         packets to reconstruct the Traffic Class field in the
         reassembled packet.  See Section 5.3 of RFC3168 for more
         information.

I continue to think this is clear and is unlikely to create any confusion if ECN is a new requirement in IPv6 implementations.  I think it’s the appropriate change for moving to Internet Standard.

It does resolve the issue that Mirja’s raised about there not being any mention of ECN in the reassembly text.

Thanks,
Bob

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 19 Apr 2017 17:47:50 -0400

Hi Bob,

On Apr 19, 2017 5:16 PM, "Bob Hinden" <[email-masked]> wrote:

Mike,

This looks good to me as well. My only concern with the previous version
was that it sounded normative.

Regards
Suresh

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 20 Apr 2017 00:44:05 +0200

Hi,

I really don’t like the term "Nodes that support Explicit Congestion Notification“. I guess we understand something different under „support“ but maybe can just avoid that word to avoid any confusion.

Thanks,
Mirja

> Am 19.04.2017 um 23:47 schrieb Suresh Krishnan <[email-masked]>:
> 
> Hi Bob, 
> 
> This looks good to me as well. My only concern with the previous version was that it sounded normative. 
> 
> Regards 
> Suresh 
>

---

From: "Black, David" <[email-masked]>
Date: Thu, 20 Apr 2017 00:50:53 +0000

Based on Brian's comment on DSCP, only the ECN portion of the traffic class field is involved.

I agree, but offer some more explanation about another scenario.  I could see a traffic shaper changing AF drop precedence on some fragments but not others without looking to see whether or not any fragment contains a transport protocol header.  OTOH, to a first approximation, because that shaper's not looking beyond the IP headers, the likelihood of it remarking a first fragment should be the same as its overall remarking likelihood, hence reassembly based on the DSCP in the first fragment (e.g., at a tunnel egress) should on average result in the same degree of remarking in the reassembled packet stream as was in the fragmented packet stream.   The shaper has consistent long-term behavior, where long term means many, many RTTs for the flows involved, so an appeal to things averaging out is plausible.  In contrast, ECN operates on RTT timescale, making this averaging rationale inapplicable to ECN.

I would call ECN out explicitly:

          Nodes that support Explicit Congestion Notification (ECN) [RFC3168]
          use ECN  information in the Traffic Class field from all fragment
          packets to reconstruct the ECN portion of the Traffic Class field in
          the reassembled packet.  See Section 5.3 of RFC3168 for more
          information.

Beyond that, I have to concur with some part of Mirja's underlying concern about what "Nodes that support" means.   Suppose I have a user-mode SCTP implementation that uses ECN in the UDP encapsulation (think Web RTC) and an IPv6 kernel-mode implementation that uses only the first fragment's ECN codepoint in doing ECN reassembly.   Congestion indications in other than the first fragment are lost, which is bad.  The options for bringing such an IPv6 implementation into compliance with RFC 3168 without doing all-fragment ECN reassembly are not pretty:
	- Always clear the ECN field to not-ECT (i.e., 00) on outbound traffic. This should block any negotiation of ECN by higher-level protocols.
	- Drop any inbound fragmented packet.
The "completely correct" definition of "Nodes that do not support ECN" probably includes clearing the ECN field to not-ECT on outbound traffic - is the concern that we're looking at IPv6 implementations that allow ECN usage in outbound traffic but don't get ECN correct in fragment reassembly for inbound traffic?

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Mirja
> Kuehlewind (IETF)
> Sent: Wednesday, April 19, 2017 6:44 PM
> To: Suresh Krishnan <[email-masked]>
> Cc: [email-masked]; 6MAN <[email-masked]>; tsvwg
> <[email-masked]>; C. M. Heard <[email-masked]>; Bob Hinden
> <[email-masked]>; IESG <[email-masked]>; [email-masked]
> Subject: Re: [tsvwg] Mirja Kühlewind's Discuss on draft-ietf-6man-rfc2460bis-
> 09: (with DISCUSS and COMMENT)
> 
> Hi,
> 
> I really don’t like the term "Nodes that support Explicit Congestion
> Notification“. I guess we understand something different under „support“
> but maybe can just avoid that word to avoid any confusion.
> 
> Thanks,
> Mirja
> 
>

---

From: Bob Hinden <[email-masked]>
Date: Wed, 19 Apr 2017 19:19:28 -0700

Mirja,

> On Apr 19, 2017, at 3:44 PM, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Hi,
> 

While I think it’s clear, alternatives might be “implement”, “perform”, “practice”, “effect”, etc.

Bob