1. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 1 SCPS-TP, TCP and Rate-Based Protocol Evaluation Diepchi Tran, Fran Lawas-Grodek, BobDimond and Will Ivancic wivancic@grc.nasa.gov 216-433-3494

2. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 2 Presentation Outline Goals TCP Over Wireless Links Testbed Layout Test Philosophy SCPS-TP / TCP /Rate-Based Test Results Conclusions

3. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 3 Space-Base Protocol Testing Goal Provide an objective, scientific analysis of currently available and proposed protocols for space-based networks. –Where do they work? –Where do they fall apart? –How can they be improved or fixed? –What is the state of their maturity? Determine which protocol is appropriate for a given scenario. Remove the marketing hype from the space-based protocol discussions.

4. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 4 TCP over Satellite/Wireless Links TCP slow start takes a long time to reach equilibrium –log 2 (bandwidth × delay) round-trip times (RTTs) poor performance over long fat networks particularly for short flows –on retransmission timeout, TCP enters slow start again poor performance over lossy high capacity links TCP infers congestion on all packet drops –even if the loss is due to packet corruption due to noise TCP congestion avoidance throttles source unnecessarily TCP sends a burst of packets when window opens –this can cause congestion drops in intermediate routers

5. Emulated Topology Reliable Transport Protocol Testbed

6. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 6 SCPS-TP / TCP Testing Philosophy Tune and baseline protocol on error-free link for each bandwidth-delay product. –Both SCPS-TP and TCP where tuned for best performance over the given delay. Record all measurements, not just optimal runs! Minimum of 30 runs for congestion friendly protocols and 20 runs for rate-based protocols. Measurement time is from SYN to FIN Run single flows and multi-flows (3 connections) to ensure accurate reporting and application of results. Capture and save some complete trace files – particularly when the unexpected is occurring.

7. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 7 Protocol Test Results

8. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 8 SCPS-TP and TCP Tests Single Stream Baseline with no congestion Multi-Stream with three sources and sinks for congestion control algorithm testing. Solaris Operating System 100 BaseT Interfaces Binomial Error Distributions –1E-8, 1E-7, 1E-6, 1E-5 Packet Size 1024 Bytes Delay –10 msec, 250 msec, 500 msec

9. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 9 Rate-Based Protocols Investigate COTS solutions which tend to be directed at multicast applications –MFDP, MDP, Digital Fountain, others Are commercial implementations available and usable? Are multicast-based implementations overly complex? Should unicast protocols be developed? Congestion is controlled by network owner rather than protocol. Therefore, multi-stream tests where not considered necessary.

10. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 10 Theoretical Steady State Throughput Increasing Delay Delay Tolerant TCP Performance equitation is from Mathis, M. et al, "The Macroscopic Behavior of the Congestion Avoidance Algorithm",Computer Communications Review, volume 27, number 3, July 1997.

11. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 11 Another Example of TCP Steady State Performance Chart is from “Why not use the Standard Internet Suite for the Interplanetary Internet?” By Robert C. Durst, Patrick D. Feighery, Keith L. Scott Don’t Use TCP for long delays. However, one can still use IP and a rate-base protocol.

12. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 12 TCP Throughput at 250 msec RTT Slow Start Phenomena

13. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 13 TCP Standard Deviation for 30 Trials When the first error occurs has a large effect on TCP throughput as shown by the standard deviations for 1E-8 and 1E-7

14. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 14 Protocol Throughput 500 msec Delay / 10 Mbyte File, Single Flow All Rate-Based protocols need work to reach their full potential. Rate-Based

15. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 15 Protocol Throughput 500 msec Delay / 10 Mbyte File, Single Flow Congestion Friendly Rate-Based

16. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 16 Multi-stream Testing of Congestion-Friendly Protocols Necessary –Only truly meaningful test for congestion-friendly protocols (need to add congestion!) –Single stream tests provide baseline, but that is all. Mitre Implementation of SCPS-TP –Many Problems Getting SCPS to operate correctly in multi-streaming configuration. Solaris appears to be most stable system. BSD is very buggy for both SCPS-TP (all cases) and TCP (over long delays). For single machine operation, SCPS has to be recompiled as three applications and then performs load sharing which is undesirable for this emulation. –Using three steams competing for bandwidth. Using three senders and three receivers due to load sharing occurring in SCPS for single machine sending three streams.

17. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 17 Total Throughput for Congestion Friendly Protocols 3 (nearly) simultaneous flows over a 15 Mbps rate limited channel

18. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 18 MDP Tuning (Packet Size 1024 Bytes, Delay 500 msec) Rate Setting Our Operating System and hardware could keep up with the current MDP implementation at rates up to 20 Mbps Greatest throughput achievable at Transmission rate settings of 35 – 40 Mbps Receiver cannot keep up and performance degrades rapidly at transmission settings greater than 40 Mbps

19. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 19 Protocol Throughput – SCPS-TP Pure Rate Based (Ack Every Other Packet, Single Flow, 1024 Byte packets) Performance is delay tolerant, but not completely insensitive to delay. Increasing Delay Initialization and Termination

20. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 20 Conclusions Very small transactions such as command and control should see little difference in performance for TCP or any variant of SCPS- TP or a rate-based protocol. The single stream and multi-stream test results clearly illustrate that the SCPS-Vegas enhancements to TCP provide measurable performance improvements over the TCP SACK implementation tested. –The value of these performance increases is subjective and would need to be judged on a mission by mission basis. In extremely errored environments with high RTT delays, a rate- based protocol is advisable if you properly engineer the network. –Beware of using rate-based protocols on shared networks unless you can reserve bandwidth. –Rate-based protocols may be applicable for any environment where bandwidth reservation is practical and available.

21. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 21 Conclusions Even with equal performance, the deployment of an in-kernel rate-based protocol such as SCPS rate-based protocols may be more desirable than the deployment of MDP or other application level protocols when unicast data delivery is the goal. –The SCPS rate-based protocol is a sending-side only modification; thus, all "standard" TCP applications can be deployed without modification. The existing standard transport protocols and capabilities (drawn from a variety of communities) appear to satisfy all known mission needs; however, the space community should maintain as awareness of current and future TCP research. New TCP research may dramatically improve TCP operation for near planetary environments. –Stream Control Transmission Protocol (SCTP) –TCP Pacing with Packet Pair Probing –TCP Westwood –TCP Explicit Transport Error Notification (ETEN) –Others yet to be identified

22. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 22 Recommendations All rate-based protocols need further testing on faster machines and for different operating systems to determine if that will improve performance or if these protocols need further development. An investigation of SCPS performance under different operating systems and using faster machines is recommended. In addition, using an in-kernel SCPS-TP implementation may result in better performance of the SCPS protocols. For specific environments, SCPS-Vegas should be investigated as the Vegas algorithm has some know problems. –Rerouting a path may change the propagation delay of the connection, and this could result in a substantial decrease in throughput. Therefore, Vegas may not perform well in mobile environments or over intermittent links. –TCP-Reno steals bandwidth from Vegas This could be considered a TCP-Reno problem, but Reno was there first.

23. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division SpaceOps2002, October 9-12, 2002 23 Take Notice SCPS-TP advertises SCPS protocol number for compression, but TCP protocol number for all other transactions. –Allows rate-base transmissions to appear as TCP transmissions –Makes QoS and Queue engineering management problematic SCPS-NP, as specified, will not accommodate the National Security Agency’s High Assurance Internet Protocol Interoperability Specification (HAIPIS); thus, use of SCPS-NP for secure government applications may be problematic.