Re: [tcpm] Is this a problem?

Joe Touch <touch@ISI.EDU> Tue, 30 October 2007 05:16 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1ImjTD-0002vl-2J; Tue, 30 Oct 2007 01:16:55 -0400
Received: from tcpm by with local (Exim 4.43) id 1ImjTB-0002vg-2h for; Tue, 30 Oct 2007 01:16:53 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1ImjTA-0002vY-44 for; Tue, 30 Oct 2007 01:16:52 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1ImjT9-0004EI-4U for; Tue, 30 Oct 2007 01:16:52 -0400
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id l9U5G4ud017427; Mon, 29 Oct 2007 22:16:05 -0700 (PDT)
Message-ID: <>
Date: Mon, 29 Oct 2007 22:15:55 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Mahesh Jethanandani <>
Subject: Re: [tcpm] Is this a problem?
References: <> <78C9135A3D2ECE4B8162EBDCE82CAD7702765252@nekter> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.4
X-ISI-4-43-8-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc:, Caitlin Bestler <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============0827481749=="

Mahesh Jethanandani wrote:
> Caitlin,
> Caitlin Bestler wrote:
>> This is indeed a problem. I’m just not convinced it’s a transport problem.
>> Only the application layer has enough information to know when a client’s
>> behavior is abusive and/or suspicious.
> Applications if anything have less knowledge than TCP on why a
> connection is not making progress. In this particular case, HTTP could
> not make a distinction between a connection not making progress because
> of congestion in the network or because the client is advertising zero
> window. 

If an application - or host - has limited resources, it doesn't matter
why a connection isn't making progress.

> And yet all Apache can do is to reset the connection after a
> fixed amount of time. Again, HTTP may know how many of its connections
> are in the stuck state, it will not know how many FTP connections are
> seeing the same issue or how seriously constrained the system is.

There is no rule that TCP connections "see" each other per se; from
within a single connection, an implementation could be able to access
only a single connection's state.

And, ultimately, a system is constrained when it runs out of processor
or memory - which have nothing to do necessarily with the connections in
progress. I.e., an application can ask the OS - or the OS can tell the
app - when such limitations come into play anyway.

> We have found that a fixed timeout also does not work. It is easy to
> guess and work around as we did with our client program.
> The solution has to be adaptive to the condition which in this case
> involves TCP and applications have little knowledge of the state of all
> of TCP connections.
>> The transport layer should remain
>> militantly ignorant of these matters.
> When it impacts TCP's ability to function, I can hardly see that being
> ignorant will help.

You're declaring that someone who sends a zero receive window longer
than you expect to be noncompliant. There's nothing in the spec that
says that a TCP connection has to make forward progress in any fixed
timescale - even based on RTTs. This has allowed TCP to proceed over
shared links where less than one segment succeeds per RTT - e.g.,
congested transatlantic links. My concern is that this modification will
disable correct behavior in the corner cases.

Not all TCP connections must - or should - work only for the common cases.


tcpm mailing list