RE: Internet II is coming...

[Sean Doran <smd () cesium clock org>]

| The institution in the situation you describe, procure an ATM interface to the
| provider.  Have the provider two PVC's.  Set both PVC's for EPD.  Contract
| the Researchers PVC as a VBR PVC, and contract the other as a ABR or UBR
| PVC.

In other words, somewhere close to the edge of a network fabric,
some router is making a decision based on things like origin/destination
or protocol number or what-have-you to send traffic across a point-to-point
line instead of the Internet.

Instead of building a real point-to-point line, you build a
PVC using ATM, and then play games to make sure the ATM fabric
does the right thing or some approximation thereof if there
is contention in the ATM fabric.

In the brave new world of an ATM-free future (assuming the ATM people
don't get _cheap_ SVCs out the door before we get the "Peter-Tony Protocol" 
model deployed), you can do the same for less cost by pulling a 
tributary out of your SONET MUX at the appropriate bandwidth, and 
doing policy-based routing using your favourite vendor's NetFlow switching
or some future tag-switching-like system or the equivalent.
This is your PVC, no EPD or PPD needed.  Cells?  What are those?

All each approach is doing is source-routing across different paths, making
a decision somewhere close to one or both edges of a given fabric.

This could as easily be accomplished by having a fabric made
up of either multiprotocol routers which deal with IPv4 and
something else which does source-routing, or of routers which 
have the time budgets to do Christmas-tree packets (all decorated with options).
If you make decisions to do different queue/drop algorithms 
based on something decided at the edge of a fabric, or at a host, 
then you might not even necessarily need any sort of separate
infrastructure to meet most reasonable QOS-like demands.

This is your *BR game-playing with ATM, for dealing with contention.

The separate circuit model has an attraction in that you can
avoid having Special Traffic move normal traffic out of the way,
and you avoid paying a huge penalty in routers in the core of
the best-efforts Internet, both of which are serious problems in
efforts like RSVP.

A mix of separate circuit/parallel infrastructure vs. smart
queuing in IP routers should really be done using the appropriate
parts: real circuits and real routers.   Playing games with ABR
and friends introduces the problems of disconnected resource
consumption feedback loops (TCP vs ABR, for example), which 
tend to compete with each other in nasty ways.

Temporary circuits of whatever flavour have an attraction in
that you can get a mix of parallel infrastructure and smarter
infrastructure without necessarily incurring enormous cost,
and without worrying about byzantine billing for normal Internet
traffic.  This is coming, both for ATM and for non-ATM models.

Finally, I assert that we are already at the point where anything 
that can be deployed today that is based on ATM (which incidentally 
typically rides over SONET/SDH) can be kludged up (or even done right) 
with Cisco gear and SONET/SDH.  ATM has a temporary edge in being
multivendor and making it easy to do TDM-style and point-to-multipoint
things, however the former is likely to be short-term and the latter
is something that can be done better for Internet traffic anyway,
with a bit of cleverness in the latest and in the next generation
of IP routers.

Since these routers will be needed with or without ATM, the time
to ponder whether ATM really has that much added value in the
long run is upon people already.

        Sean.
- - - - - - - - - - - - - - - - -