Subject: ATM, state in the network, etc...

From: [email-masked] (Noel Chiappa)
Date: Fri, 25 Mar 94 12:06:17 -0500

From: Christian Huitema

    > the only folks we have to convince are those folks who believe ATM is a
    > bad idea, and based on the frequency which which ATM is mentioned
    > favorably on IETF lists, I suspect the folks who think ATM is a bad
    > thing constitute less than half the IETF.... :-)

    not to mention a number of folks who believe that ATM is a bad idea

Be careful here. There are a number of people who want to introduce more
awareness of traffic streams into the network (by increasing the amount of
non-critical state inside the network) such as Dave Clark, me, etc, but still
think the particular instantiation of ATM is a Broken Idea (for various
complex reasons I'll pass over now).

    because it is based on a circuit-switching paradigm, which is not needed
    for integrated services.

I'm not sure exactly what your definition of "circuit-switching" is (I don't
consider even X.25 to be "circuit-switched"), but I think it's important to
point out that there are pretty substantial fundamental differences (e.g. in
where critical state is stored, and how resources are allocated) between the
classical examples of circuit-switched networks, and new designs such as both
ATM and flows.

    In fact, I believe that a lot of what ATM is claimed to provide, e.g.
    phone circuits or video circuits, can easily be achieved with conventional
    datagram IP.

Sure, in a lightly loaded network, with no special user policy requirements,
conventional datagrams can do a lot. However, our current widely deployed
applications (telnet, mail, FTP, etc) respond reasonably well (thanks to Van)
to sudden drops in the available resource level caused by traffic
fluctuations: so your file transfer slows down, big deal. Real-time
applications may not respond as well.

I'm sure I don't need to remind you of the long history of packet voice and
video work on the Internet, ranging back to packet voice work done on the
ARPANet. We're not working purely from theory here. What seems to have been
the universal experience is that a lot of variance in delay or bandwidth makes
these applications basically not work, and that while unloaded datagram
networks don't display those variances, loaded ones do.

Then there are all the other reasons to put more non-critical state in the
network, as packet processing becomes more complex as we add on security,
policy, authentication, etc, etc. We're *already* seeing soft state in
routers, it's just state that they infer by watching the packet stream.

My thinking is, why force the router to jump through hoops trying to
reconstruct the soft state it needs from poring over packets; why not just do
it explicitly? In the long run it'll be simpler; my system design experience
has been that doing anything by a round-about way eventually comes back to
bite you.

    for classic audio or video application, in a point to point or small group
    environment, it is possible to design applications that adapt dynamically
    to the network's quality of service.

Sure, within a range. However, there's usually a rate floor below which you
just can't go. That's not true of, say, FTP.

	Noel