Re: [tcpm] New I-D

Mark Allman <> Tue, 20 February 2007 23:54 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1HJeo8-0007TL-R0; Tue, 20 Feb 2007 18:54:04 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1HJeo8-0007TG-Ar for; Tue, 20 Feb 2007 18:54:04 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1HJeo6-0001cl-Vh for; Tue, 20 Feb 2007 18:54:04 -0500
Received: from ( []) by pork.ICSI.Berkeley.EDU ( with ESMTP id l1KNruCg028258; Tue, 20 Feb 2007 15:53:56 -0800
Received: from ( []) by (Postfix) with ESMTP id 9844D7F3404; Tue, 20 Feb 2007 18:53:50 -0500 (EST)
Received: from (localhost []) by (Postfix) with ESMTP id 057B41822A6; Tue, 20 Feb 2007 18:53:28 -0500 (EST)
From: Mark Allman <>
Subject: Re: [tcpm] New I-D
In-Reply-To: <>
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Cocaine
MIME-Version: 1.0
Date: Tue, 20 Feb 2007 18:53:27 -0500
Message-Id: <>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
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="===============1184101709=="

> Well behaved applications usually SHOULD do this, i
> agree, can't be guaranteed though. Leaving the problem
> to be addressed by the app, does not ensure timeliness
> from the point of view that TCP resources such as
> buffers and connections are scarce and by how much
> etc. The scheme lacks robustness if left to the
> application, and for it to be beneficial, ALL
> applications running on a system should be doing it,
> otherwise there is the weakest link.

So, let me step back.  I should have been more careful.  I think this is
a problem with the draft-not the approach.  That is, I can certainly
understand why a TCP would want to not depend on apps.  But, the text in
the i-d doesn't lead me to that conclusion and I think it is at very
best dubious in some places.

> At first glance, it does seem like an OS resource issue, but TCP
> connections can have data backlogged in their send queues for a
> variety of reasons and for variable amounts of time, i am not sure how
> a protocol unaware OS based solution can make the distinction between
> the network causing the backlog transiently, and a legitimate vs rogue
> receiver causing the backlog etc, i feel that making it TCP protocol
> specific (something designed only for persist state) allows for well
> controlled, granular solution(s) and heuristics to detect specifically
> misbehaving receivers in this scenario.

We are having a terminology problem here.  I meant "OS" as in the thing
that contains the TCP implementation.  I did not mean that an OS could
blindly reap off resources without understanding anything about TCP.

Let me put it this way ... This seems to me to be a TCP
**implementation** issue.  Why should we need to standardize this issue
and not other internal resource contention issues?  Why is this anything
but a very local problem that can be handled by the TCP implementation
in whatever way that implementation chooses?

And, then why is the proposed solution the right one?


tcpm mailing list