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

From: "C. M. Heard" <[email-masked]>
Date: Mon, 17 Apr 2017 08:59:41 -0700

[ TSVWG added to solicit advice on implementation of RFC 3186 Section 5.3 ]

On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote:
> On Apr 15, 2017, at 4:53 AM, C. M. Heard <[email-masked]> wrote:
>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote:
>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote:
>>> ...
>>>>>>>> ----------------------------------------------------------------------
>>>>>>>> COMMENT:
>>>>>>>> ----------------------------------------------------------------------
>>>>>>>>
>>>>>>>> One question because I'm not sure if I interpret this correct to make it
>>>>>>>> part of my discuss:
>>>>>>>> Section 4.5: "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."
>>>>>>>> Does this mean the ECN codepoint (part of the Traffic Class field) is
>>>>>>>> copied from the first fragment? This doesn't seem to be correct, however,
>>>>>>>> also not sure what the correct answer is. I know this was not changed in
>>>>>>>> this revision but maybe we can still get this right.
>>>>>>>
>>>>>>> When fragments are created most of the fields are copied from the IPv6
>>>>>>> headers (e.g., Source Address, Destination address, flow label, traffic
>>>>>>> class, hop limit).  Some like payload length, next header, and hop limi
>>>>>>> t are modified.
>>>>>>>
>>>>>>> If I understand your question, the answer is yes, the ECN code point is
>>>>>>> copied from the first fragment, but should be the same from all of the
>>>>>>> fragments.
>>
>> That is inconsistent with the following guidance in RFC 3168 (see
>> https://tools.ietf.org/html/rfc3168#section-5.3):
>>
>> 5.3.  Fragmentation
>>
>>   ECN-capable packets MAY 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:
>>
>>      * Set the CE codepoint on the reassembled packet.  However, 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 reassembled, for any
>>        other reason.
>>
>>   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.
>>
>>>>>> My concern is that the ECN code point could be changed on one of the
>>>>>> fragmented packets to signal congestion of a intermediate node and
>>>>>> then when you reassemble this information gets lost. That seems wrong.
>>>>>
>>>>> That is an interesting idea, but I think out of scope for advancing this
>>>>> document to Internet Standard.  Then there is the question of how to
>>>>> encode n of m fragments experienced congestion.  Interesting future work.
>>>>
>>>> Yes there might be some more further work needed but that still makes the
>>>> guidance in this text wrong. Maybe we can add some text that the Traffic
>>>> Class may be handled differently because it could be changed on the path.
>>>
>>> Good point. It's not only ECN that can change; the DSCP can change too.
>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logical
>>> for 2460bis to note this issue.
>>
>> It seems that we (6man WG) missed this because RFC 3168 was not marked
>> as updating RFC 2460. But in effect it did so for IPv6 implementations
>> of ECN, even though it was not written in an IP version-agnostic manner.
>>
>> At the very least text should be added to the description of the
>> reassembly process that points the reader to RFC 3168 or its
>> successor document.
>
> Do we have any evidence that the guidance in RFC 3168 regarding reassembling
> IPv6 fragments is implemented?  I don’t know, but think if it there is
> evidence I agree some text should be added to rfc2460bis, if not, then
> maybe not.

Since I lack the expertise to answer that question, I'm hoping that someone
in TSVWG will see this message and do so.

Regardless of the answer to that question, my position would be that since
2460bis already defers to RFC 2474 and RFC 3168 regarding the handling of
the Traffic Class field, the following modification to 2460bis Section 4.5
would be an appropriate way to deal with Mirja's comment:

OLD:
      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.
NEW:
      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, nodes that support Explicit
      Congestion Notification [RFC3168] may use information in the
      Traffic Class field from all fragment packets to reconstruct the
      Traffic Class field in the reassembled packet.

Note that this would not cause 2460bis itself to levy an additional
requirement on how IPv6 nodes reassemble fragmented packets. It would
simply be making note of a requirement that is already levied by
RFC 3168.

Thanks and regards,

Mike Heard

---

From: "Black, David" <[email-masked]>
Date: Mon, 17 Apr 2017 17:44:22 +0000

> simply be making note of a requirement that is already levied by

In which case, the RFC 3168 requirement should be stated e.g.:

OLD:
      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.
NEW:
      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, nodes that support Explicit
      Congestion Notification [RFC3168] may use information in the
      Traffic Class field from any or all fragment packets to reconstruct
      the Traffic Class field in the reassembled packet in order to meet
      RFC 3168's requirements, e.g., that reassembly not lose indications
      of congestion, see Section 5.3 of RFC 3168 for additional information.

Pointing the implementer at Section 5.3 of RFC 3168 is better than
hoping she figures out on her own that she ought to take a look at it .

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of C. M. Heard
> Sent: Monday, April 17, 2017 12:00 PM
> To: 6MAN <[email-masked]>; tsvwg <[email-masked]>
> Cc: [email-masked]; Bob Hinden
> <[email-masked]>; Mirja Kuehlewind (IETF) <[email-masked]>;
> IESG <[email-masked]>; 6man Chairs <[email-masked]>
> Subject: Re: [tsvwg] Mirja Kühlewind's Discuss on draft-ietf-6man-rfc2460bis-
> 09: (with DISCUSS and COMMENT)
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 17 Apr 2017 18:55:16 +0100

It is good to include text. The offered text seems to step back from the 
current normative text in RFC3168 (which I think does apply to RFC2460).

The key requirement from secton 5.3, is that "Reassembly of a fragmented 
packet MUST NOT lose indications of congestion."  i.e., the network 
layer does not ignore CE marks in fragments. AT the very least, I think 
the text needs to explicitly point to that section.

Gorry

On 17/04/2017, 16:59, C. M. Heard wrote:
>> On Apr 15, 2017, at 4:53 AM, C. M. Heard<[email-masked]>  wrote:

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Apr 2017 07:58:13 +1200

In line...

> hoping she figures out on her own that she ought to take a look at it .

Yes. This is correct.

   Brian

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Bob Hinden <[email-masked]>
Date: Mon, 17 Apr 2017 14:08:48 -0700

Hi,

After reading through the discussion, I think a new paragraph (after the text that says how to construct a reassembled packet) like the following would be appropriate.

         Nodes that support Explicit Congestion Notification [RFC3168]
         should 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 don’t think we need to quote what RFC3168 says, just point the the correct section.

This also doesn’t effect nodes that don’t support ECN, so it shouldn't be making any new requirements.

Comments?

Bob

> On Apr 17, 2017, at 12:58 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> In line...
>

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 17 Apr 2017 14:36:11 -0700

Bob,

I agree with you on all points. This is a good solution.

Mike Heard

On Mon, Apr 17, 2017 at 2:08 PM, Bob Hinden <[email-masked]> wrote:

> Hi,
>
> After reading through the discussion, I think a new paragraph (after the
> text that says how to construct a reassembled packet) like the following
> would be appropriate.
>
> >>>>>>>>>>> One question because I'm not sure if I interpret this correct
> to
> >>> make it
> >>>>>>>>>>> part of my discuss:
> >>>>>>>>>>> Does this mean the ECN codepoint (part of the Traffic Class
> field)
> >>> is
> >>>>>>>>>>> copied from the first fragment? This doesn't seem to be
> correct,
> >>> however,
> >>>>>>>>>> When fragments are created most of the fields are copied from
> the
> >>> IPv6
> >>>>>>>>>> class, hop limit).  Some like payload length, next header, and
> hop
> >>> limi
> >>>>>>>>>> t are modified.
> >>>>>>>>>>
> >>>>>>>>>> copied from the first fragment, but should be the same from all
> of
> >>> the
> >>>>>>>>>> fragments.
> >>>>>
> >>>>>>>> encode n of m fragments experienced congestion.  Interesting
> future
> >>> work.
> >>>>>>>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Apr 2017 12:38:48 +1200

