for the Next-Generation Tactile Internet Mohamed Faten Zhani cole - PowerPoint PPT Presentation

IRTF Network Management Research Group 55 th meeting Introducing FlexNGIA: A Flexible Internet Architecture for the Next-Generation Tactile Internet Mohamed Faten Zhani École de technologie supérieure (ÉTS Montreal) Canada Montreal, Canada, 27 July 2019

Outline • A Glance into the Future • Limitations of Today’s Internet • FlexNGIA: Fully-Flexible Next-Generation Internet Architecture • Use cases/intent • Conclusion M. F. Zhani, H. ElBakoury, “ FlexNGIA: A Flexible Internet Architecture for the Next-Generation Tactile Internet ,” ArXiV 1905.07137, May 17, 2019 https://arxiv.org/abs/1905.07137 2

Requirements & Characteristics • Future Applications: Telepresence, VR/AR, Holoportation • Requirements: o High processing power: real-time processing o High bandwidth (e.g., VR (16K, 240 fps)  31.85 Gbps) o Ultra-low Latency: 1ms to 20ms o Multi-flow synchronization o High availability 3 M. F. Zhani, H. ElBakoury - FlexNGIA 2019 (https://arxiv.org/abs/1905.07137)

Requirements & Characteristics • Octopus-like applications: huge number of flows for each application • Changing requirements : requirements can change over time 4 M. F. Zhani, H. ElBakoury - FlexNGIA 2019 (https://arxiv.org/abs/1905.07137)

Outline • A Glance into the Future • Limitations of Today’s Internet o Internet Infrastructure and Services o Network Stack Layers and Headers o Sources of Latency • FlexNGIA: Fully-Flexible Next-Generation Internet Architecture • Use cases/intents • Conclusion 5 M. F. Zhani, H. ElBakoury - FlexNGIA 2019 (https://arxiv.org/abs/1905.07137)

Internet Infrastructure and Services • A network of networks ISP4 • Offered service : “Best effort” data delivery.. no more ISP3 ISP2 • No control over the infrastructure  No control over the end-to-end ISP1 path and quality of service  No performance guarantees 6 M. F. Zhani, H. ElBakoury - FlexNGIA 2019 (https://arxiv.org/abs/1905.07137)

Transport Layer Protocols Many modern protocols like SCTP and QUIC b ut let’s focus first on TCP.. • One-size-fits-all service offering: TCP offers reliability, data retransmission, congestion and flow control • Blind Congestion control • The two end points limitation: o High retransmission delays (~ 3x e2e delay) o Transport and network layers are not aware which flows belong to the same application 7 M. F. Zhani - FlexNGIA 2019

Network Layer Protocols • Not aware of the applications o The application composition (in terms of flows) o Performance requirements of each of these flows and how these requirement change over time  Drop packets « blindly » • No collaboration with the transport layer o Do not provide explicit feedback or support to transport layer (maybe ECN is interesting but it is not enough) o Do not help with other transport services (e.g., reliability) 8 M. F. Zhani, H. ElBakoury - FlexNGIA 2019 (https://arxiv.org/abs/1905.07137)

Network Stack header Problems with current headers: • Do not provide additional informations about objects/sensors, flows belonging to the same application, applications’ requirements, etc. • Not flexible enough: It is not easy to incorporate meta-data and commands 9 M. F. Zhani, H. ElBakoury - FlexNGIA 2019 (https://arxiv.org/abs/1905.07137)

Outline A Glance into the Future • • Limitations of Today’s Internet FlexNGIA: Fully-Flexible Next-Generation Internet Architecture • o Future Internet Infrastructure and services o Business Model o Management Framework o Network Protocol Stack/Functions o Stack Headers Use cases/intents • Conclusion • 10 M. F. Zhani, H. ElBakoury - FlexNGIA 2019 (https://arxiv.org/abs/1905.07137)

FlexNGIA:a Flexible Internet Architecture for the Next-Generation Tactile Internet FlexNGIA Application-Aware Flexible Computing Cross-layer Design Business model Network headers resources (Transport+Network) Management - Advanced functions - Tailored - Breaking the - Multiple source - In-Network tailored to to the end-to-end paradigm destination Computing: applications application Service Function - In-network advanced any function - App-aware traffic transport functions Chains anywhere engineering - Stringent - Better congestion control performance - Stringent performance requirements and reliability guarantees 11 M. F. Zhani - FlexNGIA 2019

Future Internet Infrastructure and Services How a network will look like? 11 • Computing resources are everywhere: 0 13 10 Available at the edge and at the core 8 3 7 1 of the network 6 4 12 2 • Commodity servers but also dedicated 9 hardware, FPGA, GPU, NPU, etc. 5  In-Network computing Cloud Data Center  Reduce steering delay Micro cloud  Full Programmability: Any function could be provisioned anywhere (virtual machines/containers) 12 M. F. Zhani, H. ElBakoury - FlexNGIA 2019 (https://arxiv.org/abs/1905.07137)

Future Internet Infrastructure and Services How does Future Internet look like? • Still a network of networks.. • What is new? o More services: Service Function chains  More advanced functions  More than just delivery o Stringent performance guarantees 13 M. F. Zhani, H. ElBakoury - FlexNGIA 2019 (https://arxiv.org/abs/1905.07137)

Future Internet Infrastructure and Services Application-Driven Intent: Service Function Chain (SFC) AA S0 AA D0 Multiple connected network functions • AA D1 AA S1 NF 13 NF 12 NF 11 Multiple sources and destinations • AA D2 AA S2 Made out from Network Functions • Sensors/ objects Defines, for each network function, the type, • S Traffic Source software, input/output packet format, expected D Traffic Destination processing delay, buffer size Application AA Assistant Sensors/objects Defines performance requirements • (e.g., throughput, packet loss, end-to-end delay, jitter) 14 M. F. Zhani, H. ElBakoury - FlexNGIA 2019 (https://arxiv.org/abs/1905.07137)

Business Model Network Operators Function S0 Service Chain S1 D=13 • Own and manage the physical NAT IDS S2 Firewall infrastructure (i.e., one network) • Deploy platforms and software Mapping required to run network functions 11 0 • The service could be simply data Infrastructure 13 10 Physical S delivery or a SFC Source 8 D Destination 3 7 1 • Provision and manage SFCs POP 6 12 4 Link 2 Mapped instance 9 Virtual Link 5 15 M. F. Zhani, H. ElBakoury - FlexNGIA 2019 (https://arxiv.org/abs/1905.07137)

Business Model (cont) Customers Could be other network operators, companies or Institutions • Define the required SFC and Identify the chain sources/destinations • Rely on the operator to provision and manage the SFC and satisfy SLA • SFC composition • SLA requirements for the SFC • Bandwidth o Operator End-to-end delay o Reliability, availability o Customer NAT IDS SLA requirements for each NFs • Firewall Processing power o Packet format(s) o Packet drop criteria… o 16 M. F. Zhani, H. ElBakoury - FlexNGIA 2019 (https://arxiv.org/abs/1905.07137)

Business Model (cont) • Example of potential Network Operators: o ISPs (e.g., AT&T or Bell Canada) and web-scale companies (e.g., Google, Facebook, Amazon) o Example: Google Cloud Platform • World wide global Infrastructure • Software defined platform • Full control over the infrastructure 15 Data centers 100 Points of Presence (PoPs) 1000+ Edge nodes 17 M. F. Zhani, H. ElBakoury - FlexNGIA 2019 (https://arxiv.org/abs/1905.07137) Source: cloud.google.com

Resource Management Framework Service Function Chain SFC 1 associated with Application 1 AA S0 Resource Allocation AA AA S1 D13 NF 13 NF 12 The Service Function Chain (SFC) • NF 11 is defined by the application designer AA S2 Translation Sensors/ 2-step resource allocation: • objects Translation: the SFC is translated • AA 3 8 0 Topology AA Virtual into a virtual topology 6 AA 1 4 9 11 Mapping: virtual topology • S Traffic Source 7 AA 2 5 10 D Traffic Destination are mappa Point of Presence Mapping Physical Link AA 11 AA Mapped Instance 0 Infrastructure Physical 13 Virtual Link 10 Application AA 8 Assistant AA 3 7 Sensors/objects 1 Service 6 12 SFC 4 Function Chain 2 AA 9 5 18 M. F. Zhani, H. ElBakoury - FlexNGIA 2019 (https://arxiv.org/abs/1905.07137)

Resource Management Framework Resource Management Framework Signaling Module AA S0 Monitoring AA Data Application Main components: Control Resource Allocation AA S1 D1 Module Module NF 12 NF 13 NF 11 Signaling module • AA S2 Application 1 - SFC 1 .. Monitoring .. Application Control Module Module • AA Monitoring S5 AA Data Application Ressource allocation Module • Failure Management AA Control S6 DN Module Module NF n2 NF n3 NF n1 AA S7 Application n - SFC n Sensors/ objects Monitoring Data Mapping Commands AA 11 AA 0 13 10 S 8 Traffic Source D 3 7 Traffic Destination AA 1 6 12 Point of Presence 4 2 Physical Link 9 AA Mapped Instance 5 Virtual Link Physical Infrastructure AA Application Assistant Sensors/objects NB: For simplicity, the figure shows only the mapping of the chain SFC 1 19 M. F. Zhani, H. ElBakoury - FlexNGIA 2019 (https://arxiv.org/abs/1905.07137) SFC Service Function Chain associated to Application 1