OCARINA ("Optimizations to Compel Adoption of RINA") Michael Welzl RINA Workshop Research Day i2cat Barcelona

Transcription

1 OCARINA ("Optimizations to Compel Adoption of RINA") Michael Welzl RINA Workshop Research Day i2cat Barcelona

2 Project overview 5-year project funded by Norwegian research council, started 1 October 2016; 1 postdoc + 3 Ph.D. students Focused on performance. Assumptions: 1. RINA needs to show fantastic performance, 2. RINA can show fantastic performance! 3 main WPs: cong. control, routing, Internet deployment RINA forces us to think differently about network algorithms such as routing and congestion control E.g., Internet-like "end-to-end" congestion control could be implemented in a RINA network, but that would be a very strange configuration 2

3 Two major mistakes of Internet CC. 1. First produce congestion, then react to it CC. is not only about controlling a problem after it happens: CC. is about determining the right sending rate at any time Congestion is also not binary, and loss and delay are bad signals Solution: create a meaningful "load" signal that does not embed a very specific algorithm (give some freedom to designers) 2. Clueless about underlying infrastructure, by design Inevitable result of Internet layering: "IP over everything" (good idea), "TCP optimized to blindly run over IP" (bad idea) "Cross-layer" solutions show: we could do better; but they can never be standardized because they don't fit the Internet model... and PEPs pragmatically improve things but "shouldn't exist" Solution: use per-dif loops, work with back-pressure 3

4 Addressing problem #1: Fixing ECN Why is it broken? Cost incurred in the network is additive per hop (see NUM theory), but can't re-mark a marked packet Note: cost not additive when packets are dropped Originally not a major problem because ECN signal should be rare; but poor signal Better "load" signal in DCTCP-style usage: instantaneous queue marking, count marks / RTT Even better "load" signal when marking before a queue even grows (virtual Q) Better signal quality, more problems with multiple links 4

5 Problems of using ECN as load It is not additive; it s a product: (p r : end-to-end marking probability) (p l : link marking probability) Modern controllers such as DCTCP converge at high marking probabilities. The theory (e.g. Network Utility Maximization (NUM)) needs an additive signal; a product value deviates much in high marking probabilities ( > 0.04)! 5

6 Our Solution Extending the KKT theorem to include functions as multipliers, and then use as multiplier. With a lot of math and stability analysis of course Results: (assuming a logarithmic utility) Numerical Simulation results results deviation (previous theory) our method x (1) : avg. rate of a five-hop flow x (2) : avg. rate of a one-hop flow Advantages: 1. New signal is a pretty general solution; just conveys "load", and could (relatively) easily be extended to multi-bit 2. New signal is probably good input to load-based routing too 3. RED as an already-deployed solution can be used; only small changes at senders and receivers 6

7 How it works

8 Applications Obtaining utility function when the marking probability is high, e.g. DCTCP: Deflating marking probability Playing with the base of log And the potential of dealing with virtual ("phantom") queues!

9 Addressing problem #2: Per-DIF loops PRISTINE background A sequence of DIFs doing TCP CC. is much like a sequence of split-tcp PEPs can be beneficial [1] Examples on the next slides However, controls using recursive queue based feedback can have stability issues (+ delay from multiple queues) [2] Envision to address this with logistic growth based control [3] + new "fixed" ECN More on the next slides 1. Peyman Teymoori, Michael Welzl, Stein Gjessing, Eduard Grasa, Roberto Riggio, Kewin Rausch, Domenico Siracusa: "Congestion Control in the Recursive InterNetworking Architecture (RINA)", IEEE ICC 2016, Kuala Lumpur, Malaysia, May David Hayes, Peyman Teymoori, Michael Welzl: "Feedback in Recursive Congestion Control", 13th European Workshop on Performance Engineering (EPEW 2016), Chios, Greece, 5-7 October Peyman Teymoori, David Hayes, Michael Welzl, Stein Gjessing: "Even Lower Latency, Even Better Fairness: Logistic Growth Congestion Control in Datacenters", IEEE LCN 2016, Dubai, UAE, Nov 2016.

10 Horizontal: Consecutive DIFs Topology: Results:

11 Vertical: Stacked DIFs Topology: Results: 1 sender, 1 receiver: Sender sends flow 1 (large) at 0, and flow 2 (small) at time 10.

12 Logistic Growth: Population Dynamics Proven to be globally asymptotically stable K = carrying capacity N t = 0 r = growth rate N N t is maximized N t = Time

13 LGC in a chain Multiple Loops Foodchain model: various stability analyses exist... x1=x1+x1 r (C1 x1 q1) x2=x2+x2 r (C2 x2 q2) x3=x3+x3 r (C3 x3 q3) C1 = min (x2, L1,1, L1,2) C2 = min (x3, L2) q 1 reflects the congestion measure at both routers 1 and C 1 C 2 C 3 L 1,2 L 1,1 L 2 L 3 router 1 router 2 router

14 What about Machine Learning? Remy (offline learning), PCC + Vivace (online learning) derive "optimal" TCP behavior ML! Like in a self-driving car! Self-driving! 14

15 Limitations of e2e CC There are many... e.g. consider the "vertical stacking" case: Remy etc. can't help here either More "modern" example: especially with 5G, PHY link capacity can change a lot, and quickly TCP cannot quickly react to it: TCP can't be sure a signal is from the bottleneck IETF failure; recent example: "throughput guidance" Only safe to reduce the rate (and only if signal trustworthy) Survey of such ideas that failed in the IETF: draft-dawkins-panrg-what-not-to-do RINA is an opportunity to apply ML to better-scoped problems! 15

16 Deployment We can consider RINA-under-IP, RINA overlay, and RINA-IP gateways... But we can also consider "switching over"! Once a host discovers that the whole path to the other end is RINA-enabled, switch Today, often, paths are short (Google, FB,... are not far away from you) TCP/IP are only rendez-vous protocols Some recent IETF standards could help A little ironic J 16

17 Transport Services (IETF TAPS WG) Makes apps independent of protocol and network interface Finished surveying and condensing services provided by: TCP, MPTCP, UDP, UDP-Lite, SCTP, LEDBAT Now working on Proposed Standard API + implementation guidance, with Apple among others; implementations: Apple, NEAT (open source) API properties: callback-based, message-oriented Hides protocols, but supports all features of all protocols above + plan: QUIC Some example protocol properties (some also: protocol & path selection): Reliability, Ordering, Per-Message Reliability, 0-RTT Session Establishment, RTX and ICMP notification, Checksum coverage control, Capacity profile (normal, low latency, CBR, scavenger), Interface type, Multiplexing (multistreaming), Relative Niceness within group Various security parameters 17

18 Interface diagram (taken from: Brian Trammell, IETF 101) 18

19 Provisioning Domains (PvDs) (INTAREA WG) Router Advertisement (RA) option from first-hop router conveys FQDN that host can use to retrieve extra info about network access characteristics via HTTP over TLS query Applications then select (via local IP address) which PvD to use, and can learn config. params for transport layer and above Example from NEAT project (Gorry Fairhurst, Tom Jones (University of Aberdeen) André Venne, Eric Bruneau (Cisco) ) 19

20 Conclusion Congestion control RINA "forces" us to do it in a fundamentally different, and (probably) inherently better way better throughput, less latency This will enable load-based routing chance for much higher throughput... and there are interesting deployment opportunities 20

21 Thank you! Questions? 21