Re: [tcpm] (ref. RFC 7323) Increase of shift count from 14 to 15.

[Sanjeev Ranot <[e-mail]>]

Hi Yoshi,

thanks for replying. I have done some work in these couple of days on
how exchange and interoperability of shift count 15 or greater will work.

Basically my idea is for the new TCP stack (which will support shf.cnt >=
15)
to exchange shf.cnt even in Data Transfer Phase and not only in connection
establishment. I have presented this exchange work in the document enclosed.

Please have a look at the document and let me know for any info or
clarification
required. I hope it helps in your related studies and work.

Please feel free to write and discuss.

Thanks & Regards,
Sanjeev Ranot


On 26 August 2016 at 00:31, Yoshifumi Nishida <[e-mail]>
wrote:

> Hello Sanjeev,
>
> I wrote a draft about it before.
> I am still working on it as I need to do some studies a bit more, but I
> think it's probably ok to use 15 as a shift count.
> A question would be how to migrate it even if using 15 is possible.
> Or, we can publish this draft as reference information as we've seen this
> question from time to time.
>
> https://tools.ietf.org/html/draft-nishida-tcpm-maxwin-00
>
> Thanks,
> --
> Yoshi
>
> On Thu, Aug 25, 2016 at 1:29 AM, Sanjeev Ranot <[e-mail]
> > wrote:
>
>> Hi,
>>
>> please can the team explain why we don't use 15 as a shift count instead
>> of 14 as mentioned in RFC 7323. Is it because of machines not supporting
>> unsigned storage or is it more than sufficient guard for denying old or
>> unwanted segment retransmissions from the previous window.
>>
>> My understanding:
>> We know that 2^32 sequence counter (sequence counter is the the sequence
>> field in TCP header) has valid sequence numbers from 0 to 4294967295. To
>> determine if a data segment is "old" or "new" it sets the window size to
>> floor((2^32-1 )/2) +1 since sender's and receiver's window can be out of
>> phase by at-most 1 window.
>> 1st part has valid range of sequence numbers from = 0 to 2147483647 and
>> since its contained inside size of of 2^32 therefore we get another valid
>> range of sequence numbers from 2147483648 to 4294967295. So if the sender
>> has sent all its packets within the window from 0 to 2147483647 and
>> receiver
>> has accepted all the packets and sent cumulative acks as well for all of
>> these then it advances RCV.NXT to start of next maximum available range
>> of sequence numbers.
>> Upon receiving all cumulative acks the sender also advance to next set of
>> available sequence numbers. Otherwise, if considering the scenario when
>> spurious retransmission occurs or another scenario where all cumulative
>> acks
>> are lost and retransmission timeout or another scenario when cumulative
>> ack
>> carrying widow update information is lost, then in such cases the sender
>> will retransmit segment with sequence number that will fail receiver's
>> segment acceptability test.
>>
>> If there is a reason behind this then please cite in response. Also
>> please
>> tell if such change is valid then do we need to report it as correction
>> or as a
>> change for RFC 7323.
>>
>> Thanks & Regards,
>> Sanjeev Ranot
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>>
>