Internet-Draft ALTO-TRANS November 2020
Gao Expires 6 May 2021 [Page]
Workgroup:
ALTO
Internet-Draft:
draft-gao-alto-new-transport-00
Published:
Intended Status:
Standards Track
Expires:
Author:
K. Gao
Sichuan University

ALTO Extension: New Transport Layer Protocols

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.

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].

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.

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.

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.

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, , <http://www.ietf.org/internet-drafts/draft-ietf-alto-incr-update-sse-22.txt>.
[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, , <http://www.ietf.org/internet-drafts/draft-ietf-alto-path-vector-11.txt>.
[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, , <http://www.ietf.org/internet-drafts/draft-ietf-alto-unified-props-new-12.txt>.
[I-D.ietf-quic-http]
Bishop, M., "Hypertext Transfer Protocol Version 3 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-quic-http-32, , <http://www.ietf.org/internet-drafts/draft-ietf-quic-http-32.txt>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC2387]
Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, DOI 10.17487/RFC2387, , <https://www.rfc-editor.org/info/rfc2387>.
[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, , <https://www.rfc-editor.org/info/rfc7285>.
[RFC7540]
Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, , <https://www.rfc-editor.org/info/rfc7540>.

Author's Address

Kai Gao
Sichuan University
No.24 South Section 1, Yihuan Road
Chengdu
610000
China