# Presentation: 803210

## SCPS-TP, TCP and Rate-Based Protocol Evaluation 

**Diepchi****  Tran, Fran Lawas-Grodek, BobDimond and Will Ivancic**
**wivancic@grc.nasa.gov**
**216-433-3494**

## Presentation Outline

- Goals
- TCP Over Wireless Links
- Testbed Layout
- Test Philosophy
- SCPS-TP / TCP /Rate-Based Test Results
- Conclusions

## 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.

## TCP over Satellite/Wireless Links

- TCP slow start takes a long time to reach equilibrium
- log2 (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

## Emulated Topology

- Reliable Transport Protocol Testbed

## 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.

## Protocol Test Results

## 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

## 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.

## Theoretical Steady State Throughput

- Increasing Delay

- Delay Tolerant

- TCP Performance equitation is from Mathis, M. et al, "The Macroscopic Behavior of the Congestion AvoidanceAlgorithm",Computer Communications Review, volume 27, number 3, July 1997.

## 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.**

## TCP Throughput at 250 msec RTT

- Slow Start
- Phenomena

## 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**

## Protocol Throughput 500 msec Delay / 10 Mbyte File, Single Flow

**Protocol Throughput ****500 msec Delay / 10 Mbyte File, Single Flow**

**All Rate-Based protocols need work**
** ****to reach their full potential.**

- Rate-Based

## Protocol Throughput 500 msec Delay / 10 Mbyte File, Single Flow

**Protocol Throughput ****500 msec Delay / 10 Mbyte File, Single Flow**

- Congestion Friendly

- Rate-Based

## 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.

## Total Throughput for Congestion Friendly Protocols3 (nearly) simultaneous flows over a 15 Mbps rate limited channel

## 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**

## 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.**

## 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.

## 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

## 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.

## 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.