SONET Interconnect (was RE: MCI)

Fri Mar 29 15:04:56 UTC 1996

Gentlemen,

I was reading this thread with interest and perhaps I have missed
something...... but here is what comes to mind;

As pointed out by Zhang et. al. in the late 80's, real-time applications
over a store-and-forward datagram service is very problematic 
because IP is a best-effort service and there are no bandwidth/delay
guarantees in the IP paradigm.

ST-II build another unreliable service (with a smaller IPv5 header)
and created an odd-ball, no tool set, ST/SCMP paradigm that
continues to be unreliable without addition transport services.
Hence, the goal of a real-time QoS for datagrams over a routed
topology was not reached.

RSVP, building with lessons learned from ST-II and the added
IP feature of interdomain multicasting, has a better chance to
survive and to become accepted on a wider scale because
it is built on IPv4 with existing IPv4 tools and toolsets.
But never-the-less RSVP cannot guarantee packet delivery
and completely reliable real-time services.  Resource reservation
does *not* guarantee a time-critical packet arrives from
source to sink and requires a transport protocol (like TCP
or some other flow control).

Therefore, for applications where packet loss is acceptable, 
RSVP works; but in a real-time distributed internetwork
where data MUST be delivered within a specific QoS, RSVP
hold little real promise.  On the other hand, for many applications
of datagram voice and video, packet losses are acceptable
so RSVP/IP is acceptable as well.

On the other hand, ATM (based on the original ATM charter) was envisioned
to offer a guaranteed QoS.  As pointed out by numerous people in
this thread and before, IP/ATM is not efficient; and it is for
this reason and others that many IP protagonists love to bash
ATM, and with good reason from an IP perspective.

But, will all the cross fire and debate raging and the ATM - IP
debate raging the fact remains:

There is no current architecture to *guarantee* a close to zero
packet loss in the IP world.   

Do we need a real-time protocol that is highly reliable in the
world?  The answer, is of course YES.  Will a datagram service
ever provide the .99999++++  delivery service required by
distributed, network based real-time systems?  Maybe.
But IP based solutions alone will more-than-likely not
solve the problem.

Finally, as pointed out TCP/IP/ATM is not efficient.  On the other
hand, transmitting packets, losing them in the network and
retransmitting them or just dropping packets from the stream
is not the most efficient method of delivery either.  

Highly efficient, guaranteed packet delivery services with a
close to zero packet loss is an oxymoron and does not exist
and will not exist with RSVP (but will help but not to 
.99+++ as required by real-time network services).

On the other hand, it is possible that a transport technology
that can deliver a guaranteed QoS under IP will work,
perhaps inefficiently, but it can deliver real-time data.

I am not necessarily a protagonist for ATM, and my personal
opinion is that ATM is too complex and tries to be all things
to everyone, and that rarely if ever works.  But, there are
real-time applications where unreliable datagrams with
heavy transport protocol overheads similar to TCP/IP
are undesirable as well; and this paradigm is not so efficient
either.

Best Regards,

Tim

postscript:

The reader is invited to read and comment on a draft paper
http://www.silkroad.com/working/stii-rsvp.ps related
to this subject (but not addressing the ATM issue).

+------------------------------------------------------------------------+
| Tim Bass                           |                                   |
| Principal Network Systems Engineer | "... the fates of men are bonded  |
| The Silk Road Group, Ltd.          |  one to the other by the cement   |
|                                    |  of wisdom."                      |
| http://www.silkroad.com/           |                Milan Kundera      |
|                                    |				         |
+------------------------------------------------------------------------+