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

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

Return-Path: <kaigao@scu.edu.cn>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32153A0E1A for <alto@ietfa.amsl.com>; Wed, 11 Nov 2020 06:30:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrzaCwde5QWU for <alto@ietfa.amsl.com>; Wed, 11 Nov 2020 06:30:10 -0800 (PST)
Received: from zg8tmty1ljiyny4xntqumjca.icoremail.net (zg8tmty1ljiyny4xntqumjca.icoremail.net [165.227.154.27]) by ietfa.amsl.com (Postfix) with SMTP id 87E5E3A0E12 for <alto@ietf.org>; Wed, 11 Nov 2020 06:30:08 -0800 (PST)
Received: by ajax-webmail-app1 (Coremail) ; Wed, 11 Nov 2020 22:30:04 +0800 (GMT+08:00)
X-Originating-IP: [171.214.214.195]
Date: Wed, 11 Nov 2020 22:30:04 +0800 (GMT+08:00)
X-CM-HeaderCharset: UTF-8
From: kaigao@scu.edu.cn
To: alto@ietf.org, "alto-weekly-meeting@googlegroups.com" <alto-weekly-meeting@googlegroups.com>
X-Priority: 3
X-Mailer: Coremail Webmail Server Version XT5.0.13 build 20200820(b2b8cba1) Copyright (c) 2002-2020 www.mailtech.cn mail
Content-Type: multipart/alternative; boundary="----=_Part_313208_226611638.1605105004134"
MIME-Version: 1.0
Message-ID: <7b91831a.1582f.175b7b6ae66.Coremail.kaigao@scu.edu.cn>
X-Coremail-Locale: en_US
X-CM-TRANSID: 4wAACgAXHsZs9atfvkURAQ--.30796W
X-CM-SenderInfo: 5ndlwt3r6vu3oohg3hdfq/1tbiAQIRB138kkZ9GAAAsF
X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU=
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/feU4Tr2IYpNFqisT28_U1Vc2m2o>
Subject: [alto] ALTO Recharter: New Transport - ALTO over HTTP/2 and HTTP/3
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2020 14:30:15 -0000

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