Internet Backbone Index

Mailman List Mirror (Read Only)
1

Sean, we only have 805 Mbps of possible bandwidth to other networks. I not
sure what you mean by a better engineered network. If you only have a
routed network, not sure this is the best way to engineer a network today.
Switch technology can do alot of good things.

The model does fall apart if you say you are only going to buy from these
three to five, but it does not fall apart if you watch your traffic and you
buy from whom your traffic is going to. The idea is not to engineer poor
peering in the MAEs and NAPs with a bunch of networks. Buy and manage from
the networks you are going to and you will engineer a better product. I
still think that if you really looked at a normal NSP traffic that the bulk
of it is with 5 to 8 networks.

I some what agree with some of what you say, that a peer could be a good
thing if it is private and not in a shared peering in the MAEs and NAPs.
You talk about engineering good networks, why then use something that is
unmanaged and uses poor technology and poor engineer designs in a MAE or
NAP? Where is most of the packet lost on the internet? MAEs and NAPs.
Where does most of the latency come from? Routers. MAEs and NAPs are
yesterdays ideas that everyone who has bought into the concept now has to
live with it, they did not build the business around the fact they had to
pay and manage to provide good service.

The time is almost upon us that you pay for what you get on the internet
and you must pay for the bandwidth that you use, not what you can over
subscribe until your customer begin to leave. This is a tough model, few
will make it.

Some day the internet will use measurements, such as QOS and customer will
be willing to pay for those who have engineered their networks to provide
QOS.

I only have one more question for you; how many router hops, on your
network, from New York to Los Angeles? If it is more than 1, then tell me
what your latency is from end to end. Let's compare, shall we.

Gary Zimmerman
V.P. of Network Engineering
Savvis Communications Corp.
email: garyz@savvis.com
http://www.savvis.com
Office: 314.719.2423
Address: 7777 Bonhomme Suite 1000
               St. Louis, MO 63105

2

Where does most of the latency come from? Routers.

Uhh... what about longlines??

MAEs and NAPs are
yesterdays ideas that everyone who has bought into the concept now has to
live with it, they did not build the business around the fact they had to
pay and manage to provide good service.

Hey, if that's your opinion then that's fine. Most of us aren't so ready to
throw out *ANY* of the tools available to us to build networks. Routers
have a place, IXPs have a place and switching has a place. You do things
your way and we'll do it our own ways and next year we will see who had the
best ideas.

The time is almost upon us that you pay for what you get on the internet
and you must pay for the bandwidth that you use, not what you can over
subscribe until your customer begin to leave. This is a tough model, few
will make it.

What makes it tough is that there is very low customer demand for this sort
of network. Every experiment with pay-per-use communications services over
the past twenty years has shown that customers don't like it. The Internet
boom of 1995 demonstrated quite graphically that flat rate telecom has an
outrageously strong customer demand. Our job is to figure out how to
continue to scale a network that can profitably provide flatrate services.
That's the bread and butter of this industry.

Some day the internet will use measurements, such as QOS and customer will
be willing to pay for those who have engineered their networks to provide
QOS.

Yes, definitely. But that's still an extra cost luxury over and above the
flatrate bread and butter services. ANd there is no certainty that ATM will
be needed to provide QOS. There are some interesting options in certain
routers as well.

I only have one more question for you; how many router hops, on your
network, from New York to Los Angeles? If it is more than 1, then tell me
what your latency is from end to end. Let's compare, shall we.

You aren't going to make latency disappear by replacing router hops with
ATM switch hops. Those electrons still have to cross the continent.

3

You talk about engineering good networks, why then use something that is
unmanaged and uses poor technology and poor engineer designs in a MAE or
NAP? Where is most of the packet lost on the internet? MAEs and NAPs.

This is gratutitous and misleading to the journalists and other
non-network engineers here.

The packet loss at NAPs and MAEs is caused by providers not upgrading the
size or number of connections they have to/from the various exchange
points they are experiencing problems at.

An example of this disingenous usage of exchanges is Sprint's completely
saturated T1 connection to CIX. There are many other examples. The
solution is to not use those routes.

