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

Tongji University

4800 Cao'An Road Shanghai 201804 China jingxuan.n.zhang@gmail.com

TSV Area ALTO Working Group RFC Request for Comments I-D Internet-Draft Application-Layer Traffic Optimization, HTTP/2, HTTP/3, SSE, Message Queue The ALTO base protocol [RFC7285] is based on HTTP/1.x, focusing on the simple, sequential request-reply use case, in which an ALTO client requests a sequence of information resources, and the server sends the complete content of each information resource to the client one by one. ALTO/SSE [RFC8895] defines a new transport design to allow an ALTO client to request the monitoring of multiple resources, and the server can then continuously, concurrently, and incrementally push updates whenever monitored network information resources change. But ALTO/SSE assumes an HTTP/1.x setting, and essentially designs a new concurrent transport protocol on top of a sequential HTTP/1.x connection, but newer versions of HTTP (e.g., HTTP/2 [RFC7540]) already support concurrent, non-blocking transport of multiple streams in the same HTTP connection. This document introduces the ALTO transport information publication service (TIPS), which allows the naming of individual incremental updates to multiple ALTO information resources and the distribution of the naming, enabling ALTO to take advantage of newer HTTP versions. In particular, it gives an ALTO client the new capability to explicitly request (pull) a specific incremental update. It also provides an ALTO server the new capability to push a specific incremental update using native HTTP/2 or HTTP/3 server push. This document defines TIPS as a service, independent of client pull or server push. A companion document defines server-push ALTO transport based on ALTO TIPS. 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 Application-Layer Traffic Optimization (ALTO) provides means for network applications to obtain network status information. The ALTO base protocol is based on the sequential request and response model of HTTP/1.1 . Hence, the base protocol cannot support well the use cases where an ALTO client (e.g., a controller) may need to efficiently monitor the changes to a set of network information resources. If the client opens only a single HTTP connection, the first request for resource A may block the request for B resource. To address the issue using a protocol that is still based on the HTTP/1.1 transport model, the ALTO Working Group introduces ALTO/SSE (ALTO Incremental Update based on Server-Sent-Event) , so that an ALTO client can manage (i.e., add and remove) a set of requests maintained at an ALTO server, and the server can continuously, concurrently, and incrementally push updates whenever a monitored network information resource changes. Figure 1 shows the architecture and message flow of ALTO/SSE, which can be considered as a more general transport protocol than the ALTO base transport protocol. Although ALTO/SSE allows the concurrent transport of multiple ALTO information resources, it has complexities and limitations. For example, it requires that the server provides a separate control URI, leading to complexity in management; it needs its own envelop protocol to multiplex the incremental updates of multiple resources on a single HTTP connection, not using the functions of substream multipelxing in newer HTTP versions; its envelop does not provide naming for individual incremental updates, and hence cannot support client explicit pull or server push, which needs to indicate the URI.

ALTO SSE Architecture and Message Flow. | | | | 3.add/ | | | | 1'. control uri | | | | remove | | | | | | | | resource |Stream | |Update | | | | -------->|Control| private |Stream | 2a. data update |Client| -- |Server |<------->|Server | messages | | -------- | | | | --------------> | | <- | response | | | | --------------> | | | | | | | | 2b.control update| | | | +-------+ +-------+ messages +------+ | | | ------------------------------------------------------------------ ]]>

This document specifies ALTO transport queue information service, which allows the naming of individual incremental updates to multiple ALTO information resources and the distribution of the naming, enabling ALTO to take advantage of newer HTTP versions. In particular, it gives an ALTO client the new capability to explicitly request (pull) a specific incremental update. It also provides an ALTO server the new capability to push a specific incremental update using native HTTP/2 or HTTP/3 server push. ALTO New Transport, which realizes ALTO/SSE functions but takes advantage of newer versions of HTTP (e.g., HTTP/2 ) that support concurrent, non-blocking transport of multiple streams in the same HTTP connection.

TIPS Overview A key design of the ALTO TIPS is to distinguish between information about ALTO resources and information about ALTO transport. The latter information provides meta information about the transport of ALTO information resources.

