1 computer networks lecture 18 tcp cubic, tcp in 4g lte 11/5/2013 lecturer: namratha vedire
TRANSCRIPT
Admin
• Assignment 4Check Point 1: Nov 15, 11:55 pmTo Do: Discuss design with instructor or a TF Nov 11Code and Report: Nov 19, 11:55 pmTo Do: Discuss design with instructor or a TF Nov 14
Recap : RTT & Timeout
• RTT
Sample RTT
EstimatedRTT = (1-α)*EstimatedRTT + α*SampleRTT (α=0.125)
DevRTT = (1-β)*DevRTT + β*|SampleRTT – EstimatedRTT| (β=0.
• Timeout = EstimatedRTT + 4*DevRTT
SEG
ACK
Recap : Congestion Control
• Congestion istoo many sources sending too much data too fast.
• Manifestation1. Lost packets 2. High Delay
3. Wasted Bandwidth
LoadD
elay
Thro
ughp
ut
knee cliff
congestioncollapse
packetloss
Load
Recap : Congestion Control
• Efficiency- Close to full utilization but low delay.- Fast convergence after disturbance.
• Fairness- Resource Sharing
• Distributed- No central knowledge necessary- Scalability
Recap : Simple Model
Flows observe congestion signal d, and locally take actions to adjust rates.
User 1
User 2
User n
d = xi > Xgoal?
x1
x2
xn
Recap : TCP/ Reno
• Two cases- 3 duplicate ACKs (network capable of delivering some packets)-Timeout (more alarming)
• Two phases1. Slow start (SS) - MI
2*cwnd per RTT till congestion
2. Congestion avoidance(CA) – AIMD cwnd increase by 1 per RTT - 3 duplicate ACKs cwnd = cwnd/2 - Timeout cwnd =1 - In timeout timeout = 2*timeout
Recap : TCP/ Reno
Time
cwnd
SS CA
TD
TOssthresh
ssthresh ssthreshssthresh
CA
TD
CA SS CA
TD
SS – Slow StartCA – Congestion AvoidanceTD – Three Duplicate ACKsTO - Timeout
Recap : TCP/ Reno
There is a filling and draining of buffers for each TCP flow.
Time
cwnd
CA
TD
ssthresh
bottleneckbandwidth
filling buffer
draining buffer
çç
TCP/ Reno Throughput Analysis
• Understand throughput in terms of- RTT- Packet loss rate (p)- Packet size (S)
Throughput calculations- Assume congestion avoidance and no timeouts occur- Mean window size Wm segments, round trip time RTT & pack size S
- Throughput ≈Wm * S
RTT bytes/sec
Deterministic Analysis
• Consider congestion avoidance- Assume one packet is lost per cycle- Total packets sent per cycle - Packet loss (p)
• Throughput =
83
243 2WWW
Time
cwnd
CA
TD
ssthresh
availablebandwidth
W/2W
S*Wm
RTT
= ½*(W + W/2) * W/2 = 3W2/8= 1/(3W2/8) = 8/(3W2)
TCP/ Reno Drawbacks
• Multiple packets lost simultaneously cannot be accounted for
ACK for segment 7
segment 1
segment 2segment 3segment 4segment 5
cwnd = 6
3 duplicate ACK’sRe-transmit segment 1cwnd = 3 segment 1
segment 6segment 7
3 duplicate ACK’sRe-transmit segment 2cwnd = 1 segment 2
cwnd might reduce twice for packets lost in same window
TCP/ Reno Drawbacks
RTT unfairness- Flows with different RTT’s grow their congestion windows differently- Users with shorter RTT ramp up faster!- On long distance links, RTT is high and cwnd takes longer to increase
leading to underutilization of link.
Synchronized losses- Simultaneous packet loss events for multiple competing flows.
New Protocol Necessary!!
Desired Characteristics in TCP
Adaptive schemes that grow the congestion window depending on network conditions
- Scalable- RTT Fairness- Faster convergence to better utilize full bandwidth
Growth functions
– Consider TCP/Reno growth function
Time
cwnd
CA
TD
ssthresh
TD TD TD
Wm
CA CA CA
Grows linearly throughout
TCP BIC
Binary Increase Congestion Control (BIC) algorithm
PHASE 1 cwnd < low_wind, follows TCP
- ACK received : cwnd = cwnd + 1- Loss event: cwnd = cwnd/2
PHASE 2 cwnd > low_wind, follows BIC
BIC Algorithm
Some preliminaries - βmultiplicative decrease factor- Wmax = cwnd size before the reduction
- Wmin = β*Wmax – just after reduction
- midpoint = (Wmax + Wmin)/2
BIC performs binary search between Wmax and Wmin looking for the midpoint.
BIC Algorithm
Packet loss event
Wmax
Wmin = β*Wmax
midpoint = (Wmin + Wmax)/2
Wmin – midpoint > Smax
Wmin + SmaxWmin
midpoint = (Wmin + Wmax)/2
Wmin + Smax
Wmin
Additive Increase
midpoint = (Wmin + Wmax)/2Wmin + Smin
Wmin(Wmin – midpoint) < Smin
Binary Search
Wmax + SminWmax + Smin
Wmax +Smax
Slow Start
Wmax + 2Smax
Wmax + 3Smax
Additive Inc.
Max Probing
BIC Algorithm
while (cwnd != Wmax){
If ((Wmin – midpoint) > Smax)
cwnd = cwnd + Smax
elseIf ((Wmin – midpoint) < Smin)
cwnd = Wmax
else cwnd = midpoint
If (no packet loss)Wmin = cwnd
elseWmin = β*cwnd
Wmax = cwnd
midpoint = (Wmax + Wmin)/2
}
Additive Increase
Binary Search
BIC Algorithm
while (cwnd >= Wmax){
If (cwnd < Wmax + Smax) cwnd = cwnd + Smin
elsecwnd = cwnd + Smax
If (packet loss)Wmin = β*cwnd
Wmax = cwnd
}
Slow Start
Additive IncreaseMax Probing
TCP BIC - Summary
Packet loss event
Binary Increase
Additive Increase
SlowStart
Max Probing
+ Smax
Time
Additive Increase
Wmax
jump to midpoint
+ Smin + Smax
TCP BIC Advantages
– Scalability: quickly scales to fair BW share
Fairness and convergence: Achieves better fairness and faster convergence
Slow Growth around Wmax ensures that unnecessary timeouts do not occur.
TCP BIC Drawbacks
cwnd growth is aggressive for TCP with short RTT or low speed - Short RTT makes cwnd ramp up soon
Still dependent on RTT- Proportional to inverse square of the RTT like TCP/ Reno
Complex window growth function- Difficult for analysis and actual implementation
TCP Cubic
cwnd = C( t – K)3 + Wmax
- Wmax = cwnd before last reduction
- βmultiplicative decrease factor- C scaling factor
-
- t is the time elapsed since last window reduction
TCP CUBIC
Packet loss event
Time
Steady State Behavior
Max Probing
Wmax
Around Wmax, window growth almost becomes zero
Fast growth upon reduction
Cubic starts probing for more Bandwidth
TCP Cubic Advantages
Good RTT fairness- Growth dominated by t, competing flows have same t after
synchronized packet loss
Real-time dependent- Similar to BIC but linear increases are time dependent- Does not depend on ACK’s like TCP/ Reno
Scalability- Cubic increases window to Wmax (or its vicinity) quickly and keeps it
there longer
TCP Cubic Drawbacks
Slow Convergence- Flows with higher cwnd are more aggressive initially- Prolonged unfairness between flows
Bandwidth Delay Products- Linear increase artefacts
4G LTE
Bandwidths match (often exceed) home broadband speeds.
Higher Energy Efficiency- New resource management policy
Higher Throughputs
Lower Latency
4G LTE - Architecture
UE – User EquipmentRAN – Radio Access NetworkCN – Core NetworkSGW – Switching GatewayPGW – Packet Data Network Gateway
4G LTE - Latency
End-to-end latency of a packet that requires a UE’s radio interface is long - RRC promotion delay
Promotion delay is not included in either uplink or downlink as the delay has already finished when it reaches the server
Estimating the Promo Delay- Tsa – Timestamp of SYN
- TSb – Timestamp of ACK
- G – inverse of clock frequency- Promo Delay = G(TSb – TSa)
4G LTE - Latency
– 3G Networks- 2 s from idle to high power state- 1.5 s from low to high power state
4G Networks- 600 ms promotion delays
4G LTE - Queuing Delays
During data transfer phase, a TCP sender will increase its congestion window, allowing number of unacknowledged packets to grow.- “in-flight” packets buffered by routers in network path- buffers extensively accommodate cellular network conditions and
conceal packet loss
In-flight bytes of more than 200KB leads to longer queuing delays.
Fast retransmission
Fast retransmission allows TCP to directly send the lost segment to the receiver possibly preventing retransmission timeout
4G LTE – Undesired Slow Start
RTT: 262msRTO: 290ms
TCP uses RTT estimate to update retransmission timeout (RTO)However, TCP does not update RTO based on duplicate ACKs
Duplicate ACKs
4G LTE – Undesired Slow Start
RTT: 356msRTO: 290msRTT > RTO, timeout!
Retransmission timeout causes slow start
SLOW START
4G LTE – Undesired Slow Start
4G LTE – Undesired Slow Start
If large number of packets are in flight and one packet is lost- large number of duplicate ACKs trigger fast re-transmission- avoid timeout
Large in-network queues hold many packets and delay the retransmitted packet- If specified ACK does not arrive within timeout, this triggers timeout and
cwnd = 1- Undesired Slow Start
SOLUTION: Update the estimated RTT with duplicate ACKs
4G LTE – TCP Receive Window
In 4G LTE networks, receive windows have become the bottleneck - Initial receive window is not large (mostly 131.8 KB) - Application is not reading data fast enough from the receive buffer
TCP rate is jointly controlled by congestion window and receive window- a full receive window prevents the server from sending more data- This leads to bandwidth underutilization
SOLUTION-Move data from transport layer buffers to application layer buffers to empty receive window-Increase receive window at network level – deployment is challenging