[e2e] number of flows per unit time in routers

[Ping Pan]

Hi,

Thank for the reply.

Here is what I think: in today's Internet, there is little value in 
counting network flows in backbone and local campus networks.

Actually, if you believe in those peerless backbones, the number of 
network flows is the number of MPLS LSP's. If it is DiffServ-aware MPLS, 
the number of flows is probably eight times the number of LSP's.

As you said, there is probably little value in counting flows in campus 
networks if network resource is not an issue.

As the carriers begin to expand toward access (DSL/PON, or over-hyped 
triple play), there is another layer of network emerging between 
backbone and access, aggregation network. This is the place where the 
network nodes need to gather user flows, process them for whatever the 
reason (SLA, accounting, conversion...) and then groom them toward the 
core. As this part of the network starts to evolve, it would be 
interesting to understand:

1. How many "flows" are we dealing here? A flow can be anything that 
worth of deep-packet-inspection from layer-1 to layer-7 (GFP, VLAN, IP 
address, ICMP, TCP, RTP, SIP..)

2. What would be the desirable topology? Meshed? Spoke? How would this 
effect the way we build the routers/switches today? Full line-rate 
routing and switching may not be important in spoke network. As such, 
the cost of the system may come down... big time.

3. To make matter more interesting, what are we going to do with 
multicast? If you believe in all the IPTV talks and trails, what would 
be the user "flow" dynamic with all those IGMP going on?

It sounds like I am trying to bring back the "bad" memory of 
RSVP/IntServ/QoS from the 90's, well... they are not needed in the 
over-provisioned core. ;-) A paper from Sprint research a while back 
had proved that with minor overprovisioning per link, there would be no 
need for QoS in the core. The newly built Comcast IP backbone is all 
over provisioned... What traffic engineering? ;-)

What about the aggregation region? How can people overprovision access 
links except universities with government's money? How can we 
overprovision RAN (radio area network) for wireless traffic? For people 
who want to offer VoIP and VoD from their servers, unless they 
understand the traffic "flows" (or load), how big the "pipe" are they 
going to buy?...

IMHO, unless we have the ability to "count" flows and apply some 
regulation to the traffic, the network will have a tough time to scale.

This is the reason why I was asking the previous question. ;-)

Thanks!

- Ping


Detlef Bosau wrote:
> Ping Pan wrote:
> 
>>Hi,
>>
>>This is very interesting. Other than backbone links, does anyone have
>>data on campus and carrier edge links? Have some flow duration
>>information would be nice too.
>>
>>Counting flows in the backbone is interesting, but the flows are mainly
>>processed at edge. So it would be nice to see something in that region.
>>
> 
> 
> I see the point. However, the problem is that in campus links
> statistical methods are perhpas much more difficult to apply than in
> backbone links.
> In backbone links, I "tend to believe" (my apologies for the word, but
> in fact TCP congestion control _has_ some aspects of a religion...) that
> statistical abstraction is possible. I don´t believe this in campus
> links.
> 
> However, from my own experience, on campus networks often routers are
> equipped with "sufficient memory", i.e. congestion drop does hardly
> occur, and than anything works fine. As long as the queues resulting
> from that do not introduce inacceptable latencies, anything is fine.
> 
> So, although a study of network behaviour on campus networks may be
> interesting, the question is: From what network size on this study
> is really helpful and relevant? And in which cases networks are designed
> by "feeling", "faith and religion", "well founded private opinions" - or
> simply because the local BOFH-instance is big enough and old enough and
> ugly enough to design a network and that´s it?
> 
> I think, this is an important question. I guess, that backbone traffic
> is quite well understood today. Furthermore, I guess traffic
> in small networks is not understood because there is nothing to
> understand. You don´t need any networking expertise to provide
> for a proper Linux installation party. The problem is the area in
> between. When networks become that large that they _must_ be understood,
> nevertheless
> they are still that small that the statistical and asymptotic
> abstraction from the Tier 1 Backbone do not hold.
> 
> This could be the case for networks with, just as a guess, say 5.000 to
> 100.000 participants. Just a guess. So, provider links and provider
> networks
> may be really interesting.
> 
> Detlef
> 
>