TIPS Design Requirements ALTO TIPS is designed to provide meta information about transport to satisfy a set of requirements. First, it should satisfy the following requirements to realize the functions of ALTO/SSE:

• R1: The client can request the addition (start) of transport of incremental updates to a resource.
• R2: The client can request the deletion (stop) of transport of incremental updates to a resource.
• R3: The server can signal to the client the start or stop of transport of incremental updates to a resource.
• R4: The server can choose the type of each incremental update encoding, as long as the type is indicated to be acceptable by the client.

ALTO TIPS provides meta information to allow an ALTO client to take advantage of newer HTTP design features, in particular, parallel transfers, but be as transparent to versions (HTTP/2, HTTP/3) as possible. If a design is based on a particular HTTP version, it should respect its semantics:

• R5: The design respects specific HTTP semantics such as the semantics of PUSH_PROMISE, if the feature is used.

TIPS Concepts

• The transport state from the ALTO server to an ALTO client (or a set of clients) for an ALTO information resource is conceptually through a transport queue. A static ALTO information resource (e.g., Cost Map, Network Map) has a single transport queue, and a dynamic ALTO information resource (e.g., Filtered Cost Map) may create a queue for each unique filter request.
• The base transport queue defined in this document includes only a single element: the incremental update message queue, which includes a sequence of incremental update messages. A particular transport design may extend the base design to include additional state. For example, the server-push design may include the additional receiver set state, which includes the set of receivers receiving incremental push updates from the ALTO server.
• The transport queue state is exposed to clients through views; that is, a client can see only a virtual view of the server state.

Figure 2 shows an example illustrating the aforementioned information. It includes the additional receiver-set state, to illustrate the possibility of extension. Each ALTO client (Client 1, Client 2, or Client 3) maintains a single HTTP connection with the ALTO server.

ALTO Transport Information.

The basic work flow of a client connecting to an ALTO server is the following:

ALTO New Transport Workflow. | Create TQ o o o | Return URI to TQ |...........>|.......>|......>| |<---------------------| . . . | (Pull Mode) . . . . | Request update queue status . . . |------------------------------------------->| . | Return status of the update queue . | . |<-------------------------------------------| . | Request an element in the UQ . . . |--------------------------------------------------->| | Return the content of an incremental update. | |<---------------------------------------------------| | (Explicit deletion) . . . . | Close the transport queue . . . |---------------------------------->|.......>|......>| | . o o o | Close the connection . |--------------------->| o . tips: Transport Queue Service, TQ: Transport Queue UQ: Incremental Update Queue, ULS: Update Log Service ]]>

TIPS Information Resources As shown in , TIPS defines 4 new ALTO information resources: Transport Information Service, Transport Queue, Incremental Updates Queue, and Update Log Service (optional).

Notations This document uses the same syntax and notations as introduced in Section 8.2 of RFC 7285 to specify the extensions to existing ALTO resources and services.

Transport Information Publication Service

Media Type The media type of the Transport Information Publication Service resource is "application/alto-tips+json".

HTTP Method The Transport Queue Service resource is requested using the HTTP POST method.

Capabilities The capabilities of a Transport Queue Service are the same as the capabilities of an Update Stream Service, as defined in Section 6.3 of .

Uses The "uses" of a Transport Queue Service has the same format as that of an Update Stream Service, as defined in Section 6.4 of .

Request: Accept Input Parameters The input parameters of the Transport Queue Service resource are supplied in the body of an HTTP Post request, which MUST be a JSON object of type AddUpdateReq (defined in Section 6.5 of ), indicated by the media type "application/alto-tipsparams+json".

Response The response of a successful POST request MUST be a JSON object of type AltoTransportData with field:

tq:

The relative URI to the incremental updates queue resource.

Example For simplicity, assume the ALTO server is using the Basic authentication. If a client with username "client1" and password "helloalto" wants to create a transport queue of an ALTO Cost Map resource with resource ID "my-routingcost-map", it can send the following request: If the operation is successful, the ALTO server returns the following message:

Transport Queue

Media Type None.

