Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)

[Suresh Krishnan <[e-mail]>]

Hi Pascal,
  I went through the latest rev and found an off-by-one error on the Fragment size.

* Section 5.1.

   Fragment_Size:  10-bit unsigned integer; the size of this fragment in
      a unit that depends on the Link-Layer technology.  Unless
      overridden by a more specific specification, that unit is the
      byte, which allows fragments up to 1024 bytes.

Shouldn’t this be fragments upto *1023* bytes instead of 1024 bytes?

Thanks
Suresh

> On Mar 23, 2020, at 9:54 AM, Pascal Thubert (pthubert) <pthubert=[e-mail]> wrote:
> 
> Hello Again Mirja : )
> 
> 
>> Thanks for this additional text. I just cleared my discuss.
> Very cool; again and again, many thanks for your deep reviews.
> 
>> 
>> A couple of nits you/Suresh maybe want to add as RFC editor note:
> 
> 
> Happy to republish:           https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-21 
> 
>> 
>> OLD
>> Note that the action upon detecting a congestion only applies till the end of
>> the datagram 
>> NEW Note that the action upon detecting congestion only
>> applies till the end of the datagram.
>> MAYBE EVEN
>> Note that any action that has been performed upon detection of congestion
>> only applies for the transmission of one datagram
> 
> Picked the latter
> 
>> 
>> OLD
>> an inter-frame gap can be as a flow control or a congestion control measure
>> NEW The inter-frame gap can be used as a flow control or a congestion
>> control measure
> 
> done
> 
>> OLD
>> a conservative Window_Size of, say, 3, will be the gating factor that starves
>> the sender 
>> MAYBE a conservative Window_Size of, say, 3, will be the gating
>> factor that limits the transmission rate of the sender
>> 
> 
> 
> Again and again, many thanks;
> all the best with the IAB,
> 
> Pascal
>