MIRCC: Mul)path-aware ICN Rate-based Conges)on Control Milad Mahdian - - PowerPoint PPT Presentation

▶
mircc mul path aware icn rate based conges on control
SMART_READER_LITE
LIVE PREVIEW

MIRCC: Mul)path-aware ICN Rate-based Conges)on Control Milad Mahdian - - PowerPoint PPT Presentation

May 09, 2023 564 likes •839 views

MIRCC: Mul)path-aware ICN Rate-based Conges)on Control Milad Mahdian Somaya Arianfar Northeastern University Cisco Systems Jim Gibson Dave Oran Cisco Systems Cisco Systems Outline I. Introduc9on II. Single-Path MIRCC III. Mul9path MIRCC I.

slide-1
SLIDE 1

MIRCC: Mul)path-aware ICN Rate-based Conges)on Control

Jim Gibson Cisco Systems Dave Oran Cisco Systems Milad Mahdian Northeastern University Somaya Arianfar Cisco Systems

slide-2
SLIDE 2

Outline

  • I. Introduc9on
  • II. Single-Path MIRCC
  • III. Mul9path MIRCC

I. Dual-Class Best-Subflow Mul9path Rate Management

  • IV. Mul9path Evalua9on
  • V. Conclusions

2

slide-3
SLIDE 3

3

  • I. Introduc9on
slide-4
SLIDE 4

Why Should ICN Explore Rate-Based Conges9on Control?

  • Many aLrac9ve elements, in spite of lack of take-up under IP

– N. Dukkipa9, “Rate control protocol (rcp): Conges9on control to make flows complete quickly”, 2008 – Quick determina9on of sending rate (from first packet received) – Con9nuous forcing of full buffers to track conges9on point not required – Max-min fair alloca9on of boLleneck links between compe9ng flows

  • ICN differs from IP in ways that may be well-suited to rate-based

conges9on control

– Receiver-based with Interest/Data balance – Symmetric forwarding

  • ICN rela9vely clean-slate

– IP’s window-based conges9on control has assump9ons and expected behavior – Compliance with those assump9ons handicaps alterna9ves and adapta9ons

4

slide-5
SLIDE 5

Goals and Context

  • Provide fairness between flows while maximizing network

u9liza9on

– avoiding conges9on and excess latency – taking advantage of mul9path – flow defined by applica9on

  • Converge rapidly in response to load change while maintaining

stable flow alloca9on under stable load

  • Forwarders not required to maintain long-lived per-flow state

– Pending Interest Table is short-lived

  • Rely on distributed algorithms, i.e.

– in the style of the current Internet – not centralized omniscient controllers

  • Caching

– Mul9-des9na9on supported: object-level caching a form of mul9- des9na9on – Per-chunk opportunis9c caching not considered at this 9me

5

slide-6
SLIDE 6
  • II. Single-Path MIRCC

6

slide-7
SLIDE 7

Basic Single-Path Rate Control Concepts

7

f d e

Consumer App

Producer App

R(t)=20

c b a

R(t)=40 R(t)=15 R(t)=25 R(t)=10

MAX

D 20 D 20 D 15 D 10 D

Int Send

NewDate Rate

10

I

  • Each forwarder, at each interface, maintains R(t): the per-flow

stamping rate for that interface

  • Forwarder stamps each Data msg with its interface R(t) if R(t) <

received_value

  • Thus, each Data message carries lowest R(t) seen along path
  • Endpoint consumer updates flow’s Interest sending rate
  • according to Date rate indicated by received boLleneck R(t), deflated
  • Forwarder manages load by changing R(t) +/- when observed traffic is

low/high

  • R(t) calcula9on is the heart of the distributed system
slide-8
SLIDE 8

Forwarder’s R(t) Elements

8

  • R(t) represents Data rate but is calculated based on Interest rate. Why

not use Data rate?

– ICN style: ICN is pull-based, which implies managing Interests directly, Data indirectly – We assume an Interest shaper on each face

  • Shaping/Nacking Interests filters conges9on signals from Data rate
  • Maintain an Infla-on (DataSize/IntSize) es9mate

– Use shaper’s infla9on value

  • Directly stamp Data messages

– i.e. stamping Interests and reflec9ng R(t) back in Data at producer – Quicker repor9ng to consumer

slide-9
SLIDE 9

R(t) Algorithm Overview

9

  • MIRCC and RCP R(t) algorithms differ in detail, similar in spirit
  • R(t) updated once per interval T, stamped for next interval [t+T]
  • R(t) inputs:

– Inputs based on aggregates – No flow-specific state/logic – No forwarder determina9on of how many actual flows are using the link. Ñ, aka “Flow es9mate” is synthe9c, i.e unrelated to actual flows

Interval T Link capacity (leaving headroom, e.g 95%) ηC Rate calculated for previous interval R(t-T) Interests (inflated) arriving during this interval y(t) Queue depth/RTT es9mate q(t)/d(t) Constants (weighted average, tuning parameter) α, β

