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

[Brian E Carpenter <[e-mail]>]

On 19/04/2017 12:51, Mirja Kuehlewind (IETF) wrote:
> 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?

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

> Mirja
> 
> 
> 
> 
>> Am 18.04.2017 um 21:42 schrieb Mirja Kuehlewind (IETF) <[e-mail]>:
>>
>> 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 <[e-mail]>:
>>>
>>> wfm 
>>> On 18/04/2017 09:08, Bob Hinden 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.
>>>>
>>>>        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 <[e-mail]> wrote:
>>>>>
>>>>> In line...
>>>>>
>>>>> On 18/04/2017 05:44, Black, David wrote:
>>>>>> Extracting the key portions of text:
>>>>>>
>>>>>>>> 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.
>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> 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 .
>>>>>
>>>>> Yes. This is correct.
>>>>>
>>>>> Brian
>>>>>
>>>>>>
>>>>>> Thanks, --David
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: tsvwg [mailto:[e-mail]] On Behalf Of C. M. Heard
>>>>>>> Sent: Monday, April 17, 2017 12:00 PM
>>>>>>> To: 6MAN <[e-mail]>; tsvwg <[e-mail]>
>>>>>>> Cc: [e-mail]; Bob Hinden
>>>>>>> <[e-mail]>; Mirja Kuehlewind (IETF) <[e-mail]>;
>>>>>>> IESG <[e-mail]>; 6man Chairs <[e-mail]>
>>>>>>> Subject: Re: [tsvwg] Mirja Kühlewind's Discuss on draft-ietf-6man-rfc2460bis-
>>>>>>> 09: (with DISCUSS and COMMENT)
>>>>>>>
>>>>>>> [ 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 <[e-mail]> 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
>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> [e-mail]
>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> --------------------------------------------------------------------
>>>>>>
>>>>>
>>>>
>>>
>>
> 
>