internet congestion control: tcp
TRANSCRIPT
![Page 1: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/1.jpg)
Internet congestion control: TCPInternet congestion control: TCP
• 1988: "Congestion Avoidance and Control" (Jacobson/Karels)Combined congestion/flow control for TCP
• Goal: stability - in equilibrum, no packet is sent into the network until an old packet leaves– ack clocking, “conservation of packets“ principle– possible through window based stop&go - behaviour
• Superposition of stable systems = stable ->network based on TCP with congestion control = stable
• Today, TCP dominates the Internet (WWW, ..)recent backbone measurement: 98% TCP traffic
![Page 2: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/2.jpg)
User 1 Allocation x1
FairnessLine
EfficiencyLine
Use
r 2 A
lloca
tion
x2
StartingPoint
AIMD
Desirable
StartingPoint
AIAD
MIMD
Underload
Overload
AIMD BackgroundAIMD Background
User 1 Allocation x1
FairnessLine
EfficiencyLine
Use
r 2 A
lloca
tion
x2
StartingPoint
AIMD
Desirable
StartingPoint
AIAD
MIMD
Underload
Overload
![Page 3: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/3.jpg)
Some reasons for TCP stabilitySome reasons for TCP stability
• Exponential backoff:“For a transport endpoint embedded in a network of unknown topology and with an unknown, unknowable and constantly changingpopulation of competing conversations, only one scheme has any hope of working - exponential backoff - but a proof of this is beyond the scope of this paper.“
• Conservation of packets:“The physics of flow predicts that systems with this property should be robust in the face of congestion.“
• Additive Increase, Multiplicative Decrease:Not explicitely cited as a stability reason in the paper!– ...but in 1000‘s of other papers!
![Page 4: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/4.jpg)
“Proofs“ of TCP stability“Proofs“ of TCP stability
• AIMD:Chiu/Jain: diagram + algebraic proof homogeneous RTT case
• steady-state TCP model: window size ~ 1.22/sqrt(p)(p = packet loss)
• Johari/Tan, Massoulié, ..:– local stability, neglect details of TCP behaviour (fluid flow model, ..)– assumption:
“queueing delays will eventually become small relative to propagation delays“
• Steven Low:– Duality model (based on utility function / F. Kelly, ..):
Stability depends on delay, capacity, load and AQM !
![Page 5: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/5.jpg)
Extended Use of Vector DiagramsExtended Use of Vector Diagrams
• Problem:– Stability analysis very complex– TCP-like mechanism design difficult
• Solution:– Extended use of vector diagrams!
• Analyze actual results (from simulation or real life measurements)
• Instead of just explaining a concept, design in the diagram space– Necessary simplifications may even be less dramatic!
![Page 6: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/6.jpg)
How Stable is AIMD / async. RTT?How Stable is AIMD / async. RTT? U 2SER
User 1-0.0500
0.0000
0.0500
0.1000
0.1500
0.2000
0.2500
0.3000
0.3500
0.4000
0.4500
0.5000
0.5500
0.6000
0.6500
0.7000
0.7500
0.8000
0.8500
0.9000
0.9500
1.0000
0.0000 0.2000 0.4000 0.6000 0.8000 1.0000
• Simple simulation(no queues, ..)
• RTT: 7 vs. 2• AI=0.1, MD=0.5• Simul. time=175
![Page 7: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/7.jpg)
How is AIMD distorted in TCP?How is AIMD distorted in TCP? TCP 2
TCP 1
1.0000
1.5000
2.0000
2.5000
3.0000
3.5000
4.0000
4.5000
5.0000
5.5000
6.0000
6.5000
7.0000
7.5000
8.0000
8.5000
9.0000
9.5000
10.0000
2.0000 4.0000 6.0000 8.0000 10.0000 12.0000 14.0000
• ns-2 simulator• TCP Tahoe• equal RTT• 1 bottleneck link
![Page 8: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/8.jpg)
Problems with TCPProblems with TCP
• TCP over wireless: checksum error -> packet drop misinterpretation
• TCP over “long fat pipes“: large bandwidth*delay product– long time to reach equilibrium, MD = dramatic!
• TCP reaches equilibrium, but not a stable point– fluctuations lead to regular packet drops & reduced throughput– fluctuations not feasible for streaming multimedia apps
• TCP Vegas: interpret delay as congestion ... but:
similar delay, different available bandwidth!
![Page 9: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/9.jpg)
Enhancement idea: ATM ABREnhancement idea: ATM ABR
• TCP -> TCP/RED -> TCP/RED/ECN -> TCP/RED/Multilevel ECN -> ...
• logical consequence: „ECN“ with fine granularity(explicitely ask for congestion information)
• Routers know more about congestion. TCP-AI is like guessing and reacting when it is already too late.
• Idea related to ATM Available Bit Rate (ABR) service:
– Resource management (RM) cells query the network for ECN flag & Explicit Rate information
– framework for sophisticated ER calculations-> 1000s of papers
True for all mechanisms
which use binary feedback!
Often:Fairness through
flow counting-> not scalable!
![Page 10: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/10.jpg)
PTP: The Performance Transparency PTP: The Performance Transparency Protocol (draftProtocol (draft--welzlwelzl--ptpptp--05.txt)05.txt)• “Generic“ ECN / BECN - to carry traffic information
(e.g. queue length, ..)
• Stateless & simple -> scalable!
• Only every 2nd router needed for full functionality– If less routers support it, results are an upper limit
• Available Bandwidth Determination:– nominal bandwidth (“ifSpeed“) + 2* (address + traffic counter
(“if(In/Out)Octets“) + timestamp) = available bandwidth
• two modes: “forward packet stamping“ / “direct reply“ (not for available bandwidth (byte counters))
No problems w/ wireless links
unless combined with packet loss!
![Page 11: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/11.jpg)
PTP: How does it work?PTP: How does it work?
• Forward packet stamping:
Sender Receiver
Router 1 2 3
S-a A-b B-?-c C-r
TTL: 8TTL-C: 9Request:Bwinfo
TTL: 7TTL-C: 7 BWinfo
A Bwinfoa
TTL: 6TTL-C: 6 BWinfo
A BWinfoB Bwinfo
a
TTL: 4TTL-C: 4 BWinfo
A BWinfoB BWinfoc BWinfoC Bwinfo
a
9-4-5=0,completeBwinfotable
9>8! 7=7 6>5!
"Init 9"
Upper case:
Lower case:
outgoing interface
incoming interface
– The receiver can tell if the information is complete (DS Count, TTL)
![Page 12: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/12.jpg)
PTP: How does it work? /2PTP: How does it work? /2• Direct reply:
– Routers compare values; if requirements cannot be met...• the values are updated, the packet is redirected to the sender
– Similar to RSVP reservation setup– Does not work with available bandwidth (traffic counter)– Advantageous for satellite links!
• Forward packet stampingsatellite usage scenario:
1st ground station acts as a receiver - only relies on PTP
![Page 13: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/13.jpg)
Design algorithmDesign algorithm
• find useful (closely related) ATM ABR mechanism
• start with simplifications, then expand the model
• A new mechanism must work for 2 users, equal RTT– simple analysis similar to Chiu/Jain (diagram + math)
• it must also work for heterogeneous RTTs– simulate using a simple diagram based simulator– analyze using extended vector diagram analysis
• it must also work for more users and more realistic scenarios– simulate with ns
![Page 14: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/14.jpg)
The ATM ABR best match: CAPCThe ATM ABR best match: CAPC• “Congestion Avoidance with Proportional Control“ (A. Barnhart 1994)
• Uses load factor LF: Input Rate IR / Target Rate R0– R0 e.g. 95% of nominal bandwidth, d = 1 - LF (available bandwidth)
• “As long as the incoming rate is greater than R0, the desired rate, ERS will diminish at a rate that is proportional to the amount by which R0 is exceeded. Conversely, whenever the incoming rate is less than R0, ERS will increase.“
• for each new cell entering the queue:LF<=1: ERX = min(ERU, 1 + d*Rup) ... else ERX = max(ERF, 1 + d*Rdn)ERS = ERS*ERX
• constants: Rup, Rdn define the speed of rate increase / decrease,ERU, ERF = upper / lower bound
• different default values for LAN and WAN!hint for RTT dependance!
![Page 15: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/15.jpg)
Conversion for packet nets: CADPCConversion for packet nets: CADPC
• “Congestion Avoidance with Distributed Proportional Control“
• Only ask for current load, do calculations at sender
• Fairness: sender 1 RTT = x * sender 2 RTT– sender 1 needs to calculate ERS x times -> ERS = ERS*(ERX^x)
• Result in Chiu-Jain-diagram-simulator:– max-min fairness approximated for limited rtt variations
(trade-off between Rup, Rdn and allowed RTT‘s)
– not good enough, but gives a hint that weighing the rate changes with the user‘s properties can lead to max-min fairness!
Note: multiplicative!
![Page 16: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/16.jpg)
CADPC DesignCADPC Design
• Idea:– relate user‘s current rate to the state of the system! (also in LDA+)
Thought: in the Chiu-Jain-diagram, if the rate increase is indirectly proportional to the user‘s current rate, the rates will equalize.
• erx = 1 + rup * (1.0 - myRate/traffic)does not work! e.g. synchronous case -> myRate/traffic = constant!
• Solution:– erx = 1 + rup * (1.0 - myRate/d)
relationship between user‘s rate and available rate keeps changing!
• Enhancement:– dependence on rup not desirable; rate changes should be proportional
to the current load -> use d instead of rup!
![Page 17: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/17.jpg)
CADPC vector diagram analysisCADPC vector diagram analysis
![Page 18: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/18.jpg)
CADPC synchronous case analysisCADPC synchronous case analysis
• Final formula per user:d = traffic / r0;erx = 1 + d * (1.0 - myRate/d);ers = ers*erx;
• Combined:xi(t) = rateof user i,n users
• after some straight-forward derivations:
−
−+=+
∑=
0
1)(
1
)(11)()1(
r
tx
txdtxtx n
jj
iii
(Special form of) logistic equation
=> stable!
−−+=+ ∑
=
n
jjiii txtxrrtxtx
100 )()(1)()1(
![Page 19: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/19.jpg)
CADPC synchronous case analysis /2CADPC synchronous case analysis /2
• Equilibrium: assume x(t+1) = x(t)
• leads to: x(t) = r0/(n+r0)• traffic (n users): n*x(t) = n*r0/(n+r0)
Convergence of equilibrium with increasing number of users:
0
0,2
0,4
0,6
0,8
1
1,2
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29
r0 = 1
![Page 20: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/20.jpg)
ns simulation: 25 TCP / 25 CADPCns simulation: 25 TCP / 25 CADPCnot
simultaneously!
tcp.trcadpc.tr
Bandwidth (byte / s)
Time (s)
0.0000
20.0000
40.0000
60.0000
80.0000
100.0000
120.0000
140.0000
160.0000
180.0000
200.0000
220.0000
240.0000
260.0000
280.0000
300.0000
320.0000
340.0000
360.0000
380.0000
0.0000 10.0000 20.0000 30.0000 40.0000 50.0000 60.0000
single bottleneck (dumbbell)
![Page 21: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/21.jpg)
ResultsResults
• Implementation: r0 normalized to 1 -> calc -> de-normalize• 1 PTP packet every 4 RTTs, no other acks!
– rate indeed converges to n/n+1
• No packet loss
• Very smooth rate, rapid convergence
• Not in the picture:– rapid convergence to almost perfect fairness– bg traffic: rapid backoff and recovery
![Page 22: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/22.jpg)
CADPC advantagesCADPC advantages
• Better stability than TCP– smooth rate advantageous for streaming media apps
• No problems with wireless links (no packet loss interpretation)
• Rare feedback - good in environments with long delay– rapid convergence & reaction - good in environments with a high bw*delay product
• Rate calculation independent of RTT => independent of position– scalable! if PTP = x% of generated traffic n, PTP scales O(n)
• Only (rare) PTP packets necessary to calculate rate– Satellite environments:
do receiver's calculations at sat. base station and give earlier feedback– easier to differentiate pricing– easier to implement metering => traffic shaping, policing, admission control, ..
![Page 23: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/23.jpg)
Deployment plansDeployment plans
• Problem: PTP needs router support– CADPC needs complete path information (every 2nd router)
• Possibilities:
– QoS in a DiffServ class (QoS “in the small“):“we offer QoS & provide router support,you use CADPC and get a good result“
– If CADPC works with non-greedy senders:edge2edge PTP signaling (TCP over CADPC)PTP supported traffic engineering
– CADPC <=> TCP translation at edge routers?
![Page 24: Internet congestion control: TCP](https://reader030.vdocuments.us/reader030/viewer/2022032410/623253a8eaa8705321779f69/html5/thumbnails/24.jpg)
• More ns simulations– CADPC vs. AIMD in vector diagram simulator:
CADPC is much less aggressive– compare with TCP-friendly binary mechanisms– compare with other ER mechanisms PCP, ALS
• Extension to proportional fairness?
• CADPC implementation– PTP already available for Linux– compare with TCP, TFRC, RAP, ...– evaluate QoS
Future workFuture work