Subject: [tcpm] 793bis: removing "Window Management Suggestions"

From: Wesley Eddy <[email-masked]>
Date: Tue, 2 Aug 2016 15:15:25 -0400

In the latest revision of the 793bis draft, I added content from RFC 
1122 on the SWS avoidance algorithms for sender-side and receiver-side.  
These are laid out in 1122, but were not present in 793.

793 includes a section called "Window Management Suggestions", that I 
believe was a precursor to the more-developed content in 1122 on:

(1) SWS avoidance sender-side algorithm

(2) SWS avoidance receiver-side algorithm

(3) Nagle algorithm

(4) delayed ACKs

(5) zero-window probing

With all of that 1122 content worked into 793bis, I did not think it 
made sense to retain this section of the document, but it will be good 
to confirm that with the WG.

For convenience, the content from 793 that I believe is no longer needed 
is pasted below:

     Window Management Suggestions

       Allocating a very small window causes data to be transmitted in
       many small segments when better performance is achieved using
       fewer large segments.

       One suggestion for avoiding small windows is for the receiver to
       defer updating a window until the additional allocation is at
       least X percent of the maximum allocation possible for the
       connection (where X might be 20 to 40).

       Another suggestion is for the sender to avoid sending small
       segments by waiting until the window is large enough before
       sending data.  If the the user signals a push function then the
       data must be sent even if it is a small segment.

       Note that the acknowledgments should not be delayed or unnecessary
       retransmissions will result.  One strategy would be to send an
       acknowledgment when a small segment arrives (with out updating the
       window information), and then to send another acknowledgment with
       new window information when the window is larger.

       The segment sent to probe a zero window may also begin a break up
       of transmitted data into smaller and smaller segments.  If a
       segment containing a single data octet sent to probe a zero window
       is accepted, it consumes one octet of the window now available.
       If the sending TCP simply sends as much as it can whenever the
       window is non zero, the transmitted data will be broken into
       alternating big and small segments.  As time goes on, occasional
       pauses in the receiver making window allocation available will
       result in breaking the big segments into a small and not quite so
       big pair. And after a while the data transmission will be in
       mostly small segments.

       The suggestion here is that the TCP implementations need to
       actively attempt to combine small window allocations into larger
       windows, since the mechanisms for managing the window tend to lead
       to many small windows in the simplest minded implementations.

Any thoughts or feedback on removing this from 793bis will be 
appreciated, thanks!

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 2 Aug 2016 12:42:07 -0700

On Tue, Aug 2, 2016 at 12:15 PM, Wesley Eddy <[email-masked]> wrote:
> In the latest revision of the 793bis draft, I added content from RFC 1122 on
> the SWS avoidance algorithms for sender-side and receiver-side.  These are
> laid out in 1122, but were not present in 793.
>
> With all of that 1122 content worked into 793bis, I did not think it made
> sense to retain this section of the document, but it will be good to confirm
> that with the WG.
>
> For convenience, the content from 793 that I believe is no longer needed is
> pasted below:
+1

BTW on https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-03#section-3.8.3.3
<quote>
   A TCP MAY keep its offered receive window closed indefinitely.  As
   long as the receiving TCP continues to send acknowledgments in
   response to the probe segments, the sending TCP MUST allow the
   connection to stay open.
</quote>

The second unconditional MUST opens up a simple and effective DoS
attack, which Linux no longer wants to be vulnerable of.
https://patchwork.ozlabs.org/patch/392217/

> Any thoughts or feedback on removing this from 793bis will be appreciated,
> thanks!
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Tue, 2 Aug 2016 12:52:53 -0700

On 8/2/2016 12:42 PM, Yuchung Cheng wrote:
>> ...
+1

> https://patchwork.ozlabs.org/patch/392217/

I strongly discourage attempts to try to bulletproof unsecured protocols.

IMO, the ability of an endpoint to keep its window closed indefinitely
is its prerogative, just as it is the prerogative of the other end to
close such a connection. AFAICT, the Linux code is consistent with the
second half of this statement, but I don't think it should be required
or even mentioned.

It's always obvious that an endpoint OS can and should protect its
resources by whatever means it thinks necessary. These are not protocol
decisions.

Joe

---

From: David Borman <[email-masked]>
Date: Tue, 2 Aug 2016 15:14:40 -0500

The point about keeping the connection open in the face of zero window probes has the classic example of sending a job to the printer just before heading off to lunch, and when you come back later discover that the printer ran out of paper and stopped accepting new TCP data.  The printer keeps responding to the probes with a zero window, and when paper is finally added to the printer, printing resumes, the TCP window is opened and the job completes.

