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. Dual-Class Best-Subflow Mul9path Rate Management IV. Mul9path Evalua9on V. Conclusions 2
I. Introduc9on 3
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
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
II. Single-Path MIRCC 6
Basic Single-Path Rate Control Concepts Consumer App Producer 10 15 20 20 MAX D D D D D Int Send App NewDate e a b c d f Rate R(t)= 10 R(t)= 15 R(t)= 40 R(t)= 20 R(t)= 25 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 • 7
Forwarder’s R(t) Elements • 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 8
R(t) Algorithm Overview • 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: 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) α, β – 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 9
Recommend
More recommend
