RE: DoS attack ?

John C Klensin <> Fri, 07 December 2001 17:08 UTC

Return-Path: <>
Received: from by (PMDF V6.0-025 #44856) id <> (original mail from; Fri, 07 Dec 2001 12:08:48 -0500 (EST)
Received: from by (PMDF V6.0-025 #44856) id <> for (ORCPT; Fri, 07 Dec 2001 12:08:47 -0500 (EST)
Received: from by (PMDF V6.0-025 #44856) id <> for (ORCPT; Fri, 07 Dec 2001 12:08:47 -0500 (EST)
Received: from ( []) by (PMDF V6.0-025 #44856) with ESMTP id <> for; Fri, 07 Dec 2001 12:08:46 -0500 (EST)
Received: from [] (helo=P2) by with esmtp (Exim 3.22 #1) id 16CORj-000Iji-00; Fri, 07 Dec 2001 17:06:00 +0000
Date: Fri, 07 Dec 2001 12:05:43 -0500
From: John C Klensin <>
Subject: RE: DoS attack ?
In-reply-to: <23656972.1007710432@localhost>
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <>, Nicolas Popp <>, YangWoo Ko <>
Message-id: <208750488.1007726743@localhost>
MIME-version: 1.0
X-Mailer: Mulberry/2.1.1 (Win32)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE
Content-disposition: inline
References: <23656972.1007710432@localhost>
List-Owner: <>
List-Post: <>
List-Subscribe: <>, <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Help: <>, <>
List-Id: <>

--On Friday, 07 December, 2001 07:33 +0100 Patrik Fältström
<> wrote:

>> So, just from that standpoint, it could be useful for the
>> protocol to support the notion of results set range (query)
>> as well as referral (response).
> We have been through this when looking at other
> protocols....and I would urge you to learn from earlier
> mistakes (and successes).
> (1) One practical path is to give in the protocol a way for
> the server to say "I'm sorry, but I will not do that operation
> you requested. Instead I did the following". This generic
> response can be "you only got 10 records even though the
> result set is larger".
> (2) As soon as you do "paged results", you force the server to
> keep state. Depending on whether the protocol is stateful or
> stateless, it is harder or easier for the server to know when
> to remove the cached search. Further, as soon as you start
> doing pages results, you end up getting problems with sorting
> the result, handling of database changes between the two
> fetches (i.e. can the server re-issue the query for the second
> fetch, or do the server really have to cache the result set
> and return the second part at the second fetch) and million of
> other problems.
> So, my suggestion is "don't go there".

I think, given this and what I wrote earlier, we are in violent
agreement.  I would only add, to both your comments and mine,
that keeping state in a distributed system -- one in which a
"first" query could reach one server and a subsequent one could
reach a second one-- is terribly complex technically.  While it
is, of course, possible to be sure that all queries in a
sequence go to the same server (e.g., by opening a TCP
connection for the query and keeping it open until the query is
completely satisfied) such things don't have very attractive
performance or scaling proper for high-demand,
frequent-repetition, short processes.