HTTP Method The Transport Queue resource can be requested using the HTTP DELETE method.

Capabilities None.

Uses None.

Request: Accept Input Parameters None.

Response When receiving a DELETE request, the ALTO server MUST check whether the client has the permission to close the transport queue. Specifically, if the request is issued by the same client that creates the Transport Queue, the ALTO server MUST return an HTTP message with status code 200 (OK) to indicate that the operation is successful. Otherwise, the ALTO server must return an HTTP message with status code 403 (Forbidden).

Example Assume the client wants to close the transport queue, it can send the following request: As the credential matches the client that creates the transport queue, the request will succeed and the ALTO server returns the following message:

Incremental Updates Queue

Path The path to an Incremental Updates Queue resource has the following format: where TQ_URI is the URI of the Transport Queue resource and SEQ is the sequence number of an incremental update log. For example, if the relative URI of a transport queue is "/tq/2718281828459", the URI of the corresponding incremental update queue is "/tq/2718281828459/uq".

Media Type The media type of an Incremental Update Queue resource is "application/alto-tipsqueue+json".

HTTP Method The Incremental Update Queue resource must be requested using the HTTP GET method.

Capabilities None.

Uses None.

Accept Input Parameters None.

Response If the transport queue indicated by the TQ_URI is closed, the ALTO server MUST return an HTTP message with status code 404 (Not Found). Otherwise, the response is encoded as a JSON object of type AltoIncUpdateQueue ; } AltoIncUpdateQueue; ]]> with field:

uq:

An ordered list of update logs.

Each incremental update is encoded as a JSON object of type AltoIncUpdateLog with fields:

seq:

A required JSON integer indicating the sequence number of the incremental update. As JSON allows a large integer space, when the server reaches the largest integer, the server SHOULD close the incremental update queue.

media-type:

A required JSON string giving the type of the incremental update (see ALTO/SSE).

tag:

A required JSON string which is defined the same way as the "tag" field of VersionTag (see Section 10.3 of ).

link:

An optional JSON string giving an optional link for a client to directly request a resource as a complete snapshot (not through incremental updates).

Example Assume the client wants to query the status of the incremental update queue of the transport queue whose URI is "/tips/2718281828459", it can send the following request: Assume the server returns the following response: The media type of the first update log (with sequence number 101) is "application/alto-costmap+json", which indicates that the update contains a full replacement. The media types of the logs with sequence number 102 and 103 are both "application/merge-patch+json", which indicates that the two updates contain incremental updates encoded as JSON merge patches. Note that the "link" attribute of the log with sequence number 103 is present. Thus, the client can request a full replacement by sending a GET message to "/tips/2718281828459/snapshot/2e3f".

Update Log Service

Path The path to an Incremental Update Log Service resource has the following format: where TQ_URI is the URI of the Transport Queue resource and SEQ is the sequence number of an incremental update log. For example, if the client wants to query the content of the first update log (with sequence number 101), it can send a request to "/tips/2718281828459/uq/101".

Media Type The media type of an Update Log Service resource MUST be the same as the "media-type" field of the update log with sequence number SEQ in the transport queue identified by the TQ_URI. For example, if the client wants to query the content of the first update log (with sequence number 101) whose media type is "application/alto-costmap+json", it must set the "Accept" header to "application/alto-costmap+json, application/alto-error+json" in the request.

HTTP Method The Incremental Update Queue resource must be requested using the HTTP GET method.

Capabilities None.

Uses None.

Accept Input Parameters None.

Response Let TQ_URI and SEQ denote the URI of the Transport Queue resource and the sequence number of an incremental update log indicated in the path. If the transport queue indicated by TQ_URI is closed, the ALTO server MUST return an error HTTP message with status code 404 (Not Found) and media type "application/alto-error+json". Otherwise, let LOW_SEQ and HIGH_SEQ represent the smallest and largest sequence number in the incremental update queue of the transport queue respectively. If SEQ is smaller than LOW_SEQ, the ALTO server MUST return an error HTTP message with status code 410 (Gone) and media type "application/alto-error+json". If SEQ is greater than HIGH_SEQ, the ALTO server MAY either treat the request as a long polling request or return an error HTTP message with status code 400 (Bad Request). If the request is valid, the response is encoded as a JSON object whose data format is indicated by the media type.

