[e2e] number of flows per unit time in routers

[Fred Baker]

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 per second, or some such, and  
btw, some statistic reporting typical flow duration. Of course, on  
average over a longish interval one hopes that flows created per  
second equals flow expirations per second, but on a shorter period  
the rates will be skewed, with the number of flow records  
simultaneously open alternately increasing for a while and then  
decreasing for a while.

In our experience, the flow creation rate is predicted by the number  
of packets per second crossing an interface and is modified by the  
characteristics of the current definition of a "flow". Under  
configuration control, the network manager can store data about IP  
prefix pairs, IP address pairs, IP address pairs using the TCP  
protocol, IP address pairs establishing individual TCP sessions  
between them, etc etc etc. If you think about the dynamics of a web  
page, opening a web page may mean that your machine starts accessing  
files on a number of machines, usually mostly at the target site but  
not necessarily the same machine. Clicking on a link can result in  
the creation of a single IP prefix pair netflow entry, a few IP  
address pair netflow entries, or a series of TCP-session-between-IP- 
address-pair netflow entries. Therefore, the changing definition of a  
flow can easily change the flow creation rate by an order of  
magnitude. But if you know the average number of packets in a flow  
(if you know, for example, that web tcp sessions are typically 10  
packets each way and that is what you're tracking in netflow), then  
the flow creation rate is proportional to the packet rate on the  
interface.

Flow duration, btw, is generally proportional to the number of RTTs  
necessary to support the flow. Speaking in round numbers, a mumble  
packet web tcp session has an RTT for SYN/SYN-ACK, a second RTT for  
the request packet burst, a third RTT for the first response packet  
burst, potentially several more RTTs for more data, and then finally  
an RTT for the closing exchange. So flow duration is not proportional  
to line speed, but rather is proportional to some function of  
exchange (file) size and RTT.




On Oct 28, 2005, at 1:41 PM, Craig Partridge wrote:

>
> Hi Bob:
>
> Sounds as if I need to provide a bit of context.  If you are tracking
> flows (imagine a router keeping track of flows, using, say  
> something like
> NetFlow), one question is how many flows do I need to keep track of.
> Another question is how fast may I have to create new flows or expire
> old flows.  Yet another question, and the one I was aiming at, is that
> if I'm archiving flow records over time, at what rate do I have to
> archive?
>
> Note that for all but the first question, flows per second makes  
> perfect
> sense.
>
> Thanks!
>
> Craig
>
> In message <200510281712.KAA11769 at gra.isi.edu>, Bob Braden writes:
>
>
>>
>> It seems to me that this question is ill-posed.  It seems to make
>> sense to talk about the number of flows per time T only when average
>> flow duration << T.  So, flows per hour might make since, assuming
>> few flows are longer than a few minutes, but flows per second makes
>> no sense.
>>
>> Bob Braden
>

--------------------------------------------------------------
"Don't worry about the world coming to an end today. It's already  
tomorrow in Australia." (Charles Schulz )