The Application-Layer Traffic Optimization (ALTO) Transport Information Publication Service (TIPS)
Extracted elements (29)
For load balancing, TIPS supports both a stateless architecture (TIPS view state stored in a distributed database, enabling any backend to serve requests) and a stateful architecture with Layer 7 load balancing routing based on the tips-view-path URI component. Layer 4 (TCP 5-tuple) load balancing is incompatible with stateful backends.
Optional shortcut incremental updates (skipping versions i to i+k, k>1) can speed synchronization but have trade-offs: they may grow the updates graph to O(n^2) size, require extra server storage, and can reduce concurrency when updates are disjoint (a single shortcut cannot be transferred concurrently unlike multiple mandatory steps).
Persistent HTTP connections for client liveness detection were removed because they conflict with HTTP best practices: when a client accesses a TIPS view through an HTTP proxy, connections exist between client-proxy and proxy-server separately, so persistent connections do not correctly detect client liveness.
The TIPS view URI is NOT RECOMMENDED to encode properties outside the request body (such as cookies or client IP address) to avoid creating duplicate TIPS views for the same resource, e.g., when a mobile client changes IP. Servers may intentionally use client info for service isolation, but this is discouraged for common resources.
TIPS is designed as a complement to ALTO/SSE, not a replacement. ALTO/SSE optimizes latency by immediately pushing new events, while TIPS optimizes throughput by enabling concurrent, out-of-order transport. ALTO/SSE also lacks naming for individual incremental updates, preventing use of HTTP/2 and HTTP/3 concurrent streams.
TIPS uses a client-pull (long-polling) model rather than server push. HTTP/2 and HTTP/3 server push was considered but not adopted due to lack of broad server push support and increased protocol complexity. The long-polling approach achieves sub-RTT update delivery while remaining compatible with HTTP/1.1.
TIPS is designed to function with HTTP/1.1, HTTP/2, and HTTP/3. On HTTP/1.1, concurrent update fetching requires multiple connections; on HTTP/2 or HTTP/3, it leverages multiplexed streams within a single connection. The URI naming convention is independent of HTTP version.
TIPS reuses the incremental update data formats from RFC 8895 (JSON merge patch and JSON patch), enabling compatibility with existing ALTO incremental update implementations. An example IRD shows ALTO base protocol, ALTO/SSE, and ALTO TIPS coexisting on the same server.
If the resource-id references a POST-mode service requiring input, the ALTO client MUST set the 'input' field to a JSON object with the expected parameters. If 'input' is missing or invalid, the server MUST return the same error response that resource would return for missing or invalid inputs.
Operators of ALTO servers MUST follow the TLS security guidelines in RFC 9325 to avoid new TLS vulnerabilities discovered after RFC 7285 was published. All base protocol security considerations (authenticity, integrity, privacy) fully apply to TIPS.
The server's processing logic for update item GET requests MUST be: return content if 'ug/<i>/<j>' exists; else if long polling is acceptable, queue the request and respond when ready or interrupted; else return an error. It is RECOMMENDED that servers support long polling at least for <end-seq> -> <end-seq+1>.
The TIPS 'uses' attribute MUST be an array with resource IDs of every network information resource for which the TIPS service can provide updates. It is RECOMMENDED that this set be closed under resource dependency: if the TIPS serves resource R1 which depends on R0, R0 should also be in the 'uses' set.
The tips-view-uri scheme MUST be 'http' or 'https', and ALTO servers SHOULD use 'https'. A server MUST NOT reuse the same URI for different TIPS views. The URI MUST contain only ASCII characters; international characters MUST be percent-encoded.
The updates graph MUST satisfy three invariants: Continuity (all versions between start-seq and end-seq must exist, with incremental updates between every consecutive pair); Feasibility (a snapshot of start-seq must always be provided); and Right-shift only (start-seq and end-seq can only increase over time, never decrease).
To announce a TIPS information resource in the IRD, an ALTO server MUST specify the media-type ('application/alto-tips+json'), capabilities (TIPSCapabilities with incremental-change-media-types), and uses (array of resource IDs the TIPS service can serve).
When a JSON merge patch would cause semantic ambiguity (because null means 'remove field' in merge patch but a resource may distinguish null from undefined), the server MUST choose JSON patch encoding over JSON merge patch for incremental updates if both are supported.
When generating the start-edge-rec: if the client provides no version tag, the server MUST recommend the edge of the latest available snapshot (from 0). If the client provides a tag, the server MUST recommend either the first incremental update from the tagged version or the latest snapshot edge, chosen by implementation (e.g., comparing cumulative sizes).
A TIPS view (tv) is the container of incremental transport information for a network information resource. Its primary component is the updates graph (ug), a directed acyclic graph whose nodes are resource versions identified by monotonically increasing sequence numbers, and whose edges are update items (snapshots or incremental updates).
An update item is the content on an edge of the updates graph, represented as a pair (op, data) where op indicates snapshot or incremental update, and data is the content. Mandatory incremental updates exist between consecutive versions i and i+1; optional shortcut updates may exist between non-consecutive versions.
The AddTIPSResponse object (media type 'application/alto-tips+json') is returned on a successful TIPS view open request. It contains 'tips-view-uri' (URI to the TIPS view root) and 'tips-view-summary', which includes the UpdatesGraphSummary with start-seq, end-seq, and a start-edge-rec (recommended first edge as seq-i and seq-j).
The New Next Edge Recommendation service allows a client to POST to '<tips-view-path>/ug' when it has lost track of the next valid edge (e.g., after server graph compaction). The server returns a JSON merge patch to AddTIPSResponse containing an updated UpdatesGraphSummary with a new recommended start-edge-rec.
The TIPSCapabilities object contains an 'incremental-change-media-types' field mapping resource IDs to their supported incremental update media types. The supported values are 'application/merge-patch+json', 'application/json-patch+json', or both comma-separated.
The TIPSReq object (media type 'application/alto-tipsparams+json') is sent via HTTP POST to open a TIPS view. It contains a mandatory 'resource-id' field, an optional 'tag' field (the client's current version tag for incremental starting point selection), and an optional 'input' field required for POST-mode filtered services.
IANA has registered media type 'application/alto-tips+json' for the ALTO TIPS response format (AddTIPSResponse), as defined in Section 6.2 of RFC 9569. Encoding follows 'application/json' conventions per RFC 8259.
IANA has registered media type 'application/alto-tipsparams+json' for the ALTO TIPS request body format (TIPSReq), as defined in Section 6.1 of RFC 9569. Encoding follows 'application/json' conventions per RFC 8259.
Continuous TIPS updates can overload ALTO clients with limited processing capacity. No built-in flow control for clients is specified; TCP, HTTP/2, and QUIC stream/connection flow control may help. Under overload, a client MAY drop high-update-rate resources and must be careful about using potentially stale information to avoid stability issues.
TIPS enables a new class of DoS attacks: malicious clients may create excessive TIPS views to exhaust server resources. Mitigations include limiting active TIPS views and pending long-poll requests (returning HTTP 429), applying TIPS view eviction policies, IP reputation filtering, rate limiting, and threshold compartmentalization. Clients MAY establish SLAs with servers.
A TIPS view progresses through three states: Created (on client POST to TIPS frontend), Active (serving polling requests), and Closed (server may close at any time due to inactivity or load). Transitions: Created→Active on successful open; Active→Closed by server decision. When Closed, edge requests receive HTTP 404, and the client must open a new TIPS view.
Update items are addressed using the URI template `<tips-view-uri>/ug/<i>/<j>`, where i is the source version sequence number and j is the target. For long polling a future update, a client constructs `<tips-view-uri>/ug/<end-seq>/<end-seq+1>`. Incremental updates are fetched using HTTP GET.