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

Mark Allman <> Mon, 26 November 2007 16:13 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IwgaV-0006CV-MZ; Mon, 26 Nov 2007 11:13:35 -0500
Received: from tcpm by with local (Exim 4.43) id 1IwgaU-0006CE-DF for; Mon, 26 Nov 2007 11:13:34 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IwgaU-0006C5-2O for; Mon, 26 Nov 2007 11:13:34 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1IwgaT-0004Te-I6 for; Mon, 26 Nov 2007 11:13:33 -0500
Received: from ( []) by pork.ICSI.Berkeley.EDU ( with ESMTP id lAQGDWKW002976; Mon, 26 Nov 2007 08:13:32 -0800
Received: from ( []) by (Postfix) with ESMTP id F07FE12621C8; Mon, 26 Nov 2007 11:13:27 -0500 (EST)
Received: from (localhost []) by (Postfix) with ESMTP id 29EFA2FC343; Mon, 26 Nov 2007 11:12:59 -0500 (EST)
To: Joe Touch <touch@ISI.EDU>
From: Mark Allman <>
Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]
In-Reply-To: <>
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Walk on the Wild Side
MIME-Version: 1.0
Date: Mon, 26 Nov 2007 11:12:59 -0500
Message-Id: <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
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="===============0357636511=="


You and I are just going to disagree.

> That OS is required to reserve per-connection resources when
> connections are created. It can halt new connections.

If this is the general reading of the spec then TCP has a built-in DoS
vulnerability that we need to fix.

> It *CANNOT* kill existing connections to make up for poor resource
> management and call itself compliant with the current language in
> 1122.

I disagree.

> >     That doesn't mean I think the words in 1122 are wrong.  That means I
> >     think that if folks would call a stack that has run out of memory
> >     (or, hits some threshold, say) and therefore kills some connections
> >     that are doing ZWP "non-conformant" then they are simply wrong and
> >     applying too much protocol lawyering and too little common sense.
> The lack of common sense came when the OS designer failed to allocate
> sufficient per-connection resources. Throw your stones in their
> direction, please.

Huh?  The lack of allocation of sufficient per-connection resources?
What?  The problem here is that the OS *did* allocate resources and with
a low-rate handshake those resources can be tied up indefinitely.  I
have no idea how the OS "failed to allocate sufficient per-connection

If a TCP were omniscient and could know the workload to be imposed on it
arbitrarily far into the future then perhaps it could wisely allocate
resources to avoid this problem.  But, since that is impossible then a
host can get into resource contention problems and in that case it
should have the flexibility to mitigate these problems.

It is absurd to me that a TCP (or any protocol) would allow a peer to
indefinitely tie up a local resource without being subject to local
policies on that resource.  I cannot imagine that such a notion falls
within the spirit of 793 & 1122.  If we have wide-spread agreement that
your interpretation is right then I support a one-page standards-track
RFC that says it is not.


tcpm mailing list