Re: [tcpm] Persist condition clarification draft, now "clarification of sending behavior" draft - comments solicited

"Caitlin Bestler" <> Fri, 01 August 2008 17:24 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id F0CE93A6890; Fri, 1 Aug 2008 10:24:19 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0152E3A6890 for <>; Fri, 1 Aug 2008 10:24:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dtzWjzPSl1A1 for <>; Fri, 1 Aug 2008 10:24:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EE35D3A680F for <>; Fri, 1 Aug 2008 10:24:17 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 01 Aug 2008 13:23:39 -0400
Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77040417BC@nekter>
In-Reply-To: <>
Thread-Topic: [tcpm] Persist condition clarification draft, now "clarification of sending behavior" draft - comments solicited
Thread-Index: AcjzvnEZvyeer9goSRSsPQ0TxlC6CQAO7XzA
References: <> <>
From: Caitlin Bestler <>
To: Stefanos Harhalakis <>,
Subject: Re: [tcpm] Persist condition clarification draft, now "clarification of sending behavior" draft - comments solicited
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefanos Haralakis wrote:
> On Thursday 31 July 2008, Caitlin Bestler wrote:
> > Is an RFC really needed?
> >
> > I've always assumed that the application layer MAY
> > do pretty much whatever it wants. Further application
> > layer servers SHOULD protect their own resources against
> > abusive clients. Those protection mechanisms MAY include
> > terminating connections.
> >
> > All of that is true independent of any specific method
> > of abusing server resources.
> Since this is an OS issue that will affect all running
> applications and it is impossible to ensure that all
> TCP-listening applications won't be exploitable, I believe
> it is best to take some (customizable) measures at the OS
> side too (if understand correctly, that's what the resource
> management entity, even if it is implemented as a user-space
> part). Of course any application is able to enforce stricter
> rules.

By "application layer" I did not mean to limit the scope to
a user-space application running under a classic user/kernel
OS. Rather, I simply met the set of entities that uses the
TCP layer as a client.

Even when the TCP layer allocates resources itself, it is
doing so as an agent of a specific client/connection/listen.
Setting policy on what is a wise use of resources will  
always belong above the TCP layer, even if some implementations
delegate enforcement of that policy to the TCP layer.

Please keep in mind that any document coming through TCPM has
to make sense not only for the conventional user/kernel style
OS, but for embedded web servers that are part of devices or
TCP offload devices with the TCP layer implemented in silicon.
Treating everything above the TCP layer as an amorphous blob
is the only way to do this. Standardization within specific
sub-families of those amorphous blobs are best done in other
forums. We need to focus on telling them how TCP is supposed
to function, without telling them how to manage memory.

tcpm mailing list