# Presentation: 186746

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

**Cindy Tran, Fran Lawas-Grodek, Bod Dimond 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

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

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

## Protocol Throughput 250 msec Delay / 10 Mbyte, Single Flow

**Slight improvement in Congestion Friendly Protocols **
**At 250 msec vs 500 msec Delay**

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

**The smaller the file, the more important **
**the startup algorithms become **
**– ****except for EXTREMELY small transactions**
**such as command and control.**

## 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 Packet,  Single Flow

**Performance is delay tolerant, but**
**not completely insensitive to delay.**

## Multi-stream Testing of Congestion-Friendly Protocols

- Necessary
- Only truly meaningful test for congestion-friendly protocols (need to add congestion!)
- Single steam tests provide baseline, but that is all.
- Work in Progress
- 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.

## SCPS Gateway

- Working on evaluation of SCPS gateway using MITRE provided code.
- Gateway is operation
- Testing is just beginning

## 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.
- From the single stream tests and preliminary multi-stream tests, there does not appear to be a significant advantage to deploying SCPS-TP over TCP.
- 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.
- All rate-based protocols need tested work and/or faster machines to reach their potential.
- For the commercial rate-based protocols tested, this may be due to their algorithms and coding being optimized for multicast operation.
- New TCP research may dramatically improve TCP operation for near planetary environments.
- TCP Pacing with Packet Pair Probing, TCP Westwood,  TCP Explicit Transport Error Notification (ETEN).