RFC 9569
The Application-Layer Traffic Optimization (ALTO) Transport Information Publication Service (TIPS)
RFC 9569 🎀 The Application-Layer Traffic Optimization (ALTO) Transport Information Publication Service (TIPS)
Okay bestie, this is RFC 9569 💖 It's a Standards Track doc from the IETF, dated September 2024, with ISSN 2070-1721. The authors are K. Gao (Sichuan University), R. Schott (Deutsche Telekom), and Y. R. Yang, L. Delwiche, and L. Keller (all at Yale University). The header doesn't list any Obsoletes or Updates entries, so this RFC doesn't say it replaces or amends anything. 🧚
Abstract ✨
Okay so, "Application-Layer Traffic Optimization (ALTO) Protocol" (RFC 7285) runs on HTTP/1.1 and is built for the simple, one-after-another vibe. An ALTO client asks for a bunch of information resources in order, and the server sends back the full content of each one, one at a time. 🍓
Then RFC 8895 came in with ALTO incremental updates using Server-Sent Events (SSE). It adds a multiplexing protocol on top of HTTP/1.x so the ALTO server can push resource updates whenever the network information it's watching changes. That means clients can monitor several resources at once 👑 But here's the tea: HTTP/2 and later already handle several streams at the same time over one HTTP connection, without blocking each other. 💅
So this document introduces the ALTO Transport Information Publication Service (TIPS) 🦋 TIPS uses an incremental RESTful design, which gives an ALTO client a brand new power: explicitly asking for specific incremental updates (pulling them) concurrently and without blocking, using HTTP/2 or HTTP/3. And it still works fine on HTTP/1.1. Iconic. 🫶
Status of This Memo ✨
This is an Internet Standards Track document. 🌈
It's a product of the Internet Engineering Task Force (IETF), and it reflects the consensus of the IETF community. It went through public review and got the green light for publication from the Internet Engineering Steering Group (IESG). For more on Internet Standards, check out Section 2 of RFC 7841. 📚
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9569. 💜
Copyright Notice ✨
Copyright (c) 2024 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) as they're in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. 🙈
Also, any Code Components pulled out of this document have to include the Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Revised BSD License. ⚖️
Table of Contents 🗂️
1. Introduction
1.1. Requirements Language
1.2. Notations
2. TIPS Overview
2.1. Transport Requirements
2.2. TIPS Terminology
3. TIPS Updates Graph
3.1. Basic Data Model of an Updates Graph
3.2. Updates Graph Modification Invariants
4. TIPS Workflow and Resource Location Schema
4.1. Workflow
4.2. Resource Location Schema
5. TIPS Information Resource Directory (IRD) Announcement
5.1. Media Type
5.2. Capabilities
5.3. Uses
5.4. An Example
6. TIPS Management
6.1. Open Request
6.2. Open Response
6.3. Open Example
6.3.1. Basic Example
6.3.2. Example Using Digest Authentication
6.3.3. Example Using ALTO/SSE
7. TIPS Data Transfers - Client Pull
7.1. Request
7.2. Response
7.3. Example
7.4. New Next Edge Recommendation
7.4.1. Request
7.4.2. Response
7.4.3. Example
8. Operation and Processing Considerations
8.1. Considerations for Load Balancing
8.2. Considerations for Cross-Resource Dependency Scheduling
8.3. Considerations for Managing Shared TIPS Views
8.4. Considerations for Offering Shortcut Incremental Updates
9. Security Considerations
9.1. TIPS: Denial-of-Service Attacks
9.2. ALTO Client: Update Overloading or Instability
10. IANA Considerations
10.1. application/alto-tips+json Media Type
10.2. application/alto-tipsparams+json Media Type
11. References
11.1. Normative References
11.2. Informative References
Appendix A. A High-Level Deployment Model
Appendix B. Conformance with "Building Protocols with HTTP" (RFC
9205) Best Current Practices
Appendix C. Push-Mode TIPS Using HTTP Server Push
Appendix D. Persistent HTTP Connections
Acknowledgments
Authors' Addresses1. Introduction ✨
The Application-Layer Traffic Optimization (ALTO) protocol gives network applications a way to get network status information 🌐 So far, ALTO information can travel in two ways:
- Using the ALTO base protocol [RFC7285]. It's built for the simple case where an ALTO client requests a network information resource, and the server sends the complete content of the requested information (if any) resource to the client.
- Using ALTO incremental updates via Server-Sent Events (ALTO/SSE) [RFC8895]. This one lets an ALTO client tell the server it wants updates for a set of resources. Then the server can concurrently and incrementally push updates to that client whenever the monitored resources change. 🦋
Both protocols are designed for HTTP/1.1 [RFC9112]. They still work with HTTP/2 [RFC9113] and HTTP/3 [RFC9114], but ALTO and ALTO/SSE can't fully take advantage of the new features those versions offer. 🥺
- First, look at the ALTO base protocol. It's only designed to transfer complete information resources. A client can run the base protocol on top of HTTP/2 or HTTP/3 to request multiple information resources in concurrent streams, but every request has to be for a complete information resource. The server has no way to send incremental updates. So there can be a lot of overhead when the client already has an information resource and then there are small changes to it. 😩
- Next, consider ALTO/SSE [RFC8895]. Although ALTO/SSE can transfer incremental updates, it adds a custom multiplexing protocol on top of HTTP, and that protocol assumes a total-order message channel from the server to the client. The multiplexing design doesn't give individual incremental updates a name (i.e., a resource identifier). Without that identifier, the design can't use the concurrent data streams that HTTP/2 and HTTP/3 offer, because both cases require a resource identifier. On top of that, ALTO/SSE is a push-only protocol, which takes away the client's flexibility to choose how and when it receives updates. 🙅♀️
To deal with these issues, this document introduces a new ALTO service called the Transport Information Publication Service (TIPS) 🎀 TIPS uses an incremental RESTful design to give an ALTO client a new capability: explicitly and concurrently issuing non-blocking requests for specific incremental updates using HTTP/2 or HTTP/3, while still working on HTTP/1.1. ✨
Both ALTO/SSE [RFC8895] and TIPS can transport incremental updates of ALTO information resources to clients, but they have different design goals. The TIPS extension aims for more scalable and robust distribution of incremental updates, but it's missing the session management and built-in server push capabilities that ALTO/SSE has. 📦 From a performance angle, TIPS optimizes throughput by using concurrent and out-of-order transport of data. ALTO/SSE optimizes latency, because new events can be sent to clients right away without waiting for another round of communication when there are multiple updates. ⚡ So no, we don't see TIPS as a replacement for ALTO/SSE. We see it as a complement 🫶 One example of combining these two extensions is shown in Section 6.3.3.
Also, future extensions may use server push, a feature of HTTP/2 [RFC9113] and HTTP/3 [RFC9114], as an alternative to SSE. Why this alternative design isn't ready yet at the time of writing is covered in Appendix C. 🔮
Specifically, this document specifies:
- Extensions to the ALTO Protocol for dynamic subscription and efficient uniform update delivery of an incrementally changing network information resource. 📬
- A new resource type that indicates the TIPS updates graph model for a resource. 🕸️
- URI patterns to fetch the snapshots or incremental updates. 🔗
Some operational complexities you need to think about when implementing this extension are discussed in Section 8. These include load balancing in Section 8.1, and fetching and processing incremental updates of dependent resources in Section 8.2. 🧠
Appendix B discusses how far the TIPS design sticks to the best current practices for building protocols with HTTP [RFC9205]. 📝
1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 💖
1.2. Notations 🖊️
This document uses the same syntax and notations as introduced in Section 8.2 of [RFC7285] to specify the extensions to existing ALTO resources and services. 🌸
2. TIPS Overview ✨
2.1. Transport Requirements ✨
Okay so the ALTO Protocol and its extensions support two transport mechanisms 💅:
- A client can directly request an ALTO resource and obtain a complete snapshot of that ALTO resource, as specified in the base protocol [RFC7285];
- A client can subscribe to incremental changes of one or multiple ALTO resources using the incremental update extension [RFC8895], and a server pushes the updates to the client through SSE.
ngl, the current transport mechanisms are not optimized for storing, transmitting, and processing (incremental) updates of ALTO information resources 💀. So the new transport mechanism must satisfy the following requirements:
- Incremental updates: Incremental updates only maintain and transfer the "diff" upon changes. Thus, it is more efficient than storing and transferring the full updates, especially when the change of an ALTO resource is minor. The base protocol does not support incremental updates and the current incremental update mechanism in [RFC8895] has limitations (as discussed below).
- Concurrent, non-blocking update transmission: When a client needs to receive and apply multiple incremental updates, it is desired to transmit the updates concurrently to fully utilize the bandwidth and to reduce head-of-line blocking. Unfortunately, the ALTO incremental update extension [RFC8895] does not satisfy this requirement. Even though the updates can be multiplexed by the server to avoid head-of-line blocking between multiple resources, the updates are delivered sequentially and can suffer from head-of-line blocking inside the connection (for example, when there is a packet loss).
- Long polling updates: Long polling updates can reduce the time to send the request, making it possible to achieve sub-RTT transmission of ALTO incremental updates. In [RFC8895], this requirement is fulfilled using SSE and is still desired in the new ALTO transport.
- Backward compatibility: While some of the previous requirements are offered by HTTP/2 [RFC9113] and HTTP/3 [RFC9114], it is desired that the new ALTO transport mechanism can work with HTTP/1.1 as many development tools and current ALTO implementations are based on HTTP/1.1.
The new ALTO transport specified in this document satisfies all of the following design requirements above by:
- Reusing the data format introduced in [RFC8895] that enables incremental updates using JSON patches or merge patches.
- Introducing a unified data model to describe the changes (snapshots and incremental updates) of an ALTO resource, referred to as a "TIPS view". In the data model, snapshots and incremental updates are indexed as individual HTTP resources following a unified naming convention, independent of the HTTP version. Thus, these updates can be concurrently requested and be transferred in a non-blocking manner either by using multiple connections or leveraging multiplexed data transfer offered by HTTP/2 or HTTP/3.
- Basing the unified naming convention on a monotonically increasing sequence number, making it possible for a client to construct the URL of a future update and send a long polling request.
- Making the unified naming convention independent of the HTTP versions and able to operate atop HTTP/1.1, HTTP/2, or HTTP/3.
This document assumes the deployment model discussed in Appendix A.
2.2. TIPS Terminology 🦋
In addition to the terms defined in [RFC7285], this document uses the following terms 🧚:
- Transport Information Publication Service (TIPS): A new type of ALTO service, as specified in this document, to enable a uniform transport mechanism for updates of an incrementally changing ALTO network information resource.
- Network information resource: A piece of retrievable information about network state, per [RFC7285].
- TIPS view (tv): The container of incremental transport information about the network information resource. The TIPS view has one basic component, the updates graph (ug), but may include other transport information.
- Updates graph (ug): A directed, acyclic graph whose nodes represent the set of versions of an information resource and whose edges represent the set of update items to compute these versions. An ALTO map service (e.g., a cost map or a network map) may need only a single updates graph. A dynamic network information service (e.g., a filtered cost map) may create an updates graph (within a new TIPS view) for each unique request. The encoding of an updates graph is specified in Section 6.1.
- Version: The representation of a historical content of an information resource. For an information resource, each version is associated with and uniquely identified by a monotonically and consecutively increased sequence number. This document uses the term "version s" to refer to the version associated with sequence number "s". The version is encoded as a JSONNumber, as specified in Section 6.1.
- Start sequence number (
<start-seq>): The smallest non-zero sequence number in an updates graph. - End sequence number (
<end-seq>): The largest sequence number in an updates graph. - Snapshot: A full replacement of a resource that is contained within an updates graph.
- Incremental update: A partial replacement of a resource contained within an updates graph, codified in this document as a JSON merge patch or a JSON patch. An incremental update is mandatory if the source version (i) and the target version (j) are consecutive (i.e., i + 1 = j); otherwise, it is optional (or a shortcut). Mandatory incremental updates are always in an updates graph, while optional/shortcut incremental updates may or may not be included in an updates graph.
- Update item: The content on an edge of the updates graph, which can be either a snapshot or an incremental update. An update item can be considered to be a pair (op, data) where op denotes whether the item is an incremental update or a snapshot and data is the content of the item.
- ID#i-#j: Denotation of the update item on a specific edge in the updates graph to transition from version i to version j, where i and j are the sequence numbers of the source node and the target node of the edge, respectively.
+-------------+
+-----------+ +--------------+ | Dynamic | +-----------+
| Routing | | Provisioning | | Network | | External |
| Protocols | | Policy | | Information | | Interface |
+-----------+ +--------------+ +-------------+ +-----------+
| | | |
+-----------------------------------------------------------------+
| ALTO Server |
| +-------------------------------------------------------------+ |
| | Network Information | |
| | +-------------+ +-------------+ | |
| | | Information | | Information | | |
| | | Resource #1 | | Resource #2 | | |
| | +-------------+ +-------------+ | |
| +-----|--------------------------------------/-------\--------+ |
| | / \ |
| +-----|------------------------------------/-----------\------+ |
| | | Transport Information / \ | |
| | +--------+ +--------+ +--------+ | |
| | | tv1 | | tv2 | | tv3 | | |
| | +--------+ +--------+ +--------+ | |
| | | / | | |
| | +--------+ +--------+ +--------+ | |
| | | tv1/ug | | tv2/ug | | tv3/ug | | |
| | +--------+ +--------+ +--------+ | |
| +----|----\----------------|-------------------------|--------+ |
| | \ | | |
+------|------\--------------|-------------------------|----------+
| +------+ | |
| \ | |
+----------+ +----------+ +----------+
| Client 1 | | Client 2 | | Client 3 |
+----------+ +----------+ +----------+
tvi = TIPS view i
tvi/ug = incremental updates graph associated with tvi
Figure 1: Overview of ALTO TIPSFigure 1 shows an example illustrating an overview of the ALTO TIPS extension. The server provides TIPS for two information resources (#1 and #2) where #1 is an ALTO map service and #2 is a filterable service. There are three ALTO clients (Client 1, Client 2, and Client 3) that are connected to the ALTO server.
Each client uses the TIPS view to retrieve updates. Specifically, a TIPS view (tv1) is created for the map service #1 and is shared by multiple clients. For the filtering service #2, two different TIPS views (tv2 and tv3) are created upon different client requests with different filter sets.
3. TIPS Updates Graph ✨
In order to provide incremental updates for a resource, an ALTO server creates an updates graph, which is a directed acyclic graph that contains a sequence of incremental updates and snapshots (collectively called "update items") of a network information resource. 🌸
3.1. Basic Data Model of an Updates Graph 🦋
okay so, for each resource (think a cost map or a network map), the incremental updates and snapshots can be shown as a directed acyclic graph. The server tracks every change to the resource map with version IDs, and they're assigned sequentially, going up by one each time 🔢✨
- Nodes: each node is a version of the resource, identified by a sequence number (defined as a JSONNumber). Version 0 is reserved as the initial state (empty/null) 🌸
- Tags: a tag identifies the content of a node. It has the same format as the "tag" field in Section 10.3 of [RFC7285], and it's only valid within the scope of the resource 🏷️
- Edges: each edge is an update item. The edge from i to j is the update item for moving from version i to version j 🛣️
- Path independence: the version is path independent, which means different paths that land on the same version end up with the same content. No cap, this is the part that makes it so clean 💅
Figure 2 is a concrete example. There are seven nodes in the graph, so seven different versions of the resource. The edges show the updates from the source version to the target version. Thick lines are mandatory incremental updates (like ID103-104), dotted lines are optional incremental updates (like ID103-105), and thin lines are snapshots (like ID0-103). Node content is path independent, so the content of node v can be obtained by applying the updates from any path that ends at v. 🧚
Here's the vibe: say the latest version is 105 and a client already has version 103. The client's base version is 103, because that's the thing incremental updates get applied on top of 🎀
The target version 105 can be fetched in three ways. It can be directly fetched as a snapshot, or it can be computed incrementally by applying the updates between 103 and 104, then 104 and 105, or it can be computed incrementally by taking the "shortcut" path from 103 to 105, but only if the optional update from 103 to 105 exists. Iconic options 👑
+======+
------| 0 |
/ +======+
ID0-101 / | |
|/__ | |
+======+ | |
tag: 3421097 -> | 101 | | |
+======+ | |
ID101-102 || | |
\/ | |
+======+ | |
tag: 6431234 -> | 102 | | |
+======+ | |
ID102-103 || | |
\/ | |
+======+ / |
+--------------+ tag: 0881080 -> | 103 |<--------/ |
| Base Version | =======> +======+ ID0-103 |
+--------------+ 103-104 || .. |
\/ .. |
+======+ .. |
tag: 6452654 -> | 104 | .. ID103 |
+======+ .. -105 |
ID104-105 || .. | ID0-105
\/ |._ /
+======+ /
tag: 7838392 -> | 105 |<-----------/
+======+
ID105-106 ||
\/
+======+
tag: 6470983 -> | 106 |
+======+Figure 2: TIPS Model Example
3.2. Updates Graph Modification Invariants 🔒
A server is allowed to change its updates graph (to compact it, add nodes, and so on), but it has to make sure that any resource state it offers is reachable by clients. That can happen directly through a snapshot (relative to 0), or indirectly by requesting an earlier snapshot plus a contiguous set of incremental updates. ✨ Also, so clients can proactively build URIs for future update items, the ID of each added node has to go up contiguously by 1. The updates graph MUST satisfy the following invariants:
- Continuity: at any time, let
nsbe the smallest non-zero version (i.e.,<start-seq>) in the updates graph, and letnebe the latest version (i.e.,<end-seq>). Then any version in betweennsandneMUST also exist. This means the incremental update fromnitoni + 1exists for anyns <= ni <= ne, and all the version numbers in the updates graph (except 0) make up exactly the integer interval[ns, ne]. It's a whole chain, no gaps 🔗 - Feasibility: let
nsbe<start-seq>in the updates graph. The server MUST provide a snapshot ofns. In other words, there is always a direct link tonsin the updates graph 🎯 - "Right shift" only: assume a server provides versions in
[n1, n2]at timetand versions in[n1', n2']at timet'. Ift' > t, thenn1' >= n1andn2' >= n2. The window only ever slides forward, never backward 🌈
Here's a hot example. Say a server compacts a resource's updates graph to save space, using the model from Section 3.1. At time 0, the server provides the versions {101, 102, 103, 104, 105, 106}. At time 1, both {103, 104, 105, 106} and {105, 106} are valid sets. However, {102, 103, 104, 105, 106} and {104, 105, 106} are NOT valid sets, because there's no snapshot to version 102 or 104 in the updates graph. So there's a real risk: the right content of version 102 (in the first example) or 104 (in the second example) can't be obtained by a client that doesn't have version 101 or 103, respectively. Yikes 😭
4. TIPS Workflow and Resource Location Schema 🧚
4.1. Workflow 💖
At a high level, an ALTO client first requests the TIPS information resource (called TIPS-F, where F is for frontend) to say which information resource or resources it wants to monitor. For each requested resource, the server returns a JSON object. That object has a URI pointing to the root of a TIPS view (called TIPS-V), plus a summary of the current view, which has what the client needs to interact with the current view correctly. Once the client has that URI for the root of a TIPS view, it can build URIs (see Section 4.2) to fetch incremental updates 🎀
Figure 3 shows an example workflow. After TIPS-F gets the request from the client to monitor updates for an ALTO resource, it creates a TIPS view resource and sends the matching info back to the client. The URI points to that specific TIPS-V instance, and the summary has the <start-seq> and <end-seq> of the updates graph, plus a server-recommended edge to consume first (for example, from i to j) 🦋
Then the ALTO client can keep pulling each additional update with that info. In Figure 3, the client first fetches the update from i to j, then from j to j+1. The update item at <tips-view-uri>/ug/<j>/<j+1> might not exist yet, so the server holds the request until the update shows up. That's called long polling, and it's giving patience 🕰️
A server MAY close a TIPS view at any time (for example, under high system load or because of client inactivity). If a TIPS view gets closed, an edge request gets error code 404 (Not Found) back, and the client has to request a new TIPS view URI. Rough, but that's the deal 💀
If resources allow, a server SHOULD avoid closing TIPS views that have active polling edge requests or have recently served responses, until clients have had a reasonable interval to request the next update. The exception is when specific control policies say otherwise 🫶
Client TIPS-F TIPS-V
o . .
| POST to create/receive a TIPS view . Create TIPS .
| for resource 1 . View .
|-------------------------------------> |.-.-.-.-.-.-.-> |
| <tips-view-uri>, <tips-view-summary> . |
| <-------------------------------------| <-.-.-.-.-.-.-.|
| .
| GET /<tips-view-path>/ug/<i>/<j> .
|------------------------------------------------------> |
| content on edge i to j |
| <------------------------------------------------------|
| .
| GET /<tips-view-path>/ug/<j>/<j+1> .
|------------------------------------------------------> |
. .
. .
| content on edge j to j+1 |
| <------------------------------------------------------|
| .
o .
.
TIPS View Closed oFigure 3: ALTO TIPS Workflow Supporting Client Pull
Okay bestie, picking up right where we left off 💅✨
#4.2. Resource Location Schema ✨
Okay so this part is about how a client actually builds the URIs to grab incremental updates 🦋 The idea is that you treat the whole updates graph like a little "virtual" file system (an adjacency list 🗂️) that lives inside the root of a TIPS view URI. (Check out Section 6.2 for what tips-view-uri means, it's giving foundational 🫶)
Say the updates graph of your TIPS view looks like Figure 2. Then the location schema ends up looking like Figure 4 below 👑
<tips-view-path> // root path to a TIPS view
|_ ug // updates graph
| |_ 0
| | |_ 101 // full 101 snapshot
| | |_ 103
| | \_ 105
| |_ 101
| | \_ 102 // 101 -> 102 incremental update
| |_ 102
| | \_ 103
| |_ 103
| | |_ 104
| | \_ 105 // optional shortcut 103 -> 105 incr. update
| |_ 104
| | \_ 105
| \_ 105
| \_ 106
\_ ...
Figure 4: Location Schema ExampleTIPS uses this directory layout to make template URIs, so once a client gets the tips-view-uri from the server, it can build the address of any incremental update itself 🧚 The generic template for the update on the edge from node 'i' to node 'j' in the updates graph is:
<tips-view-uri>/ug/<i>/<j>Now the sequential update IDs are the best part, ngl 🌈 Because they go in order, a client can long poll an update that doesn't exist yet (like the incremental update from 106 to 107) 🙈 You build the URI for the next edge that will be added, starting from the sequence number of the current last node (that's <end-seq> in the graph) to the next sequential node (<end-seq + 1>):
<tips-view-uri>/ug/<end-seq>/<end-seq + 1>Last bit, and it's simple: incremental updates of a TIPS view are read-only, so they get fetched with the HTTP GET method 💖
5. TIPS Information Resource Directory (IRD) Announcement 🎀
Okay so to announce a TIPS information resource in the IRD, an ALTO server MUST specify "media-type", "capabilities", and "uses" as follows 💅
5.1. Media Type 🦋
The media type of the Transport Information Publication Service (TIPS) resource is "application/alto-tips+json" ✨
5.2. Capabilities 🌸
The "capabilities" field of a TIPS information resource is modeled on the one defined in Section 6.3 of [RFC8895] 🫶
Specifically, the capabilities are an object of the TIPSCapabilities type:
object {
IncrementalUpdateMediaTypes incremental-change-media-types;
} TIPSCapabilities;
object-map {
ResourceID -> String;
} IncrementalUpdateMediaTypes;
Figure 5: TIPSCapabilitieswith the field:
incremental-change-media-types: If a TIPS information resource can provide updates with incremental changes for a resource, the "incremental-change-media-types" field has an entry whose key is the ID of the resource and whose value is the supported media types of incremental changes, separated by commas. For this specification to be implemented, this MUST be "application/merge-patch+json", "application/json-patch+json", or "application/merge-patch+json,application/json-patch+json", unless a future extension defines something else 🔥
When choosing the media types to encode incremental updates for a resource, the server MUST consider the limitations of the encoding 🙈 For example, when a JSON merge patch says the value of a field is null, the semantics are that the field gets removed from the target, so the field is no longer defined (undefined). But that might not be what you want, when null and undefined mean different things for the resource 💀 In that case, the server MUST choose JSON patch encoding over JSON merge patch encoding for the incremental update if both "application/json-patch+json" and "application/merge-patch" are supported by the TIPS information resource 👑
5.3. Uses 🍓
The "uses" attribute MUST be an array with the resource IDs of every network information resource that this TIPS information resource can provide service for 🌈
This set MAY be any subset of the ALTO server's network information resources, and it MAY include resources defined in linked IRDs. However, it is RECOMMENDED that the ALTO server selects a set that is closed under the resource dependency relationship 🫶 That means if a TIPS information resource's "uses" set includes resource R1, and R1 depends on ("uses") resource R0, then the "uses" set should include R0 as well as R1 ✨ For example, if a TIPS information resource provides a TIPS view for a cost map, it should also provide a TIPS view for the network map that the cost map depends on 🗺️
If the set is not closed, at least one resource R1 in the "uses" field of a TIPS information resource depends on another resource R0 that is NOT in that same "uses" field. So a client can't receive incremental updates for R0 🥲 If the client sees in an update of R1 that the version tag for R0 has changed, it MUST request the full content of R0, which is likely to be less efficient than getting the incremental updates of R0 😭
Wait, correction, I need to keep the original wording exactly here: where the original says "it must request the full content of R0", that is a plain-language statement and not a requirement keyword, so it stays as written. Here it is, with no capital letters added:
If the set is not closed, at least one resource R1 in the "uses" field of a TIPS information resource depends on another resource R0 that is not in the "uses" field of the same TIPS information resource. Thus, a client cannot receive incremental updates for another resource R0 that is not in the "uses" field of the same TIPS information resource. If the client observes in an update of R1 that the version tag for R0 has changed, it must request the full content of R0, which is likely to be less efficient than receiving the incremental updates of R0 😭
5.4. An Example 📸
Extending the IRD example in Section 8.1 of [RFC8895], Figure 6 is the IRD of an ALTO server supporting the ALTO base protocol, ALTO/SSE, and ALTO TIPS 🎀
"my-network-map": {
"uri": "https://alto.example.com/networkmap",
"media-type": "application/alto-networkmap+json"
},
"my-routingcost-map": {
"uri": "https://alto.example.com/costmap/routingcost",
"media-type": "application/alto-costmap+json",
"uses": ["my-network-map"],
"capabilities": {
"cost-type-names": ["num-routingcost"]
}
},
"my-hopcount-map": {
"uri": "https://alto.example.com/costmap/hopcount",
"media-type": "application/alto-costmap+json",
"uses": ["my-network-map"],
"capabilities": {
"cost-type-names": ["num-hopcount"]
}
},
"my-simple-filtered-cost-map": {
"uri": "https://alto.example.com/costmap/filtered/simple",
"media-type": "application/alto-costmap+json",
"accepts": "application/alto-costmapfilter+json",
"uses": ["my-network-map"],
"capabilities": {
"cost-type-names": ["num-routingcost", "num-hopcount"],
"cost-constraints": false
}
},
"update-my-costs": {
"uri": "https://alto.example.com/updates/costs",
"media-type": "text/event-stream",
"accepts": "application/alto-updatestreamparams+json",
"uses": [
"my-network-map",
"my-routingcost-map",
"my-hopcount-map",
"my-simple-filtered-cost-map"
],
"capabilities": {
"incremental-change-media-types": {
"my-network-map": "application/json-patch+json",
"my-routingcost-map": "application/merge-patch+json",
"my-hopcount-map": "application/merge-patch+json"
},
"support-stream-control": true
}
},
"update-my-costs-tips": {
"uri": "https://alto.example.com/updates-new/costs",
"media-type": "application/alto-tips+json",
"accepts": "application/alto-tipsparams+json",
"uses": [
"my-network-map",
"my-routingcost-map",
"my-hopcount-map",
"my-simple-filtered-cost-map"
],
"capabilities": {
"incremental-change-media-types": {
"my-network-map": "application/json-patch+json",
"my-routingcost-map": "application/merge-patch+json",
"my-hopcount-map": "application/merge-patch+json",
"my-simple-filtered-cost-map": "application/merge-patch+json"
}
}
},
"tips-sse": {
"uri": "https://alto.example.com/updates/tips",
"media-type": "text/event-stream",
"accepts": "application/alto-updatestreamparams+json",
"uses": [ "update-my-costs-tips" ],
"capabilities": {
"incremental-change-media-types": {
"update-my-costs-tips": "application/merge-patch+json"
}
}
}
Figure 6: Example of an ALTO Server Supporting the ALTO Base
Protocol, ALTO/SSE, and ALTO TIPSNote that it is straightforward for an ALTO server 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-tips" provides an ALTO TIPS information resource, and this is indicated by the media type "application/alto-tips+json" 💜
6. TIPS Management 🧚
Upon request, a server sends a TIPS view to a client 💌 This TIPS view might be created at the time of the request, or it might already exist (either because another client already created a TIPS view for the same requested network resource, or because the server perpetually maintains a TIPS view for an often-requested resource) 🌸
6.1. Open Request 💖
An ALTO client requests that the server provide a TIPS view for a given resource by sending an HTTP POST body with the media type "application/alto-tipsparams+json" 📮 That body contains a JSON object of the TIPSReq type, where:
object {
ResourceID resource-id;
[JSONString tag;]
[Object input;]
} TIPSReq;
Figure 7: TIPSReqwith the following fields:
resource-id: This field contains the resource ID of an ALTO resource to be monitored, which MUST be in the TIPS information resource's "uses" list (Section 5). If a client does not support all incremental methods from the set announced in the server's capabilities, the client MUST NOT use the TIPS information resource 🙅♀️
tag: If the "resource-id" is associated with a GET-mode resource with a version tag (or "vtag"), as defined in Section 10.3 of [RFC7285], and the ALTO client has previously retrieved a version of that resource from ALTO, the ALTO client MAY set the "tag" field to the tag part of the client's version of that resource. The server MAY use the tag when calculating a recommended starting edge for the client to consume. Note that the client MUST support all incremental methods from the set announced in the server's capabilities for this resource 🍓
input: If the resource is a POST-mode service that requires input, the ALTO client MUST set the "input" field to a JSON object with the parameters that the resource expects ✨
6.2. Open Response ✨
okay bestie, the server's reply to a valid request MUST be a JSON object of the AddTIPSResponse type, and it comes back as media type application/alto-tips+json 💖
object {
URI tips-view-uri;
TIPSViewSummary tips-view-summary;
} AddTIPSResponse;
object {
UpdatesGraphSummary updates-graph-summary;
} TIPSViewSummary;
object {
JSONNumber start-seq;
JSONNumber end-seq;
StartEdgeRec start-edge-rec;
} UpdatesGraphSummary;
object {
JSONNumber seq-i;
JSONNumber seq-j;
} StartEdgeRec;
Figure 8: AddTIPSResponseIt has these fields:
tips-view-uri: this is the URI to the TIPS view you asked for 🦋 Its value MUST follow this format:
scheme "://" tips-view-host "/" tips-view-path
tips-view-host = host [ ":" port]
tips-view-path = pathThe scheme MUST be "http" or "https", unless a future extension says otherwise. The host, port, and path follow Sections 3.2.2, 3.2.3, and 3.3 in [RFC3986]. An ALTO server SHOULD use "https", unless the TIPS view contents are meant to be public and don't raise security concerns. The field MUST contain only ASCII characters. If the original URL has international characters (like in the domain name), the ALTO server implementation MUST properly encode it into ASCII (for example, with the "urlencode" function) 🌸
A server MUST NOT use the same URI for different TIPS views, whether that's for different resources or for different request bodies to the same resource. How the URI gets made is up to the implementation. For example, you could compute a Universally Unique Identifier (UUID) [RFC9562], or a hash value based on the request, and tack it onto a base URL. For performance reasons, it is NOT RECOMMENDED to use properties that aren't in the request body to decide the URI of a TIPS view, like cookies or the client's IP address. That can end up making duplicate TIPS views, which happens a lot with mobile clients 🙈 Still, this isn't mandatory, because a server might purposely use client info to build the TIPS view URI so it can isolate service between clients.
tips-view-summary: this one contains an updates-graph-summary 💅
The "updates-graph-summary" field holds the <start-seq> of the updates graph (in the "start-seq" field) and the <end-seq> that's currently available (in the "end-seq" field). It also has a recommended edge to consume (in the "start-edge-rec" field). If the client doesn't give a version tag, the server MUST recommend the edge of the latest available snapshot. If the client does give a version tag, the server MUST either recommend the first incremental update edge starting from the client's tagged version, or recommend the edge of the latest snapshot. Which one it picks depends on the implementation. For example, a server MAY work out the cumulative size of the incremental updates available from that version onward, then compare it to the size of the complete resource snapshot. If the snapshot is bigger, the server recommends the first incremental update edge starting from the client's tagged version. Otherwise, it recommends the latest snapshot edge 👑
If the request has any errors, the ALTO server MUST return an HTTP 400 (Bad Request) error code to the ALTO client. The body of the response follows the generic ALTO error response format from Section 8.5.2 of [RFC7285]. So an example ALTO error response looks like Figure 9 🔥
HTTP/1.1 400 Bad Request
Content-Length: 131
Content-Type: application/alto-error+json
{
"meta":{
"code": "E_INVALID_FIELD_VALUE",
"field": "resource-id",
"value": "my-network-map/#"
}
}
Figure 9: ALTO Error ExampleQuick note: field and value are optional fields. If the value field exists, the field field MUST exist too 🧚
- If the TIPS request doesn't have a
resource-idfield, the error code MUST be "E_MISSING_FIELD". If thefieldfield is present, it MUST be "resource-id". The ALTO server MUST NOT create any TIPS view. 💀 - If the
resource-idfield is invalid or isn't associated with the TIPS information resource, the error code MUST be "E_INVALID_FIELD_VALUE". If present, thefieldfield MUST be the full path of theresource-idfield, and thevaluefield MUST be the value of theresource-idfield from the request. - If the resource is a POST-mode service that needs input, the client MUST set the
inputfield to a JSON object with the parameters that resource expects. If theinputfield is missing or invalid, the ALTO server MUST return the same error response that resource would return for missing or invalid inputs (see [RFC7285]).
Also, it is RECOMMENDED that the server use the following HTTP code for other errors, with the media type "application/alto-error+json" 🌈
429 (Too Many Requests): this shows up when the number of TIPS view open requests goes over the server threshold. The server MAY indicate when to retry the request in the "Re-Try After" headers.
Last but not least, it is RECOMMENDED that the server provide ALTO/SSE support for the TIPS resource. That way the client can get notified about version updates for all the TIPS views it's monitoring, and make better cross-resource transport decisions (see Section 8.2 for related considerations) ✨
6.3. Open Example
6.3.1. Basic Example
Let's keep it simple and say the ALTO server uses Basic authentication [RFC7617]. If a client with username "client1" and password "helloalto" wants to create a TIPS view of an ALTO cost map resource with the resource ID "my-routingcost-map", it can send the request in Figure 10 🎀
POST /tips HTTP/1.1
Host: alto.example.com
Accept: application/alto-tips+json, application/alto-error+json
Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K
Content-Type: application/alto-tipsparams+json
Content-Length: 41
{
"resource-id": "my-routingcost-map"
}
Figure 10: Request Example of Opening a TIPS ViewIf it works, the server sends back the message in Figure 11 🦋
HTTP/1.1 200 OK
Content-Type: application/alto-tips+json
Content-Length: 255
{
"tips-view-uri": "https://alto.example.com/tips/2718281828",
"tips-view-summary": {
"updates-graph-summary": {
"start-seq": 101,
"end-seq": 106,
"start-edge-rec" : {
"seq-i": 0,
"seq-j": 105
}
}
}
}
Figure 11: Response Example of Opening a TIPS View6.3.2. Example Using Digest Authentication
Here's another example of the same query, this time with Digest authentication. It's a mandatory authentication method for ALTO servers, as defined in Section 8.3.5 of [RFC7285] 🔐 The response content is the same as in Figure 11, so it's been left out to keep things short.
POST /tips HTTP/1.1
Host: alto.example.com
Accept: application/alto-tips+json, application/alto-error+json
Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K
Content-Type: application/alto-tipsparams+json
Content-Length: 41
{
"resource-id": "my-routingcost-map"
}
HTTP/1.1 401 UNAUTHORIZED
WWW-Authenticate: Digest
realm="alto.example.com",
qop="auth",
algorithm="MD5",
nonce="173b5aba4242409ee2ac3a4fd797f9d7",
opaque="a237ff9ab865379a69d9993162ef55e4"
POST /tips HTTP/1.1
Host: alto.example.com
Accept: application/alto-tips+json, application/alto-error+json
Authorization: Digest
username="client1",
realm="alto.example.com",
uri="/tips",
qop=auth,
algorithm=MD5,
nonce="173b5aba4242409ee2ac3a4fd797f9d7",
nc=00000001,
cnonce="ZTg3MTI3NDFmMDQ0NzI1MDQ3MWE3ZTFjZmM5MTNiM2I=",
response="8e937ae696c1512e4f990fa21c7f9347",
opaque="a237ff9ab865379a69d9993162ef55e4"
Content-Type: application/alto-tipsparams+json
Content-Length: 41
{
"resource-id": "my-routingcost-map"
}
HTTP/1.1 200 OK
Content-Type: application/alto-tips+json
Content-Length: 258
{....}
Figure 12: Open Example with Digest Authentication6.3.3. Example Using ALTO/SSE
This part shows how to get incremental updates of the TIPS view summary using ALTO/SSE [RFC8895] 🧚 Say the "tips-sse" resource, announced by the IRD in Figure 6, provides ALTO/SSE for the "update-my-cost-tips" resource. A client might send the request below to receive updates of the TIPS view (authentication is left out for simplicity).
POST /updates/tips HTTP/1.1
Host: alto.example.com
Accept: text/event-stream,application/alto-error+json
Content-Type: application/alto-updatestreamparams+json
Content-Length: 76
{
"add": {
"tips-123": { "resource-id": "update-my-cost-tips" }
}
}
Figure 13: Example of Monitoring TIPS View with ALTO/SSEAfter that, the client gets the TIPS view summary like this 💜
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/event-stream
event: application/alto-tips+json,tips-123
data: {
data: "tips-view-uri": "https://alto.example.com/tips/2718281828",
data: "tips-view-summary": {
data: "updates-graph-summary": {
data: "start-seq": 101,
data: "end-seq": 106,
data: "start-edge-rec" : {
data: "seq-i": 0,
data: "seq-j": 105
data: }
data: }
data: }
data: }When the TIPS view gets an update (for example, when the "end-seq" field goes up by 1), the client receives an incremental update of the TIPS view summary like this 🌸
event: application/merge-patch+json,tips-123
data: {
data: "tips-view-summary": {
data: "updates-graph-summary": {
data: "end-seq": 107
data: }
data: }
data: }7. TIPS Data Transfers - Client Pull ✨
TIPS lets an ALTO client grab the content of an update item from the updates graph. An update item is the content on an edge in the updates graph, and that content can be either an incremental update or a snapshot 🦋
7.1. Request 🎀
Okay so bestie, the client sends an HTTP GET request, and the media type of an update item resource MUST be the same as the "media-type" field of the update item on the specified edge in the updates graph. No wiggle room, periodt 💅
The GET request MUST have the following format:
GET /<tips-view-path>/ug/<i>/<j>
HOST: <tips-view-host>Let's look at an example 🦋 Say you look at the updates graph in Figure 4. If the client wants the content of the first update item (0 -> 101) whose media type is "application/alto-costmap+json", it sends a request to "/tips/2718281828/ug/0/101" and sets the "Accept" header to "application/alto-costmap+json,application/alto-error+json". See Section 7.3 for a concrete example ✨
7.2. Response 🌸
If the request is valid (i.e., "ug/<i>/<j>" exists), the response is encoded as a JSON object, and the data format is indicated by the media type. Main character behavior 👑
A client MAY do proactive fetching of future updates by long polling updates that haven't shown up in the directory yet. For these, the client MUST indicate all media types that might appear. It is RECOMMENDED that the server allow at least the long polling of <end-seq> -> <end-seq + 1>. Lowkey the most useful tip in this whole section 🧚
So the server processing logic MUST be:
- If a resource with path "ug/<i>/<j>" exists, return content using encoding.
- Else, if long polling "ug/<i>/<j>" is acceptable, put the request in a backlog queue. Then either a response is triggered when the content is ready, or the request is interrupted (e.g., by a network error).
- Else, return error.
It is RECOMMENDED that the server use the following HTTP codes to indicate errors, with the media type "application/alto-error+json", for update item requests. 💀
404 (Not Found): Indicates that the requested update does not exist, or the requested TIPS view does not exist or is closed by the server.
410 (Gone): Indicates an update has a seq that is smaller than the <start-seq>.
415 (Unsupported Media Type): Indicates the media type (or types) accepted by the client does not include the media type of the update chosen by the server.
425 (Too Early): Indicates the seq exceeds the server long polling window.
429 (Too Many Requests): Indicates the number of pending (long poll) requests exceeds the server threshold. The server MAY indicate when to retry the request in the "Re-Try After" headers. 🙈
7.3. Example 🍓
Assume the client wants the contents of the update item on edge 0 to 101. The request looks like Figure 14 🌈
GET /tips/2718281828/ug/0/101 HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json, \
application/alto-error+json
Figure 14: GET ExampleThe response is shown in Figure 15 💖
HTTP/1.1 200 OK
Content-Type: application/alto-costmap+json
Content-Length: 50
{ ... full replacement of my-routingcost-map ... }
Figure 15: Response to a GET Request7.4. New Next Edge Recommendation 🦋
So the intended TIPS flow is that the client gets a recommended starting edge in the TIPS summary, consumes that edge, and then builds all future URIs by bumping the sequence count by one. But sometimes the client needs to request a new next edge to consume. Like, if a client has an open TIPS view but hasn't polled in a while, it might ask for the next logical incremental URI, but the server has compacted the updates graph, so that URI doesn't exist anymore 😭 In that case, the client MAY request a new next edge to consume based on its current version of the resource. Bestie, that's the save ✨
7.4.1. Request 🫶
An ALTO client asks the server for a next edge recommendation for a given TIPS view by sending an HTTP POST request with the media type "application/alto-tipsparams+json". The URL of the request MUST have the following format:
<tips-view-path>/ugand the "HOST" field MUST be "<tips-view-host>".
The POST body has the same format as the TIPSReq in Figure 7. The "resource-id" field MUST be the same as the resource ID used to create the TIPS view, and the optional "input" field MUST NOT be present. Not me reading "MUST NOT" and feeling called out 🙈
7.4.2. Response 💅
The response to a valid request MUST be a JSON merge patch to the object of the AddTIPSResponse type (defined in Section 6.2), denoted as media type "application/merge-patch+json". The "updates-graph-summary" field MUST be present in the response, so its parent field "tips-view-summary" MUST be present too. Hence the chain 🔗
If the "tag" field is present in the request, the server MUST check whether any version within the range [<start-seq>, <end-seq>] has the same tag value. If that version exists (e.g., denoted as <tag-seq>), the server MUST compute the paths from both <tag-seq> and 0 to the <end-seq>, and choose the one with the minimal cost. The cost MAY be implementation specific (e.g., number of messages, accumulated data size, etc.). The first edge of the selected path MUST be returned as the recommended next edge. Pathfinding era 🧠
If the "tag" field is not present, the interpretation MUST be that the <tag-seq> is 0.
It is RECOMMENDED that the server use the following HTTP code to indicate errors, with the media type "application/alto-error+json", for new next edge requests.
404 (Not Found): Indicates that the requested TIPS view does not exist or has been closed by the server.
7.4.3. Example 🌸
Here's an example of the new next edge recommendation service 🎀 Assume a client already creates a TIPS view (as in Section 6.3) whose updates graph looks like Figure 2. Now the client already has tag 0881080, whose corresponding sequence number is 103, and it sends this new next edge recommendation request (authentication is omitted for simplicity):
POST /tips/2718281828/ug HTTP/1.1
HOST alto.example.com
Accept: application/merge-patch+json, application/alto-error+json
Content-Type: application/alto-tipsparams+json
Content-Length: 62
{
"resource-id": "my-routingcost-map",
"tag": "0881080"
}According to Figure 2, there are three potential paths: 103 -> 104 -> 105 -> 106, 103 -> 105 -> 106, and 0 -> 105 -> 106. Assume the server picks the shortest update path by accumulated data size, and the best path is 103 -> 105 -> 106. So the server responds with this message 🦋
HTTP/1.1 200 OK
Content-Type: application/merge-patch+json
Content-Length: 193
{
"tips-view-summary": {
"updates-graph-summary": {
"start-seq": 101,
"end-seq": 106,
"start-edge-rec": {
"seq-i": 103,
"seq-j": 105
}
}
}
}8. Operation and Processing Considerations 👑
TIPS has some common operational considerations with ALTO/SSE [RFC8895], including:
- the server choosing update messages (Section 9.1 of [RFC8895]);
- the client processing update messages (Section 9.2 of [RFC8895]);
- the updates of filtered map services (Section 9.3 of [RFC8895]); and
- the updates of ordinal mode costs (Section 9.4 of [RFC8895]).
There are also some operational considerations specific to TIPS, which we discuss below 🧚
8.1. Considerations for Load Balancing ⭐
There are two levels of load balancing in TIPS: the first level balances the load of TIPS views for different clients, and the second balances the load of incremental updates. Two levels, no cap, both matter 💜
Load balancing of TIPS views can happen either at the application layer or at the infrastructure layer. For example, an ALTO server MAY set <tips-view-host> to different subdomains to distribute TIPS views, or it can simply use the same host as the TIPS information resource and rely on load balancers to distribute the load. 🌈
TIPS lets a client make concurrent pulls of incremental updates for the same TIPS view, potentially through different HTTP connections. Because of that, TIPS adds complexity when the ALTO server balances load by distributing requests to a set of backend servers. For example, a request might get sent to the wrong backend server and processed incorrectly if both of these conditions hold:
- these backend servers are stateful (i.e., the TIPS view is created and stored only on a single server); and
- the ALTO server is using Layer 4 load balancing (i.e., the requests are distributed based on the TCP 5-tuple).
So extra considerations are needed to make load balancing correct for TIPS, including:
Using a stateless architecture: One solution is to follow the stateless computing pattern. States about the TIPS view aren't kept by the backend servers, and are instead stored in a distributed database. That way, concurrent requests to the same TIPS view can be processed on arbitrary stateless backend servers, which all fetch data from the same database. Stateless is the move 🫶
Configuring the load balancers properly: If the backend servers are stateful, the load balancers MUST be properly configured to guarantee that requests for the same TIPS view always arrive at the same server. For example, an operator or provider of an ALTO server MAY configure Layer 7 load balancers that distribute requests based on the tips-view-path component in the URI. Routing that's sticky and iconic 🎀
8.2. Considerations for Cross-Resource Dependency Scheduling 🔗
Okay bestie, dependent ALTO resources create cross-resource dependencies in TIPS 🫶. Here's a pair where my-cost-map (C) depends on my-network-map (N). Each resource has its own updates graph, and the links between the graphs show who depends on who:
+---+ +---+ +---+ +---+ +---+
my-network-map (N) | 0 |-->|89 |-->|90 |-->|91 |-->|92 |
+---+ +---+ +---+ +---+ +---+
| \ \ \
| \ \ \
+---+ +---+ +---+ +---+ +---+
my-cost-map (C) | 0 |-->|101|-->|102|-->|103|-->|104|
+---+ +---+ +---+ +---+ +---+
|_______________________|Figure 16: Example Dependency Model
In Figure 16, cost-map versions 101 and 102 (C101 and C102) are dependent on network-map version 89 (N89). Cost-map version 103 (C103) is dependent on network-map version 90 (N90), and so on 💅.
So the client has to decide the order it receives and applies updates 🎀. That order may affect how fast the client builds a consistent view and how long the client needs to buffer the update.
Example 1: The client requests N89, N90, N91, C101, C102 in that order. The client either gets no consistent view of the resources or has to buffer N90 and N91.
Example 2: The client requests C101, C102, C103, N89. The client either gets no consistent view or has to buffer C103.
To get consistent ALTO information, a client must process the updates by following the guidelines in Section 9.2 of [RFC8895] ✨. If resources permit (meaning sufficient updates can be buffered), an ALTO client can safely use long polling to fetch all the updates. That lets a client build consistent views quickly, since the updates are already stored in the buffer 🌸. Otherwise, it is RECOMMENDED to request a full snapshot if the client doesn't have enough local resources to buffer and process the incremental updates.
8.3. Considerations for Managing Shared TIPS Views 🧚
From a client's point of view, it sees only one copy of the TIPS view for any resource. On the server side, though, there are different implementation options, especially for common resources (like network maps or cost maps) that lots of clients query often 💜. Here are some potential options:
- An ALTO server creates one TIPS view of the common resource for each client.
- An ALTO server maintains one copy of the TIPS view for each common resource, and all clients requesting the same resources use the same copy. There are two ways to manage storage for the shared copy:
- the ALTO server keeps track of the set of clients that have sent a polling request to the TIPS view, and only removes the view from storage when the set becomes empty and no client immediately issues a new edge request; or
- the TIPS view is never removed from storage.
Developers can pick different implementation options depending on criteria like request frequency, the available resources of the ALTO server, the ability to scale, and programming complexity 🍓.
8.4. Considerations for Offering Shortcut Incremental Updates ⚡
Besides the mandatory stepwise incremental updates (from i to i+1), an ALTO server MAY optionally offer shortcut incremental updates, or simple shortcuts, between two non-consecutive versions i and i+k (k > 1). Shortcuts offer alternative paths in the updates graph and can potentially speed up the transmission and processing of incremental updates, leading to faster synchronization of ALTO information. That's especially helpful when the client has limited bandwidth and computation 🦋. However, implementors of an ALTO server must be aware that:
- optional shortcuts may increase the size of the updates graph. The worst case is the square of the number of updates (that is, when a shortcut is offered for each version to all future versions).
- optional shortcuts require additional storage on the ALTO server.
- optional shortcuts may reduce concurrency when the updates don't overlap (for example, when the updates apply to different parts of an ALTO resource). In that case, the total size of the original updates is close to the size of the shortcut, but the original updates can be transmitted concurrently while the shortcut is transmitted in a single connection.
9. Security Considerations 🛡️
Security is not a vibe to skip, bestie. Read this part carefully 😭.
The security considerations of the base protocol (Section 15 of [RFC7285]) fully apply to this extension. For example, the same authenticity and integrity considerations (Section 15.1 of [RFC7285]) still fully apply, and the same considerations for the privacy of ALTO users (Section 15.4 of [RFC7285]) also still fully apply. Additionally, operators of the ALTO servers MUST follow the guidelines in [RFC9325] to avoid new TLS vulnerabilities discovered after [RFC7285] was published 🔐.
The additional services (the update read service and the update push service) provided by this extension extend the attack surface described in Section 15.1.1 of [RFC7285]. The following subsections discuss the additional risks and their remedies 💀.
9.1. TIPS: Denial-of-Service Attacks 🚨
Allowing TIPS views enables new classes of DoS attacks. Specifically, for the TIPS server, one or multiple malicious ALTO clients might create an excessive number of TIPS views to exhaust the server's resources and/or block normal users from accessing the service 🙈.
To avoid such attacks, the server MAY choose to limit the number of active views and reject new requests when that threshold is reached. TIPS allows predictive fetching, and the server MAY also choose to limit the number of pending requests. If a new request exceeds the threshold, the server MAY log the event and return the HTTP status 429 (Too Many Requests).
It's important to note that these approaches aren't the only possibilities 🌈. For example, a TIPS server might use somewhat more clever logic involving TIPS view eviction policies, IP reputation, rate-limiting, and compartmentalization of the overall threshold into smaller thresholds that apply to subsets of potential clients. If service availability is a concern, ALTO clients MAY establish service level agreements with the ALTO server 🤝.
9.2. ALTO Client: Update Overloading or Instability 📉
The availability of continuous updates can also overload an ALTO client, especially one with limited processing capabilities. The current design doesn't include any flow control mechanisms for the client to reduce the update rates from the server. For example, TCP, HTTP/2, and QUIC provide stream and connection flow control data limits, which might help prevent the client from being overloaded 🧱. Under overloading, the client MAY choose to remove the information resources with high update rates.
Also, under overloading, the client might no longer be able to detect whether information is still fresh or has become stale. In that case, the client should be careful about how it uses the information to avoid stability or efficiency issues 👀.
10. IANA Considerations 📋
IANA has registered the following media types from the registry available at [IANA-Media-Type] 🎀:
- application/alto-tips+json: as described in Section 6.2;
- application/alto-tipsparams+json: as described in Section 6.1;
10.1. 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
[RFC8259].
Security considerations: See the Security Considerations section of
RFC 9569.
Interoperability considerations: N/A
Published specification: Section 6.2 of RFC 9569.
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): RFC 9569 uses the media type to refer to
protocol messages; thus, it does not require a file extension.
Macintosh file type code(s): N/A
Person & email address to contact for further information:
See the Authors' Addresses section of RFC 9569.
Intended usage: COMMON
Restrictions on usage: N/A
Author: See the Authors' Addresses section of RFC 9569.
Change controller: Internet Engineering Task Force (iesg@ietf.org).10.2. 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
[RFC8259].
Security considerations: See the Security Considerations section of
RFC 9569.
Interoperability considerations: N/A
Published specification: Section 6.1 of RFC 9569.
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): RFC 9569 uses the media type to refer to
protocol messages; thus, it does not require a file extension.
Macintosh file type code(s): N/A
Person & email address to contact for further information:
See the Authors' Addresses section of RFC 9569.
Intended usage: COMMON
Restrictions on usage: N/A
Author: See the Authors' Addresses section of RFC 9569.
Change controller: Internet Engineering Task Force (iesg@ietf.org).11. References 📚
11.1. Normative References 📚✨
Okay bestie, these are the must-reads 🤓 Everything here is required reading to get TIPS, and you need them to understand the spec.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
- [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
- [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, <https://www.rfc-editor.org/info/rfc7285>.
- [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
- [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
- [RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November 2020, <https://www.rfc-editor.org/info/rfc8895>.
- [RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022, <https://www.rfc-editor.org/info/rfc9112>.
- [RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/info/rfc9113>.
- [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/info/rfc9114>.
- [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, <https://www.rfc-editor.org/info/rfc9325>.
11.2. Informative References 💅
These ones are the extra context, not strictly required, but they're so good for the vibes 🌈
- [IANA-Media-Type] IANA, "Media Types", <https://www.iana.org/assignments/media-types>.
- [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <https://www.rfc-editor.org/info/rfc7617>.
- [RFC9205] Nottingham, M., "Building Protocols with HTTP", BCP 56, RFC 9205, DOI 10.17487/RFC9205, June 2022, <https://www.rfc-editor.org/info/rfc9205>.
- [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/info/rfc9562>.
Appendix A. A High-Level Deployment Model 🧚
Okay so conceptually, the TIPS system is made of three types of resources 🦋
- (R1): The TIPS frontend to create TIPS views.
- (R2): The TIPS view directory, which provides metadata (e.g., references) about the network resource data.
- (R3): The actual network resource data, encoded as complete ALTO network resources (e.g., a cost map or a network map) or incremental updates.
Here's the picture, it's giving very clear vibes 👀
+------------------------------------------------+
| |
+------+ |R1: Frontend/Open R2: Directory/Meta R3: Data |
| | "iget" base | +-----+ +-----+ +-----+ |
| | resource 1 | | | | | | | |
| |-------------|---->| | | | | | |
| | incremental | | | | |-------->| | |
| | transfer | | | | | | | |
| | resource | | | | | | | |
| |<------------|-----------------------| | | | |
|Client| | | | +-----+ +-----+ |
| | "iget" base | | | |
| | resource 2 | | | +-----+ +-----+ |
| |-------------|---->| | | | | | |
| | incremental | | | | | | | |
| | transfer | +-----+ | | ------->| | |
| | resource | | | | | |
| |<------------|-----------------------| | | | |
+------+ | +-----+ +-----+ |
| |
+------------------------------------------------+
Figure 17: Sample TIPS Deployment ModelDesign Point: Component Resource Location 📍
Three designs, let's gooo 🚀
- Design 1 (Single): all the three resource types at the same single server (accessed via relative reference).
- Design 2 (Flexible): all three resource types can be at their own server (accessed via absolute reference).
- Design 3 (Dir + Data): R2 and R3 must remain together, though R1 might not be on the same server.
This document supports Designs 1 and 3 🎀 For Design 1, the ALTO server simply needs to always use the same host for the TIPS views. For Design 3, the ALTO server can set tips-view-host to a different server. Note that the deployment flexibility is at the logical level, as these services can be distinguished by different paths and potentially be routed to different physical servers by Layer 7 load balancing. See Section 8.1 for a discussion on load balancing considerations. Future documents could extend the protocol to support Design 2 🌸
Appendix B. Conformance with "Building Protocols with HTTP" (RFC 9205) Best Current Practices 🫶
This spec adheres fully to [RFC9205] as further elaborated below, so it's giving rule-following energy 💅
- TIPS does not (as described in Section 3.1 of [RFC9205]):
...redefine, refine, or overlay the semantics of generic protocol elements such as methods, status codes, or existing header fields.
and instead focuses on
...protocol elements that are specific to [the TIPS] application -- namely, [its] HTTP resources.
- There are no statically defined URI components (Section 3.2 of [RFC9205]).
- No minimum version of HTTP is specified by TIPS, which is recommended (in Section 4.1 of [RFC9205]).
- The TIPS design follows the advice (in Section 4.1 of [RFC9205]) that:
When specifying examples of protocol interactions, applications should document both the request and response messages with complete header sections, preferably in HTTP/1.1 format...
- TIPS uses URI templates, which is recommended (in Section 4.2 of [RFC9205]).
- TIPS follows the pattern (in Section 4.4.1 of [RFC9205]) that:
Generally, a client will begin interacting with a given application server by requesting an initial document that contains information about that particular deployment, potentially including links to other relevant resources. Doing so ensures that the deployment is as flexible as possible (potentially spanning multiple servers), allows evolution, and also gives the application the opportunity to tailor the "discovery document" to the client.
- TIPS uses existing HTTP schemes (Section 4.4.2 of [RFC9205]).
- TIPS defines its errors "to use the most applicable status code" (Section 4.6 of [RFC9205]).
- TIPS does not (as in Section 4.11 of [RFC9205]):
...make assumptions about the relationship between separate requests on a single transport connection; doing so breaks many of the assumptions of HTTP as a stateless protocol and will cause problems in interoperability, security, operability, and evolution.
The only relationship between requests is that a client has to first discover where a TIPS view of a resource will be served, which is consistent with the URI discovery in Section 4.4.1 of [RFC9205]. Not making any extra assumptions, just vibes 🧚
Appendix C. Push-Mode TIPS Using HTTP Server Push 📨
TIPS allows ALTO clients to subscribe to incremental updates of an ALTO resource, and the spec here is based on the current best practice of building such a service using basic HTTP. Earlier versions of this document had investigated the possibility of enabling push-mode TIPS (i.e., by taking advantage of the server push feature in HTTP/2 and HTTP/3).
In the ideal case, push-mode TIPS can potentially improve performance (e.g., latency) in more dynamic environments and use cases with wait-free message delivery. Using the built-in HTTP server push also results in minimal changes to the current protocol. While not adopted due to the lack of server push support and increased protocol complexity, push-mode TIPS remains a potential direction of protocol improvement 🔮
Appendix D. Persistent HTTP Connections 🔌
Previous draft versions of this document used persistent HTTP connections to detect the liveness of clients. However, this design does not conform well with the best current practices of HTTP 🙈 For example, if an ALTO client is accessing a TIPS view over an HTTP proxy, the connection is not established directly between the ALTO client and the ALTO server, but between the ALTO client and the proxy and between the proxy and the ALTO server. Thus, using persistent connections might not correctly detect the right liveness state.
Acknowledgments 🌈
The authors of this document would like to thank Mark Nottingham and Spencer Dawkins for providing invaluable reviews of earlier draft versions of this document 🫶 Adrian Farrel, Qin Wu, and Jordi Ros Giralt for their continuous feedback 💜 Russ White, Donald Eastlake 3rd, Martin Thomson, Bernard Aboba, Spencer Dawkins, Linda Dunbar, and Sheng Jiang for the directorate reviews ⭐ Martin Duke for the area director review 👑 Francesca Palombini, Wesley Eddy, Roman Danyliw, Murray Kucherawy, and Zaheduzzaman Sarker for the telechat and IESG reviews 🍓 And Mohamed Boucadair for shepherding the document 🎀
Authors' Addresses 💌
Kai Gao
Sichuan University
No.24 South Section 1, Yihuan Road
Chengdu
610000
China
Email: kaigao@scu.edu.cnRoland Schott
Deutsche Telekom
Deutsche-Telekom-Allee 9
64295 Darmstadt
Germany
Email: Roland.Schott@telekom.deYang Richard Yang
Yale University
51 Prospect Street
New Haven, CT 06511
United States of America
Email: yry@cs.yale.eduLauren Delwiche
Yale University
51 Prospect Street
New Haven, CT 06511
United States of America
Email: lauren.delwiche@yale.eduLachlan Keller
Yale University
51 Prospect Street
New Haven, CT 06511
United States of America
Email: lachlan.keller@aya.yale.edu📦 where this page comes from
- ietf: rfc9569 2024-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms