Raising the Datagram API to Support Transport Protocol Evolution

Some application developers can wield huge resources to build new transport protocols, for these developers the present UDP Socket API is perfectly fine. They have access to large test beds and sophisticated tools. Many developers do not have these resources. This paper presents a new high-level Datagram API that is for everyone else, this has an advantage of offering a clear evolutionary path to support new requirements. This new API is needed to move forward the base of the system, allowing developers with limited resources to evolve their applications while accessing new network services

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

Is Explicit Congestion Notification usable with UDP?

We present initial measurements to determine if ECN is usable with UDP traffic in the public Internet. This is interesting because ECN is part of current IETF proposals for congestion control of UDPbased interactive multimedia, and due to the increasing use of UDP as a substrate on which new transport protocols can be deployed. Using measurements from the author’s homes, their workplace, and cloud servers in each of the nine EC2 regions worldwide, we test reachability of 2500 servers from the public NTP server pool, using ECT(0) and not-ECT marked UDP packets. We show that an average of 98.97% of the NTP servers that are reachable using not-ECT marked packets are also reachable using ECT(0) marked UDP packets, and that ~98% of network hops pass ECT(0) marked packets without clearing the ECT bits. We compare reachability of the same hosts using ECN with TCP, finding that 82.0% of those reachable with TCP can successfully negotiate and use ECN. Our findings suggest that ECN is broadly usable with UDP traffic, and that support for use of ECN with TCP has increased

Reinterpreting the transport protocol stack to embrace ossification

Ubiquitous deployment of middleboxes has resulted in ossification of the transport layer, with TCP and UDP becoming part of the narrow waist of the Internet. This is a necessary stage in the evolution of the network, caused by its progression from research, to production, to increasingly critical infrastructure. New transport layer protocols will be needed in future, but since we are working with essential infrastructure, we cannot expect to have scope to make wholesale rapid changes. Future development must be done using the existing protocols as substrates, always maintaining on-the-wire compatibility. To advance, we must embrace the ossification of the network, and learn to reinterpret and extend the existing protocols

A QUIC Implementation for ns-3

Quick UDP Internet Connections (QUIC) is a recently proposed transport protocol, currently being standardized by the Internet Engineering Task Force (IETF). It aims at overcoming some of the shortcomings of TCP, while maintaining the logic related to flow and congestion control, retransmissions and acknowledgments. It supports multiplexing of multiple application layer streams in the same connection, a more refined selective acknowledgment scheme, and low-latency connection establishment. It also integrates cryptographic functionalities in the protocol design. Moreover, QUIC is deployed at the application layer, and encapsulates its packets in UDP datagrams. Given the widespread interest in the new QUIC features, we believe that it is important to provide to the networking community an implementation in a controllable and isolated environment, i.e., a network simulator such as ns-3, in which it is possible to test QUIC's performance and understand design choices and possible limitations. Therefore, in this paper we present a native implementation of QUIC for ns-3, describing the features we implemented, the main assumptions and differences with respect to the QUIC Internet Drafts, and a set of examples.Comment: 8 pages, 4 figures. Please cite it as A. De Biasio, F. Chiariotti, M. Polese, A. Zanella, M. Zorzi, "A QUIC Implementation for ns-3", Proceedings of the Workshop on ns-3 (WNS3 '19), Firenze, Italy, 201

The QUIC Fix for Optimal Video Streaming

Within a few years of its introduction, QUIC has gained traction: a significant chunk of traffic is now delivered over QUIC. The networking community is actively engaged in debating the fairness, performance, and applicability of QUIC for various use cases, but these debates are centered around a narrow, common theme: how does the new reliable transport built on top of UDP fare in different scenarios? Support for unreliable delivery in QUIC remains largely unexplored. The option for delivering content unreliably, as in a best-effort model, deserves the QUIC designers' and community's attention. We propose extending QUIC to support unreliable streams and present a simple approach for implementation. We discuss a simple use case of video streaming---an application that dominates the overall Internet traffic---that can leverage the unreliable streams and potentially bring immense benefits to network operators and content providers. To this end, we present a prototype implementation that, by using both the reliable and unreliable streams in QUIC, outperforms both TCP and QUIC in our evaluations.Comment: Published to ACM CoNEXT Workshop on the Evolution, Performance, and Interoperability of QUIC (EPIQ

Performance analysis of next generation web access via satellite

Acknowledgements This work was partially funded by the European Union's Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT). The views expressed are solely those of the author(s).Peer reviewedPostprin