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

From: Sanjeev Ranot <[email-masked]>
Date: Thu, 25 Aug 2016 13:59:30 +0530

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

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 25 Aug 2016 12:01:04 -0700

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 <[email-masked]>
wrote:

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>

---

From: Sanjeev Ranot <[email-masked]>
Date: Sun, 28 Aug 2016 14:25:09 +0530

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 <[email-masked]>
wrote:

> On Thu, Aug 25, 2016 at 1:29 AM, Sanjeev Ranot <[email-masked]
> > wrote:
>
>> Hi,
>>
>> 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
>>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 29 Aug 2016 00:32:12 -0700

Hi Sanjeev,

> Please have a look at the document and let me know for any info or

Thanks for the doc.
I personally think you might want to clarify why we want to change
shift count in data transfer phase a bit more.
This is because even if we use shift count=15, I think we can specify
rather small window size by using a small number for the timestamp
value. So, if the stack supports shift count=15, I think it can just
use it from the beginning of the data transfer in most cases.

If your focus is to have a feature to update shift count during data
transfer phase in general, I think it can be a separate proposal from
increasing max shift count. Because it looks a more broad topic to me.

Thanks,
--
Yoshi

---

From: Sanjeev Ranot <[email-masked]>
Date: Wed, 31 Aug 2016 09:32:05 +0530

Hi Yoshi,

Yes, using shf.cnt of 15 in connection establishment phase is sufficient
enough, but  while thinking from migration and interoperability this
suggestion of changing shf.cnt during Data Transfer Phase came to mind.

Present behavior is that if window limit is reached then we cannot
transfer no matter how big cwnd is. This limits the rate of growth of
congestion window if not growth completely. Now with high speed interfaces
it will not always be the case that we increase size of MTU (as for jumbo
frames) to get the bandwidth with support of bundling (etherChannels).

Generally when shf.cnt is chosen it defines the size of SND.WND
within range from 0 to max SND.WND. SND.WND proves to be a
constraint in situation discussed below.

Note: With PAWS we need to make sure that it is sufficiently large
enough to provide ample monotonically non-decreasing numbers so that
they can be differentiated or make its use in such a way so that
its always sufficient to distinguish at-least between 2 successive
windows. RFC 7323 defines such a way by putting same TSval for all
segments belonging to the same window.

Before citing situation for the need of dynamic exchange of shf.cnt we
need to discuss why sequence number of greater than 32 bit is not needed
because of PAWS and PAWS timestamp Interface transfer speed and window
size are related

With PAWS, each wrap of timestamp must be >= 2*MSL. This MSL is based
on transfer rate. Assuming 1 timestamp tick is 1 ms, hence if we
transfer 2^30 bytes of data in each window i.e. with shf.cnt = 14 then
maximum transfer rate which we need to get this big a window is of
1 Tera bytes (TbE) with PAWS in place

1000 ms (1s) = 1000 Gb (1TbE)
1ms  = 1 Gb ~ 2^30

Therefore with PAWS timestamp tick of 1ms allows 1 Gb of window size that
we can transmit safely without data corruption due to duplicate data or
ACK segments. This minimum timestamp click needed for PAWS safety is
provided with a base consideration of sequence number of 32 bits in size.
It takes 49.6 days for a 32 bit sequence number to wrap again when
timestamp tick is 1ms.  If in future we were to increase sequence numbers
to 64 bits, then this timestamp tick can be reduced or we MAY never need
PAWS again thereafter if 64 bit sequence number is used and we can never
increase bandwidth speed no matter how much we bundle cables.

The situation discussed assume that we are never going to increase the
sequence number size and we are good with PAWS to provide us safety from
duplicate data and ACK segment or of old packets from previous incarnations
of the same TCP connection.

Another example with shf.cnt = 15 :
With shf.cnt = 15
1000ms  = 2000 Gb (2TbE)
1ms        = 2000000000 bits = 2 Gb ~ 2^31
Therefore with a speed of 2Tbps and 1 ms timestamp tick for PAWS we can
get a window size of 2 Gb.

*Migration Notes:*
This means that when we introduce a shf.cnt of 15, then we MAY either let
PAWS timestamp tick to remain same as used for 1 Gb of window size with
shf.cnt of 14 if its sufficient enough or we may think to readjust if we
want to gain more speed by lowering the previous PAWS timestamp.

Similary with a speed of 4Tbps and 1 ms timestamp tick for PAWS we can
get a window size of 4 Gb.

*Situation:*
TCP connection is going on for days using same shf.cnt which was
exchanged on day 1 when this TCP connection was established. Suppose
due to incredible high transfer rate of the inter-continent link
cwnd == SND.WND was already reached at end of day 1 and now the
transfer rate is limited by SND.WND (decided by shf.cnt) when only
very small fraction of link speed is utilized. Now suppose a very
huge surplus of memory is made available by hot-swappable memory
card inserted on both ends while TCP connection is running its
Data Transfer Phase. Shf.cnt was already decided in beginning of
this TCP connection and it was decided on the basis of amount on
total memory available at that time to be allocated to its RCV.BUF.
It required restarting this ongoing connection to have a new shf.cnt
that will now consider this new additional memory surplus (i.e.
increase RCV.BUF) and start all over again from start or further
from the last index received is area of improvement.

*My proposal is that (this is separate from the on going work on shf.cnt =
15) :*
If TCP stack have support of exchanging shf.cnt in data transfer phase
when large amount of memory is available dynamically then we can achieve
significant high transfer rates without ever having to restart the
connection.

This feature comes in heading "Dynamically adjustable TCP window" and
shf.cnt_interoperability.pdf mentions one of the possible mechanisms
for implementing this introducing 7 new state variables and 1 TCP flag.

Also, just to reiterate regarding migration purposes please look into
PAWS and discuss with stake holders if they are ok with existing
timestamp for new shf.cnt of 15.

Thanks & Regards,
Sanjeev Ranot