1. SCPS-TP, TCP and Rate-Based Protocol Evaluation
Cindy Tran, Fran Lawas-Grodek, Bod Dimond and Will Ivancic

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

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

5. Reliable Transport Protocol Testbed
Emulated Topology
Reliable Transport Protocol Testbed

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. Protocol Test Results

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. 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. Theoretical Steady State Throughput
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.
Delay Tolerant
Increasing Delay

11. Another Example of TCP Steady State Performance
Don’t Use TCP for long delays.
However, one can still use IP
and a rate-base protocol.
Chart is from “Why not use the Standard Internet Suite for the Interplanetary Internet?”
By Robert C. Durst, Patrick D. Feighery, Keith L. Scott

12. TCP Throughput at 250 msec RTT
Slow Start
Phenomena

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. Protocol Throughput 500 msec Delay / 10 Mbyte File, Single Flow
All Rate-Based protocols need work
to reach their full potential.

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

16. Protocol Throughput 250 msec Delay / 10 Mbyte, Single Flow
Slight improvement in Congestion Friendly Protocols
At 250 msec vs 500 msec Delay

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

18. MDP Tuning (Packet Size 1024 Bytes, Delay 500 msec)
Receiver cannot keep up and performance
degrades rapidly at transmission settings
greater than 40 Mbps
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
Rate Setting

19. Performance is delay tolerant, but
Protocol Throughput SCPS-TP Pure Rate Based – Ack Every Packet, Single Flow
Increasing Delay
Initialization and
Termination
Performance is delay tolerant, but
not completely insensitive to delay.

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

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

22. 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).