C. Cicconetti, L. Lossi, E. Mingozzi and A. Passarella, A Preliminary Evaluation of QUIC for Mobile Serverless Edge Applications, 1st Workshop on ICT for Integrated Smart Mobility Solutions, co-located with IEEE 22nd International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM), 2021, pp. 268-273, DOI: 10.1109/WoWMoM51794.2021.00050
Resources
- full paper on IEEEXplore
- BibTeX
- GitHub repository: ServerlessOnEdge
- scripts and artifacts: see experiments from
300
to304
on GitHub
Topics
- Edge computing
- Serverless & Function-as-a-Service (FaaS)
- QUIC & HTTP/3
Summary
We consider an edge system where nodes can execute functions on demand following a serverless model. We assume that the clients send their function execution requests to brokers, which dispatch them towards the edge nodes depending on the current load and network conditions.
In this activity, we assume that such dispatching is done with ServerlessOnEdge. For remote function invocation, ServerlessOnEdge uses Google’s gRPC, which is based on HTTP/2, which in turn uses TCP as the transport protocol. The HTTP/2+TCP stack has some known issues:
- TCP’s three-way handshake requires 1.5 RTTs to establish the connection between client and server. When using TLS, which is necessary for authentication and data confidentiality, then 2 further RTTs are needed before data can be exchanged between the peers.
- TCP does not cope well with packet losses that are not due to congestion, which is especially relevant for mobile and wireless clients. In particular, even though HTTP/2 has the concept of streams, which in theory allow the application to multiplex multiple logical channels of data inside the same TCP connection, in practice the kernel will not deliver to the application segments until all the previous ones have been correctly received: this leads to a phenomen called head-of-line blocking.
Therefore, we decided to explore the use of QUIC, a new transport layer using UDP, originally proposed by Google.
In ServerlessOnEdge, we have kept control-plane exchanges on gRPC, but added optional (and experimental) support to QUIC using Facebook’s libraries mvfst and proxygen for data-plane exchanges, i.e., serverless function invocations.
Main findings
- We have been able to use HTTP/3+QUIC+UDP as a drop-in replacement of Google’s gRPC (using HTTP/2+TCP). This has allowed the migration from TCP to QUIC with relatively small effort. However, this way some important features of QUIC are not used, including stream multiplexing; as a result, the current release of ServerlessOnEdge (v1.1.1) is still subject to head-of-line blocking.
- QUIC copes well with sporadic to moderate packet loss, resulting in significantly lower end-to-end tail latencies compared to TCP. With severe packet loss, TCP performs better.
Furthermore, it is worth mentioning that with no packet loss and high-speed network links QUIC detected spurious packet losses, leading to unnecessary retransmissions, hence higher traffic consumption than with TCP. We suspect that this can be avoided by a careful tuning of the internal mvfst
parameters, which however requires a very good understanding of QUIC and a priori knowledge of the network link characteristics (or non-trivial dynamic adaptation).
Future research directions
- Adoption of the stream multiplexing QUIC feature.
- Experiments in the wild (currently we have used emulated networks).