If a provider is leaking bad routes and flaps continously, would you peer
with them? Likewise, if a provider has a notoriously saturated connection
to an exchange does it them become a (misleading) casebook example of why
exchange points are bad?

No and No.

Mike.

+------------------- H U R R I C A N E - E L E C T R I C -------------------+

4

Where does most of the latency come from? Routers.

Uhh... what about longlines??

On second thought, here are some URLs....

I went to http://www.nanog.org and searched the mailing list archives for
the last time this was argued. Here are some references:

http://www.cctec.com/maillists/nanog/historical/9610/msg00263.html

http://www.cctec.com/maillists/nanog/historical/9604/msg00043.html

http://www.cctec.com/maillists/nanog/historical/9610/msg00586.html

5

I was going to ignore this particular pissing contest, but this caught my eye.

I heard from some people that there are customers who complain about the
number of IP hops through a network, and didn't get why they would ask such an
irrelevant question, but now I see why.

For the Nth time, routers by themselves do _NOT_ introduce any significant
increased latency over switches, and whatever amount that may be is dwarfed by
the propagation delay of long haul circuits.

If argue otherwise is just silly marketing stunt.

Now, there are failure modes in which routed networks can add large amounts of
latency to flows. However, I can think of just as many failure modes in
switched networks that will do the same.

There are many valid reasons why you'd want to build a switched WAN backbone
as opposed to a routed one in the current environment. However, to argue that
a switched backbone has an inherent advantage over a routed one is at best
disingenuous, and at worst dishonest.

-dorian

6

It's been pointed out to me that I've neglected to mention the effects of
buffering delay. Rather than go on, I've included an article by Scott Bradner
on this topic:

-dorian

7

There is one significant difference between routed and switched backbones.
The hops on routed backbones can be seen by end users using tools such as
traceroute. On switched backbones, the hops are still there, but can not be
seen by end users. Hence the marketing perception is different though the
results are really the same.

The router side could turn the argument. "With a routed backbone, you can
actually SEE what is happening to your packets. It is not a hidden unknown,
thus prone to failure you can not diagnose. With routers you know it went
bad at nqu1. With switches, it just went bad."

randy

8

Doesnt an IP Switch have lower latency and higher pps?

Is a Cisco running NetFlow any faster then a routed Cisco?

.stb

9

There is one significant difference between routed and switched backbones.
The hops on routed backbones can be seen by end users using tools such as
traceroute. On switched backbones, the hops are still there, but can not be
seen by end users. Hence the marketing perception is different though the
results are really the same.

Actually, from the IP packet's standpoint, no, the results aren't
necessarily the same. It's unlikely, but possible, that a switched
mesh backbone could forward some packets that a routed one couldn't,
due to TTL issues.

Didn't some older kernels set rediculously low TTLs on IP packets?

The router side could turn the argument. "With a routed backbone, you can
actually SEE what is happening to your packets. It is not a hidden unknown,
thus prone to failure you can not diagnose. With routers you know it went
bad at nqu1. With switches, it just went bad."

It's a problem I'd accept for this amount of debugging flexibility,
though.

Cheers,
-- jra

10

Actually, from the IP packet's standpoint, no, the results aren't
necessarily the same.

Indeed. As has been discussed to death many times, each has micro-problems.

Bottom line seems to be that each has its role and personal tastes vary.

Personally, I use both. And, at OC3 and below, I'll take routers. And
soon, that border will be moving.

randy

11

> There is one significant difference between routed and switched backbones.

Doesnt an IP Switch have lower latency and higher pps?

What's an IP switch? If you can define what this is other than a marketing
stunt, I'd appreciate it.

Is a Cisco running NetFlow any faster then a routed Cisco?

No. A cisco router running netflow switching doesn't make it a switch, just as
a cisco router running optimum switching doesn't make it a switch either.

There can be large amounts of confusion that gets created because of marketing
silliness.

All routers and switches forward traffic. When the forwarding decision is
made in layer 3, this is usually referred to as being "routed" and when
forwarding decision is made in layer 2, this is usually referred to as
being "switched".

