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:
RINA needs to show fantastic performance,
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

3. Two major mistakes of Internet CC.
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)
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

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

5. Problems of using ECN as “load”
It is not additive; it’s a product:
(pr: end-to-end marking probability)
(pl: 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)!

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)
Advantages:
New signal is a pretty general solution; just conveys "load", and could (relatively) easily be extended to multi-bit
New signal is probably good input to load-based routing too
RED as an already-deployed solution can be used; only small changes at senders and receivers
Simulation results
deviation (previous theory)
Numerical results
our method
x(1): avg. rate of a five-hop flow
x(2): avg. rate of a one-hop flow

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
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 2016.
David Hayes, Peyman Teymoori, Michael Welzl: "Feedback in Recursive Congestion Control", 13th European Workshop on Performance Engineering (EPEW 2016), Chios, Greece, 5-7 October 2016.
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
r = growth rate ∆N ∆t
= 0 N ∆N ∆t
is maximized ∆N ∆t
= 0
1800
1900
Time

13. LGC in a chain – Multiple Loops Foodchain model: various stability analyses exist...
x1=x1+x1 r (C1 – x1 – q1)
C1 = min (x2, L1,1 , L1,2)
x2=x2+x2 r (C2 – x2 – q2)
C2 = min (x3, L2)
x3=x3+x3 r (C3 – x3 – q3)
q1 reflects the congestion measure at both routers 1 and 2 1 2 C1 C2 C3
L1,1
L1,2 L2 L3
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!

15. Limitations of e2e CC R I N A
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!
R I N A

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 

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

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

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) )

20. Conclusion Congestion control This will enable load-based routing
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

21. Thank you! Questions?