[e2e] number of flows per unit time in routers
pingpan at cs.columbia.edu
Sat Oct 29 14:01:51 PDT 2005
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. ;-)
Detlef Bosau wrote:
> Ping Pan wrote:
>>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
> 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,
> 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
> may be really interesting.
More information about the end2end-interest