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!ucbvax!decvax!bellcore!petrus!karn
From: karn@petrus.UUCP (Phil R. Karn)
Newsgroups: net.dcom
Subject: Re: Re: Re: Standards for commercial pac
Message-ID: <549@petrus.UUCP>
Date: Tue, 17-Sep-85 13:09:13 EDT
Article-I.D.: petrus.549
Posted: Tue Sep 17 13:09:13 1985
Date-Received: Thu, 19-Sep-85 05:20:20 EDT
References: <678@wdl1.UUCP> <513@petrus.UUCP> <231@gipsy.UUCP>
Organization: Bell Communications Research, Inc
Lines: 64

> Please don't try to revive the old VC/D.gram polemic! Refer to the
> litterature instead.

Actually, I think the real issue here is whether you should have some form
of resource preallocation in your network. This affects the datagram/VC
choice, because VC networks allow for preallocation at circuit setup time
while datagram nets can't.

I've done a lot of thinking about this issue lately and am fast coming to
the conclusion that if you REALLY need guaranteed bandwidth after "circuit
setup", then you want an ordinary circuit-switched network, not packet
switching.  If your traffic has a peak-to-average ratio near 1 for long
periods of time, or if you're willing to pay extra for reserve idle
bandwidth, then circuit switching is clearly superior to any form of packet
switching, be it datagram or virtual circuit.

Packet switching is meant to statistically multiplex for transmission
traffic from a collection of users whose individual requirements are
unpredictably bursty.  As you pool more and more users, however, the law of
large numbers means that the aggregate traffic becomes more and more
predictable. Therefore as public data networks grow and their links increase
in bandwidth, I think that the need for "preallocation" will decrease
considerably.

Preallocation of buffer space is, I think, an obsolete issue. Maybe this was
important at one time when memory was expensive, but now there's little
reason why packet switches cannot be given so much memory that they almost
never have to drop packets or invoke congestion control. Delays may get
large, but only if there isn't enough transmission bandwidth to go around.

> At INRIA we experimented with LAN-satellite connections; the first
> design used a datagram based gateway for "transparent" interconnection.
> However we found out that the efficiency was poor, as the gateway had to
> trow away packets when the load increased.

Only because you didn't have enough buffer space in your gateways.

> Thus, in the next design, we have
> implemented X25 on top of Ethernet, which allows for an easy interconnecton
> to the outer world, and for a much more efficient usage of external
> connection. This will not cause an undue overload for local communications,
> as we can use the "class 0" transport protocol, i.e. no end to end
> acknowledgments. X25 allows you to optimize windows and packet sizes on each
> subnetworks.

I'm not willing to live dangerously and trust assurances of reliability from
any network, even Ethernet. Therefore I'm not willing to give up using a
transport protocol with end-to-end acknowledgements, like TCP.  Worrying
about protocol overhead on a 10 mb/s LAN, where the minimum packet size
is 60 bytes anyway, is silly.

The best way to improve efficiency (i.e., reduce the effects of protocol
header overhead) on ANY network is to send fewer, larger packets.  This will
have a much greater effect than trying to trim down the header sizes,
because it will also reduce packet switch CPU requirements.

> The last, but not the least, advantage of X25 is that all public data
> networks are interconnected, and that one can establish a direct connection
> with virtually any computer in the world. 

The same is true of the public telephone network, but it doesn't mean
that it's ideal for my purposes.

Phil


Brought to you by Super Global Mega Corp .com