Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!oberon!cit-vax!ucla-cs!zen!ucbvax!TSCA.ISTC.SRI.COM!ejc
From: ejc@TSCA.ISTC.SRI.COM
Newsgroups: comp.protocols.tcp-ip
Subject: Re: ARPAgrams
Message-ID: <8710161219.AA03576@milk4>
Date: Fri, 16-Oct-87 08:19:43 EDT
Article-I.D.: milk4.8710161219.AA03576
Posted: Fri Oct 16 08:19:43 1987
Date-Received: Sat, 17-Oct-87 19:27:42 EDT
References: <[A.ISI.EDU]15-Oct-87.20:35:55.CERF>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 35


It would be a great improvement to have another transport flavor
available for wire subnets, but I think more than a minor tuning of
current protocols is required.  First, a bit of history..  Type 3 had
the appearance to the user of the characteristics described by Dave.
However, the way it was done did not improve the real movement of
packets within the ARPAnet itself.  The only difference between type 0
(normal) and type 3 (best efforts) was the initiating IMP did not wait
for a RFNM before sending packets.  The result was that more than eight
packets could be in the net simultaneously.  This reduced the delay
variance somewhat to allow us to experiment with packet voice, but had
the potential of creating havoc in the sub-net.  The variance was still
large (from SRI to LL, 400ms< T < 2200ms) although quite less than type
0, and thruput low < 10 kb/s user data).  Not great real-time
performance, since the buffering strategies in the speech terminal
would introduce additional ETE delays to smooth out the variance.
Hence, the maximum delay (in this case 2200 ms) became the actual ETE
delay.

If one wants to provide such a service, you will need more than flow
control.  I would guess that flow control alone might reduce delay
variance, but likely push the mean toward the high end of the
distribution.  Our terminal buffering strategy did that anyway.  You
will need to figure out how to move SOME subset of packets through the
net faster, either by queue priorities, some type of VC reservation, or
something else.  But it is a major departure from datagram mode.

Hence, the subnet would need to support two different kinds of
transport protocol simultaneously.  The PODA scheme in the WB SATnet is
the only operational subnet transport protocol that I know of that
offers this.  Is there a serious interest/desire in developing such a
capability in wire subnets?  Packet voice is only one of several
applications that need real-time (low, bounded delay) transport.

Earl