Subject: RE: TCP timeout mechanism

From: Bernie Volz <[email-masked]>
Date: Fri, 4 Aug 2000 16:17:01 -0400

Why get rid of them? Limit the number of connections you track, overwrite
old ones with new ones. That way, you never need a timer thread. It may be
that occasionally you drop a good connection (because of hash collision),
but that might not be a problem? (It isn't clear what you're doing with
these connections.)

Another method is to use a separate timer queue. Whenever you see packets
for a connection, move that connection to the end of the timer queue (with
doubling linked lists, this should be relatively inexpensive?). Now, your
timer thread only needs to check if the first one on the list is "old" and
if it is drop it (and look at the next until no more to drop). This approach
is also nice if you need to limit the number of connections for once you
reach the limit and you have a new connection, just drop the one at the head
of the queue (it's the oldest connection). NOTE: As a performance boost, if
you keep your timers fairly granular (say in 10 seconds chunks), you might
also add an optimization to not move a the packet to end of the list if it
has been moved recently (in the same timer chunk). That may occasionally
cause problems, but it may save a lot of queue moves.

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Proneet Biswas [mailto:[email-masked]]
Sent: Friday, August 04, 2000 3:07 PM
To: Alan Cox; TCP List
Subject: Re: TCP timeout mechanism

Hi Alan,
 I am sorry I had not been very specific. The device I intend to support is
kind of a firewall which does not have a stack on it. It will create the
session entries based on the packets which flow through it ot other
machines.
SO, it is the internal data structures which I need to clear. To put it a
different fashion :

There is a cache to which I add entries whenever a new session starts. The
problem is identifying the sessions in the cache which have timed out
without
using a timer thread to go through all the entries.

Thanks.
Proneet.

Alan Cox wrote:

> Track state (remembering to allow for unreliability/retransmits) and also
> generate faked probe acks _very_ carefully and with backoffs to test if
the
> socket has died after a timeout.
>
> Hardly rocket science.
>
> Once ipsec is standard you won't be much able to session track anything
tho

---

From: Alan Cox <[email-masked]>
Date: Fri, 4 Aug 2000 23:57:30 +0100 (BST)

> but that might not be a problem? (It isn't clear what you're doing with

He said a firewall. A hostile can now potentially DoS the firewall.

---

From: stanislav shalunov <[email-masked]>
Date: 04 Aug 2000 20:04:24 -0400

Bernie Volz <[email-masked]> writes:

> It may be that occasionally you drop a good connection (because of
> hash collision), but that might not be a problem?

Wouldn't the users be able to artificially create hash collisions?

-- 
Stanislav Shalunov						Internet2
"Cells are diodes. Electrons only go one way. If you have both poles turned
north, that will stop the traffic and will damage your health."	--Alex Chiu
	http://www.alexchiu.com/affiliates/clickthru.cgi?id=shalunov

---

From: Bill Sommerfeld <[email-masked]>
Date: Sat, 05 Aug 2000 22:51:38 -0400

> Wouldn't the users be able to artificially create hash collisions?

You can get around this if you use a "keyed" hash function with a
secret key.

However, the internet is not the phone system.. putting unrecoverable
state into the middle of the network is evil.

A box of this form will be a source of annoyance to many end users..
it should be possible to suspend one or both ends of a connection,
wake them up again 12 hours or two weeks later, and continue as if
nothing had happened.

					- Bill