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

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 <sanjeev.ranot.81@gmail.com>
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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>