slide-10
SLIDE 10

Simula9on Results Single-Path MIRCC vs. Straight Port of RCP Algorithm

[Cisco implementa9on of CCNx1.0, run under ns-3]

10

  • 250

500 750 1000 82 83 84 85

Time (s) Rate (Kbps)

  • 250

500 750 1000 82 83 84 85

Time (s) Rate (Kbps)

Rate convergence in MIRCC Rate convergence in RCP

slide-11
SLIDE 11
  • III. Mul9path MIRCC

11

slide-12
SLIDE 12

Issue 1: Path Iden9fica9on and Steering

A flow consists of mul9ple subflows. Each subflow’s path reports its own Rsf(t)

  • What en9ty tracks a flow’s mul9ple subflows and their current Rsf(t)?

– Consumer endpoint (applica9on/applica9on-library), the only en9ty given stated goals and assump9ons – Significant extra responsibility for consumer vs. single-path situa9on

  • How does consumer endpoint iden9fy subflows and per-subflow Rsf(t)?

– Path iden-fier, reported in Data message

  • How are consumer endpoint’s decisions about per-subflow rates

honored for the consumer’s Interests?

– Path iden-fier, reflected back in Interest as hint

  • How are subflows discovered?

– Interests without path iden9fiers must be sent ini9ally/periodically – Forwarders with mul9ple next hops choose probabilis9cally

  • Path steering mechanisms have other possible uses, e.g. for ICN ping

performance measurement and for ICN traceroute

12

slide-13
SLIDE 13

Issue 2: Mul9path Fair Flow Rate

  • Simple schemes do not meet the stated goals

– Send at rate of Best-Subflow : Max(Rsf(t))

  • Underu9lized network (easily evident with small number of flows)

– Send at Total per-Subflow rate: Σ Rsf(t)

  • Flow-Unfair: Not max-min fair between flows
  • Link-Unfair: Can occupy more than one flow-share of shared links
  • Signaling a complete picture of flow’s subflow

topology (including joint boLleneck link rates) to consumer or forwarders is not tractable

13

slide-14
SLIDE 14

Mul9path Fair Flow Rate Solu9on

Dual-Class Best-Subflow Mul)path Rate Management

  • Exis9ng (“Primary”) Class

– Forwarder maintains and stamps Rp(t) in every Data message – Primary pool con9nues to be sized to link capacity: C – Consumer sends Primary Interests at Best-Subflow rate: Max(Rp(t)) – Generally high level of fairness between flows

  • New (“Secondary”) Class, for any remaining bandwidth

– Forwarder also maintains and stamps Rs(t) in every Data message – Secondary pool sized to unused primary bandwidth: C – primary_traffic(t) – Consumer sends Secondary Interests at Total per-Subflow rate: Σ Rs(t) – “Soaks up” any remaining available bandwidth

  • Forwarders preferen9ally drop Secondary traffic under conges9on

14

slide-15
SLIDE 15

15

  • III. Evalua9on
slide-16
SLIDE 16

MIRCC Mul9path: Single Flow Arrival and Departure

16

R(t)=15Mbps R(t)=12 Mbps Consumers 1, 2 Producer 1a F2 E1 Producers 1b, 2 E4

Consumer 1 Consumer 2 la lb lc

R(t)=9 Mbps E3

15-12-9 Slingshot Topology Note:

  • Joint boLleneck la always fully u9lized

(C1:TotalRate + C2:TotalRate)

  • Stable flow rates under stable load
  • While C1 and C2 are compe9ng
  • no excess capacity
  • secondary rate traffic goes to 0

95% of Bottleneck Link (Note: Flow TotalRate = Primary + Secondary)

C1:TotalRate C1:PrimaryRate C1:SecondaryRate C2:TotalRate

2 4 6 8 10 12 14 16 18 20 80 85 90 95

Time (s) Rate (Mbps)

Rate management for two consumers,

  • ne with mul)path
slide-17
SLIDE 17

MIRCC Mul9path: Mix of Short and Long Flows

17

  • 16807

2 984943658 2 1144108930 3 1457850878 4 2007237709 5 1784484492 5000 10000 15000 20000 5000 10000 15000 20000 5000 10000 15000 20000 50 100 150 200 50 100 150 200

Time (s) RcvdData (Kbit) 0.00 0.25 0.50 0.75 1.00 5000 10000 15000

Completion Time (ms) CDF of Flow Completion Time length R(t)=100Mbps Scenario 1: R(t)=100Mps Scenario 2: R(t)=15Mbps 10Mbps

Consumers A-D Producers A-E F2 F3 F4 F5 E0 E6

la lc ld lf le lg 100Mbps

Consumer E E1

R(t)=100Mbps lb

Diamond Topology Flows arriving/leaving frequently (0.5s) Note:

  • Short flows not disadvantaged
  • Links fully u9lized

Short flows Long flows

slide-18
SLIDE 18

Single-Path vs. Mul9path

