]> Deutsche Telekom

Heinrich-Hertz-Strasse 3-7 64295 Darmstadt Germany Roland.Schott@telekom.de

Yale University

51 Prospect St New Haven CT 06520 USA yry@cs.yale.edu

Sichuan University

Chengdu 201804 China kgao@scu.edu.cn

Yale University

51 Prospect St New Haven CT 06520 USA lauren.delwiche@yale.edu

TSV Area ALTO Working Group RFC Request for Comments I-D Internet-Draft Application-Layer Traffic Optimization, HTTP/2, SSE, Message Queue The ALTO New Transport introduces ALTO transport information structures (TIS) at an ALTO server. The introduction of ALTO TIS allows at least two types of efficient transport using HTTP: (1) HTTP/2/3 independent client long poll allowed by non-blocking, newer HTTP, and (2) HTTP/2 specific server push. This document defines HTTP/2 specific server-push ALTO transport based on ALTO TIS. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Introduction The ALTO new transport introduces ALTO transport queues for an ALTO server to manage the transport of ALTO information to an ALTO client. The base design, however, supports only client pull. Hence, for a client to obtain the latest ALTO information, the client need to maintain a pending pull on the incremental updates queue. This document extends the base design to allow server push, potentially reducing information distribution delay. The extension to realize server push on a transport queue is by adding a receiver set. Figure 2 shows an example illustrating the additional receiver set at each transport queue.

ALTO New Transport Information Structure.

This document specifies the operation to manage the receiver set.

Manage Server Push: Receiver Set

Receiver Set Operations A client starts to receive server push when it is added to the receiver set. A client can add itself to the receiver set when creating the transport queue, or add itself explicitly to the receiver set. A client can read the status of the receiver set and delete itself from the receiver set to stop server push. Implicit Create: As a short cut, when creating a transport queue, an ALTO client can start server push by setting the "incremental-changes" field to be true when creating a transport queue using the HTTP POST method with ALTO SSE AddUpdateReq ([RFC 8895] Sec. 6.5) as the parameter: PUT Create: A client can add itself in the receiver set by using the HTTP PUT method: PUT transport-queue/rs/self Read: A client can see only itself in the receiver set. The appearance of self in the receiver set (read does not return "not exists" error) is an indication that push starts. Delete: A client can delete itself (stops receiving push) either explicitly or implicitly.

• Explicit delete: A client deletes itself using the HTTP DELETE method: DELETE transport-queue/rs/self.
• Implicit delete: Transport queue is connection ephemeral: the close of connection or stream for the transport queue deletes the transport queue (from the view) for the client.

Examples The first example is a client creating a transport queue and starting server push. server request HEADERS - END_STREAM + END_HEADERS :method = POST :scheme = https :path = /tqs host = alto.example.com accept = application/alto-error+json, application/alto-transport+json content-type = application/alto-transport+json content-length = TBD DATA - END_STREAM { "resource-id": "my-routingcost-map", "incremental-push": true } ]]> client response: HEADERS - END_STREAM + END_HEADERS :status = 200 content-type = application/alto-transport+json content-length = TBD DATA - END_STREAM {"tq": “/tqs/2718281828459”} ]]> If the client reads the status of the transport queue created above using the read operation (GET) in the same HTTP connection, the client should see itself in the receiver set: server request HEADERS - END_STREAM + END_HEADERS :method = GET :scheme = https :path = /tqs/2718281828459 host = alto.example.com accept = application/alto-error+json, application/alto-transport+json Server -> client response: HEADERS - END_STREAM + END_HEADERS :status = 200 content-type = application/alto-transport+json content-length = TBD DATA - END_STREAM { "uq": [ {“seq”: 101, "media-type": "application/alto-costmap+json", “tag”: "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" }, {“seq”: 102, "media-type": "application/merge-patch+json", “tag”: "cdf0222x59740b0b2e3f8eb1d4785acd42231bfe" }, {“seq”: 103, "media-type": "application/merge-patch+json", “tag”: "8eb1d4785acd42231bfecdf0222x59740b0b2e3f", "link": "/tqs/2718281828459/snapshot/2e3f"} ], "rs": ["self"] } ]]> A client can stop incremental push updates from the server to itself by sending the request:

Server Push of Incremental Updates

Server Push The work flow of server push of individual updates is the following:

• Initialization: the first update pushed from the server to the client MUST be the later of the following two: (1) the last independent update in the incremental updates queue; and (2) the following entry of the entry that matches the tag when the client creates the transport queue. The client MUST set SETTINGS_ENABLE_PUSH to be consistent.
• Push state: the server MUST maintain the last entry pushed to the client (and hence per client, per connection state) and schedule next update push accordingly.
• Push management: The client MUST NOT cancel (RST_STREAM) a PUSH_PROMISE to avoid complex server state management.

Examples A client can wait for the server for incremental push, where the server first sends PUSH_PROMISE, for the first example in Sec. 2.2: client PUSH_PROMISE in current stream: PUSH_PROMISE - END_STREAM Promised Stream 4 HEADER BLOCK :method = GET :scheme = https :path = /tqs/2718281828459/uq/101 host = alto.example.com accept = application/alto-error+json, application/alto-costmap+json Server -> client content Stream 4: HEADERS + END_STREAM + END_HEADERS :status = 200 content-type = application/alto-costmap+json content-length = TBD DATA + END_STREAM { "meta" : { "dependent-vtags" : [{ "resource-id": "my-network-map", "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" }], "cost-type" : { "cost-mode" : "numerical", "cost-metric": "routingcost" }, "vtag": { "resource-id" : "my-routingcost-map", "tag" : "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" } }, "cost-map" : { "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, "PID3": { "PID1": 20, "PID2": 15 } } } Server -> client PUSH_PROMISE in current stream: PUSH_PROMISE - END_STREAM Promised Stream 6 HEADER BLOCK :method = GET :scheme = https :path = /tqs/2718281828459/uq/102 host = alto.example.com accept = application/alto-error+json, application/merge-patch+json Server -> client content Stream 6 HEADERS + END_STREAM + END_HEADERS :status = 200 content-type = application/merge-patch+json content-length = TBD DATA + END_STREAM { ...} ]]>

Server Push Stream Management

Server -> Client [PUSH_PROMISE for Transport Queue on Stream SID_tq] The server push MUST satisfy the following requirements:

• PUSH_PROMISE MUST be sent in stream SID_tq to serialize to allow the client to know the push order;
• Each PUSH_PROMISE chooses a new server-selected stream ID, and the stream is closed after push.

Server Push Information Resource Directory (IRD) Extending the IRD example in Section 8.1 of , below is the IRD of an ALTO server supporting ALTO base protocol, ALTO/SSE, and Server Push. In particular,

Security Considerations The properties defined in this document present no security considerations beyond those in Section 15 of the base ALTO specification [RFC7285].

IANA Considerations IANA will need to register server push.

Acknowledgments The authors of this document would also like to thank many for the reviews and comments.

References Normative References 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. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. 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. 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. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Application-Layer Traffic Optimization (ALTO) protocol (RFC 7285) 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. Informative References Many Internet applications are used to access resources such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. This memo discusses deployment-related issues of ALTO. It addresses different use cases of ALTO such as peer-to-peer file sharing and Content Delivery Networks (CDNs) and presents corresponding examples. The document also includes recommendations for network administrators and application designers planning to deploy ALTO, such as recommendations on how to generate ALTO map information.