Links on the blink - reprise

Sat Nov 18 02:02:38 UTC 1995

In message <Pine.SUN.3.91.951117162036.28454M-100000 at tigger.jvnc.net>, Gordon C
ook writes:
> People are starting to tell me that the way out of smashing into the 
> brick wall at 60 miles and hour that the Links on the Blink discussion 
> was worrying about a week ago, is to take cascade or other frame relay 
> switches for the national service providers backbone topology and push 
> routers out to spoke and wheel hubs at the perimiters of the back bone 
> where traffic sent on the backbone at the data link layer (2) can pop out 
> and into the appropriate router for layer 3 routing to the final destination.
> 
> PSI and UUNET have apparently been following this strategy with their 
> backbones for some time.  Netcom has also come on board.  Its advocates 
> say that this combination can scale and avoid the 60 mile per hour brick 
> wall crash.  Are they right?  And if so why aren't sprint and MCI running 
> in this direction and away from purely router based networks as fast as 
> they can?
> 
> If they are why are they wrong?  Where does this architecture fail?  If 
> it fails.
> 
> 
> ********************************************************************
> Gordon Cook, Editor & Publisher       Subscript.: Individ-ascii  $85
> The COOK Report on Internet                Non Profit.          $150
> 431 Greenway Ave, Ewing, NJ 08618          Small Corp & Gov't   $200
> (609) 882-2572                             Corporate            $350
> Internet: cook at cookreport.com              Corporate. Site Lic  $650
> Newly expanded COOK Report Web Pages http://pobox.com/cook/
> ********************************************************************

Gordon,

I don't want to bash any equipment vendors or other service providers.
I suggest you take into consideration who is unstable and what
component or network element of their network is going unstable.  The
brick wall is that a particular piece of equipment from a particular
vendor that a lot of service providers have made a large investment in
doesn't really perform all that well in the real world.

That doesn't mean that piece of equipment is terrible, it just has
some limits.  It is actually a very nice piece of technology if you
can keep within its limits and if keeping within those limits meets
your needs.  It also means some service providers may not have been as
aware of its limits as they should have been and got caught stepping
over the limits on their backbone.  I can think of one service
provider using the same equipment that has managed to keep their
network within its limits and has kept a very stable network.  The
technology we use has some very serious limits too.

wrt your question - There is no real disadvantage to going into a
level 2 cloud if either you are overprovisioned or congestion control
is properly taken into account.  That means neither too much or too
little buffering if using tail drop.  Doing something a little better
than tail drop helps.  Shredding packets into cells and dropping cells
hurts big time.  As long as you are not exceeding the capacity of your
router technology, going with a level 2 cloud has no real advantage
either.  You can screw up in either case if you don't know what you
are doing.

We think there is better chance of working with IP router vendors to
get IP requirements met, particularly in the area of traffic
management since the technologies closer to the telcos tend to have
different ideas about traffic management than the IP world.  Vendors
of the technologies closer to the telcos tend to be averse to
accommodating the dynamics of TCP traffic, to the point of being
hostile toward the idea (suggestions that the solution is to get rid
of TCP, etc).

In terms of capacity, router based backbone nodes are supporting
multiple DS3s.  This is pushing FR already.  If you need to go higher,
you need to go to OC-3 and then you are probably into ATM.  The
problem here is that ATM traffic management available today is an
incredible botch.  Some feel ABR will fix this.  I remain skeptical of
that, but it may work.  For now, you must still build a router based
network using ATM VBR without the "V", by setting PCR==SCR and traffic
shaping not to exceed that.  Happily DS3 still has some life left in it.

One aspect of being a good service provider is understanding the
limits of the technology you are working with and understanding the
upcoming technology that you will be faced with.  You must work with
vendors to make sure you don't exceed the capability of you existing
technology and make sure your vendors understand your needs and take
them into consideration in their next generation technology.  One
aspect of being a good vendor is understanding the needs of your
customer and the limits of your own equipment and responding by
removing the limits before your customers have operational problems.

As far as FR, ATM, router networks or layer 2 clouds goes, different
service providers will choose different paths.  I suggest you take a
look at who has a reputation for understanding the limitation of the
technology and for keeping their backbone stable and take what
everyone says with an appropriately sized grain of salt.  Time will
tell who was right.  I think reporting that one technology is clearly
better would be irresponsible unless you say better at what (equipment
supporting the technology is more mature, more cost effective,
theoretically scales to a higher limit, available products perform
well, under what conditions the technology or available equipment
performs well or poorly, etc).

Curtis

ps - I tried to be fair and hope to avoid any religious wars.