IETF
Meetings
1. Metaverse Side Meeting
Publication URL: https://github.com/giuseppefioccola/Metaverse-side-meeting-at-IETF
Discussion about the related IETF technologies in order to understand what IETF can or cannot do on Metaverse
An IETF non-working group email list has been created.
List address: metaverse@ietf.org
Archive: https://mailarchive.ietf.org/arch/browse/metaverse
To subscribe: https://www.ietf.org/mailman/listinfo/metaverse
Media over QUIC WG (moq)
Publication URL: https://datatracker.ietf.org/wg/moq/about/
Introduction:
Media over QUIC (moq) will develop a simple low-latency media delivery solution for ingest and distribution of media. This solution addresses use cases including live streaming, gaming, and media conferencing and will scale efficiently. The working group will define MoQ so that the media publication protocol can leverage coordinating relays, caches, or replication points wherever applicable to improve the delivery performance. Media content may be end-to-end encrypted in certain use cases, where the “end-to-end” keys are available to media sources and consumers, but not relays. Even when media content is end-to-end encrypted, the relays can access metadata needed for caching (such as timestamp), making media forwarding decisions (such as drop or delay under congestion), and so on.
Multiplexed Application Substrate over QUIC Encryption (masque)
Publication URL: https://datatracker.ietf.org/wg/masque/about
Introduction:
Many network topologies lead to situations where transport protocol proxying is beneficial. For example, proxying enables endpoints to communicate when end-to-end connectivity is not possible or to apply additional encryption where desirable (such as a VPN). Proxying can also improve client privacy, e.g., by hiding a client’s IP address from a target server. Proxying technologies such as SOCKS and HTTP(S) CONNECT exist, albeit with their own shortcomings. For example, SOCKS signalling is not encrypted and HTTP CONNECT is currently limited to TCP.
The primary goal of this working group is to develop mechanism(s) that allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside an HTTP connection. The group has specified CONNECT-UDP and CONNECT-IP, collectively known as MASQUE, to enable this functionality. MASQUE leverages the HTTP request/response semantics, multiplexes flows over streams, uses a unified congestion controller, encrypts flow metadata, and enables unreliable delivery suitable for UDP and IP-based applications.
The MASQUE working group will now develop HTTP extensions, which might be specific to the HTTP version, to the core client-initiated CONNECT-UDP and CONNECT-IP functionality. Services that a proxy initiates without any prompt from a client are out of scope.
Exercising the extension points defined by CONNECT-UDP and CONNECT-IP helps to make it easier to support new use cases or accommodate changes in the environment in which these protocols are deployed. The initial set of extensions will be in support of UDP listening, and CONNECT-UDP proxying optimizations when the UDP traffic is QUIC. Additional extensions that provide missing functionality, improve performance, or otherwise ease deployability for use cases may be adopted where there are multiple implementation and/or deployment proponents. The intended status is Standards Track, but the WG may downgrade if it believes that is appropriate for the ultimate document maturity level.
Low Latency, Low Loss, Scalable Throughput (L4S)
1. Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4s-arch/
Introduction:
This document describes the L4S architecture, which enables Internet applications to achieve Low queuing Latency, Low Loss, and Scalable throughput (L4S). L4S is based on the insight that the root cause of queuing delay is in the capacity-seeking congestion controllers of senders, not in the queue itself. With the L4S architecture all Internet applications could (but do not have to) transition away from congestion control algorithms that cause substantial queuing delay, to a new class of congestion controls that can seek capacity with very little queuing. These are aided by a modified form of explicit congestion notification (ECN) from the network. With this new architecture, applications can have both low latency and high throughput.
2. DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S)
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled/
Introduction:
This specification defines a framework for coupling the Active Queue Management (AQM) algorithms in two queues intended for flows with different responses to congestion. This provides a way for the Internet to transition from the scaling problems of standard TCP Reno-friendly (‘Classic’) congestion controls to the family of ‘Scalable’ congestion controls. These are designed for consistently very Low queuing Latency, very Low congestion Loss and Scaling of per-flow throughput (L4S) by using Explicit Congestion Notification(ECN) in a modified way. Until the Coupled DualQ, these scalable L4S congestion controls could only be deployed where a clean-slate environment could be arranged, such as in private data centres.
3. Explicit Congestion Notification (ECN) Protocol for Very Low Queuing Delay (L4S)
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id/
Introduction:
This specification defines the protocol to be used for a new network service called low latency, low loss and scalable throughput (L4S). L4S uses an Explicit Congestion Notification (ECN) scheme at the IP layer that is similar to the original (or ‘Classic’) ECN approach, except as specified within. L4S uses ‘scalable’ congestion control, which induces much more frequent control signals from the network and it responds to them with much more fine-grained adjustments, so that very low (typically sub-millisecond on average) and consistently low queuing delay becomes possible for L4S traffic without compromising link utilization. Thus even capacity-seeking (TCP-like) traffic can have high bandwidth and very low delay at the same time, even during periods of high traffic load.
4. Operational Guidance for Deployment of L4S in the Internet
Publication URL: https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4sops/
Introduction:
This document is intended to provide guidance in order to ensure successful deployment of Low Latency Low Loss Scalable throughput(L4S) in the Internet. Other L4S documents provide guidance for running an L4S experiment, but this document is focused solely on potential interactions between L4S flows and flows using the original(‘Classic’) ECN over a Classic ECN bottleneck link. The document discusses the potential outcomes of these interactions, describes mechanisms to detect the presence of Classic ECN bottlenecks, and identifies opportunities to prevent and/or detect and resolve fairness problems in such networks. This guidance is aimed at operators of end-systems, operators of networks, and researchers.
Academia
Workshop on Metaverse as a network problem: Performance and enabling technologies
Publication URL: https://www.ieee-metacom.org/2023/workshop-metaverse-as-a-network-problem.php
Introduction:
Metaverse can be seen as a network problem, since AR/VR applications need high throughput, high bandwidth demands with a high sensitivity to latency and dropped packets. There are already solutions dealing with these issues but there are also limitations. Client-pull technologies are more flexible, firewall-friendly, and scalable than server-push technologies. However, there is less control given its decentralized nature, which introduces new challenges for the transport network to offer a consistent and possibly higher quality of service. Therefore, a close cooperation between client applications and network would be desirable.