TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 full duplex data: bi-directional data flow in same connection MSS: maximum segment size connection-oriented: handshaking (exchange of control msgs) init’s sender, receiver state before data exchange flow controlled: sender will not overwhelm receiver point-to-point: one sender, one receiver reliable, in-order, byte steam: no “message boundaries” pipelined: TCP congestion and flow control set window size send & receive buffers socket door TCP send buffer TCP receive buffer socket door segment application writes data application reads data TCP segment structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number Receive window Urg data pnter checksum F S R P A U head len not used Options (variable length) URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) # bytes rcvr willing to accept counting by bytes of data (not segments!) Internet checksum (as in UDP)
23
Embed
TCP: Overview - wmich.edualfuqaha/Fall07/cs6030/lectures/tcp-rev2.pdfSummary: TCP Congestion Control When CongWinis below Threshold, sender in slow-start phase, window grows exponentially.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581
full duplex data:bi-directional data flow in same connection
MSS: maximum segment size
connection-oriented:handshaking (exchange of control msgs) init’ssender, receiver state before data exchange
flow controlled:sender will not overwhelm receiver
When connection begins, increase rate exponentially fast until first loss event
TCP Slow Start (more)
When connection begins, increase rate exponentially until first loss event:
double CongWinevery RTT
done by incrementing CongWin for every ACK received
Summary: initial rate is slow but ramps up exponentially fast
Host A
one segment
RTT
Host B
time
two segments
four segments
RefinementAfter 3 dup ACKs:
CongWin is cut in half
window then grows linearly
But after timeout event:CongWin instead set to 1 MSS;
window then grows exponentially
to a threshold, then grows linearly
• 3 dup ACKs indicates network capable of delivering some segments• timeout before 3 dup ACKs is “more alarming”
Philosophy:
Refinement (more)Q: When should the
exponential increase switch to linear?
A: When CongWingets to 1/2 of its value before timeout.
Implementation:Variable Threshold
At loss event, Threshold is set to 1/2 of CongWin just before loss event
Summary: TCP Congestion Control
When CongWin is below Threshold, sender in slow-start phase, window grows exponentially.
When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly.
When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold.
When timeout occurs, Threshold set to CongWin/2and CongWin is set to 1 MSS.
Congestion Avoidance
TCP’s strategycontrol congestion once it happens
repeatedly increase load in an effort to find the point at which congestion occurs, and then back off
Alternative strategypredict when congestion is about to happen
reduce rate before packets start being discarded
call this congestion avoidance, instead of congestion control
Random Early Detection (RED)
Notification is implicit just drop the packet (TCP will timeout)could make explicit by marking the packet
Early random droprather than wait for queue to become full, drop each arriving packet with some drop probability whenever the queue length exceeds some drop level
Weight * SampleLen0 < Weight < 1 (usually 0.002)SampleLen is queue length each time a packet
arrivesMaxThreshold MinThreshold
AvgLen
RED Details (cont)
Two queue length thresholds
if AvgLen <= MinThreshold then
enqueue the packet
if MinThreshold < AvgLen < MaxThreshold then
calculate probability P
drop arriving packet with probability P
if ManThreshold <= AvgLen then
drop arriving packet
RED Details (cont)
Drop Probability Curve
P(drop)
1.0
MaxP
MinThresh MaxThresh
AvgLen
TCP VegasIdea: source watches for some sign that router’s queue is building up and congestion will happen too; e.g.,
RTT grows
TCP VegasLet BaseRTT be the minimum of all measured RTTs (commonly the RTT of the first packet)If not overflowing the connection, then
ExpectRate = CongestionWindow/BaseRTTSource calculates sending rate (ActualRate) once per RTTSource compares ActualRate with ExpectRate
Diff = ExpectedRate - ActualRateif Diff < α
increase CongestionWindow linearlyelse if Diff > β
decrease CongestionWindow linearlyelse
leave CongestionWindow unchanged
Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/KPractically this does not happen in TCP as connections with lower RTT are able to grab the available link bandwidth more quickly.
TCP connection 1
bottleneckrouter
capacity R
TCP connection 2
TCP Fairness
Fairness (more)
Fairness and UDP
Multimedia apps often do not use TCP
do not want rate throttled by congestion control
Instead use UDP:pump audio/video at constant rate, tolerate packet loss
Research area: TCP friendly
Fairness and parallel TCP connections
nothing prevents app from opening parallel cnctionsbetween 2 hosts.
Web browsers do this
Example: link of rate R supporting 9 cnctions;
new app asks for 1 TCP, gets rate R/10
new app asks for 11 TCPs, gets R/2 !
TCP Options: Protection Against Wrap Around Sequence