[alto] ALTO Recharter: New Transport - ALTO over HTTP/2 and HTTP/3

kaigao@scu.edu.cn Wed, 11 November 2020 14:30 UTC

Date: Wed, 11 Nov 2020 22:30:04 +0800
From: kaigao@scu.edu.cn
To: alto@ietf.org, "alto-weekly-meeting@googlegroups.com" <alto-weekly-meeting@googlegroups.com>
Content-Type: multipart/alternative; boundary="----=_Part_313208_226611638.1605105004134"
MIME-Version: 1.0
Message-ID: <7b91831a.1582f.175b7b6ae66.Coremail.kaigao@scu.edu.cn>
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/feU4Tr2IYpNFqisT28_U1Vc2m2o>
Subject: [alto] ALTO Recharter: New Transport - ALTO over HTTP/2 and HTTP/3
Precedence: list

Dear all,

One item that we would like to include in the recharter is new transport mechanisms for ALTO, most notably using HTTP/2 and HTTP/3. You comments and feedback are more than welcome.

Best,

Kai

Problem Statement

- The ALTO base protocol and its extensions are built on top of HTTP/1.x. Its limitations (e.g., HTTP/1.0 is short-lived, no native support for push-mode data delivery and multiplexing) lead to several problems in the ALTO protocol, such as data inconsistency between dependent resources, and application-layer event multiplexing when handling incremental updates. New versions of the HTTP protocol, i.e., HTTP/2 and HTTP/3, provide new features that can potentially help resolve these issues, such as persistent connection, server push and stream multiplexing. This recharter item will investigate how these new features can help resolve the problems of data consistency and event multiplexing, and specify the ALTO protocol over HTTP/2 and HTTP/3.

- Basic issue

- ALTO resources have dependencies, e.g., a cost map depends on a network map. However, the resources are requested through different TCP connections and ALTO does not provide synchronization, leading to potentially inconsistent data.

- For cases where data consistency is crucial, e.g., in the path vector extension, a more complex message format (e.g., a multipart/related message) is used, increasing the complexity of server/client development.

- The incremental update extension uses Server-Sent Events to deliver the updates, which establishes two connections (one for control and one for events). The updates are multiplexed in a single event stream in the transport layer, leading to potentially inefficient data delivery.

- How should the ALTO protocol be adapted to leverage the new features of HTTP/2 and HTTP/3

- Potential solution(s)

- These issues can potentially be solved by using the newer features in HTTP/2 and HTTP/3

- The consistency issue can be solved with persistent connection and server push: an ALTO server can detect the dependencies of user queries and actively push changes related to dependent resources.

- The property map part of a path vector request can be actively pushed to the client, so no message format is required.

- The incremental updates can be supported in a single connection (unless strong use cases where separated control/event exist) using server push and stream multiplexing.

- Remaining issues to be addressed

- Potential security risks of HTTP/2 and HTTP/3

[alto] ALTO Recharter: New Transport - ALTO over … kaigao