Reliable Packet Streams with Multipath Network Coding

With increasing computational capabilities and advances in robotics, technology is at the verge of the next industrial revolution. An growing number of tasks can be performed by artificial intelligence and agile robots. This impacts almost every part of the economy, including agriculture, transportation, industrial manufacturing and even social interactions. In all applications of automated machines, communication is a critical component to enable cooperation between machines and exchange of sensor and control signals. The mobility and scale at which these automated machines are deployed also challenges todays communication systems. These complex cyber-physical systems consisting of up to hundreds of mobile machines require highly reliable connectivity to operate safely and efficiently. Current automation systems use wired communication to guarantee low latency connectivity. But wired connections cannot be used to connect mobile robots and are also problematic to deploy at scale. Therefore, wireless connectivity is a necessity. On the other hand, it is subject to many external influences and cannot reach the same level of reliability as the wired communication systems. This thesis aims to address this problem by proposing methods to combine multiple unreliable wireless connections to a stable channel. The foundation for this work is Caterpillar Random Linear Network Coding (CRLNC), a new variant of network code designed to achieve low latency. CRLNC performs similar to block codes in recovery of lost packets, but with a significantly decreased latency. CRLNC with Feedback (CRLNC-FB) integrates a Selective-Repeat ARQ (SR-ARQ) to optimize the tradeoff between delay and throughput of reliable communication. The proposed protocol allows to slightly increase the overhead to reduce the packet delay at the receiver. With CRLNC, delay can be reduced by more than 50 % with only a 10 % reduction in throughput. Finally, CRLNC is combined with a statistical multipath scheduler to optimize the reliability and service availability in wireless network with multiple unreliable paths. This multipath CRLNC scheme improves the reliability of a fixed-rate packet stream by 10 % in a system model based on real-world measurements of LTE and WiFi. All the proposed protocols have been implemented in the software library NCKernel. With NCKernel, these protocols could be evaluated in simulated and emulated networks, and were also deployed in several real-world testbeds and demonstrators.:Abstract 2 Acknowledgements 6 1 Introduction 7 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2 Use Cases and Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3 Opportunities of Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.4 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2 State of the Art of Multipath Communication 19 2.1 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2 Data Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.3 Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.4 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5 Application Layer and Session Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.6 Research Gap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3 NCKernel: Network Coding Protocol Framework 27 3.1 Theory that matters! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.1 Socket Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.2 En-/Re-/Decoder API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.4 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.5 Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.4 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.5 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4 Low-Latency Network Coding 35 4.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.2 Random Linear Network Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3 Low Latency Network Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.4 CRLNC: Caterpillar Random Linear Network Coding . . . . . . . . . . . . . . . . . . 38 4.4.1 Encoding and Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.4.2 Decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.4.3 Computational Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.5.1 System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.5.2 Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.5.3 Packet Loss Probability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.5.4 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.5.5 Window Size Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5 Delay-Throughput Tradeoff 55 5.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.2 Network Coding with ARQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.3 CRLNC-FB: CRLNC with Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.3.1 Encoding and Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.3.2 Decoding and Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.3.3 Retransmissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.4.1 System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.4.2 Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.4.3 Systematic Retransmissions . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.4.4 Coded Packet Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.4.5 Comparison with other Protocols . . . . . . . . . . . . . . . . . . . . . . . . 67 5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 6 Multipath for Reliable Low-Latency Packet Streams 73 6.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 6.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.3 System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 6.3.1 Traffic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 6.3.2 Network Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 6.3.3 Channel Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 6.3.4 Reliability Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 6.4 Multipath CRLNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 6.4.1 Window Size for Heterogeneous Paths . . . . . . . . . . . . . . . . . . . . . 77 6.4.2 Packet Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.5.1 Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.5.2 Preliminary Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.5.3 Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 7 Conclusion 94 7.1 Results and Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.2 Future Research Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Acronyms 99 Publications 101 Bibliography 10

Controlling Network Latency in Mixed Hadoop Clusters: Do We Need Active Queue Management?

