Subject: [tcpm] increasing max window size of TCP

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 10 Mar 2015 23:34:48 -0700

Hi,

We have submitted a short draft which proposes to increase max window size
of TCP.
If you're interested, please take a look at the following info.
Some may say this is a minor thing, but we still believe we need to
consider this for future extensions of TCP.

We will appreciate your feedback!
--
Yoshi & Hiro

-------------------------------------------------------------------------
From: <[email-masked]>
Date: Mon, Mar 9, 2015 at 1:09 PM
Subject: I-D Action: draft-nishida-tcpm-maxwin-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Increasing Maximum Window Size of TCP
        Authors         : Yoshifumi Nishida
                          Hirochika Asai
        Filename        : draft-nishida-tcpm-maxwin-00.txt
        Pages           : 6
        Date            : 2015-03-09

Abstract:
   This document proposes to increase the current max window size
   allowed in TCP.  It describes the current logic that limits the max
   window size and provides a rationale to relax the limitation as well
   as the negotiation mechanism to enable this feature safely.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-nishida-tcpm-maxwin/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-nishida-tcpm-maxwin-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft
<https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>
directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 13 Mar 2015 10:16:39 +0000

Hi Yoshi,

multiple times
s/archive/achieve/

One comment: A receiver that sees WS > 14 is expected to clamp WS at 14; (see the paragraph in RFC7323 right after the one that you quoted).

So, if you signal to a regular RFC7323 receiver a WS of 15, if will behave as if WS 14 was sent, limiting its maximum sending windowsize, right? No harm done except that session getting less bandwidth.