Example Assume the client wants to get the contents of updates 101, the request is: And the response will be

Transport Information: Transport Queue

Transport Queue Operations Create a transport queue: An ALTO client creates a transport queue using the HTTP POST method with ALTO SSE AddUpdateReq ([RFC 8895] Sec. 6.5) as the parameter: In the base design, the client should not include the incremental-changes field. A successful POST request MUST return a JSON object of type ALTOTransportQueueData with field:

tq:

The relative URI to the incremental update queue resource.

Read a transport queue: A client reads the status of a transport queue by issuing a GET request to the transport queue URI returned from the POST method. Delete a transport queue: a transport queue exposed to a client can be closed (deleted) either explicitly or implicitly.

• Explicit delete: A client uses the HTTP DELETE method to explicitly delete a transport queue. If successful, the transport queue is deleted from the local view of the client, although the server may still maintain the transport queue for other client connections.
• Implicit delete: Transport queue for a client is ephemeral: the close of the HTTP connection between the client and the server deletes the transport queue from the client's view --- when the client reconnects, the client MUST NOT assume that the transport queue is still valid.

Error codes: ALTO TIPS uses HTTP error codes.

Examples The first example is a client creating a transport queue. server request POST /tips HTTP/1.1 Host: alto.example.com Accept: application/alto-tips+json, application/alto-error+json Content-Type: application/alto-tipsparams+json Content-Length: [TBD] { "resource-id": "my-routingcost-map" } ]]> client response: HTTP/1.1 200 OK Content-Type: application/alto-tips+json Content-Length: [TBD] {"tq": “/tips/2718281828459”} ]]> The client can then read the status of the transport queue using the read operation (GET) in the same HTTP connection. Below is an example (structure of incremental updates queue will be specified in the next section): server request GET /tips/2718281828459 HTTP/1.1 Host: alto.example.com Accept: application/alto-tips+json, application/alto-error+json Server -> client response: HTTP/1.1 200 OK Content-Type: application/alto-tips+json Content-Length: [TBD] { "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": "/tips/2718281828459/snapshot/2e3f" } ] } ]]>

Transport Information: Incremental Updates Queue

Incremental Updates Queue Operations Among the CRUD operations, an incremental updates queue supports only the read operation: a client cannot create, update, or delete incremental updates queue directly---it is read only, and associated with transport queue automatically. Reads an incremental updates queue: A client reads the status of an incremental updates queue using the HTTP GET method: GET transport-queue-uri/uq, where the transport-queue-uri is the URI returned in the transport queue create method.

Media Type The media type of the incremental update queue resource is "application/alto-tipsqueue+json".

HTTP Method The incremental update queue resource is requested using the HTTP GET method.

Response The response informs the client the backlog status, and potential direct links. Specifically, the response is encoded as a JSON object of type ALTOIncUpdateQueue ; } ALTOIncUpdateQueue; ]]> with field:

uq:

A queue of incremental updates.

Each incremental update is encoded as a JSON object of type ALTOIncUpdate with fields:

seq:

A required JSON integer indicating the sequence number of the incremental update. As JSON allows a large integer space, when the server reaches the largest integer, the server SHOULD close the incremental update queue.

media-type:

A required JSON string giving the type of the incremental update (see ALTO/SSE).

tag:

A required JSON string which is defined the same way as the "tag" field of VersionTag (see Section 10.3 of [RFC7285]).

link:

An optional JSON string giving an optional link for a client to directly request a resource as a complete snapshot (not through incremental updates).

Note that the server determines the state (window of history and type of each update) in the incremental updates queue, as specified by [R4].

Examples Assume the same example in the preceding section. The client can check the status of the incremental updates queue of a transport queue from the same connection: server request: GET /tips/2718281828459/uq HTTP/1.1 Host: alto.example.com Accept: application/alto-tipsqueue+json, application/alto-error+json Server -> client response: HTTP/1.1 200 OK Content-Type: application/alto-tipsqueue+json Content-Length: [TBD] { "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": "/tips/2718281828459/snapshot/2e3f"} ] } ]]>

