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

From: Suresh Krishnan <[email-masked]>
Date: Thu, 20 Apr 2017 22:43:52 -0400

Hi Mirja/all,
  Even though I like Bob's suggested text (with David's suggested
change), I would like to suggest an alternate formulation that is
generic (with ECN as an example) to see if it works.

OLD:
      Only those headers in the Offset zero fragment packet are retained in
      the reassembled packet.

NEW:

      Only those headers in the Offset zero fragment packet are retained in
      the reassembled packet. Other fields in the IPv6 header may also
      vary across the fragments being reassembled. Specifications that
      use these fields may provide alternate instructions if this basic
      mechanism of using the values from the Offset zero fragment is not
      sufficient. e.g. Section 5.3 of [RFC3168] describes how to combine
      the ECN bits from the different fragments to derive the ECN bits of
      the reassembled packet.

I realize it is a bit verbose but I couldn't shorten it further.
Thoughts/suggestions?

Thanks
Suresh

On Wed, Apr 19, 2017 at 6:44 PM, Mirja Kuehlewind (IETF)
<[email-masked]> wrote:
> 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,
>>
>> On Apr 19, 2017 5:16 PM, "Bob Hinden" <[email-masked]> wrote:
>> Mike,
>>
>> > On Apr 19, 2017, at 10:54 AM, C. M. Heard <[email-masked]> wrote:
>> >
>> > On Wed, Apr 19, 2017 at 10:25 AM, Mirja Kühlewind wrote:
>> >> 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...
>> >
>> > 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.
>>
>> 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.
>>
>>
>> This looks good to me as well. My only concern with the previous version was that it sounded normative.
>>
>> Regards
>> Suresh
>>
>

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 20 Apr 2017 20:32:26 -0700

Sounds good!
Verbosity in this case a positive factor.

Regards,
Jeff

> On Apr 20, 2017, at 19:43, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Mirja/all,
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sat, 22 Apr 2017 13:57:54 +0200

Hi Suresh,

thanks this text is fine for me. 

I’d like propose three tiny editorial only changes/nits: 
s/Other/Further,/
s/this basic/the basic/
s/sufficient. e.g./sufficient, e.g./

     Only those headers in the Offset zero fragment packet are retained in
     the reassembled packet. Further, fields in the IPv6 header may also
     vary across the fragments being reassembled. Specifications that
     use these fields may provide alternate instructions if the basic
     mechanism of using the values from the Offset zero fragment is not
     sufficient, e.g. Section 5.3 of [RFC3168] describes how to combine
     the ECN bits from the different fragments to derive the ECN bits of
     the reassembled packet.

And I would be even more happier if we could add a few more words to the last sentence:

     ... e.g. Section 5.3 of [RFC3168] describes how to combine
     the ECN bits from the different fragments to derive the ECN bits of
     the reassembled packet such that no congestion indications are lost.

Thanks!
Mirja

> Am 21.04.2017 um 04:43 schrieb Suresh Krishnan <[email-masked]>:
> 
> Hi Mirja/all,

---

From: Suresh Krishnan <[email-masked]>
Date: Sun, 23 Apr 2017 23:30:55 -0400

> s/sufficient. e.g./sufficient, e.g./

Thanks Mirja. These edits all seem fine.

>      the reassembled packet such that no congestion indications are lost.

This is not strictly true. If any of the fragments carries the not-ECT
codepoint, congestion indications will be lost (according to RFC3168),
but my earlier proposed text still works. So if you don't care
strongly about it, I would prefer keeping the old text.

Regards
Suresh

---

From: Bob Hinden <[email-masked]>
Date: Tue, 25 Apr 2017 08:11:57 -0700

Suresh,

> On Apr 23, 2017, at 8:30 PM, Suresh Krishnan <[email-masked]> wrote:
> 

I looked at the proposed text and came up with the following (including the text before and after):

   The following conditions are not expected to occur frequently, but
   are not considered errors if they do:

      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.

      The Next Header values in the Fragment headers of different
      fragments of the same original packet may differ.  Only the value
      from the Offset zero fragment packet is used for reassembly.

      Other fields in the IPv6 header may also vary across the fragments
      being reassembled.  Specifications that use these fields may
      provide additional instructions if the basic mechanism of using
      the values from the Offset zero fragment is not sufficient.  For
      example, Section 5.3 of [RFC3168] describes how to combine the
      Explicit Congestion Notification (ECN) bits from different
      fragments to derive the ECN bits of the reassembled packet.

The biggest change was to split it into two paragraphs and put the new text after the paragraph about Next Header values.  Otherwise it doesn’t read well.

I also did a few editorial changes including spelling out ECN as it was the first time in the document that was used.  The text about Traffic Class comes later in document.  Changed “alternate” to “additional” because the ECN spec does not respecify the whole reassembly algorithm, just the ENC parts.

Comments?

Bob

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 25 Apr 2017 08:39:36 -0700

I think that this text does the job very well. It reads well, does not levy
any requirements on the reassembly process that were not in RFC 2460,
clearly states that that other specs such as ECN may levy additional
requirements, and points the reader to the relevant section of RFC 3168 for
more information. Thanks for putting this together.

//cmh

On Tue, Apr 25, 2017 at 8:11 AM, Bob Hinden <[email-masked]> wrote:

> The biggest change was to split it into two paragraphs and put the new
> text after the paragraph about Next Header values.  Otherwise it doesn’t
> read well.
>
> I also did a few editorial changes including spelling out ECN as it was
> the first time in the document that was used.  The text about Traffic Class
> comes later in document.  Changed “alternate” to “additional” because the
> ECN spec does not respecify the whole reassembly algorithm, just the ENC
> parts.
>
> Comments?
>
> Bob
>
>
>