An Improved Hop-by-hop Interest Shaper for Congestion Control in Named Data Networking

1© 2013 Cisco and/or its affiliates. All rights reserved.

An Improved Hop-by-hop Interest Shaper for Congestion Control in Named Data Networking

Yaogong Wang, NCSU

Natalya Rozhnova, UPMC

Ashok Narayanan, Cisco

Dave Oran, Cisco

Injong Rhee, NCSU

3© 2013 Cisco and/or its affiliates. All rights reserved.

NDN Congestion control• Two important factors to consider:

1. Receiver-driven: one interest generates one data packet

2. Symmetric: Content retrieved in response to an interest traverses the same path in reverse

• Content load forwarded on a link is directly related to interests previously received on that link

• Given these properties, shaping interests can serve to control content load and therefore proactively avoid congestion.

• There are multiple schemes that rely on slowing down interests to achieve congestion avoidance or resolution

• But, detecting the congestion in question is not simpleBecause it appears on the other side of the link where interests can be slowed

4© 2013 Cisco and/or its affiliates. All rights reserved.

Interest shaping• Different schemes have been proposed

• HoBHISFirst successful scheme, demonstrated the feasibility of this methodSlows down interests on the hop after congestionRelies on backpressure to alleviate congestion

• ICP/HR-ICPRuns per-flow AIMD scheme to manage outstanding interestsTracks estimated RTT as a mechanism to rapidly detect congestion & lossEndpoints control flow requests by shaping interest issue rateMain congestion control operates end-to-end, some hop-by-hop shaping for special cases

5© 2013 Cisco and/or its affiliates. All rights reserved.

Basic interest shaping• Assume constant ratio r of content-size/interest-size

• Simple unidirectional flow with link rate c

• Ingress interest rate of c/r causes egress content rate of c

• If we shape egress interest rate to c/r, remote content queue will not be overloaded

• Issues with varying content size, size ratio, link rate, etc.

• But the biggest issue is…

6© 2013 Cisco and/or its affiliates. All rights reserved.

What about interests?• Interests consume bandwidth

(specifically, c/r in the reverse direction)

• Bidirectional data flow also implies bidirectional interest flow

• Therefore, the reverse path is not available to carry c bandwidth of data, it also needs to carry some interests

• And similarly, the rate of interests carried in the reverse direction cannot budget the forward path entirely for data, it needs to leave space for forward interests as well

• Ordinarily there is no way to predict and therefore account for interests coming in the other direction, but…

• There is a recursive dependence between the interest shaping rate in the forward and reverse directions.

7© 2013 Cisco and/or its affiliates. All rights reserved.

Problem overview

8© 2013 Cisco and/or its affiliates. All rights reserved.

Problem formulation• We can formulate a mutual bidirectional optimization as follows

• u(.) is link utility function This must be proportionally fair in both direction, to avoid starvation We propose log(s) as utility function

• i1 = received forward interest load• i2 = received reverse interest load• c1 = forward link bandwidth• c2 = reverse link bandwidth• r1 = ratio of received content size to

sent interests size• r2 = ratio of sent contents size to

received interests size

9© 2013 Cisco and/or its affiliates. All rights reserved.

Optimal solution• Feasible region is convex

• First solve for infinite load in both directions

• Optimal solutions at the Lagrange points marked with X

• If Lagrangian points do not lie within feasible region (most common case), convert to equality constraints and solve

10© 2013 Cisco and/or its affiliates. All rights reserved.

Finite load scenarios• Optimal shaping rate assumes unbounded load in both directions

We can’t model instantaneously varying load in a closed-form solution

• If one direction is underloaded, fewer interests need to travel in the reverse direction to generate the lower load

• As a result, the local shaping algorithm need not leave as much space for interests in the reverse direction

Extreme case: unidirectional traffic flow

• Actual shaping rate needs to vary between two extremes depending on actual load in the reverse path

• BUT, we don’t want to rely on signaling reverse path load

11© 2013 Cisco and/or its affiliates. All rights reserved.

Practical interest shaping algorithm• We observe that each side can independently compute both

expected shaping rates

• Our algorithm observes the incoming interest rate, compares it to the expected incoming interest shaping rate, and adjusts our outgoing interest rate between these two extremes

• On the router, interests and contents are separated in output queues. Interests are shaped as per the equation above, and contents flow directly to the output queue.

12© 2013 Cisco and/or its affiliates. All rights reserved.

Explicit congestion notification• When an interest cannot be enqueued into the interest shaper queue,

it is rejected

• Instead of dropping it, we return it to the downstream hop in the form of a “Congestion-NACK”

• This NACK is forwarded back towards the client in the place of the requested content

Consumes the PIT entries on the way

• Note that the bandwidth consumed by this NACK has already been accounted for by the interest that caused it to be generated

Therefore, in our scheme Congestion-NACKs cannot exacerbate congestion

• Clients or other nodes can react to these signals

• In our current simulations, clients implement simple AIMD window control, with the NACK used to cause decrease

13© 2013 Cisco and/or its affiliates. All rights reserved.

Simulation results – basic topology

ScenarioData Throughput

(Mbps)Data loss

(%)Interest rejection rate

(%)Client 1 Client 2 R1 R2 Client 1 Client 2

Baseline25B Interest, 1KB Data

9.558±0.001

9.559±0.002

0 0 0.015±0.0006

0.015±0.0011

Varying Pkt SizeData from 600-1400B

9.432±0.005

9.434±0.008

0 0 0.018±0.0014

0.017±0.0015

Asymmetric data size1000B/500B

9.373±0.014

9.326±0.001

0 0 0.007±0.0006

0.016±0.0006

Asymmetric bandwidth10 Mbps/1 Mbps

9.774±0.001

0.719±0.001

0 0 0.012±0.0005

0.058±0.0000

14© 2013 Cisco and/or its affiliates. All rights reserved.

Simulation results – dumbbell topology

ScenarioData Throughput

(Mbps)Data loss

(%)Interest rejection rate

(%)

Client 1Server 3

Client 2Server 4

R1 R2 Client 1Server 3

Client 2Server 4

Homogeneous RTT 5.142±0.5

4.692±0.5

0 0 0.515±0.011

0.063±0.013

Heterogeneous RTTR2—S4 link now 20ms

5.209±0.38

4.624±0.38

0 0 0.513±0.009

0.042±0.007

Flipped data flowsClient1Server3, Client4Server2

9.566±0.001

9.419±0.007

0 0 0.148±0.0004

0.012±0.0005

15© 2013 Cisco and/or its affiliates. All rights reserved.

Client window and queue evolution• Queue depth on bottleneck queues is small

1 packet for homogeneous RTT caseVaries slightly more in heterogeneous RTT case, but is quite low (<17 packets)

• Client window evolution is quite fair

16© 2013 Cisco and/or its affiliates. All rights reserved.

Benefits of our scheme• Optimally handles interest shaping for bidirectional traffic

• No signaling or message exchange required between routersCorollary: no trust required between peers

• No requirement of flow identification by intermediaries

• Fair and effective bandwidth allocation on highly asymmetric links

• Congestion NACKs offer a timely and reliable congestion signal

• Congestion is detected downstream of the bottleneck link

17© 2013 Cisco and/or its affiliates. All rights reserved.

Future work• Use congestion detection and/or NACKs to offer dynamic reroute

and multi-path load balancing

• Use NACKs as backpressure mechanism in the network to handle unco-operative clients

• Investigate shaper under different router AQM schemes (e.g. RED, CoDEL, PIE) and client implementations (e.g. CUBIC).

18© 2013 Cisco and/or its affiliates. All rights reserved.

Questioners get…