18 M.11 S.11 M.13 S.13 M.14 S.14 M.15 S.15 M.17 S.17 M.18 S.18 M.20 S.20 M.21 S.21 20000 40000 60000

Delivery time (ms) Node ID Prefix

/Amazon /Google /Warner

Note:

  • 3 synthe9c producer nodes (not really

Amazon/Google/Warner)

  • 8 consumer nodes, random assignment
  • Random mix of flow sizes
  • Enabling Mul9path significantly lowers

average delivery 9me vs. Single-path

  • not on 14, 15

Delivery Time [sec]

Abilene Topology

slide-19
SLIDE 19

Conclusions

  • We iden9fy an algorithm for maintaining R(t) that

provides beLer throughput and convergence, in our ICN simula9ons, than (a straight port of) RCP’s algorithm

  • For mul9path rate-based conges9on control

– We devise a scalable path management solu9on, opera9ng at the endpoints, that is based on a path iden9fica9on/steering mechanism – We devise a rate management solu9on that

  • Maintains a high degree of fairness between flows
  • Achieves high network u9liza9on
  • Uses addi9onal machinery that is in the spirit of the simpler single-

path rate-based conges9on control

– We avoid forwarder per-flow state.

19

slide-20
SLIDE 20

Q/A

20

slide-21
SLIDE 21

21

  • Appendix. Backup Slides
slide-22
SLIDE 22
  • 𝑆 𝑢 = 𝐶𝑏𝑡𝑓𝑆𝑏𝑢𝑓 𝑢 + 𝐹𝑦𝑑𝑓𝑡𝑡𝑆𝑏𝑢𝑓 𝑢
  • the stamping rate
  • 𝐶𝑏𝑡𝑓𝑆𝑏𝑢𝑓 𝑢 =

𝜃𝐷 −𝛾(𝑢)𝑟(𝑢)

𝑒(𝑢)

𝑂

  • non-recursive formula to split the allowed link bandwidth among

the passing flows

  • 𝐹𝑦𝑑𝑓𝑡𝑡𝑆𝑏𝑢𝑓 𝑢 = 𝑆 𝑢 − 𝑈 −

𝑧 𝑢 𝑂

  • recursively fill up the extra available bandwidth with traffic equally
  • 𝑂 =

max(𝐷,𝑧 𝑢 ) 𝑆(𝑢−𝑈)

  • equivalent number of flows with full rate
  • 𝛾 𝑢 = max

𝛾′,

𝑧 𝑢 −𝑧(𝑢−𝑈) 𝑧(𝑢)

  • self-tuned parameter chosen for stability

MIRCC R(t) Algorithm

22

slide-23
SLIDE 23

Rate-Based Basic (Single Path) Scheme: Flow Rate Convergence

F1 (E) F2 (E) F3 (E) F4 (E)

10G

4 responsive (elas9c) flows sharing link

  • R(t) [FlowStampingRate]: 2.5Gig
  • FlowCount(No9onal): 4

10G

0 flows currently using link

  • R(t) [FlowStampingRate]: 10Gig (cap)
  • FlowCount(No9onal): 1/0

F1 (E) F2 (1G) F3 (1G) F4 (1G)

10G

4 responsive (elas9c) flows sharing link, 3 are boLlenecked elsewhere at 1G

  • R(t) [FlowStampingRate]: 7Gig
  • FlowCount(No9onal): 1.43

F1 (1pps) F2 (1pps)

….

F100 (1pps)

10G

100 CBR flows (1 pps) sharing link

  • R(t) [FlowStampingRate]: ~10Gig (cap)
  • FlowCount(No9onal): 1/0
slide-24
SLIDE 24

Basic Single-Path Rate Control Proper9es

  • Achieves max-min fairness among flows

sharing link

  • No flow-specific state/logic at forwarder for

calcula9ng stamping rate

  • Not based on forwarder determina9on of how

many actual flows are using the link

  • Minimal endpoint responsibili9es in single-

path version

24

slide-25
SLIDE 25

MIRCC Mul9path: Single Flow Arrival and Departure (Symmetric 10Mbps Producer Links)

25

Note:

  • Joint boLleneck la always fully u9lized

(C1:TotalRate + C2:TotalRate)

  • Stable flow rates under stable load
  • While C1 and C2 are compe9ng
  • no excess capacity
  • secondary rate traffic goes to 0

95% of Bottleneck Link (Note: Total = Primary + Secondary)

C1:TotalRate C1:PrimaryRate C1:SecondaryRate C2:TotalRate

2 4 6 8 10 12 14 16 18 20 80 85 90 95

Time (s) Rate (Mbps)

Rate management for two consumers,

  • ne with mul)path

15-10-10 Slingshot Topology

R(t)=15Mbps R(t)=10 Mbps Consumers 1, 2 Producer 1a F2 E1 Producers 1b, 2 E4

Consumer 1 Consumer 2 la lb lc

R(t)=10 Mbps E3