ALTO K. Gao Internet-Draft Sichuan University Intended status: Standards Track 2 November 2020 Expires: 6 May 2021 ALTO Extension: New Transport Layer Protocols draft-gao-alto-new-transport-00 Abstract The current ALTO transport is based on HTTP/1.x connections between ALTO servers and ALTO clients. On the other hand, recent extensions to HTTP/1.x such as HTTP/2 [RFC7540] and HTTP/3 [I-D.ietf-quic-http] introduce capabilities such as server push and stream multiplexing, which can potentially be integrated into ALTO to improve ALTO capabilities such as incremental updates. This document identifies use cases of ALTO and its extensions that may benefit from the advanced features of HTTP/2 and HTTP/3, and proposes ALTO extensions to fully leverage the benefits. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 May 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Gao Expires 6 May 2021 [Page 1] Internet-Draft ALTO-TRANS November 2020 extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 3. HTTP/2 and HTTP/3 Protocol Overview . . . . . . . . . . . . . 3 3.1. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1.1. Persistent Connection . . . . . . . . . . . . . . . . 3 3.1.2. Server Push . . . . . . . . . . . . . . . . . . . . . 3 3.1.3. Stream Multiplexing . . . . . . . . . . . . . . . . . 3 3.2. HTTP/3 . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. ALTO Use Cases . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Transport of Dependent Information Resources . . . . . . 3 4.2. Transport of Incremental Update . . . . . . . . . . . . . 4 4.3. Transport of Multipart Messages . . . . . . . . . . . . . 4 5. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Server Push/Stream Multiplexing for Filtered Services . . 4 6. ALTO Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The ALTO protocol {{RFC7285} and its extensions are based on HTTP/1.x connections between ALTO servers and clients. Recently, newer versions of the HTTP protocol, i.e., HTTP/2 [RFC7540] and HTTP/3 [I-D.ietf-quic-http], are introduced to the IETF. The upgrades have many benefits such as performance gains and new features, most notably server push and stream multiplexing. While the ALTO base protocol should work on top of HTTP/2 and HTTP/3 and gain performance improvement without modification, it is worth looking into the question of whether and how ALTO can further take advantage of the new features. The purpose of this document is 1) to identify use cases of the ALTO protocol and its extensions that may benefit from the new features of HTTP/2 and HTTP/3, and 2) to propose extensions to fully leverage the benefits. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Gao Expires 6 May 2021 [Page 2] Internet-Draft ALTO-TRANS November 2020 All numeric values are in network byte order. Values are unsigned unless otherwise indicated. Literal values are provided in decimal or hexadecimal as appropriate. Hexadecimal literals are prefixed with "0x" to distinguish them from decimal literals. This document uses the following terms defined in RFC 7285 [RFC7285]: TBD. This document uses the following terms defined in RFC 7540 [RFC7540]: TBD. This document uses the following terms defined in [I-D.ietf-quic-http]: TBD. 3. HTTP/2 and HTTP/3 Protocol Overview 3.1. HTTP/2 TBD 3.1.1. Persistent Connection TBD 3.1.2. Server Push TBD 3.1.3. Stream Multiplexing TBD 3.2. HTTP/3 TBD 4. ALTO Use Cases 4.1. Transport of Dependent Information Resources Features to be used: ~ Persistent connection, server push, and stream multiplexing Examples: ~ Delivery of Network Map and Cost Map, delivery of Unified Property Map(s) TBD. Gao Expires 6 May 2021 [Page 3] Internet-Draft ALTO-TRANS November 2020 4.2. Transport of Incremental Update Features to be used: ~ Persistent connection, server push, and stream multiplexing TBD. 4.3. Transport of Multipart Messages Features to be used: ~ Persistent connection, server push, and stream multiplexing Example: ~ Path Vector [I-D.ietf-alto-path-vector] TBD. 5. Issues 5.1. Server Push/Stream Multiplexing for Filtered Services An ALTO Client may send multiple requests to the same service with different filters, for example, making two different requests to the same Filtered Cost Map service. An intelligent ALTO server may want to push the related Filtered Network Maps to the ALTO Client. However, the two Filtered Network Maps cannot be distinguished by their resource URI alone. A similar issue is already discussed in the incremental update extension [I-D.ietf-alto-incr-update-sse]. TBD. 6. ALTO Extensions TBD 7. Security Considerations TBD 8. Normative References [I-D.ietf-alto-incr-update-sse] Roome, W. and Y. Yang, "ALTO Incremental Updates Using Server-Sent Events (SSE)", Work in Progress, Internet- Draft, draft-ietf-alto-incr-update-sse-22, 20 March 2020, . Gao Expires 6 May 2021 [Page 4] Internet-Draft ALTO-TRANS November 2020 [I-D.ietf-alto-path-vector] Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang, "ALTO Extension: Path Vector", Work in Progress, Internet- Draft, draft-ietf-alto-path-vector-11, 14 July 2020, . [I-D.ietf-alto-unified-props-new] Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K. Gao, "Unified properties for the ALTO protocol", Work in Progress, Internet-Draft, draft-ietf-alto-unified-props- new-12, 13 July 2020, . [I-D.ietf-quic-http] Bishop, M., "Hypertext Transfer Protocol Version 3 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- quic-http-32, 20 October 2020, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, DOI 10.17487/RFC2387, August 1998, . [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, . [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, . Author's Address Gao Expires 6 May 2021 [Page 5] Internet-Draft ALTO-TRANS November 2020 Kai Gao Sichuan University No.24 South Section 1, Yihuan Road Chengdu 610000 China Email: kaigao@scu.edu.cn Gao Expires 6 May 2021 [Page 6]