ALTO Extension: New Transport Layer Protocols
Sichuan University
No.24 South Section 1, Yihuan Road
Chengdu
610000
China
kaigao@scu.edu.cn
Application
ALTO
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 and HTTP/3 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.
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 and HTTP/3 ,
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.
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 .
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 : TBD.
This document uses the following terms defined in RFC 7540 : TBD.
This document uses the following terms defined in : TBD.
HTTP/2 and HTTP/3 Protocol Overview
HTTP/2
TBD
Persistent Connection
TBD
ALTO Use Cases
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.
Transport of Incremental Update
Features to be used:
~ Persistent connection, server push, and stream multiplexing
TBD.
Transport of Multipart Messages
Features to be used:
~ Persistent connection, server push, and stream multiplexing
Example:
~ Path Vector
TBD.
Issues
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
.
TBD.
Security Considerations
TBD
Normative References
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Application-Layer Traffic Optimization (ALTO) Protocol
Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.
The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps.
This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks.
Hypertext Transfer Protocol Version 2 (HTTP/2)
This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.
This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
The MIME Multipart/Related Content-type
This document defines the Multipart/Related content-type and provides examples of its use. [STANDARDS-TRACK]
Hypertext Transfer Protocol Version 3 (HTTP/3)
The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3.
ALTO Incremental Updates Using Server-Sent Events (SSE)
The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol provides network related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients, to achieve two benefits: (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes; and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available.
Unified properties for the ALTO protocol
This document extends the Application-Layer Traffic Optimization (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint properties" to generic types of entities, and by presenting those properties as maps, similar to the network and cost maps in [RFC7285].
ALTO Extension: Path Vector
This document is an extension to the base Application-Layer Traffic Optimization protocol [RFC7285]. The current ALTO Cost Services only allow applications to obtain cost values on an end-to-end path defined by its source and destination. The present extension provides abstracted information on particular network components or elements traversed by a path between its source and destination. Examples of such abstracted components are networks, data centers or links. This is useful for applications whose performance is impacted by particular network components they traverse or by their properties. Applications having the choice among several connection paths may use this information to select paths accordingly and improve their performance. In particular, they may infer that several paths share common links and prevent traffic bottlenecks by avoiding such paths. This document introduces a new cost type called Path Vector. A Path Vector is an array of entities that each identifies an abstracted representation of a network part and that are called Abstract Network Element (ANE). Each ANE is defined by a set of properties. ANE properties are conveyed by an ALTO information resource called "Property Map", that can be packed together with the Path Vectors in a multipart response. They can also be obtained via a separate ALTO request to a Property Map. An ALTO Property Map is an extension to the ALTO protocol, that is specified in another document entitled "Unified Properties for the ALTO Protocol" [I-D.ietf-alto-unified-props-new].