Subject: per-flow?

From: [email-masked]
Date: Fri, 24 Oct 1997 12:53:39 -0400

I advocate using per-flow queueing and a buffer management mechanism
employing components of pushout and RED. RED helps TCP a lot and 
is more robust when per-flow state is kept (FRED is one example).

However, I believe the identificatation of a flows is the hard part 
of doing packet scheduling/buffer management in packet networks.
Once you can identify a flow, you can do per-flow scheduling and
buffer management. Pushout mechanisms prevent lockout and get e2e 
notification earlier while enabling more dynamic memory sharing.

For a guaranteed "flow", there is not reason the router can't 
be given a filter to identify them on arrival and place into a
per-flow queue. (Doing this fast?.. )
For BE traffic, approximations such as hashing into queues (possibly
restricting some routes to a set of these) can be used. If you do FQ 
among the 'routes' then among the set of queues mapped for that route, 
you prevent a user or a network from taking a disproportionate share.
(FQ among all flows would have this or other problems).

Actually identifying individual BE flows (what is and is not), 
can be done.. but requires either a dynamically managed state table
or a special-purpose CAM (content addressable memory) of size N
(where N is the number of buffers). This opens us to the "multiple
flow" attack..

-Donpaul