un-cooperative congestion control kartikeya chandrayana prof. shivkumar kalyanaraman ecse dept.,...
TRANSCRIPT
Un-Cooperative Congestion Control
Kartikeya Chandrayana
Prof. Shivkumar Kalyanaraman
ECSE Dept., R.P.I.
[email protected] (http://www.rpi.edu/~chandk)
Outline
• Review• Motivation• Previous Work• Network Optimization• Proposed Framework• Results
Present Internet
• Uses TCP.– TCP Variants
• Tahoe (First Proposal)• Reno, New-Reno : Windows 95/98• Sack: Windows 2000+• Vegas
– Other variants possible.
• Routers Deploy FIFO queues to absorb bursts.
Internet Dynamics
Search Game: User searches for bandwidth with some help from the network
Feedback from Network
• Positive Feedback– Acks
• Negative Feedback– Implicit
• Drop Packets
– Explicit• Mark Packets
– Set a bit in the packet.– This bit is echoed in the Acks
• Explicit Congestion Notification (ECN)
TCP
• Slow Start – Probe exponentially for bandwidth.
• Congestion Avoidance– Send w packets in a round-trip time.
– If receive w acks then put w+1 packets in next RTT
– If congestion put w/2 packets in next RTT.
TCP Variants
TCP Friendliness: Any rate control scheme gets the same throughput as TCP under same operating conditions.
Why ?• TCP does not get beaten down by newer protocols
Examples of TCP-Friendly Protocols: SQRT: Increase: 1/sqrt(w) Decrease: sqrt(w) IIAD : Increase: 1/w Decrease: 1
Mathematical Definition:x: Rate = w/RTT p: loss rateTCP Friendliness x 1/sqrt(p)
But..
• Application needs changed.– Different congestion control protocols.
• Real-Player, Windows Media, Quake, Half-Life etc.
– Some of these are constant rate protocols.
• Linux, FreeBSD Boxes came along.– Make your own TCP.– If receive w acks then put w+5 packets in next RTT
– If congestion put 3w/4 packets in next RTT.
So..
Users can choose their rate control algo Rate Control Scheme rate allocation. Aggressive Rate Control More Rate Incentive for users to misbehave. But majority of users are responsible.
Assume (for now) the network’s standard CC scheme is TCP
Any scheme which gets more rate than TCP is uncooperative
Consequences
Selfish flows grab most of the bandwidth.
One form of traffic volume based denial of service attack. Congestion Collapse Network has no control over equilibrium
rate distributions. Unfair Sharing aggravated on a network of Drop-Tail queues
Effect of MisbehaviorLong Flow: Conformant (TCP Reno, U=-1/x),
Short Flows: Mis-Behaving (U=-1/x0.5)
Incr : 1 packet/RTTDecr: sqrt(w) on loss
Drop Tail Queue
TCP Flows shut out
Present Internet is a network of Drop Tail queuesHappened in NCSU !
AQM: Active Queue Management
• Drop Tail (FIFO) queues has limitations.• Synchronization:
– Queue is full– Packets from all flows are dropped.– All flows cut their rates by half simultaneously.– For a long period link is not fully utilized.– Pattern of simultaneous increase and decrease.
AQM: Drop some packets before queue gets full. • Some flows get early congestion signal and cut back.• Link tends to be fully utilized.• Example: Random Early Drop (RED)• Selfish flows will probably have more packets in the buffer
Probably they will cut their rates more often.
AQM: Effect of Misbehavior
Long Flow: Conformant (TCP Reno, U=-1/x),
Short Flows: Mis-Behaving (U=-1/x0.5)
RED
RED Helps: Though unfair sharing persists
AQM: Deployment
• RED was proposed in 1993• Almost all routers have RED.• But RED is not deployed !
– No one knows how to configure it. – Providers don’t like to drop packets.– RED too has limitations !
• Lots of them • Unfair sharing• At High Loads RED is worse than Drop Tail !
Present Internet is just network of Drop Tail queues !Possibility of Volume based Denial of Service Attack
Related Work
Some Buffer Mgmt. Scheme
Users
End System Based Solution: Use same congestion control
algorithm
Network
Routers
Network Based Solution: Use AQM/Scheduler in the network
Limitation
Constrains the choice of congestion control algorithms
AQM Placement Required at every router.
Limitations
May require exchange of control information between all AQMs/Schedulers in the network.
Generally only provides Max-Min Fairness.
Most Solutions do not work with a Drop Tail queue Network
No clean method to manage non-conformant flowsWhat is the right architectural response ?
Detour: Congestion Control-Optimization Frameworks
• Utility Functions– Economics– One function can
capture a group of rate control schemes.
– TCP-Friendly schemes imply• U(x) = -1/x
x (Rate)
U(x)
Detour: Congestion Control-Optimization Frameworks
• Users choose congestion control algorithm. Choose a Utility Function. TCP : U(x) = -1/x
• CC Scheme Utility function
• Every user maximizes his own utility function.
• Distributed optimization.
• Network communicates price (loss, mark, delay) to users.
• Users use this price to update their rate.
Idea: Managing Non-Conformance: Work in the Utility Function Space
Key Design Objectives:• Deployment Ease
• Retain existing link price update rules.
No changes in the core.• Retain existing user’s rate
updation rules. Allows users to chose
rate control protocol.
• Should work with either drop or marking based network.
• Should work on a network of Drop Tail queues.
U1
U2
Us
Conformant
Non Conformant
U1,U2 define the conformance space
U
x (Rate)
Map user’s Utility Function to Conformant Space
• User s is described by: – xs: Rate, Us: Utility function, q: end-to-end price – xs = Us'-1(q)
– If source was using Uobj then rate would be: xs = Uobj'-1(q)
• Communicate to user the price qnew : qnew = Us' (Uobj'-1(q))
• Now user’s update algorithm looks like xs = Us'-1(qnew)
xs = Uobj'-1(q)
Appears as if user is maximizing Uobj !
Map user’s utility function to some (or range of) objective utility function
Us Uobj , Uobj [U1 , U2 ]
How? By Penalty Function Transformation
Core Network (No Changes)
Any queue mgmt algorithm Drop Tail/RED etc.
Core Routers
Edge Routers
Edge Based Re-Marking Agent
Maps utility function
Manages Selfish Flows. (Decouple it from AQM design)
Provides Service differentiation (Map users to different utility functions).
Users
Free to choose their congestion control algorithm
Either marking or dropping
Idea: Remap @ the Edge, Not in AQM
Decouple Management of Non-Conformant Flows from AQM Design
Users
Network
Routers
Placement
Destination
Mark Packets
MarkAcks
MarkAcks
Drop Packets
What do we need to make it work ?
• Need to identify misbehaving flows.– Smart Sampling in Netflow, Sample & Hold etc
• Estimate loss/mark rate– Currently using EWMA, WALI methods of TFRC
• Estimate utility function– Currently using Least Squares, Recursive LS– Needs only estimates of sending and loss rates
• Scalability– Keep state about only mis-behaving flows
• CBR/UDP flows – Need to drop (Marking does not work)
Re-Marker Design
• Implemented it in Network Simulator• Estimation of loss rate• Estimation of throughput• Get utility function estimate• Compute the Re-Marking function• Appropriately Mark/Drop packets.
– Can also Mark Acks
• Different Algorithm for CBR flows.
Results: Single Bottleneck
Conformance: TCP-Friendliness
2 Flows: Conformant (TCP Reno, U=-1/x),
Mis-Behaving (U=-1/x0.5)
• Packet Drop Based Network. • Drop packets from mis-behaving flows at the edge of the network.
• Marking Based Network. • Re-mark packets from mis-behaving flows at the edge of the network.
Drop TailRED
ECN Enabled
Results: Multi-Bottleneck (Drop Tail)
Conformance: TCP-Friendliness
Long Flow: Conformant (TCP Reno, U=-1/x),
Short Flows: Mis-Behaving (U=-1/x0.5)
TCP Flows shut out
Framework prevents volume based denial of service attack.
Without Re-MappingWith Re-Mapping
Results: Multi-Bottleneck (RED)
Conformance: TCP-Friendliness
Long Flow: Conformant (TCP Reno, U=-1/x),
Short Flows: Mis-Behaving (U=-1/x0.5)
Framework improves fair sharing of network
Without Re-Mapping
With Re-Mapping
Results: Multi-Bottleneck in an ECN Enabled Network
Ideal Case No Re-Mapping With Re-Mapping
Conformance: TCP-Friendliness
Long Flow: Conformant (TCP Reno, U=-1/x),
Short Flows: Mis-Behaving (U=-1/x0.5)
More Results
• Background Traffic– Web (http) Traffic– Single/Multi Bottleneck scenarios
• Cross Traffic– Reverse path congestion– Especially important with RED– Multi-Bottleneck scenarios
• Comparison with other AQM schemes
• Differentiated Services
Conclusions• On a network of Drop Tail queues Mis-Behaving flows can
force Traffic Volume based denial of service attack.– RED can prevent it though not unfair sharing.
• Edge-based transformation of price can handle misbehaving flows– No changes in the core
• No need to add penalty box functions in the context of AQM schemes (eg: CHoKe …)– Decouple mgmt of non-conformant flows from AQM Design.
• Works with packet drop or packet marking (ECN)
• Independent of buffer management algorithm.
• Limitation : Path Asymmetry– Different Exit and Entry routers
Thanks
For more details see http://networks.ecse.rpi.edu/~kartikc/nccc.ps Or email [email protected]