A receiver also implementing your proposal could, however, make use of the nearly twice as large windowsize. Monitoring of the evolution of the receive window signaled vs. data transmitted could allow a sender to determine passively, if the receiver actually supports the larger windowscale option. But I’m not sure if this is really necessary… (the signaled window would shrink half as fast for unprocessed data in the receive buffer, compared to WS14; however, the step change in the window would only happen when there are 16 kB (or 32kB-1) bytes of data unprocessed.

But the sender must stop sending when the receive window is signaled to be zero (except for retransmissions) either way.

Also, I guess you want to clamp every other received value than 15 down to 14 still… Not that you start scaling by (2^255 – 1).

Since you are effectively doing a special case handling with WS==15, you may want to describe the necessary operations to an implementer alike section 2.3 of RFC7323, that is, instead of only a simple left shift by 15 bits(multiply by 2^15), you need to multiply by (2^15-1) if I understand your proposal correctly. (Or course, a multiplication by 2^15-1 is a left shift by 15, followed by a subtraction of the original value; perhaps gcc even optimizes this multiplication nowadays ☺ )

BTW, I think the formula you give in the last sentence of sec  1 is off; the signaled window spans 2^16, but the maximum value of the window signaled is 2^16-1; times (2^15-1) gives a maximum window of 2147385345

I don’t think an additional option is necessary for this change, and provided I understood your intention and calculations correctly (as described above), I would support this going forward as experimental.

Best regards,
  Richard

From: tcpm [mailto:[email-masked]] On Behalf Of Yoshifumi Nishida
Sent: Mittwoch, 11. März 2015 07:35
To: [email-masked]
Cc: [email-masked]
Subject: [tcpm] increasing max window size of TCP

Hi,

We have submitted a short draft which proposes to increase max window size of TCP.
If you're interested, please take a look at the following info.
Some may say this is a minor thing, but we still believe we need to consider this for future extensions of TCP.

-------------------------------------------------------------------------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Mar 9, 2015 at 1:09 PM
Subject: I-D Action: draft-nishida-tcpm-maxwin-00.txt
To: [email-masked]<mailto:[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sat, 14 Mar 2015 11:25:48 -0700

Hi Richard,

> s/archive/achieve/

Ugh.. Thanks for pointing this out. We'll fix them.

>
>
> One comment: A receiver that sees WS > 14 is expected to clamp WS at 14;
> (see the paragraph in RFC7323 right after the one that you quoted).
>
>
>
> So, if you signal to a regular RFC7323 receiver a WS of 15, if will behave
> as if WS 14 was sent, limiting its maximum sending windowsize, right? No
> harm done except that session getting less bandwidth.
>

Right.
But, I personally would like to not discuss clamping cases in the draft if
possible. We would like to avoid this situation rather than allowing it.

>
>
> A receiver also implementing your proposal could, however, make use of the
> nearly twice as large windowsize. Monitoring of the evolution of the
> receive window signaled vs. data transmitted could allow a sender to
> determine passively, if the receiver actually supports the larger
> windowscale option. But I’m not sure if this is really necessary… (the
> signaled window would shrink half as fast for unprocessed data in the
> receive buffer, compared to WS14; however, the step change in the window
> would only happen when there are 16 kB (or 32kB-1) bytes of data
> unprocessed.
>

Yes. I'm not very sure if this is necessary, either. (as I would like to
avoid this)
But, I think it is possible.

>
> But the sender must stop sending when the receive window is signaled to be
> zero (except for retransmissions) either way.
>
>
>
> Also, I guess you want to clamp every other received value than 15 down to
> 14 still… Not that you start scaling by (2^255 – 1).
>
>
>
> Since you are effectively doing a special case handling with WS==15, you
> may want to describe the necessary operations to an implementer alike
> section 2.3 of RFC7323, that is, instead of only a simple left shift by 15
> bits(multiply by 2^15), you need to multiply by (2^15-1) if I understand
> your proposal correctly. (Or course, a multiplication by 2^15-1 is a left
> shift by 15, followed by a subtraction of the original value; perhaps gcc
> even optimizes this multiplication nowadays J )
>

Hmm. I've checked 7323, but I couldn't find this formula. I think I missed
something. Could you point it out?

> BTW, I think the formula you give in the last sentence of sec  1 is off;
> the signaled window spans 2^16, but the maximum value of the window
> signaled is 2^16-1; times (2^15-1) gives a maximum window of 2147385345
>

>
> I don’t think an additional option is necessary for this change, and
> provided I understood your intention and calculations correctly (as
> described above), I would support this going forward as experimental.
>

Great! Thank for the feedback!

Regards,
--
Yoshi

>
>
>
>
>
> *From:* tcpm [mailto:[email-masked]] *On Behalf Of *Yoshifumi
> Nishida
> *Sent:* Mittwoch, 11. März 2015 07:35
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [tcpm] increasing max window size of TCP
>
>
>
> Hi,
>
>
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Sat, 14 Mar 2015 20:29:42 +0000

Hi Yoshi,

Right.
But, I personally would like to not discuss clamping cases in the draft if possible. We would like to avoid this situation rather than allowing it.

As you mentioned in the draft, WS is not really negotiated, just offered; If you offer WS=15 to a legacy receiver, it will only send you at most (2^16-1)*(2^14) bytes in one RTT, while a receiver that also supports this extension, would send you at most (2^16-1)*(2^15-1) bytes…

The restriction that any received WS value larger than 14 MUST be interpreted as WS=14 is here:

     ”If a
   Window Scale option is received with a shift.cnt value larger than
   14, the TCP SHOULD log the error but MUST use 14 instead of the
   specified value.  This is safe as a sender can always choose to only
   partially use any signaled receive window.  If the receiver is
   scaling by a factor larger than 14 and the sender is only scaling by
   14, then the receive window used by the sender will appear smaller
   than it is in reality.”

Also, this text give a very good rationale, why you don’t need to worry too much about unilaterally sending out WS=15.

My point being, your extension should be safe for deployment, without any checking if the opposite side interprets the value properly or not…

Hmm. I've checked 7323, but I couldn't find this formula. I think I missed something. Could you point it out?

Section 2.3:
 “SND.WND = SEG.WND << Snd.Wind.Shift”
(in C notation, where “x << y” is synonymous with “ x *2^y”).

Your extension, in C, would probably need a conditional like

If (Snd.Wind.Shift <= 14)
SND.WND = SEG.WND << Snd.Wind.Shift
Elseif (Snd.Wind.Shift == 15)
        SND.WND = SEG.WND * (2^Snd.Wind.Shift – 1)
[[
without multiply:
SND.WND = ( SEG.WND << Snd.Wind.Shift ) – SEG.WND
]]

And similarily:

If (Rcv.Wind.Shift <= 14)
        SEG.WND = RCV.WND >> Rcv.Wind.Shift
Elseif (Rcv.Wind.Shift == 15)
        SEG.WND = RCV.WND / (2^Rcv.Wind.Shift – 1)

[[
without division (also fits in uint32):
SEG.WND = (RCV.WND + (RCV.WND >> 15) + 1) >> 15

Do we carter for architectures where there is no efficient division or optimizing compiler?
]]

 (and actually, the initial paragraph in Section 2.2 has it wrong:

  “The maximum scale
   exponent is limited to 14 for a maximum permissible receive window
   size of 1 GiB (2^(14+16))“

to be absolutely correct, that should read

  “The maximum scale
   exponent is limited to 14 for a maximum permissible receive window
   size of nearly 1 GiB ( (2^16 – 1) * 2^14 )“

Don’t know if this warrants an errata :)

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 15 Mar 2015 11:26:10 -0700

Hi Richard,

On Sat, Mar 14, 2015 at 1:29 PM, Scheffenegger, Richard <[email-masked]>
wrote:

> As you mentioned in the draft, WS is not really negotiated, just offered;
> If you offer WS=15 to a legacy receiver, it will only send you at most
> (2^16-1)*(2^14) bytes in one RTT, while a receiver that also supports this
> extension, would send you at most (2^16-1)*(2^15-1) bytes…
>
> Also, this text give a very good rationale, why you don’t need to worry
> too much about unilaterally sending out WS=15.
>
>
> My point being, your extension should be safe for deployment, without any
> checking if the opposite side interprets the value properly or not…
>

OK, I see the point. We haven't thought about it, but it's an interesting
idea.
We'll think this more.

> Do we carter for architectures where there is no efficient division or

Oh. Now I see what you mean. Sorry.
But, our intention in the draft was to propose (2^16 -1) * 2^15.. I'm not
very sure to use 2^15 -1.. Could you elaborate the reason for this?

> Don’t know if this warrants an errata :)

Right. It could be an errata.
--
Yoshi