[alto] charter-ietf-alto-04-01: (with COMMENT)

Qin Wu <bill.wu@huawei.com> Thu, 26 August 2021 13:17 UTC

Return-Path: <bill.wu@huawei.com>
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 A64913A12AB; Thu, 26 Aug 2021 06:17:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 LDgwbaUgZMO3; Thu, 26 Aug 2021 06:16:57 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0720A3A12A0; Thu, 26 Aug 2021 06:16:57 -0700 (PDT)
Received: from fraeml745-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GwNcy5N5lz67Lsv; Thu, 26 Aug 2021 21:15:30 +0800 (CST)
Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by fraeml745-chm.china.huawei.com (10.206.15.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.8; Thu, 26 Aug 2021 15:16:52 +0200
Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeml753-chm.china.huawei.com (10.1.199.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Thu, 26 Aug 2021 21:16:50 +0800
Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2176.012; Thu, 26 Aug 2021 21:16:50 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "alto-chairs@ietf.org" <alto-chairs@ietf.org>, "alto@ietf.org" <alto@ietf.org>
Thread-Topic: charter-ietf-alto-04-01: (with COMMENT)
Thread-Index: AdeaecGt1CBaJM95R3WsB4CH77P5GQ==
Date: Thu, 26 Aug 2021 13:16:49 +0000
Message-ID: <6485664fb29f485e8d8c5fd0d9c7e453@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.123.117]
Content-Type: multipart/alternative; boundary="_000_6485664fb29f485e8d8c5fd0d9c7e453huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/M2qHi80s0132991dzny0RyjrNJU>
Subject: [alto] charter-ietf-alto-04-01: (with COMMENT)
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: Thu, 26 Aug 2021 13:17:02 -0000

Thank Ben for additional comment, see clarification below.
>    o Support for modern transport protocols. ALTO only uses the
>    capabilities of HTTP version 1. Since then, the IETF has developed
>    HTTP/2 and HTTP/3.  The working group will develop any necessary
>    protocol extensions and guidance to support the use of ALTO over HTTP/2
>    and HTTP/3.

>The IESG is reviewing on this same telechat a "bis" version of BCP56,
>guidelines for applications using HTTP.  Let's discuss whether this
>language is consistent with the guidance contained therein, which
>includes:

>   [...] Requiring a particular
>   version of HTTP makes it difficult to use in these situations, and
>   harms interoperability.  Therefore, it is NOT RECOMMENDED that
>   applications using HTTP specify a minimum version of HTTP to be used.

>   However, if an application's deployment would benefit from the use of
>   a particular version of HTTP (for example, HTTP/2's multiplexing),
>   this ought be noted.
[Qin]:Thanks for bringing this up, regarding guidelines defined in draft-ietf-httpbis-bcp56bis-14<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-bcp56bis-14>
I think HTTP/2's multiplexing is the exact feature we are looking for to enhance
Incremental update SSE defined in RFC8895. Maybe there is some other features which could be
Leverages, I can not speak for ALTO proponents.


>My understanding is that typically it suffices to "just use HTTP", and
>that there should be no need for ALTO extensions to support running the
>protocol over HTTP/2 or HTTP/3.  Any HTTP-version-specific work would
>then be about making more effective use of features that are available
>in those later versions, without requiring them to be available.
[Qin]Maybe protocol extension is not needed, but I assume some kind of mapping between ALTO and HTTP/2, HTTP/3 is needed, just like DNS over QUIC,RTP over QUIC.
see section 4 of RFC8650 for example, which provides different QoS treatment for
HTTP/1 and HTTP/2.