Earl Craighill (ejc%sri-gemini@sri-tsc)
Sun, 30 Mar 86 23:48:20 pst
There is some data on ARPAnet performance for real-time traffic using
type-3 packets. We conducted exercises (experiments on the internet
are VERY difficult to set up or interpret) using packet speech over a
variety of networks (ARPAnet, WB SATnet, Atlantic SATnet, PRnet,
RINGnets, LEXnet) in June of 1983. The sites were NTA in Norway,
Lincoln Laboratory in Lexington, Mass. and SRI in California. We
estimated the likely range of delays in the ARPAnet for two segments--
SRI to LL, and LL to CSS. The maximum time for SRI-LL was 2200 ms.
The minimum route at that time was 11 hops, so the minimum time
(calculated, not measured) was about 300 ms. The LL-CSS route (min.
path 3 hops) was 90 to 550 ms. I won't mention the delays on the other
nets, even the satellite nets look better than the DARPAnet. With
increased traffic, these numbers have to increase. Also, high thruput
wasn't the difficulty since we used low-rate (2400 baud) coded speech.
This data indicates that type-3 wasn't great for real-time traffic. Of
course, the ARPAnet wasn't designed for real-time traffic. But the new
design shouldn't assume that datagrams are the "right" method for low
delay service. Further, flow-control algorithms may protect the
network as a whole, but won't help low-delay service, especially with
the anticipated growth in traffic (however, we did make effective use
of feedback from the PRnet to throttle back our offered rate). What is
needed is flow-enhancement, say, some sensible use of priority in PSN
queue management. Our experiments on the PRnet indicate that some
portion of "preferred" traffic can be supported without bringing the
network to its knees.
I would encourage more experimentation, especially at the subnet level.
Our measures were very coarse and could not identify reasons for the
high delays (imps throwing away packets, long holding times in queues,
rerouting because of congestion, ??). The current picture does not
look good. Hopefully, some experimental data may lead to a different
transport mechanism that will provide low-delay service.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:05 GMT