Years ago there were examples of situations like this where TCP connections were being timed out relatively quickly in the face of a zero window, causing failures when there was no need for a failure.  It’d be nice if trying to address a potential DOS situation didn’t cause normal situations to regress back to those days; it then becomes a matter of balancing how long to wait before giving up on a zero window connection.

			-David Borman

> On Aug 2, 2016, at 2:52 PM, Joe Touch <[email-masked]> wrote:
> 
> 
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 2 Aug 2016 13:17:36 -0700

Hi, David,

I agree. IMO, DOS situations should be handled by the OS by withdrawing
resources *as needed*. That includes closing down zero-window situations
as below, as well as closing idle connections when resources are limited.

I don't see this as something the protocol needs to decide.

Joe

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 2 Aug 2016 13:22:25 -0700

> Years ago there were examples of situations like this where TCP connections were being timed out relatively quickly in the face of a zero window, causing failures when there was no need for a failu…
I am well aware of the printer story and which part in my original
email did I advocate to remove the MUST?

Linux only chops the ropes when these connections have no real owners
(i.e., orphaned socket in Linux) and the amount exceeds a configurable
system limit.  I am mentioning there is a real attack behind this
simple MUST.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 2 Aug 2016 20:25:25 +0000

At a minimum, that means switching the language from "MUST allow the connection to stay open" to "SHOULD allow the connection to stay open" maybe with a caveat like "unless server size resource management requires that it be closed."

And the printer-out-of-paper scenario really ought to be solved at the application layer. After all, if you are waiting for a printout, knowing why you are waiting is somewhat helpful...

-- Christian Huitema

> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Tuesday, August 2, 2016 1:18 PM
> To: David Borman <[email-masked]>
> Cc: [email-masked] Extensions <[email-masked]>
> Subject: Re: [tcpm] 793bis: removing "Window Management Suggestions"
> 
> Hi, David,
> 
> > The point about keeping the connection open in the face of zero window
> probes has the classic example of sending a job to the printer just before
> heading off to lunch, and when you come back later discover that the printer
> ran out of paper and stopped accepting new TCP data.  The printer keeps
> responding to the probes with a zero window, and when paper is finally added
> to the printer, printing resumes, the TCP window is opened and the job
> completes.
> >
> > Years ago there were examples of situations like this where TCP connections
> were being timed out relatively quickly in the face of a zero window, causing
> failures when there was no need for a failure.  It’d be nice if trying to address a
> potential DOS situation didn’t cause normal situations to regress back to those
> days; it then becomes a matter of balancing how long to wait before giving up
> on a zero window connection.
> >
> > 			-David Borman
> >
> is
> appreciated,

---

From: Joe Touch <[email-masked]>
Date: Tue, 2 Aug 2016 13:31:38 -0700

> At a minimum, that means switching the language from "MUST allow the connection to stay open" to "SHOULD allow the connection to stay open" maybe with a caveat like "unless server size resource man…
I disagree.

The entirety of every protocol would turn into "SHOULD, unless resources
become restricted". That's OS design, not protocol design.

> And the printer-out-of-paper scenario really ought to be solved at the application layer. After all, if you are waiting for a printout, knowing why you are waiting is somewhat helpful...
It should, but that's another reason not to build a solution into the
protocol.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 2 Aug 2016 13:36:01 -0700

> system limit.  I am mentioning there is a real attack behind this

There MIGHT BE an attack. There might not. Just because an endpoint does
something you didn't expect, does not mean it is malicious.

A variant of the Postel Principle applies here - IMO, anything a benign
endpoint CAN do MUST NOT be interpreted as an attack.

A node has the right to protect itself and its resources, but should not
infer malice where it isn't known to exist. It might be worth noting
somewhere the ways in which an *implementation* of TCP can help protect
resources, but that's an implementation suggestion, not protocol guidance.

Joe

---

From: David Borman <[email-masked]>
Date: Tue, 2 Aug 2016 15:56:44 -0500

Sorry, my intention was to provide context on the mailing list for why that MUST is there, not necessarily aimed at you, but for anyone else that is reading this list and might not be familiar with the background.

I think it should remain a MUST, but implementations are always free to do what they need to do when under attack or run out of resources.
			-David

> On Aug 2, 2016, at 3:22 PM, Yuchung Cheng <[email-masked]> wrote:
>

---

