SCPSTP, TCP and RateBased Protocol Evaluation

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

• Diepchi Tran, Fran Lawas-Grodek, BobDimond and
  Will Ivancic
• wivancic_at_grc.nasa.gov
• 216-433-3494

2
Presentation Outline

• 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
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
AvoidanceAlgorithm",Computer Communications
Review, volume 27, number 3, July 1997.
Delay Tolerant
Increasing Delay
11
Another Example of TCP Steady State Performance
Dont 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.
Rate-Based
15
Protocol Throughput 500 msec Delay / 10 Mbyte
File, Single Flow
Rate-Based
Congestion Friendly
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
Total Throughput for Congestion Friendly
Protocols3 (nearly) simultaneous flows over a 15
Mbps rate limited channel
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
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.
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
Conclusions

• The deployment of an in-kernel protocol may be
  more desirable than the deployment of an
  application level protocol, for more efficient
  use of resources and performance issues. However,
  one may also argue, that it is far easier to
  maintain a protocol at the application level than
  within a kernel.
• 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
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
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 Agencys High Assurance
  Internet Protocol Interoperability Specification
  (HAIPIS) thus, use of SCPS-NP for secure
  government applications may be problematic.