tcp (part ii)
DESCRIPTION
TCP (Part II). Shivkumar Kalyanaraman Rensselaer Polytechnic Institute [email protected] http://www.ecse.rpi.edu/Homepages/shivkuma. TCP interactive data flow TCP bulk data flow TCP congestion control TCP timers TCP futures and performance - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/1.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 1
TCP (Part II)
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
http://www.ecse.rpi.edu/Homepages/shivkuma
![Page 2: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/2.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 2
TCP interactive data flowTCP bulk data flowTCP congestion controlTCP timersTCP futures and performance
Ref: Chap 19, 20, 21; RFC 793, 1323, 2001, papers by Jacobson, Karn/Partridge
Overview
![Page 3: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/3.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 3
TCP Interactive Data Flow Problems:
Overhead: 40 bytes header + 1 byte dataTo batch or not to batch: response time
important Batching acks:
Delay-ack timer: piggyback ack on echo200 ms timer (fig 19.3)
Batching data:Nagle’s algo: Don’t send packet until next
ack is received.Developed because of congestion in WANs
![Page 4: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/4.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 4
TCP Bulk Data FlowTCP Bulk Data Flow Sliding window:
Send multiple packets while waiting for acks (fig 20.1) upto a limit (W)
Receiver need not ack every packetAcks are cumulative. Ack # = Largest consecutive sequence
number received + 1Two transfers of the data can have different
dynamics (eg: fig 20.1 vs fig 20.2) Receiver window field:
Reduced if TCP receiver short on buffers
Sliding window: Send multiple packets while waiting for
acks (fig 20.1) upto a limit (W)Receiver need not ack every packetAcks are cumulative. Ack # = Largest consecutive sequence
number received + 1Two transfers of the data can have different
dynamics (eg: fig 20.1 vs fig 20.2) Receiver window field:
Reduced if TCP receiver short on buffers
![Page 5: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/5.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 5
TCP Bulk Data Flow (Contd) TCP Bulk Data Flow (Contd) End-to-end flow controlWindow update acks: receiver ready Default buffer sizes: 4096 to 16384 bytes. Ideal: window and receiver buffer =
bandwidth-delay product TCP window terminology: figs 20.4, 20.5, 20.6
Right edge, Left edge, usable window “closes” => left edge (snd_una) advances“opens” => right edge advances (receiver
buffer freed => receiver window increases)“shrinks” => right edge moves to left (rare)
End-to-end flow controlWindow update acks: receiver ready Default buffer sizes: 4096 to 16384 bytes. Ideal: window and receiver buffer =
bandwidth-delay product TCP window terminology: figs 20.4, 20.5, 20.6
Right edge, Left edge, usable window “closes” => left edge (snd_una) advances“opens” => right edge advances (receiver
buffer freed => receiver window increases)“shrinks” => right edge moves to left (rare)
![Page 6: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/6.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 6
The Congestion Problem Problem: demand outstrips available capacity … Q: Will the “congestion” problem be solved when:
a) Memory becomes cheap (infinite memory)?
No buffer Too late
All links 19.2 kb/s Replace with 1 Mb/s
SS SS SS SS SS SS SS SS
File Transfer Time = 7 hoursFile Transfer time = 5 mins
b) Links become cheap (high speed links)?
![Page 7: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/7.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 7
Ans: None of the above solves congestion ! Congestion: Demand > Capacity
It is a dynamic problem => Static solutions are not sufficient
TCP provides a dynamic solution
A
BSS
C
DScenario: All links 1 Gb/s. A & B send to C.
c) Processors become cheap (fast routers
switches)?
![Page 8: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/8.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 8
TCP Congestion ControlTCP Congestion Control Window flow control: avoid receiver overrun Dynamic window congestion control:
avoid/control network overrunObservation: Not a good idea to start with a
large window and dump packets into networkTreat network like a black box and start from a
window of 1 segment (“slow start”) Increase window size exponentially
(“exponential increase”) over successive RTTs => quickly grow to claim available capacity.
Window flow control: avoid receiver overrun Dynamic window congestion control:
avoid/control network overrunObservation: Not a good idea to start with a
large window and dump packets into networkTreat network like a black box and start from a
window of 1 segment (“slow start”) Increase window size exponentially
(“exponential increase”) over successive RTTs => quickly grow to claim available capacity.
![Page 9: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/9.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 9
Technique: Every ack: increase cwnd (new window variable) by 1 segment.
Effective window = Min(cwnd, Wrcvr)
Technique: Every ack: increase cwnd (new window variable) by 1 segment.
Effective window = Min(cwnd, Wrcvr)
![Page 10: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/10.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 10
DynamicsDynamics
Rate of acks = rate of packets at the bottleneck: “Self-clocking” property.
Rate of acks = rate of packets at the bottleneck: “Self-clocking” property.
100 Mbps 10 Mbps
RouterQ
1st RTT 2nd RTT 3rd RTT 4th RTT
![Page 11: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/11.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 11
Congestion Detection Packet loss as an indicator of congestion.
Set slow start threshold (ssthresh) to min(cwnd, Wrcvr)/2
Retransmit pkt, set cwnd to 1 (reenter slow start)
Time (units of RTTs)
CongestionWindow (cwnd)
Receiver Window
IdleInterval
Timeout
1
ssthresh
![Page 12: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/12.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 12
Congestion avoidance Increment cwnd by 1 per ack until ssthresh Increment by 1/cwnd per ack afterwards
(“Congestion avoidance” or “linear increase”) Idea: ssthresh estimates the bandwidth-delay
product for the connection. Initialization: ssthresh = Receiver window or
default 65535 bytes. Larger values thru options. If source is idle for a long time, cwnd is reset to
one.
![Page 13: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/13.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 13
Timeout and RTT EstimationTimeout and RTT Estimation Timeout: for robust detection of packet loss Problem: How long should timeout be ?
Too long => underutilization; too short => wasteful retransmissions
Solution: adaptive timeout: based on RTT
RTT estimation: Early method: exponential averaging:
R *R + (1 - )*M { M =measured RTT} RTO = *R { = delay variance factor} Suggested values: = 0.9, = 2
Timeout: for robust detection of packet loss Problem: How long should timeout be ?
Too long => underutilization; too short => wasteful retransmissions
Solution: adaptive timeout: based on RTT
RTT estimation: Early method: exponential averaging:
R *R + (1 - )*M { M =measured RTT} RTO = *R { = delay variance factor} Suggested values: = 0.9, = 2
![Page 14: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/14.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 14
RTT EstimationRTT Estimation Jacobson [1988]: this method has problems
w/ large RTT fluctuations New method: Use mean & deviation of RTT
A = smoothed average RTT D = smoothed mean deviation Err = M - A { M = measured RTT} A A + g*Err {g = gain = 0.125} D D + h*(|Err| - D) {h = gain = 0.25} RTO = A + 4D Integer arithmetic used throughout. Complex
initialization process ...
Jacobson [1988]: this method has problems w/ large RTT fluctuations
New method: Use mean & deviation of RTT A = smoothed average RTT D = smoothed mean deviation Err = M - A { M = measured RTT} A A + g*Err {g = gain = 0.125} D D + h*(|Err| - D) {h = gain = 0.25} RTO = A + 4D Integer arithmetic used throughout. Complex
initialization process ...
![Page 15: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/15.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 15
Timer Backoff/Karn’s AlgorithmTimer Backoff/Karn’s AlgorithmTimer backoff: If timeout, RTO = 2*RTO
{exponential backoff}Retransmission ambiguity problem:
During retransmission, it is unclear whether an ack refers to a packet or its retransmission. Problem for RTT estimation
Karn/Partridge: don’t update RTT estimators during retransmission.
Restart RTO only after an ack received for a segment that is not retransmitted
Timer backoff: If timeout, RTO = 2*RTO {exponential backoff}
Retransmission ambiguity problem: During retransmission, it is unclear whether
an ack refers to a packet or its retransmission. Problem for RTT estimation
Karn/Partridge: don’t update RTT estimators during retransmission.
Restart RTO only after an ack received for a segment that is not retransmitted
![Page 16: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/16.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 16
Fast Retransmit and Recovery Goals:
Timeout avoidance: The 500 ms timer granularity can have an adverse performance impact especially for high speed n/ws
Selective retransmission: Especially when packets are dropped due to error or light congestion
Fast Recovery: Converge quickly to a state of congestion avoidance (linear increase) with half-current window -- the assumed ideal window size.
Observation: Receivers are required to send an immediate duplicate acknowledgment when they receives out-of-order data segments.
![Page 17: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/17.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 17
Fast Retransmit and Recovery
3 duplicate acks => assume loss More duplicate acks => other packets have reached
destination safely. Wait for about 1/2*RTT, and resume transmitting new
segments for every subsequent duplicate ack received. Stop this process once the ack for the missing segment received
0500
Ack 500Ack 500Ack 500Ack 500Ack 500
FRR
![Page 18: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/18.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 18
Fast Retransmit and Recovery Fast Retransmit: Received third duplicate ack:
Set ssthresh to 1/2 of current cwnd Retransmit the missing segment Set cwnd to ssthresh+3
Fast Recovery: For each duplicate ack hence: Increment cwnd by 1 MSS New packets are transmitted once cwnd grows
large enough. [If old cwnd was a pipe of length 1*RTT, the
network gets a relief period of 1/2*RTT]
![Page 19: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/19.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 19
FRR (contd)FRR (contd) Upon receiving the next (non-duplicate) Ack:
Set cwnd to ssthresh & enter linear growth phase
Upon receiving the next (non-duplicate) Ack:Set cwnd to ssthresh & enter linear growth
phase
CWND
TIME
CWND/2
New packets sent during thisphase
![Page 20: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/20.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 20
FRR problemsFRR problems Burst loss of 3 pkts => Timeout + window
shutdown to cwnd/8 !
Burst loss of 3 pkts => Timeout + window shutdown to cwnd/8 !
CWND
Time1st FastRetransmit 2nd Fast
Retransmit
Timeout
CWND/2
CWND/4CWND/8
W
![Page 21: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/21.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 21
TCP Performance OptimizationTCP Performance Optimization SACK: selective acknowledgments: specifies
blocks of packets received at destination. Random early drop (RED) scheme spreads the
dropping of packets more uniformly and reduces average queue length and packet loss rate.
Scheduling mechanisms protect well-behaved flows from rogue flows.
Explicit Congestion Notification (ECN): routers use a explicit bit-indication for congestion instead of loss indications.
SACK: selective acknowledgments: specifies blocks of packets received at destination.
Random early drop (RED) scheme spreads the dropping of packets more uniformly and reduces average queue length and packet loss rate.
Scheduling mechanisms protect well-behaved flows from rogue flows.
Explicit Congestion Notification (ECN): routers use a explicit bit-indication for congestion instead of loss indications.
![Page 22: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/22.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 22
Congestion control summary Sliding window limited by receiver window. Dynamic windows: slow start (exponential rise),
congestion avoidance (linear rise), multiplicative decrease.
Adaptive timeout: need mean RTT & deviation Timer back off and Karn’s algo during
retransmission Go-back-N or Selective retransmission Cumulative and Selective acknowledgements Timeout avoidance: FRR Drop policies, scheduling and ECN
![Page 23: TCP (Part II)](https://reader035.vdocuments.us/reader035/viewer/2022062321/56812a43550346895d8d6ba1/html5/thumbnails/23.jpg)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 23
Summary
Interactive and bulk TCP flow TCP congestion control Informal exercises: Perform some of the
experiments described in chaps 19-21 to see various facets of TCP in action