With the advent of big data, data center applications are processing vast amounts of unstructured and semi-structured data, in parallel on large clusters, across hundreds to thousands of nodes. The highest performance for these batch big data workloads is achieved using expensive network equipment with large buffers, which accommodate bursts in network traffic and allocate bandwidth fairly even when the network is congested. Throughput-sensitive big data applications are, however, often executed in the same data center as latency-sensitive workloads. For both workloads to be supported well, the network must provide both maximum throughput and low latency. Progress has been made in this direction, as modern network switches support Active Queue Management (AQM) and Explicit Congestion Notifications (ECN), both mechanisms to control the level of queue occupancy, reducing the total network latency. This paper is the first study of the effect of Active Queue Management on both throughput and latency, in the context of Hadoop and the MapReduce programming model. We give a quantitative comparison of four different approaches for controlling buffer occupancy and latency: RED and CoDel, both standalone and also combined with ECN and DCTCP network protocol, and identify the AQM configurations that maintain Hadoop execution time gains from larger buffers within 5%, while reducing network packet latency caused by bufferbloat by up to 85%. Finally, we provide recommendations to administrators of Hadoop clusters as to how to improve latency without degrading the throughput of batch big data workloads.The research leading to these results has received funding from the European Unions Seventh Framework Programme (FP7/2007–2013) under grant agreement number 610456 (Euroserver). The research was also supported by the Ministry of Economy and Competitiveness of Spain under the contracts TIN2012-34557 and TIN2015-65316-P, Generalitat de Catalunya (contracts 2014-SGR-1051 and 2014-SGR-1272), HiPEAC-3 Network of Excellence (ICT- 287759), and the Severo Ochoa Program (SEV-2011-00067) of the Spanish Government.Peer ReviewedPostprint (author's final draft

Datacenter Traffic Control: Understanding Techniques and Trade-offs

Datacenters provide cost-effective and flexible access to scalable compute and storage resources necessary for today's cloud computing needs. A typical datacenter is made up of thousands of servers connected with a large network and usually managed by one operator. To provide quality access to the variety of applications and services hosted on datacenters and maximize performance, it deems necessary to use datacenter networks effectively and efficiently. Datacenter traffic is often a mix of several classes with different priorities and requirements. This includes user-generated interactive traffic, traffic with deadlines, and long-running traffic. To this end, custom transport protocols and traffic management techniques have been developed to improve datacenter network performance. In this tutorial paper, we review the general architecture of datacenter networks, various topologies proposed for them, their traffic properties, general traffic control challenges in datacenters and general traffic control objectives. The purpose of this paper is to bring out the important characteristics of traffic control in datacenters and not to survey all existing solutions (as it is virtually impossible due to massive body of existing research). We hope to provide readers with a wide range of options and factors while considering a variety of traffic control mechanisms. We discuss various characteristics of datacenter traffic control including management schemes, transmission control, traffic shaping, prioritization, load balancing, multipathing, and traffic scheduling. Next, we point to several open challenges as well as new and interesting networking paradigms. At the end of this paper, we briefly review inter-datacenter networks that connect geographically dispersed datacenters which have been receiving increasing attention recently and pose interesting and novel research problems.Comment: Accepted for Publication in IEEE Communications Surveys and Tutorial

Reducing Internet Latency : A Survey of Techniques and their Merit

Bob Briscoe, Anna Brunstrom, Andreas Petlund, David Hayes, David Ros, Ing-Jyh Tsang, Stein Gjessing, Gorry Fairhurst, Carsten Griwodz, Michael WelzlPeer reviewedPreprin

MP-CFM: MPTCP-Based communication functional module for next generation ERTMS

184 p. El contenido de los capítulos 4,5,6,7,8 y 9 está sujeto a confidencialidadEl Sistema Europeo de Gestión del Tráfico Ferroviario (ERTMS, por sus siglasen inglés), fue originalmente diseñado para los ferrocarriles europeos. Sinembargo, a lo largo de las dos últimas décadas, este sistema se ha convertidoen el estándar de-facto para los servicios de Alta Velocidad en la mayoría depaíses desarrollados.El sistema ERTMS se compone de tres subsistemas principales: 1) el Sistemade Control Ferroviario Europeo (ETCS, por sus siglas en inglés), que actúacomo aplicación de señalización; 2) el sistema Euroradio, que a su vez estádividido en dos subsistemas, el Módulo de Seguridad Funcional (SFM, porsus siglas en inglés), y el Módulo de Comunicación Funcional (CFM, porsus siglas en inglés); y 3) el sistema de comunicaciones subyacente, GSM-R,que transporta la información intercambiada entre el sistema embarcado enel tren (OBU, por sus siglas en inglés) y el Centro de Bloqueo por Radio(RBC, por sus siglas en inglés). El sistema de señalización ETCS soporta tresniveles dependiendo del nivel de prestaciones soportadas. En el nivel 3 seintroduce la posibilidad de trabajar con bloques móviles en lugar de bloquesfijos definidos en la vía. Esto implica que la distancia de avance entre dos trenesconsecutivos puede ser reducida a una distancia mínima en la que se garanticela seguridad del servicio, aumentando por tanto la capacidad del corredorferroviario. Esta distancia de seguridad viene determinada por la combinaciónde la distancia de frenado del tren y el retraso de las comunicaciones deseñalización. Por lo tanto, se puede afirmar que existe una relación directaentre los retrasos y la confiabilidad de las transmisiones de las aplicaciones deseñalización y la capacidad operacional de un corredor ferroviario. Así pues,el estudio y mejora de los sistemas de comunicaciones utilizados en ERTMSjuegan un papel clave en la evolución del sistema ERTMS. Asimismo, unaoperatividad segura en ERTMS, desde el punto de vista de las comunicacionesimplicadas en la misma, viene determinada por la confiabilidad de lascomunicaciones, la disponibilidad de sus canales de comunicación, el retrasode las comunicaciones y la seguridad de sus mensajes.Unido este hecho, la industria ferroviaria ha venido trabajando en ladigitalización y la transición al protocolo IP de la mayor parte de los sistemasde señalización. Alineado con esta tendencia, el consorcio industrial UNISIGha publicado recientemente un nuevo modelo de comunicaciones para ERTMSque incluye la posibilidad, no solo de operar con el sistema tradicional,basado en tecnología de conmutación de circuitos, sino también con un nuevosistema basado en IP. Esta tesis está alineada con el contexto de migraciónactual y pretende contribuir a mejorar la disponibilidad, confiabilidad yseguridad de las comunicaciones, tomando como eje fundamental los tiemposde transmisión de los mensajes, con el horizonte puesto en la definición deuna próxima generación de ERTMS, definida en esta tesis como NGERTMS.En este contexto, se han detectado tres retos principales para reforzar laresiliencia de la arquitectura de comunicaciones del NGERTMS: 1) mejorarla supervivencia de las comunicaciones ante disrupciones; 2) superar laslimitaciones actuales de ERTMS para enviar mensajes de alta prioridad sobretecnología de conmutación de paquetes, dotando a estos mensajes de un mayorgrado de resiliencia y menor latencia respecto a los mensajes ordinarios; y3) el aumento de la seguridad de las comunicaciones y el incremento de ladisponibilidad sin que esto conlleve un incremento en la latencia.Considerando los desafíos previamente descritos, en esta tesis se proponeuna arquitectura de comunicaciones basada en el protocolo MPTCP, llamadaMP-CFM, que permite superar dichos desafíos, a la par que mantener laretrocompatibilidad con el sistema de comunicaciones basado en conmutaciónde paquetes recientemente propuesto por UNISIG. Hasta el momento, esta esla primera vez que se propone una arquitectura de comunicaciones completacapaz de abordar los desafíos mencionados anteriormente. Esta arquitecturaimplementa cuatro tipos de clase de servicio, los cuales son utilizados porlos paquetes ordinarios y de alta prioridad para dos escenarios distintos; unescenario en el que ambos extremos, el sistema embarcado o OBU y el RBC,disponen de múltiples interfaces de red; y otro escenario transicional en el cualel RBC sí tiene múltiples interfaces de red pero el OBU solo dispone de unaúnica interfaz. La arquitectura de comunicaciones propuesta para el entornoferroviario ha sido validada mediante un entorno de simulación desarrolladopara tal efecto. Es más, dichas simulaciones demuestran que la arquitecturapropuesta, ante disrupciones de canal, supera con creces en términos derobustez el sistema diseñado por UNISIG. Como conclusión, se puede afirmarque en esta tesis se demuestra que una arquitectura de comunicaciones basadade MPTCP cumple con los exigentes requisitos establecidos para el NGERTMSy por tanto dicha propuesta supone un avance en la evolución del sistema deseñalización ferroviario europeo

De-ossifying the Internet Transport Layer : A Survey and Future Perspectives

ACKNOWLEDGMENT The authors would like to thank the anonymous reviewers for their useful suggestions and comments.Peer reviewedPublisher PD