Transcript Powerpoint - Syzygy Engineering

Communications Technology Division
Glenn Research Center
Satellite Networks & Architectures Branch
SCPS-TP, TCP and Rate-Based Protocol
Evaluation
Diepchi Tran, Fran Lawas-Grodek, BobDimond and Will Ivancic
[email protected]
216-433-3494
SpaceOps2002, October 9-12, 2002
1
Presentation Outline
Glenn Research Center
•
•
•
•
•
•
Communications Technology Division
Satellite Networks & Architectures Branch
Goals
TCP Over Wireless Links
Testbed Layout
Test Philosophy
SCPS-TP / TCP /Rate-Based Test Results
Conclusions
SpaceOps2002, October 9-12, 2002
2
Space-Base Protocol Testing Goal
Communications Technology Division
Glenn Research Center
Satellite Networks & Architectures Branch
• 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.
SpaceOps2002, October 9-12, 2002
3
TCP over Satellite/Wireless Links
Communications Technology Division
Glenn Research Center
Satellite Networks & Architectures Branch
• 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
SpaceOps2002, October 9-12, 2002
4
PUBLIC
INTERNET
Reliable
Transport
Protocol Testbed
Emulated
Topology
Testbed Isolation point
ONE Implementation Diagram
Ka Band Testbed
Net: 10.0.8.x
1
TER2(NetBSD)
IP: 10.0.1.4
10.0.100.4
TER3 (Solaris)
IP: 10.0.1.5
10.0.100.5
10.0.1.x ISINT Terra Network
10.0.100.x Network
TER1 (NetBSD)
IP: 10.0.1.3
10.0.100.3
fffff
3
1
GRC
PBX
2
3
Delay and BER
Facilities
1. TER-rtr1 - 10.0.1.1 (100BaseT Ethernet)
2. TER-rtr2 - 10.0.3.1 (100BaseT Ethernet)
3. TER-rtr3 - 10.0.5.1 (Terra VOIP Circuit)
4. TER-rtr4 - 10.0.7.1 (OC-3 Circuit)
5. TER-rtr5 - 10.0.8.1 (HSSI/RF Circuit)
SPC-demo
(WIN NT/98)
IP: 10.0.2.2
Cisco 7100
O.N.E. DELAY
SIMULATOR
Net: 10.0.3.x
2
Terrestrial Router Interfaces
PSTN
4
SPC1 (NetBSD)
IP: 10.0.2.3
10.0.100.6
SPC2 (NetBSD)
IP: 10.0.2.4
10.2.100.7
SPC3 (NetBSD)
IP: 10.0.2.5
10.0.100.8
Space Router Interfaces
1. SPC-rtr1 - 10.0.2.1 (100Baset Ethernet)
2. SPC-rtr2 - 10.0.3.4 (100Baset Ethernet)
3. SPC-rtr3 - 10.0.6.1 (Space VOIP Circuit)
4. SPC-rtr4 - 10.0.7.2 (OC-3 Circuit)
5. SPC-rtr5 - 10.0.8.2 (HSSI/RF Circuit)
Network
Cisco 7100
5
10.0.100.x
4
TER-demo
(WINNT/98)
IP: 10.0.1.2
SX/14 DELAY
SIMULATOR
Net: 10.0.7.x
10.0.2.x ISINT Space Network
5
SCPS-TP / TCP Testing Philosophy
Glenn Research Center
Communications Technology Division
Satellite Networks & Architectures Branch
• 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.
SpaceOps2002, October 9-12, 2002
6
Glenn Research Center
Communications Technology Division
Protocol Test Results
SpaceOps2002, October 9-12, 2002
7
Satellite Networks & Architectures Branch
SCPS-TP and TCP Tests
Glenn Research Center
Communications Technology Division
Satellite Networks & Architectures Branch
• 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
SpaceOps2002, October 9-12, 2002
8
Rate-Based Protocols
Glenn Research Center
Communications Technology Division
Satellite Networks & Architectures Branch
• 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.
SpaceOps2002, October 9-12, 2002
9
Theoretical Steady State Throughput
Communications Technology Division
Glenn Research Center
Satellite Networks & Architectures Branch
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
SpaceOps2002, October 9-12, 2002
10
Another Example of TCP Steady State Performance
Glenn Research Center
Communications Technology Division
Satellite Networks & Architectures Branch
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
SpaceOps2002, October 9-12, 2002
11
TCP Throughput at 250 msec RTT
Communications Technology Division
Glenn Research Center
Slow Start
Phenomena
SpaceOps2002, October 9-12, 2002
12
Satellite Networks & Architectures Branch
TCP Standard Deviation for 30 Trials
Glenn Research Center
Communications Technology Division
Satellite Networks & Architectures Branch
When the first error occurs has a
large effect on TCP throughput as
shown by the standard deviations for
1E-8 and 1E-7
SpaceOps2002, October 9-12, 2002
13
Protocol Throughput
500 msec Delay / 10 Mbyte File, Single Flow
Communications Technology Division
Glenn Research Center
All Rate-Based protocols need work
to reach their full potential.
Rate-Based
SpaceOps2002, October 9-12, 2002
14
Satellite Networks & Architectures Branch
Protocol Throughput
500 msec Delay / 10 Mbyte File, Single Flow
Communications Technology Division
Glenn Research Center
Rate-Based
Congestion Friendly
SpaceOps2002, October 9-12, 2002
15
Satellite Networks & Architectures Branch
Multi-stream Testing of
Congestion-Friendly Protocols
Glenn Research Center
Communications Technology Division
Satellite Networks & Architectures Branch
• 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.
SpaceOps2002, October 9-12, 2002
16
Total Throughput forTotal
Congestion
Throughput for Friendly Protocols
Congestion
Friendly
3 (nearly) simultaneous flows
over
a Protocols
15 Mbps rate limited channel
Glenn Research Center
3 (nearly) simultanious flows
over a 15 Mbps rate limitted channel
Communications Technology Division
Satellite Networks & Architectures Branch
18
16
Goodput (Mbps)
14
12
TCP
10
SCPS-VJ
SCPS-Vegas
8
Channel Capacity
6
4
2
0
0
1.00E-07
1.00E-05
BER
SpaceOps2002, October 9-12, 2002
17
MDP Tuning
(Packet Size 1024 Bytes, Delay 500 msec)
Glenn Research Center
Communications Technology Division
Satellite Networks & Architectures Branch
Receiver
cannot keep
up and
and hardware
performance
Our Operating
System
Greatest
throughput
achievable
at
degrades
rapidly
at
transmission
settings
could keep rate
up with
the current
MDP
Transmission
settings
of 35 – 40
Mbps
greater
than
40
Mbps
implementation at rates up to 20 Mbps
Rate Setting
SpaceOps2002, October 9-12, 2002
18
Protocol Throughput – SCPS-TP Pure Rate Based
(Ack Every Other Packet, Single Flow, 1024 Byte packets)
Communications Technology Division
Glenn Research Center
Initialization and
Termination
Increasing Delay
Performance is delay tolerant, but
not completely insensitive to delay.
SpaceOps2002, October 9-12, 2002
19
Satellite Networks & Architectures Branch
Conclusions
Glenn Research Center
Communications Technology Division
Satellite Networks & Architectures Branch
• Very small transactions such as command and control should see
little difference in performance for TCP or any variant of SCPSTP 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 ratebased 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.
SpaceOps2002, October 9-12, 2002
20
Conclusions
Glenn Research Center
Communications Technology Division
Satellite Networks & Architectures Branch
• 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
SpaceOps2002, October 9-12, 2002
21
Recommendations
Glenn Research Center
Communications Technology Division
Satellite Networks & Architectures Branch
• 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.
SpaceOps2002, October 9-12, 2002
22
Take Notice
Glenn Research Center
Communications Technology Division
Satellite Networks & Architectures Branch
• 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.
SpaceOps2002, October 9-12, 2002
23