wfm

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 18 Apr 2017 21:42:32 +0200

Hi all,

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…

Mirja

> Am 18.04.2017 um 02:38 schrieb Brian E Carpenter <[email-masked]>:
> 
> wfm

---

From: "Black, David" <[email-masked]>
Date: Tue, 18 Apr 2017 21:17:16 +0000

The lower case "should" in the proposed new paragraph could be mis-read as weakening RFC 3168's "MUST NOT lose indications of congestion" requirement.

I would remove that one word ("should") from the proposed new paragraph to avoid that possible confusion.

Thanks, --David

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, April 17, 2017 8:39 PM
> To: Bob Hinden <[email-masked]>
> Cc: Black, David <[email-masked]>; C. M. Heard <[email-masked]>;
> 6MAN <[email-masked]>; tsvwg <[email-masked]>; draft-ietf-6man-
> [email-masked]; Mirja Kuehlewind (IETF) <[email-masked]>; IESG
> <[email-masked]>; 6man Chairs <[email-masked]>
> >>>>>>>>>>>> Section 4.5: "The number and content of the headers
> preceding
> >>>> the
> >>>>>>>>>>>> Fragment
> >>>>>>>>>>> When fragments are created most of the fields are copied
> from the
> >>>> IPv6
> >>>>>>>>>>> headers (e.g., Source Address, Destination address, flow
> label,
> >>>> traffic
> >>>>>>>>>>> copied from the first fragment, but should be the same from
> all of
> >>>> the
> >>>>>>>>>>> fragments.
> >>>>>>
> >>>>>>  a fragmented packet MUST NOT change the ECN codepoint when all
> of
> >>>> the
> >>>>>>>>>> My concern is that the ECN code point could be changed on
> one of
> >>>> the
> >>>>>>>>>> then when you reassemble this information gets lost. That
> seems
> >>>> wrong.
> >>>>>>>>>
> >>>>>>>> Class may be handled differently because it could be changed on
> the
> >>>> path.
> >>>>>>>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 19 Apr 2017 02:51:36 +0200

Hi again,

I should probably have been more constructive here. I’d like to propose the following text:

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.

Do we also need to say something about DiffServ?

Mirja

> Am 18.04.2017 um 21:42 schrieb Mirja Kuehlewind (IETF) <[email-masked]>:
> 
> Hi all,
>

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 18 Apr 2017 20:04:35 -0700

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: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Apr 2017 15:18:56 +1200

Mirja,

Reassembly takes place in the destination node, which either does or doesn't support ECN.
So I don't see your issue: if the node doesn't support ECN, the bits are ignored anyway.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Apr 2017 16:17:22 +1200

> Do we also need to say something about DiffServ?

I think not. The existing text says that the DSCP bits in the first
fragment, win and that's fine. If one of the later fragments has been
re-marked for some reason, there is no reason to take any notice.

(Specifically: we can assume that the transport header is in the first
fragment, and any meaningful re-marking would be based on the transport
header. Any re-marking of the later fragments is bogus.)

    Brian

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 18 Apr 2017 21:29:11 -0700

> header. Any re-marking of the later fragments is bogus.)

Do end systems even care what the DSCP bits are?

//cmh

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Apr 2017 16:34:05 +1200

> Do end systems even care what the DSCP bits are?

Yes, definitely if they're a tunnel end point (RFC 2983), and possibly
if they want to do some sort of input-buffer queue management for real
time traffic.

    Brian

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 19 Apr 2017 08:49:04 +0200

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. 

Mirja

> Am 19.04.2017 um 05:04 schrieb C. M. Heard <[email-masked]>:
>