TCP Performance
description
Transcript of TCP Performance
TCP Performance
Phil CaytonCSE 58101/12/02
Papers read for this discussion
TCP Behavior of a Busy Internet Server: Analysis and Improvements H. Balakrishnan, V. Padmanabhan, S. Seshan, M.
Stemm, R. KatzAn Integrated Congestion Management Architecture of Internet Hosts H. Balakrishnan, H. Rahul, S. Seshan
Endpoint Admission Control: Architectural Issues and Performance L. Breslau, E. Knightly, S. Shenker, I. Stoica, H.
ZhangTCP Congestion Control with a Misbehaving Receiver S. Savage, N. Cardwell, D. Wetherall, T. Anderson
Agenda
Overview of Loss Recovery and Congestion Control BehaviorIssues with TCP and Current Trends & Techniques to solve themAttacks against & Defenses for TCP Vulnerabilities Integrated Congestion ManagementEndpoint Admission ControlSummaryDiscussion
Changing Nature of Net Traffic
Historically – single, long-running xfers Telnet, FTP, etc
Currently – multiple, concurrent, short-lived transfers and use of transports that do not adapt to congestion Do not give TCP time to adapt to network
congestion Receiver modifications exacerbate problem by
circumventing congestion control mechanisms. Can hog bandwidth or commit DOS attacks
PROBLEM – Current trends could affect long term stability of internet
AIMD
Slow Start Start the congestion window (CW) at the size of a
single segment & send it. If segment acked before timeout add one segment to the CW size up to MSS.
Congestion Avoidance Once CW reaches threshold only add a new segment
for each estimated segment RTT.
Multiplicative Decrease Reduce CW size by half for each retransmit
Problems with Current TCP Congestion Control
Loss Recovery Techniques not effective in dealing with packet lossesDefault Socket Buffer Size to small Receiver window becomes a bottleneck
Parallel connections less responsive to congestion-induced lossesAck-Compression can artificially increase perceived queue-length
Solving Problems and Improving TCP Performance
Integrated Congestion Control/Loss Recovery Apps can use multiple TCP connections Single integrated CW for the set of TCP
connections Eliminates slow-start for new connections Decreases overall effect of congestion as all
connections are informed of and react to the congestion
Data-driven loss recovery integrated across set of TCP connections Connections know if ‘lost’ segments arrive on other
connections and do not need to timeout.
Solving Problems and Improving TCP Performance
Increase default socket buffer size Increases maximum receiver
advertised window on connection est. Allows for higher potential performance
Calculate Ack-Compression factor If significant ack-compression, slow-
data rate to limit danger of packet loss
TCP Vulnerabilities and Misbehaving ReceiversAck Division Receiver can acknowledge segments
multiple times (up to #bytes acks) Leads Sender to grow CW faster than
normal. Bunch of acks
Burst 1 RTT later
TCP Vulnerabilities and Misbehaving Receivers
Solution to Ack Division1. Modify congestion control to
guarantee segment-level granularity2. Only increment MSS when a valid
Ack arrives for the entire segment.
TCP Vulnerabilities and Misbehaving Receivers Duplicate Ack Spoofing Receiver sends multiple
acks/sequence # No way to tell what segment is being
acked Causes sender to enter fast-recovery
mode and increase MSSBurst of dup acks Sender
enters Fast Recovery and bursts 1 RTT later
TCP Vulnerabilities and Misbehaving Receivers
Solution to Duplicate Ack Spoofing Add new fields to TCP headers.
“nonce & nonce-reply” – random values sent with segments and replies. Only increment congestion Window for replies to previously unacked packets (determined by nonce/reply)
Oops…requires us to modify servers & clients Server maintains count of un-acked
segments. Only incr cwnd while count > 0
TCP Vulnerabilities and Misbehaving ReceiversOptimistic Acking Send acks for segments not yet
received Dec perceived RTT, affecting CW
growth. Segment acks
Segs arrive
TCP Vulnerabilities and Misbehaving Receivers
Solution to Optimistic Acking Again use nonce/nonce-reply as spoofer
cannot guess random-nonce values Oops… does not take into account cumulative
losses Cumulative Nonce
Oops… still requires modification of TCP “slightly” random sequence sizes
Spoofer unable to correctly anticipate segment boundaries and incorrect sequence numbers can be ignored.
Integrated Congestion Management
TCP-Friendly approach for end-system Congestion management that Enables efficient multiplexing of concurrent
flows Enables apps/xports to adapt to congestion Ensures proper and stable congestion behavior Delivers trusted intermediary between flows
for bandwidth management Provides per-host/per-domain statistics
(bandwidth, loss rates, RTT)
Integrated Congestion Management
Goals Ensure stable net behavior Enable shared state learning for app adaptation
Guiding Principles Put app in control
App decides what to transmit App decides how to apportion allocated bandwidth
Accommodate traffic heterogeneity TCP bulk xfers, short xactions, RT-flows at various rates,
layered streams, new apps Accommodate application heterogeneity (Syncronous
or Asynchronous) Learn from the application
Integrated Congestion Management
CM Functions Query path status Schedule data transmissions Update variables on congestion
CM Algorithms Rate-based AIMD control Loss-resilient, light-weight feedback protocol Exponential aging when feedback infrequent Scheduler to apportion bandwidth between
flows
Integrated Congestion Management
Web traces for web-like workload with 4
concurrent connections using TCP-Reno
Same workload with TCP/CM
Note high-variance
Note extremely low-variance
Integrated Congestion Management
More efficient if sender and receiver use CM, but not requiredCM improves Reliability & consistency to make apps better netizensCM Ensures proper & stable congestion behavior
Endpoint Admission Control
Goal of AC – Provide QOS to soft-RT flowsTraditional Approaches Integrated Services: per-flow router based AC
Flows must request service from the network. Acceptance depends on the level of available resources Limited scalability (routers must keep per-flow state & process per-flow reservation
messages) Differentiated Services: routers use priority/buffering mechanisms
based on DS field in packet headers No per-flow admission control or signaling Routers do not maintain per-flow state Good scalability No AC – QOS degrades if resources are limited
Goal –IntServe QOS & DiffServ scalability while maintaining compatibility w/ Best Effort traffic
Endpoint Admission Control
Router Scheduling Mechanisms FIFO
no flow admitted if the load while probing is greater than the capacity (no stolen bandwidth)
Fair Queuing Isolate flows to give each a fair share. Flow acceptance could
impair service to others. Possibility of lower than optimal utilization
Coexisting w/ Best Effort Traffic Don’t “borrow” bandwidth from best-effort traffic Don’t allow best-effort traffic to preempt AC traffic
Multiple Levels of Service All probes (regardless of priority) at same level Probes at different level than any data traffic to avoid “stealing”
service between levels
Endpoint Admission Control
Endpoint Probing Algorithms Acceptance Threshold
Too low threshold leads to higher blocking All AC flows should adopt uniform acceptance threshold
Accuracy In-Band Probing – probe packets same priority as data
(shorter set-up times, no starvation) Out-of-Band Probing – probe packets lower priority than
data packets (no data packet loss) Thrashing
Accepted flow levels low, but high probe-traffic prevents further admission
Use slow-start probing
Endpoint Admission Control
Simulations Probing: slow-start, early reject and
simple Options: in-band probing, out-of-band
probing, signal congestion with packet drops, signal congestion with congestion marks
Endpoint Admission Control
Thrashing - Loss rate for simple & early reject probing algorithms for in-band probing design substantially worse than that of the Intserv “MBAC” benchmark
Slow start based algorithm in contrast is much closer to MBAC OOB dropping similar loss-load frontiers as MBAC
Robustness In-band dropping has highest, OOB marking lowest dropping rates.
Heterogeneous Thresholds Lower thresholds for higher QOS->higher block rates->lower QOS Uniform thresholds seem to yield higher overall QOS
Heterogeneous Traffic Traditional admission control discriminates against bigger flows. Edge admission control less discriminate and can admit too much
Multi-hop Drop rates higher for longer/multi-hops but Admission accuracy unaffected
Endpoint Admission Control
Cons Substantial setup delay QOS unpredictable across settings No mechanism to enforce uniform admission
thresholds Users could forge admission fields and be granted
higher QOS without being subject to AC
Pros Scalable scheduling for soft-RT applications Provides multiple QOS levels along with Best-effort Early tests show good TCP-friendliness
SummaryTCP not designed for prevalent traffic patternsTCP designed for cooperative environment and contains vulnerabilitiesModest (server side) changes can make TCP more robust for current traffic and less vulnerable to spoofs and DOS attacksMore substantial (sender and reciever) changes can further add congestion management and improve overall stability and security
Discussion