Un-Cooperative Congestion Control

Kartikeya Chandrayana

Prof. Shivkumar Kalyanaraman

ECSE Dept., R.P.I.

chandk@rpi.edu (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 chandk@rpi.edu