UnCooperative Congestion Control

1
Un-Cooperative Congestion Control

• Kartikeya Chandrayana
• Prof. Shivkumar Kalyanaraman
• ECSE Dept., R.P.I.
• chandk_at_rpi.edu (http//www.rpi.edu/chandk)

2
Outline

• Review
• Motivation
• Previous Work
• Network Optimization
• Proposed Framework
• Results

3
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.

4
Internet Dynamics
Search Game User searches for bandwidth with
some help from the network
5
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)

6
TCP

• Slow Start
• Probe exponentially for bandwidth.
• Congestion Avoidance
• Send w packets in a round-trip time.
• If receive w acks then put w1 packets in next
  RTT
• If congestion put w/2 packets in next RTT.

7
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
rate TCP Friendliness ? x ? 1/sqrt(p)
8
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 w5 packets in next
  RTT
• If congestion put 3w/4 packets in next RTT.

9
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 networks standard CC
scheme is TCP Any scheme which gets more rate
than TCP is uncooperative
10
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

11
Effect of Misbehavior
Long Flow Conformant (TCP Reno, U-1/x), Short
Flows Mis-Behaving (U-1/x0.5) Incr 1
packet/RTT Decr sqrt(w) on loss
Happened in NCSU !
Present Internet is a network of Drop Tail queues
12
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.

13
AQM Effect of Misbehavior
Long Flow Conformant (TCP Reno, U-1/x), Short
Flows Mis-Behaving (U-1/x0.5)
RED Helps Though unfair sharing persists
14
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 dont 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
15
Related Work
Routers
Users
Network
Some Buffer Mgmt. Scheme
What is the right architectural response ?
16
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

U(x)
x (Rate)
17
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.

18
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 users 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.

19
How? By Penalty Function Transformation
Map users utility function to some (or range of)
objective utility function Us ? Uobj , Uobj ?
U1 , U2

• 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 users update algorithm looks like
• xs Us'-1(qnew)
• ? xs Uobj'-1(q)
• ? Appears as if user is maximizing Uobj !

20
Idea Remap _at_ the Edge, Not in AQM
Edge Routers
Core Routers
Core Network
(No Changes)
Users
Decouple Management of Non-Conformant Flows from
AQM Design
21
Placement
Routers
Users
Network
Destination
22
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)

23
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.

24
Results Single Bottleneck
Conformance TCP-Friendliness 2 Flows Conformant
(TCP Reno, U-1/x), Mis-Behaving (U-1/x0.5)
RED
Drop Tail
ECN Enabled

• 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.

25
Results Multi-Bottleneck (Drop Tail)
Conformance TCP-Friendliness Long Flow
Conformant (TCP Reno, U-1/x), Short Flows
Mis-Behaving (U-1/x0.5)
With Re-Mapping
Without Re-Mapping
Framework prevents volume based denial of service
attack.
26
Results Multi-Bottleneck (RED)
Conformance TCP-Friendliness Long Flow
Conformant (TCP Reno, U-1/x), Short Flows
Mis-Behaving (U-1/x0.5)
Without Re-Mapping
With Re-Mapping
Framework improves fair sharing of network
27
Results Multi-Bottleneck in an ECN Enabled
Network
Conformance TCP-Friendliness Long Flow
Conformant (TCP Reno, U-1/x), Short Flows
Mis-Behaving (U-1/x0.5)
28
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

29
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

30
Thanks

• For more details see
• http//networks.ecse.rpi.edu/kartikc/nccc.ps
• Or email chandk_at_rpi.edu