tcp
Post on 02-Jan-2016
22 Views
Preview:
DESCRIPTION
TRANSCRIPT
TCP ACK generation [RFC 1122, RFC 2581]Event at Receiver
Arrival of in-order segment withexpected seq #. All data up toexpected seq # already ACKed
Arrival of in-order segment withexpected seq #. One other segment has ACK pending
Arrival of out-of-order segmenthigher-than-expect seq. # .Gap detected
Arrival of segment that partially or completely fills gap
TCP Receiver action
Delayed ACK. Wait up to 500msfor next segment. If no next segment,send ACK
Immediately send single cumulative ACK, ACKing both in-order segments
Immediately send duplicate ACK, indicating seq. # of next expected byte
Immediate send ACK, provided thatsegment startsat lower end of gap
Fast Retransmit
• Time-out period often relatively long:– long delay before resending
lost packet
• Detect lost segments via duplicate ACKs.– Sender often sends many
segments back-to-back– If segment is lost, there will
likely be many duplicate ACKs.
• If sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost:– fast retransmit: resend
segment before timer expires
event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y }
Fast retransmit algorithm:
a duplicate ACK for already ACKed segment
fast retransmit
Zhenhai Duan Computer Science, FSU 5
TCP Round Trip Time and Timeout
Q: how to set TCP timeout value?• longer than RTT
– note: RTT will vary• too short: premature timeout
– unnecessary retransmissions• too long: slow reaction to segment
loss
Q: how to estimate RTT?• SampleRTT: measured time from
segment transmission until ACK receipt– ignore retransmissions, cumulatively
ACKed segments• SampleRTT will vary, want estimated
RTT “smoother”– use several recent measurements, not
just current SampleRTT
Zhenhai Duan Computer Science, FSU 6
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT
Exponential weighted moving averageinfluence of given sample decreases exponentially fasttypical value of x: 0.1
Setting the timeout• EstimtedRTT plus “safety margin”• Timeout is doubled every time a segment is timeout• large variation in EstimatedRTT larger safety margin
Timeout = EstimatedRTT + 4*Deviation
Deviation = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT|
TCP TimeoutRTT: gaia.cs.umass.edu to fantasia.eurecom.fr
100
150
200
250
300
350
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
RTT
(mill
isec
onds
)
SampleRTT Estimated RTT
TCP flow/congestion control• Sometimes sender shouldn’t send a pkt whenever
its ready– Receiver not ready (e.g., buffers full)– React to congestion
• Many unACK’ed pkts, may mean long end-end delays, congested networks
• Network itself may provide sender with congestion indication
– Avoid congestion• Sender transmits smoothly to avoid temporary network
overloads
TCP
• To react to these, TCP has only one knob – the size of the send window– Reduce or increase the size of the send window– In our project, the size is fixed
• The size of the send window is determined by two things:– The size of the receiver window the receiver told him in
the TCP segment– His own perception about the level of congestion in the
network
TCP Flow Controlreceiver: explicitly informs
sender of (dynamically changing) amount of free buffer space – RcvWindow field in
TCP segmentsender: keeps the amount of
transmitted, unACKed data less than most recently received RcvWindow
sender won’t overrun
receiver’s buffers bytransmitting too
much, too fast
flow control
receiver buffering
RcvBuffer = size of TCP Receive Buffer
RcvWindow = amount of spare room in Buffer
What is Congestion?
• Informally: “too many sources sending too much data too fast for network to handle”
• Different from flow control, caused by the network not by the receiver
• How does the sender know whether there is congestion? Manifestations:– Lost packets (buffer overflow at routers)– Long delays (queuing in router buffers)
Causes/costs of congestion
• two senders, two receivers
• one router, infinite buffers
• no retransmission
• large delays when congested
• maximum achievable throughput
unlimited shared output link buffers
Host Ain : original data
Host B
out
Approaches towards congestion control
End-end congestion control:
• no explicit feedback from network
• congestion inferred from end-system observed loss, delay
• approach taken by TCP
Network-assisted congestion control:
• routers provide feedback to end systems– single bit indicating
congestion (SNA, DECbit, TCP/IP ECN, ATM)
– explicit rate sender should send at
Two broad approaches towards congestion control:
TCP Congestion Control
• Idea– Each source determines network capacity for itself– Uses implicit feedback, adaptive congestion
window– ACKs pace transmission (self-clocking)
• Challenge– Determining the available capacity in the first
place– Adjusting to changes in the available capacity
15
Additive Increase/Multiplicative Decrease
• Objective: Adjust to changes in available capacity– A state variable per connection: CongWin
• Limit how much data source has is in transit– MaxWin = MIN(RcvWindow, CongWin)
• Algorithm– Increase CongWin when congestion goes down (no losses)
• Increment CongWin by 1 pkt per RTT (linear increase)– Decrease CongWin when congestion goes up (timeout)
• Divide CongWin by 2 (multiplicative decrease)
Computer Science, FSU 16
TCP Congestion Control• Window-based, implicit, end-end control• Transmission rate limited by congestion window size, Congwin, over
segments:
w segments, each with MSS bytes sent in one RTT:
throughput = w * MSS
RTT Bytes/sec
Congwin
TCP Congestion Control
• two “phases”– slow start– congestion avoidance
• important variables:– Congwin– threshold: defines
threshold between slow start phase and congestion avoidance phase
• “probing” for usable bandwidth: – ideally: transmit as fast as
possible (Congwin as large as possible) without loss
– increase Congwin until loss (congestion)
– loss: decrease Congwin, then begin probing (increasing) again
Why Slow Start?• Objective
– Determine the available capacity in the first place• Idea
– Begin with congestion window = 1 pkt– Double congestion window each RTT
• Increment by 1 packet for each ack• Exponential growth but slower than one blast• Used when
– First starting connection– Connection goes dead waiting for a timeout
TCP Slowstart
• exponential increase (per RTT) in window size (not so slow!)
• loss event: timeout (Tahoe TCP) and/or or three duplicate ACKs (Reno TCP)
initialize: Congwin = 1for (each segment ACKed) Congwin++until (loss event OR CongWin > threshold)
Slowstart algorithmHost A
one segment
RTT
Host B
time
two segments
four segments
TCP Congestion Avoidance
/* slowstart is over */ /* Congwin > threshold */Until (loss event) { every w segments ACKed: Congwin++ }threshold = Congwin/2Congwin = 1perform slowstart
Congestion avoidance
21
TCP Fairness
Fairness goal: if N TCP sessions share same bottleneck link, each should get 1/N of link capacity
TCP connection 1
bottleneckrouter
capacity R
TCP connection 2
Why is TCP fair?Two competing sessions:• Additive increase gives slope of 1, as throughput increases• multiplicative decrease decreases throughput proportionally
R
R
equal bandwidth share
Connection 1 throughput
Connect
ion 2
th
roughput
congestion avoidance:
additive increase
loss: decrease window by factor of 2
However,TCP is not perfectly fair.It biases towardsflows with smallRTT.
top related