[e2e] number of flows per unit time in routers

[Clark Gaylord]

Fred Baker wrote in end2end-interest at postel.org:

> The problem is that a flow is not an event, and when we talk about "X  
> per second", X is usually an event. So it sounds like it would make  
> more sense to talk about flow creations (installations of a flow data  
> record, whatever the implementation calls it, in the netflow  
> database) per second, flow expirations


Yes, "flow instantiation rate" is one of the critical parameters in 
effective network operation and yet is almost entirely overlooked.  If 
we can make buckets that leak bits and packets, why not flows? (*) This 
would be a tremendous benefit -- I have no problem with one of my hosts 
sourcing 1Gbps if that is what is appropriate for the network (**) and 
application, but I certainly do not want 10^9 flows/second coming from 
one host!

In answer to the original question, this is more answerable on a 
per-host-basis than a router interface.  We see 5,000-10,000 
flows/second from our busiest servers on campus at their normal 
high-water mark (campus mail server is the winner for flow-instantiation 
and I've seen it in the 10,000 neighborhood during "normal" operation 
... bear in mind that "normal" includes millions of spam messages per 
day).  For most "servers", high-water is closer to 1,000 and for most 
"clients", you'll sometimes see them get into three digits.  Based on 
this, I'll leave router interface calculation as an exercise to the reader.

Another point: I suspect flows are closer to our classic teletraffic 
models than packets or bytes.  After all, doesn't a flow feel more like 
a phone call to you?  You'll still see longer tails than you'd expect 
from classic models, but I think you can get away with mixures and/or 
periodic regression of tractibles (e.g. Poisson and such).  If we could 
limit flow rate to something reasonable (say 10^6/host instead of the 
10^9-ish that we have now!), these models could suddenly become more 
tractible and we could all sleep better.  The problem I'm having is the 
tractibility of the data gathering and organization! :-)

Of course, we've had flow-limiting hardware before, but now let's try to 
do it a bit more gracefully. ;-)

--ckg

(*) this question is both rhetorical and actual

(**) defined by TCP-fairness is fine ... but in the next breath I'm 
going to want you to ensure that the host is playing by the rules!