The vBNS test network connects PSC to Washington DC and Richardson TX.
The CPE at PSC consists of:There are also GDC ATM switches within the MCI ATM fabric.
We tested the network by sending two ~65 Mbit/s data streams from the alpha at PSC to the alpha at Washington. By adjusting the routing we can arrange almost any interface to be the bottleneck.
The first stream is inelastic:
The second stream is TCP:
For the data labeled Cisco AIP (which is the lower of the two data plots), the two streams were routed from one alpha to the Cisco via different FDDI rings. The streams converged at the Cisco AIP card, which was the bottleneck (only about 15 Mbit/s slower than full OC-3 ATM).
For the data labeled LightStream (which is the top-most of the two data plots), one stream was routed via one FDDI ring and the NetStar, the other stream via the other FDDI ring and the Cisco, such that the bottleneck was the wide area interface on the LightStream. In this case the LightStream was the bottleneck at (exactly?) full OC-3 ATM rates.
Dennis Ferguson stated that the GDCs were configured such that they could not be the bottleneck.
This is measured (NOT SIMULATED) data.
The X axis is the TCP socket buffer size. This determines "maxwnd", the largest permitted value for "cwnd" the TCP congestion avoidance window. If TCP does not experience any loss, it runs with a fixed window size equal to maxwnd.
The transfer sizes are 100*maxwnd. e.g. the rightmost data point represents a 100 Mbyte transfer.
The front (left) face reflects the delay of the path. 60 Mbit/s at 130 kByte window indicates a RTT of 17.3 ms.
The flat top indicates the bottleneck bandwidth. We believe that it was so flat because there was at most one lost packet.
The width of the flat top indicates the amount of queue space held by TCP before the onset of congestion (packet loss caused by an over full queue.) Note that this is not the total queue space: The UDP stream may be presumed to hold a like amount of space.
At the 650 kByte maxwind, the LightStream is running at full OC-3 rates with a constant 400 kBytes of standing TCP data in its queue!
The drop to the right is caused by Reno TCP's behavior in the presence of bursts of loss.
These graphs were selected because they might be of interest to the community: do not assume that results that we chose not to present are any less interesting.
Most of this data was collected by Jamshid Mahdavi.
In this test environment the routers and ATM switches are capable of sustained lossless operation at their full rate with large standing queues. There is no reason that we should expect anything less from the production Internet.
The vBNS will be an OC-3 network running IP over ATM. There will be five supercomputer centers on this networks. It will also connect to all NSF designated NAPS and others if necessary for reliability.
Cisco routers with dual FDDI attachments and at the NAPs will be used. The AIP card is being used at OC3c. Netstar Gigarouters are also at the Supercomputer centers using dual FDDI plus HiPPI attachements. Lightstream ATM switches are also at the supercomputer centers in support of the NAP attachmetns and at other places in the network. The vBNS is supported as a service on MCI;s ATM backbone network which is constructed of (GDC switches). The Gigarouters are interesting boxes, but they may not quite be ready for prime time and so the Cisco is a fall back. MCI is taking delivery of the equipment now. It is scheduled for installation in two weeks (Dennis does not really believe this date). Operation for testing and shakeout in early March. It will hopefully be operational on April 1, 1995.
To test this, a two node test network was constructed. This has been operational since Christmas between Washington and PSC. Static routing is done in the two ATM layers so that the IP layer will do any rerouting necessary if a circuit fails. At the IP layer, OSPF will run over an over full PVC mesh between the routers. External IP routing propagated using a full IBGP mesh (since only 16 or 17 routers are in use, this is not a big deal).
Matt is using Alphas to generate both TCP and UDP packets. The UDP is generating about 65.6Mb/sec. Matt showed that he was able to fill up OC3c for max window sizes up to .65 x10 to the 6.
