Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]

Mahesh Jethanandani spake unto us the following wisdom:
> RFC1122:
>            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.
>
>            DISCUSSION:
>                 It is extremely important to remember that ACK
>                 (acknowledgment) segments that contain no data are not
>                 reliably transmitted by TCP.  If zero window probing is
>                 not supported, a connection may hang forever when an
>                 ACK segment that re-opens the window is lost.
>
> This tells me that the concern was with ACK's getting lost in the 
> network and that is why the need to keep the connection open. The point 
> we bring up in the draft is in the case the ACK's are being received 
> reliably then the need to keep the connection open just to make sure the 
> ACK has made it to the other end goes away. That is why the request to 
> change the language to say that *in case of reliable ACK*, TCP MAY tear 
> the connection down if it is not able to service existing or new 
> connections.

I hate to wade back into this, and this may be tangential to the
discussion at hand, but the reason for allowing TCP connections to
persist indefinitely is NOT because ACKs may be lost; it is because
applications may be busy indefinitely.  ACK loss is merely the reason
for continued ZWP.

> >As has already been stated, the issue is what should the OS do when it 
> >runs out of resources.  TCP implementations typically oversubscribe 
> >their resources, and run into problems when all the open connections 
> >try to use up all the resources that they've been told they can use.  
> >In this situation, the OS has to figure out some way to free up 
> >resources.  There may be some things it can do without killing 
> >connections (e.g., flush TCP resequencing queues), but usually that 
> >won't be sufficient if you have a runaway or malicious source that is 
> >causing the resource problem in the first place.  In this situation, 
> >anything the OS decides to do, including killing TCP connections, is 
> >at the discretion of the OS, and I don't that view as violating any 
> >RFC.  You're out of resources, you have to do something.  This is not 
> >a TCP protocol issue, it is an OS implementation issue.
>
> True. But it was caused by TCP's insistence on keeping the connection 
> open that causes the OS to even run out of resources, even if the reason 
> to keep the connection open (unreliable ACKs) may not be true.

Only in the *very specific* *corner case* that the open connections
are connections in PERSIST.  As best I can tell, you have noted
elsewhere that you have never even seen this in the wild; you ran your
own DoS with a homemade tool and called that the wild.  Again,
unreliable ACKs are NOT the reason to keep the connection open, you
misread or misunderstood 1122.

Your argument seems to dance around a lot, which makes it difficult to
discuss.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764

Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]

Attachment: signature.asc