From: John Heffner <[email-masked]>
Date: Tue, 2 Aug 2016 17:14:50 -0400

This reminds me a lot of an old thread:
https://www.ietf.org/mail-archive/web/tcpm/current/msg04040.html

On Tue, Aug 2, 2016 at 4:56 PM, David Borman <[email-masked]> wrote:

> Sorry, my intention was to provide context on the mailing list for why
> that MUST is there, not necessarily aimed at you, but for anyone else that
> is reading this list and might not be familiar with the background.
>
> I think it should remain a MUST, but implementations are always free to do
> what they need to do when under attack or run out of resources.
>                         -David
>
> heading off to lunch, and when you come back later discover that the
> printer ran out of paper and stopped accepting new TCP data.  The printer
> keeps responding to the probes with a zero window, and when paper is
> finally added to the printer, printing resumes, the TCP window is opened
> and the job completes.
> >>
> >> Years ago there were examples of situations like this where TCP
> connections were being timed out relatively quickly in the face of a zero
> window, causing failures when there was no need for a failure.  It’d be
> nice if trying to address a potential DOS situation didn’t cause normal
> situations to regress back to those days; it then becomes a matter of
> balancing how long to wait before giving up on a zero window connection.
> >>
> >>                        -David Borman
> 1122 on
> >>>> BTW on
> https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-03#section-3.8.3.3
> >>>> <quote>

---

From: Joe Touch <[email-masked]>
Date: Tue, 2 Aug 2016 15:41:28 -0700

On 8/2/2016 2:14 PM, John Heffner wrote:
> This reminds me a lot of an old
> thread: https://www.ietf.org/mail-archive/web/tcpm/current/msg04040.html

Thanks for pointing that out.

RFC 6429 (the resulting doc) already says it's OK for the OS to
terminate ZWP connections if it runs out of resources.

It also very clearly states that this isn't a change to the standard and
that it is an implementation issue.

Thus I don't think this belongs in RFC793bis.

Joe

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 3 Aug 2016 12:49:56 -0700

>> thread: https://www.ietf.org/mail-archive/web/tcpm/current/msg04040.html
Thanks for the reference. I suggest a quick reference to RFC6429 at
the end of the section 3.8.3.3 in 793bis. RFC 793 is THE reference to
TCP, so making it informational on various caveats for new
implementors is really useful.

(and I expect Joe to disagree again, which he already did).

---

From: Theodore V Faber <[email-masked]>
Date: Wed, 3 Aug 2016 20:05:35 +0000

On 08/02/2016 01:18 PM, Joe Touch wrote:
> Hi, David,
> 
> I agree. IMO, DOS situations should be handled by the OS by
> withdrawing resources *as needed*. That includes closing down
> zero-window situations as below, as well as closing idle
> connections when resources are limited.
> 

Right.  The relevant distinction is between OS and protocol.  The same
way the OS needn't inform open connections that the power has failed,
the OS needn't tell open connections that it's responding to a DDoS.
The possibility of catastrophic failure is assumed.

(BTW, Joe, we're agreeing here. :-D)

- -- 
Ted Faber <[email-masked]>
Engineering Specialist
Computer Systems Research Department
310-336-7373

---

From: Joe Touch <[email-masked]>
Date: Wed, 3 Aug 2016 14:09:52 -0700

> (and I expect Joe to disagree again, which he already did).
You're right.

To clarify, my view is that RFC6429 is a recommendation to the OS, not
to TCP. That's the reason I don't think it belongs in a TCP doc. I think
it would simply waste space to put in every way in which the OS needs to
manage resources that TCP might either contribute to or be affected by.

793bis should not become a "junk drawer". The cleaner and simpler it is,
the more likely it will be supported correctly.

Joe

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 3 Aug 2016 14:39:27 -0700

> to TCP. That's the reason I don't think it belongs in a TCP doc. I think

RFC6429 says
<quote>
Rather than making a change to the standard, this document clarifies
what has been until now a misinterpretation of the tandard as
specified in RFC 1122.
</quote>

RFC793-bis says
<quote>
1.  Purpose and Scope
[snip]
   For several decades, RFC 793 plus a number of other documents have
   combined to serve as the specification for TCP [17].  Over time, a
   number of errata have been identified on RFC 793, as well as
   deficiencies in security, performance, and other aspects.  A number
   of enhancements has grown and been documented separately.  These
were  never accumulated together into an update to the base
specification.
</quote>

> the more likely it will be supported correctly.
I will agree with you if RFC6429 is a piece of junk. but I don't think so.