Information Resource Information: Client Pull Individual Updates

Individual Updates Operations A client can only read an individual update: A client uses the HTTP GET method on the incremental updates queue concatenated by a sequence number to pull an individual update.The server push model, however, depends on HTTP specific version.

Examples The first example is a client pull example, in which the client directly requests an individual update. server request: GET /tips/2718281828459/uq/101 HTTP/1.1 Host: alto.example.com Accept: application/alto-costmap+json, application/alto-error+json Server -> client response: HTTP/1.1 200 OK Content-Type: application/alto-costmap+json Content-Length: [TBD] { "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 } } } ]]> Note from the transport queue state that the 103 message has an OPTIONAL link to a complete snapshot, which a client can request. One important design is that the "seq" must be sequentially increasing. Hence, by issuing a request on the next sequence number, the client realizes long pull.

TIPS Stream Management

Objectives A main benefit of ALTO TIPS is to take advantage of concurrent streams in newer versions of HTTP (HTTP/2 and later). In particular, the objectives of ALTO TIPS include:

• Allow stream concurrency to reduce latency
• Minimize the number of streams created
• Enforce dependency among streams (so that if A depends on B, then A should be sent after B)
• Encode dependency to enforce semantics (correctness)

To realize the objectives, ALTO New Transport MUST satisfy the following stream management requirements in all 4 phases specified in the next 4 subsections.

Client -> Server [Create Transport Queue] Each request to create a transport queue (POST) MUST choose a new client selected stream ID (SID_tq), with the following requirements:

• Stream Identifier of the frame is a new client-selected stream ID; Stream Dependency in HEADERS is 0 (connection) for an independent resource, the other transport queue if the dependency is known.
• Invariant: Stream keeps open until close or error.

Client -> Server [Close Transport Queue] DELETE to close a transport queue (SID_tq) MUST be sent in SID_tq, with the following requirements:

• Stream Identifier of the frame is SID_tq, and Stream Dependency in HEADER is 0 (connection), so that a client cannot close a different stream.
• HEADERS indicates END_STREAM; server response SHOULD close the stream.

Client -> Server [Request on Data of a Transport Queue on Stream SID_tq] The request and response MUST satisfy the following requirements:

• The Stream Identifier of the frame is a new client-selected stream ID, and Stream Dependency in HEADERs MUST be SID_tq, so that a client cannot issue request on a closed transport queue;
• Both the request and the response MUST indicate END_STREAM.

Concurrency Management

• ALTO New Transport must allow concurrency control.
• From the client to the server direction, there MUST be one stream for each open transport queue, and hence a client can always close a transport queue (which it uses to open the stream) and hence can also close, without the risk of deadlock.

ALTO TIPS 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 ALTO TIPS. In particular, Note that it is straightforward for an ALTO sever to run HTTP/2 and support concurrent retrieval of multiple resources such as "my-network-map" and "my-routingcost-map" using multiple HTTP/2 streams. The resource "update-my-costs-h2" provides an ALTO TIPS based connection, and this is indicated by the media-type "application/alto-tips+json". The client can send in a sequence of control requests using media type application/alto-updatestreamparams+json. The server creates HTTP/2 streams and pushes updates to the client.

Security Considerations The properties defined in this document present no security considerations beyond those in Section 15 of the base ALTO specification and in Section 10 of the ALTO SSE specification .

IANA Considerations IANA will need to register the following media type under ALTO registry as defined in :

• application/alto-tips+json: as described in ;
• application/alto-tipsparams+json: as described in ;
• application/alto-tipsqueue+json: as described in

application/alto-tips+json Media Type

Type name:

application

Subtype name:

alto-tips+json

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

Encoding considerations are identical to those specified for the "application/json" media type. See .

Security considerations:

Security considerations relating to the generation and consumption of ALTO Protocol messages are discussed in Section 10 of and Section 15 of .

Interoperability considerations:

This document specifies format of conforming messages and the interpretation thereof.

Published specification:

of this document.

Applications that use this media type:

ALTO servers and ALTO clients either stand alone or are embedded within other applications.

Fragment identifier considerations:

N/A

Additional information:

Deprecated alias names for this type:

N/A

Magic number(s):

N/A

File extension(s):

This document uses the media type to refer to protocol messages and thus does not require a file extension.

Macintosh file type code(s):

N/A

Person and email address to contact for further information:

See Authors' Addresses section.

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

See Authors' Addresses section.

Change controller:

Internet Engineering Task Force (mailto:iesg@ietf.org).

application/alto-tipsparams+json Media Type

Type name:

application

Subtype name:

alto-tipsparams+json

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

Encoding considerations are identical to those specified for the "application/json" media type. See .

Security considerations:

Security considerations relating to the generation and consumption of ALTO Protocol messages are discussed in Section 10 of and Section 15 of .

Interoperability considerations:

This document specifies format of conforming messages and the interpretation thereof.

Published specification:

of this document.

Applications that use this media type:

ALTO servers and ALTO clients either stand alone or are embedded within other applications.

Fragment identifier considerations:

N/A

Additional information:

Deprecated alias names for this type:

N/A

Magic number(s):

N/A

File extension(s):

This document uses the media type to refer to protocol messages and thus does not require a file extension.

Macintosh file type code(s):

N/A

Person and email address to contact for further information:

See Authors' Addresses section.

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

See Authors' Addresses section.

Change controller:

Internet Engineering Task Force (mailto:iesg@ietf.org).

application/alto-tipsqueue+json Media Type

Type name:

application

Subtype name:

alto-tipsqueue+json

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

Encoding considerations are identical to those specified for the "application/json" media type. See .

Security considerations:

Security considerations relating to the generation and consumption of ALTO Protocol messages are discussed in Section 10 of and Section 15 of .

Interoperability considerations:

This document specifies format of conforming messages and the interpretation thereof.

Published specification:

of this document.

Applications that use this media type:

ALTO servers and ALTO clients either stand alone or are embedded within other applications.

Fragment identifier considerations:

N/A

Additional information:

Deprecated alias names for this type:

N/A

Magic number(s):

N/A

File extension(s):

This document uses the media type to refer to protocol messages and thus does not require a file extension.

Macintosh file type code(s):

N/A

Person and email address to contact for further information:

See Authors' Addresses section.

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

See Authors' Addresses section.

Change controller:

Internet Engineering Task Force (mailto:iesg@ietf.org).

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. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. 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.

Outlook to ALTO with HTTP/3 This draft is focusing on HTTP/2 enhancement of the ALTO protocol and the design takes advantage of HTTP/2 design features such as parallel transfer and respects HTTP/2 semantics (e.g., PUSH_PROMISE). Since QUIC and HTTP/3 respectively are coming up for various protocols on the Internet it is understandable that the question arises, if ATLO could also take advantage of the advantages of HTTP/3. QUIC can be seen as a replacement for TCP+TLS+HTTP2. HTTP/3 bases on the QUIC transport protocol and uses UDP instead of a TCP connection. QUIC has been developed by the IETF QUIC Working Group with the following goals:

• Minimizing connection establishment and overall transport latency for applications, starting with HTTP/2
• Providing multiplexing without head-of-line blocking
• Requiring only changes to path endpoints to enable deployment
• Enabling multipath and forward error correction extensions
• Providing always-secure transport, using TLS 1.3 by default

If HTTP/3 is not supported, it automatically runs on HTTP/2. The prerequisite for HTTP/3 is that both client and server support it. The basic assumption is that an implementation that runs on HTTP/2 should also run-on HTTP/3. This should be transparent. HTTP/3 uses "well known port" UDP 443 analogous to TCP 443. The network between client and server must not filter HTTP/3. Since many applications still using HTTP/2 it is mandatory for ALTO to support this protocol first. This ensures compatibility. Therefore, this document describes the update of ALTO from HTTP/1.x to HTTP/2. The usage of HTTP/3 will be described in a separate document so that compatibility of ALTO with HTTP/3 will be ensured in a later stage.