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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

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 <[e-mail]>:
> 
> 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)
> <[e-mail]> 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 <[e-mail]>:
>>> 
>>> Hi Bob,
>>> 
>>> On Apr 19, 2017 5:16 PM, "Bob Hinden" <[e-mail]> wrote:
>>> Mike,
>>> 
>>>> On Apr 19, 2017, at 10:54 AM, C. M. Heard <[e-mail]> 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
>>> 
>> 
>