The Transport-Info header provides a mechanism to transmit network transport related information such as current delivery rate and round-trip time, from a server or a client. This information has a wide range of uses such as client monitoring and diagnostics, or allowing a client to adapt to current network conditions.
RFC Editor: please remove this section before publication
Source code and issues for this draft can be found at https://github.com/bbc/draft-ohanlon-transport-info-header.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress”.
This Internet-Draft will expire on December 30, 2021.
Copyright (c) 2021 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The Transport-Info header provides for relaying of transport protocol related information from either a server or client entity with the aim of informing the sender’s view on the transport state. The state of a connection is dependent upon information based upon packet exchanges during the transport processes. Firstly, there is information that is common to both client and server, such as the calculated round-trip time (RTT), although it may be measured using different packets at each end. Secondly, there is state information that exists only at each endpoint, such as the size of the congestion, and receive windows. Thus certain transport state information is only available at the server which can be useful to the client, for example, to calculate the current transport rate. This information may then be used to better inform a client of the state of the network path and make appropriate adaptations.
The information can also be utilised by a client to provide for application level client oriented metric logging to back-end systems for monitoring and analysis purposes. Such data could be utilised in a manner not unlike that proposed in [RFC4898].
This approach is directly applicable to TCP but also can be utilised with other related transport protocols, such as QUIC [I-D.ietf-quic-transport].
There exist W3C specifications such as the Network Information API [network-info-api], which provides estimates of metrics, including downlink rate and RTT, that are measured “across recently active connections”, but are platform and browser dependent, with limited cross-browser support. In practice the downlink measurement is is generally of low accuracy and of little use for informing an application of dynamic network conditions, and the RTT measurement is also of low accuracy. However, it is implemented in Chrome and the utilisation of the API is now seen in a large proportion of websites, mainly due to adoption of the API by widely used libraries.
This information is already being sent by servers and clients so this document specifies a standard way for entities to encode and transport such information.
The header can be used to provide sender specific transport information that can inform a range of functions:
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.
The Transport-Info header uses the Structured Header Values for HTTP [RFC8941]
Transport-Info = sf-list
Each member of the parameterised list represents an entry that contains a set of metrics reported.
The list members identify either the server or client that inserted the value, and MUST have a type of either sf-string or sf-token. Depending on the deployment, this might be a product or service name (e.g., ExampleEdge or “Example CDN”), a hostname (“edge-1.example.com”), and IP address, or a generated string.
Each member of the list can also have a number of parameters that contain metrics. While all but one of these parameters are OPTIONAL, implementations are encouraged to only provide as much information as necessary.
Here is an example of a header with a single set of metrics:
Transport-Info = ExampleEdge; ts="2019-08-30T14:56:08.069Z"; alpn="h2"; send_rate="5100"
Whilst it is understood that such metrics may only provide an instantaneous view on the transport state, the Transport-Info header is designed to allow for delivery of multiple timestamped entries in a single header.
Here is an example of the header with multiple entries, utilising the structured header inner-list type:
Transport-Info = "edge-1.example.com"; ts="2019-08-30T14:56:08Z"; cwnd=24; rtt=50; mss=1452; rttvar=10; dstport=8065, "edge-1.example.com"; ts="2019-08-30T14:57:08Z"; cwnd=23; rtt=55; mss=1452; rttvar=12; dstport=8065
If the end points support HTTP/2, and later, another technique to increase temporal coverage for an ongoing session is for the client to issue additional HEAD requests for the resource at the same origin. This works with HTTP/2, and later, as all requests to the same origin usually utilise one TCP or QUIC connection. Whilst the HTTP priorities can affect the allocation of capacity between streams the header will still provide an estimate of the maximum available capacity. Likewise, in some cases with HTTP/2, and later, there may be multiple flows traversing the same transport connection to different origins if connection reuse (Section 9.1.1 of [RFC7540]) is utilised, which could have a similar effect on interpretation of the metrics to HTTP priorities, but may have privacy implications which are addressed in the privacy section Section 6.1.
The metrics may be used directly to inform entities that receive the header. The calculation of the send rate maybe performed by the sender of the header and included in the send_rate parameter, or the receiver may calculate it as described below. The decision may depend upon a variety of factors including the privacy consideration of transporting any required parameters.
In the case of TCP, calculation of the transport transmission rate is possible using the cwnd and rtt, and knowledge of the mss. The equation being as follows:
send_rate = 8 * send_window / rtt Where send_window = min (cwnd * mss, rcv_space)
If the mss is not available then it is possible to perform the calculation using an estimate of the mss, or a common value such as 1460 for IPv4. It is understood there can be some variation for different network and tunnelled paths (e.g. 1452 for IPv4 PPPoE) as can been seen in recent studies [exploring-mtu], although the large proportion of mss values fall within a range 1220-1460. The send_window is preferably calculated using a minimum of the cwnd and rcv_space, but if the rcv_space is not available it may be approximated by just using the cwnd.
This equation maybe applied for other related window based transport protocols (e.g. QUIC [I-D.ietf-quic-transport]) with similar information, although it may need some modification.
With most web server deployments an origin server sits behind some form of CDN, with varying levels of fan-out to a point where an edge server is connected on the last hop to clients. The Transport-Info header SHOULD only be inserted into an HTTP stream by the last hop edge server that is connected to clients so that it conveys information pertinent to the client’s direct transport path. The Transport-Info header MUST not be cached.
With respect to use in CORS [cors] enabled environments access to the header will be subject to restrictions in cross domain requests, which may be controlled through the inclusion of the Transport-Info header in the Access-Control-Request-Headers header.
The use of the header is expected to comply with data minimisation approaches where servers only send the necessary information on relevant flows.
RFC Editor: please remove this section before publication
The provision of the Transport-Info header is possible using a number of existing server systems that already provide support for such metrics, which currently utilise operating system support for the tcp_info data structure which is available on Linux and BSD based systems.
In terms of current implementations there is in-built support in Nginx/Openresty using its variables var.tcpinfo_rtt etc. Apache Traffic Server provides support using the TCPInfo plugin. Varnish provides access to tcp_info using their vmod_tcp module. Node.js has support through the use of a package such as tcpinfo. Whilst most of the implementations do not provide access to the TCP MSS it is available via the underlying kernel tcp_info data structure so it would be fairly straightforward to provide access to such information.
In the case where a client is configured to utilise a proxy directly, or through the use of the HTTP CONNECT pseudo-method, this proxy should be configured according to local policy as to whether it passes through, modifies, or drops the Transport-Info header. This decision can depend on a number of factors, including whether the flows are encrypted, the utility of the header given local network configuration, and also whether the header might reveal unwanted information to end clients, since the Transport-Info header would relate to the connection between the edge CDN node and the proxy.
This specification registers the following entry in the Permanent Message Header Field Names registry established by [RFC3864]:
The Transport-Info header provides information about a senders view of its network transport metrics, such as bandwidth and latency, to its receiver. This information may potentially be abused for such purposes as fingerprinting a user through their particular network metrics or a time series thereof. In some situations it might also be possible to infer location of users. This may also apply in the case where multiple users, or user identities, share a connection through the use of connection reuse mechanisms or otherwise.
Whilst such information may be available through other mechanisms we recommend that implementers minimise any potential privacy issues through the application of the following approaches:
If the header is delivered over a transport protocol whose content can be modified without detection then parties should be aware that the header could be maliciously modified to alter the metrics values which could result in the client making incorrect adaptations.
The authors would like to thank Craig Taylor, Lucas Pardue, Patrick McManus, and the IETF HTTP Working Group for feedback on the development of this document.