Mills@UDEL.EDU (10/15/87)
For BBN, DARPA, DCA, DDN, NSF and all the ships at sea: When are we going to get ARPANET Type-3 packets back? It would surely be much more efficient, cheaper and less intrusive in the long run if ARPANET and clones understood connectionless service. [ARPANET Type-3 packets were once used for datagram experiments, but have fallen down a hole along the way. They had a max packet size of about 1K bits and no flow control at all. Obviously my plaintive hoot implies fatter, controlled datagrams or ARPAgrams.) Dave P.S.: Where are you, Jack Haverty, now that we need you most? DLM
CERF@A.ISI.EDU (10/16/87)
Dave, if you get type 3 back it will have to be as a result of putting in some kind of flow control in the IMP-IMP and IMP/HOST interface. What would type 3 look like through an X.25 interface, or would you limit this capability to 1822 interface users? Vint
ejc@TSCA.ISTC.SRI.COM (10/16/87)
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
Mills@UDEL.EDU (10/17/87)
Vint, Details, he sez. How 'bout an extended X.25 header like the amateur packet radio AX.25 where the extended address fields encode the ARPANET address and where flow control can be effected by the usual LAP-B window? No call-control packets. Separate implied window for each distinct ARPANET address, as now. Sure, this is likely to turn some sheets to the wind, but there are lots of variations and you can stand upwind if necessary. Dave