Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site petrus.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!karn
From: karn@petrus.UUCP (Phil R. Karn)
Newsgroups: net.dcom
Subject: Re: Re: Re: Standards for commercial pac
Message-ID: <514@petrus.UUCP>
Date: Tue, 3-Sep-85 22:00:27 EDT
Article-I.D.: petrus.514
Posted: Tue Sep  3 22:00:27 1985
Date-Received: Thu, 5-Sep-85 00:41:43 EDT
References: <678@wdl1.UUCP> <513@petrus.UUCP>
Organization: Bell Communications Research, Inc
Lines: 34

Here's some more information about Telenet that might be interesting.  As I
understood an explanation given by one of their employees at an amateur
packet radio conference last fall, each of their packet switches appears as
a self-contained X.25 "network", and these switches speak to each other with
X.75.  (X.75 was intended as an "Internetwork" protocol for the
interconnection of X.25 networks owned by different operators, but it, like
the DoD "Internet" Protocol, can also be used internally within individual
networks as well.)

Once an initial connection is established, the packet switch translates the
VC identifier in each arriving packet to the proper identifier for the
correct outgoing link, and sends the packet.  This operation applies to flow
control (RR/RNR) as well as data packets. What this means is that regardless
of the setting of the D-bit, flow control in Telenet is done on an
end-to-end basis. (The "D", or "Delivery Confirmation" bit is supposed to
control whether X.25 DCE packet level acknowledgements indicate that the
packet has been accepted by the network or whether it has actually been
delivered to the other DTE.)

The result of this is that you can never have more than W (the window size,
typically 2) packets in flight at any one time on each virtual circuit.  The
carrier likes this, since it alleviates his congestion problems, but the
user hates it because it puts an upper bound on his throughput. This is also
the reason why the CSNET software is forced to open multiple, parallel
virtual circuits in order to get reasonable throughput. Of course, only
those of us who run datagram protocols above X.25 are able to pull this
trick; everybody else has to put up with lousy throughput.

Once this is done, I don't see any easy way for the network to control
potential congestion if resources are limited. Maximizing user throughput
and preventing network congestion seem to be in fundamental opposition,
and virtual circuit network protocols are no panacea.

Phil