People also refer to hardware/interface/link layer level forwarding decisions
made in routers as "switching."

Hence, "fast" switching, "optimum" switching, and "netflow" switching in cisco
term, which doesn't make a router a switch.

Most routers have the capability of being switches, while most switches don't
have the capability of being routers. (routers by their function needs to talk
to layer 2, while switches do not necessarily have to)

Since people seem to think that switch has some magically theraputic quality
to network performance I wonder why Bay marketing hasn't started making a big
deal about the fact that their BCNs function as frame relay switches.

See, it's a Switch-Router, and it's a photon accelerator too!

:slight_smile:

-dorian

12

>
> > There is one significant difference between routed and switched backbones.
>
> Doesnt an IP Switch have lower latency and higher pps?

What's an IP switch? If you can define what this is other than a marketing
stunt, I'd appreciate it.

Routes the first packets and switches the rest based on "flows". It
is not dependent on layer 2 or PVC's to determain the correct
route? This is what Ive read from the mfg's who claim higher pps via this
method then straight routing.

I realize this is similair to the C vs C++ argument - C++ is a method
more then a language, IP Switcing is more a routing technique then a
new hardware technology. But is it worth it?

> Is a Cisco running NetFlow any faster then a routed Cisco?

No. A cisco router running netflow switching doesn't make it a switch, just as
a cisco router running optimum switching doesn't make it a switch either.

There can be large amounts of confusion that gets created because of marketing
silliness.

All routers and switches forward traffic. When the forwarding decision is
made in layer 3, this is usually referred to as being "routed" and when
forwarding decision is made in layer 2, this is usually referred to as
being "switched".

People also refer to hardware/interface/link layer level forwarding decisions
made in routers as "switching."

Hence, "fast" switching, "optimum" switching, and "netflow" switching in cisco
term, which doesn't make a router a switch.

Most routers have the capability of being switches, while most switches don't
have the capability of being routers. (routers by their function needs to talk
to layer 2, while switches do not necessarily have to)

Since people seem to think that switch has some magically theraputic quality
to network performance I wonder why Bay marketing hasn't started making a big
deal about the fact that their BCNs function as frame relay switches.

I assume at some level it makes sense to do switching for topology
reasons. But for performance, it is not a benefit?

.stb

13

> What's an IP switch? If you can define what this is other than a marketing
> stunt, I'd appreciate it.

Routes the first packets and switches the rest based on "flows". It
is not dependent on layer 2 or PVC's to determain the correct
route? This is what Ive read from the mfg's who claim higher pps via this
method then straight routing.

Not really. Given the nature of traffic in Internet, the "cost" of flow set up
and maintenance pretty much outweigh whatever gain you get from from
cut-through switching.

This is actually quite similiar to why forwarding caches in routers aren't
very useful in the current Internet.

Now, if the device had specific functions that requires it to perform actions
on per-flow bases on a traffic that was deterministically long flow oriented,
it would be a gain, but this sort of thing is not very useful for the Internet
as we have it.

> Since people seem to think that switch has some magically theraputic quality
> to network performance I wonder why Bay marketing hasn't started making a big
> deal about the fact that their BCNs function as frame relay switches.

I assume at some level it makes sense to do switching for topology
reasons. But for performance, it is not a benefit?

Depends.

-dorian

14

Stephen Balbach <stephen@clark.net> writes:

Routes the first packets and switches the rest based on
"flows".

How is this conceptually different from cisco
fastswitching wherein the slow path is used for the first
packet towards a destination and all subsequent packets
use a cache-based fast path?

In both cases you have a slow cache-set-up path and a
finite cache.

There are significant disadvantages to using a cache in
core routers (look up Dennis Ferguson's comments in your
local NANOG archive, nobody I can think of can improve on
them).

The only principal advantage to cache-based routing is
when you haven't got the power to process all packets
through the same path without drops or mishandling of
things like options and filters, but you do have the power
to do some sort of hashed cache lookup. With luck, this
will not be the case in future routers.

  Sean.