Re: int-serv over e.g. ATM

[Mark W Garrett <[e-mail]>]

Steve,

 > It's not especially uglier than any other VC-oriented, large-cloud
 > technology, like X.25 or ISDN.

 > What's your idea of "working right"?  Why should the Internet architecture
 > be changed to accommodate ATM, when we didn't feel compelled to change it
 > to accommodate X.25 or ISDN?  What's so special about ATM that should
 > cause us to treat it as anything *other* than just another subnet du jour?

The hope is that ATM will be much more successfully deployed
than X.25 and ISDN.  However, if you want to wait until that
success is more apparent, I'd have to say that's reasonable.
It's clear that there *is* adequate effort focused on the
routing issues, from rolc, ipatm and MPOA.

On the Traffic Management side, note that X.25 and ISDN do
not have differentiated QOS.  So ATM is a new animal.  The
ATM crowd will certainly come to this discussion thinking
that they just put all these great features into the ATM
technology, only to have them hidden from the applications
by a layer of abstraction that may or may not be powerful
enough to take advantage of them.  So the real issue might
be that ATM folks are saying, ``1) here's the first network
technology to have meaningfully differentiated QOS; 2) as
Internet develops QOS capability it should consider ATM to
be special''.  And the IP folks response is that no, ATM is
not special since it fits into the model just as any other
subnet.  Now, maybe the current IP model is general enough
that implementations which follow it will naturally take
full advantage of ATM's QOS capabilities.  The IP architecture
itself is a bit of a red herring in this, because obviously
both good and bad implementations can be made consistent with
the overall model.

I think the int-serv group's approach has been to get their
own house built before going to meet the neighbors, which is
fine for now.  From the recent responses it looks like a
number of significant efforts will occur in the next year to
evaluate the interoperation of ATM QOS and IP QOS.


 > I agree with your distinction.  In my previous message, I used the phrase
 > "the module that processes RSVP", as an attempt to avoid layer connotations.
 > Does that help?

Well, I'm not the one to choose a name for it, as long as
the distinction starts soaking into our common language.
We'll get better names for things as all this gets fleshed
out.

-Mark

-------------------------------------------------------------------------------
			Bellcore   Rm. 2L-237			[phone]
Mark W. Garrett		445 South St.			[e-mail]
			Morristown NJ 07960-6438  USA	     (FAX [phone])
                        WWW: ftp://thumper.bellcore.com/pub/mwg/homepage.html
-------------------------------------------------------------------------------