6 Recap : Congestion Control Congestion istoo many sources sending too much data too fast.ManifestationLost packets High Delay3. Wasted BandwidthThroughputkneecliffcongestioncollapsepacketlossLoadLoadDelay
7 Recap : Congestion Control Efficiency- Close to full utilization but low delay.- Fast convergence after disturbance.Fairness- Resource SharingDistributed- No central knowledge necessary- Scalability
8 Recap : Simple Model User 1 User 2 d = xi > Xgoal? User n xnFlows observe congestion signal d, and locally take actions to adjust rates.
9 Recap : A(M)I - MD Protocol Apply the A(M)I – MD algorithm to a sliding window protocol
10 Recap : TCP/ Reno Two cases - 3 duplicate ACKs (network capable of delivering some packets)Timeout (more alarming)Two phases1. Slow start (SS) - MI2*cwnd per RTT till congestion2. Congestion avoidance(CA) – AIMDcwnd increase by 1 per RTT- 3 duplicate ACKs cwnd = cwnd/2- Timeout cwnd =1- In timeout timeout = 2*timeout
11 Recap : TCP/ Reno SS – Slow Start CA – Congestion Avoidance TimecwndSSCATDTOssthreshSS – Slow StartCA – Congestion AvoidanceTD – Three Duplicate ACKsTO - Timeout
12 Recap : TCP/ RenoWhen cwnd is cut to half, why does sending rate not get cut?
13 Recap : TCP/ RenoçThere is a filling and draining of buffers for each TCP flow.cwndfilling bufferTDbottleneckbandwidthdraining bufferssthreshTimeCA
15 TCP/ Reno Throughput Analysis Understand throughput in terms ofRTTPacket loss rate (p)Packet size (S)Throughput calculationsAssume congestion avoidance and no timeouts occurMean window size Wm segments, round trip time RTT & pack size SThroughput ≈Wm * SRTTbytes/sec
16 Deterministic Analysis Consider congestion avoidanceAssume one packet is lost per cycleTotal packets sent per cyclePacket loss (p)Throughput == ½*(W + W/2) * W/2 = 3W2/8= 1/(3W2/8) = 8/(3W2) S*WmRTTTimecwndCATDssthreshavailablebandwidthW/2W
17 TCP/ Reno DrawbacksMultiple packets lost simultaneously cannot be accounted forACK for segment 7segment 1segment 2segment 3segment 4segment 5cwnd = 63 duplicate ACK’sRe-transmit segment 1cwnd = 3segment 6segment 7Re-transmit segment 2cwnd = 1cwnd might reduce twice for packets lost in same window
18 New Protocol Necessary!! TCP/ Reno DrawbacksRTT unfairnessFlows with different RTT’s grow their congestion windows differentlyUsers 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 lossesSimultaneous packet loss events for multiple competing flows.New Protocol Necessary!!
19 Desired Characteristics in TCP Adaptive schemes that grow the congestion window depending on network conditionsScalableRTT FairnessFaster convergence to better utilize full bandwidth
23 BIC Algorithm Some preliminaries βmultiplicative decrease factor Wmax = cwnd size before the reductionWmin = β*Wmax – just after reductionmidpoint = (Wmax + Wmin)/2BIC performs binary search between Wmax and Wmin looking for the midpoint.
29 TCP BIC Advantages Scalability: quickly scales to fair BW share Fairness and convergence: Achieves better fairness and faster convergenceSlow Growth around Wmax ensures that unnecessary timeouts do not occur.
30 TCP BIC Drawbackscwnd growth is aggressive for TCP with short RTT or low speedShort RTT makes cwnd ramp up soonStill dependent on RTTProportional to inverse square of the RTT like TCP/ RenoComplex window growth functionDifficult for analysis and actual implementation
32 TCP Cubic cwnd = C( t – K)3 + Wmax Wmax = cwnd before last reduction βmultiplicative decrease factorC scaling factort is the time elapsed since last window reduction
33 TCP CUBIC Max Probing Cubic starts probing for more Bandwidth Packet loss eventWmaxTimeAround Wmax, window growth almost becomes zeroFast growth upon reductionSteady State Behavior
34 TCP Cubic Advantages Good RTT fairness Growth dominated by t, competing flows have same t after synchronized packet lossReal-time dependentSimilar to BIC but linear increases are time dependentDoes not depend on ACK’s like TCP/ RenoScalabilityCubic increases window to Wmax (or its vicinity) quickly and keeps it there longer
35 TCP Cubic Drawbacks Slow Convergence Bandwidth Delay Products Flows with higher cwnd are more aggressive initiallyProlonged unfairness between flowsBandwidth Delay ProductsLinear increase artefacts
37 4G LTE Bandwidths match (often exceed) home broadband speeds. Higher Energy EfficiencyNew resource management policyHigher ThroughputsLower Latency
38 4G LTE - Architecture UE – User Equipment RAN – Radio Access Network CN – Core NetworkSGW – Switching GatewayPGW – Packet Data Network Gateway
39 4G LTE - LatencyEnd-to-end latency of a packet that requires a UE’s radio interface is long - RRC promotion delayPromotion delay is not included in either uplink or downlink as the delay has already finished when it reaches the serverEstimating the Promo DelayTsa – Timestamp of SYNTSb – Timestamp of ACKG – inverse of clock frequencyPromo Delay = G(TSb – TSa)
40 4G LTE - Latency 3G Networks 4G Networks 2 s from idle to high power state1.5 s from low to high power state4G Networks600 ms promotion delays
41 4G LTE - Queuing DelaysIn-flight bytes of more than 200KB leads to longer 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 pathbuffers extensively accommodate cellular network conditions and conceal packet loss
43 4G LTE – Undesired Slow Start in-flight bytes growingThe vertical gap between data and ACK curve indicates the bytes in flightAnd we clearly see that the bytes in flight is growing as the downloading proceeds.
44 4G LTE – Undesired Slow Start Packet lossWe observe a packet loss at time 1 second
45 4G LTE – Undesired Slow Start Fast retransmission allows TCP to directly send the lost segmentto the receiver possibly preventing retransmission timeoutFast retransmissionThen based on TCP, when the sender detects that there is a packet loss,Fast retransmission would be triggered which allows it to directly send the lost segment to the receiver possibly preventing retransmission timeout.
46 4G LTE – Undesired Slow Start TCP uses RTT estimate to update retransmission timeout (RTO)However, TCP does not update RTO based on duplicate ACKsRTT: 262msRTO: 290msTCP uses RTT estimate to update retransmission timeout (RTO),In this example, when the lost segment is retransmitted, RTT is 262ms and RTO is 290ms.However, TCP does not update RTO based on duplicate ACKs.Notice that the duplicate ACKs are generated by the reception of the data packets sent AFTER the lost segment.Duplicate ACKs
47 4G LTE – Undesired Slow Start Retransmission timeout causes slow startRTT: 356msRTO: 290msRTT > RTO, timeout!However, given that the RTT is growing and by the time the ACK of the retransmitted segment is back,RTT has increased to 356ms, while RTO is not updated.Since RTT is larger than RTO now, there is unexpected retransmission timeout.It is called unexpected because the purpose of fast retransmission is to prevent such timeout to happen.After timeout, the congestion window would drop to 1 segment size, triggering slow start, which hurt TCP performanceSLOW START
48 4G LTE – Undesired Slow Start If large number of packets are in flight and one packet is lostlarge number of duplicate ACKs trigger fast re-transmissionavoid timeoutLarge in-network queues hold many packets and delay the retransmitted packetIf specified ACK does not arrive within timeout, this triggers timeout and cwnd = 1Undesired Slow StartSOLUTION: Update the estimated RTT with duplicate ACKs
49 4G LTE – TCP Receive Window In 4G LTE networks, receive windows have become the bottleneckInitial receive window is not large (mostly KB)Application is not reading data fast enough from the receive bufferTCP rate is jointly controlled by congestion window and receive windowa full receive window prevents the server from sending more dataThis leads to bandwidth underutilizationSOLUTIONMove data from transport layer buffers to application layer buffers to empty receive windowIncrease receive window at network level – deployment is challenging
Your consent to our cookies if you continue to use this website.