Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!genrad!decvax!ucbvax!engr.ub.COM!dcrocker
From: dcrocker@engr.ub.COM.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Packet network reliability
Message-ID: <8703311555.AA20531@ucbvax.Berkeley.EDU>
Date: Tue, 31-Mar-87 10:14:33 EST
Article-I.D.: ucbvax.8703311555.AA20531
Posted: Tue Mar 31 10:14:33 1987
Date-Received: Thu, 2-Apr-87 05:00:29 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: Ungermann-Bass, Inc., Santa Clara, CA
Lines: 52
Approved: tcp-ip@sri-nic.arpa

In article <8703250201.AA06443@flash.bellcore.com>
	karn@FLASH.BELLCORE.COM (Phil R. Karn) writes:

>... In "unlayered virtual circuit" networks, connection
>state information is kept not only in the end-point switches, but also in
>every intermediate switch along the path.
>... Because of this, a node or link failure ANYWHERE along the
>connection path causes an X.25 VC reset, not just failures at the end nodes.
>
>Only in "layered VC" networks such as the DDN (where datagrams are used
>internally) can intermediate node and link failures occur without resetting
>virtual circuits.  ...

Don't know how much this will contribute to the discussion, but you pushed
one of my buttons:

There are two issues often treated as one:  Virtual Circuit vs. Datagram
underlying architecture, and Robust vs. Fragile handling of major network
anomolies.

It is common for VC-oriented nets to be relatively more Fragile than
the DG-oriented ones, but that definitely is not necessary.  It has more
to do with certain economies that are perceived by the implementors.

X.25 vendors are excellent examples of the VC/Fragile orientation.  By
virtue of being very cost-conscious, they pay very close attention
to such things as packet-handling "efficiencies" and buffer management.
The handling efficiency question walks them down the path of internal
VC orientation.  (Common belief:  The processing overhead to forward a
packet in a VC-oriented system is lower than in a DG-oriented one.)

The buffer management question makes them give up a buffer as soon as the
"next" hop has acknowledged it.  That is, the only copy of the data
exists at the latest node to have accepted it.  If that node goes down,
the copy is lost.

Your note used the term "end to end reliability".  That is exactly the
issue.  The sending node must hold onto a copy of the data until the
receiving node acknowledges deliverying it to the destination host.
If it does this, than an internal X.25 Reset (for example) could be
transparently recovered from, by re-routing the circuit automatically.

A few years ago, I tried to get Databit (Siemens) to modify their
X.25 packet switches to permit holding on to the packet at the sending
node, until a final ack was received.  They were not willing to consume
buffers for that long.

By the same token, BBN could modify their switches NOT to hold on to
packets at the source PSN.  At that point, a number of problems internal
to the net would become highly visible to users.

Dave