idnits 2.17.1 draft-ohanlon-transport-info-header-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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 mile 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. Also the Transport-Info MUST not be cached. -- The document date (November 17, 2019) is 1619 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 384 == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-header-structure-14 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-23 -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP P. O'Hanlon 3 Internet-Draft J. Gruessing 4 Intended status: Standards Track British Broadcasting Corporation 5 Expires: May 20, 2020 November 17, 2019 7 The Transport-Info Response Header 8 draft-ohanlon-transport-info-header-00 10 Abstract 12 The Transport-Info header provides a mechanism to inform a client of 13 the last-mile server's view of the network transport related 14 information such as current delivery rate and round-trip time. This 15 information has a wide range of uses such as client monitoring and 16 diagnostics, or allowing a client to adapt to current network 17 conditions. 19 Note to Readers 21 _RFC Editor: please remove this section before publication_ 23 Source code and issues for this draft can be found at 24 https://github.com/bbc/draft-ohanlon-transport-info-header [1]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 20, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 63 2. The Transport-Info Response Header . . . . . . . . . . . . . 3 64 2.1. Utilisation of Transport-Info header metrics . . . . . . 5 65 3. Server side behaviour . . . . . . . . . . . . . . . . . . . . 6 66 4. Client side proxy considerations . . . . . . . . . . . . . . 6 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 7.2. Informative References . . . . . . . . . . . . . . . . . 8 72 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 The Transport-Info header provides for relaying of transport protocol 78 related information from a last-mile edge server entity to a client 79 with the aim of informing the client of the server's view on the 80 transport state. The state of a connection is dependent upon 81 information based upon packet exchanges during the transport 82 processes. Firstly, there is information that is common to both 83 client and server, such as the calculated round-trip time (RTT), 84 although it may be measured using different packets at each end. 85 Secondly, there is state information that exists only at each 86 endpoint, such as the size of the congestion, and receive windows. 87 Thus certain transport state information is only available at the 88 server which can be useful to the client, for example, to calculate 89 the current transport rate. This information may then be used to 90 better inform a client of the state of the network path and make 91 appropriate adaptations. 93 The information can also be utilised by a client to provide for 94 application level client oriented metric logging to back-end systems 95 for monitoring and analysis purposes. Such data could be utilised in 96 a manner not unlike that proposed in [RFC4898]. 98 This approach is directly applicable to TCP but also can be utilised 99 with other related transport protocols, such as QUIC 100 [I-D.ietf-quic-transport]. 102 1.1. Motivation 104 This work is motivated in part by the fact that even in modern web 105 browsers web applications are not currently able to obtain such low 106 level information about their connections. Additionally some 107 information is only available at the server, such as the size of the 108 server congestion window. As a result clients often resort to 109 application level measurements, to infer such things as the current 110 delivery rate, but these are not always indicative of the performance 111 of the transport layer. 113 There exist W3C specifications such as the Network Information API 114 [network-info-api], which contains an attribute named "downlink" that 115 purports to provide measurement of effective bandwidth "across 116 recently active connections". However, in practice the downlink 117 measurement appears to be a very rough estimate which is of little 118 use for informing an application of dynamic network conditions. 119 Furthermore, it currently has limited browser support. 121 1.2. Notational Conventions 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 This document uses the Augmented Backus-Naur Form (ABNF) notation of 130 [RFC5234] with the list rule extension defined in [RFC7230], 131 Appendix B. It includes by reference the DIGIT rule from [RFC5234] 132 and the OWS and field-name rules from [RFC7230]. 134 2. The Transport-Info Response Header 136 The Transport-Info header uses the proposed Structured Header draft 137 [I-D.ietf-httpbis-header-structure] 139 Transport-Info = sh-list 141 Each member of the parameterised list represents an entry that 142 contains a set of metrics reported by the edge server. 144 The list members identify the server that inserted the value, and 145 MUST have a type of either sh-string or sh-token. Depending on the 146 deployment, this might be a product or service name (e.g., 147 ExampleEdge or "Example CDN"), a hostname ("edge-1.example.com"), and 148 IP address, or a generated string. 150 Each member of the list can also have a number of parameters that 151 contain metrics. While all but one of these parameters are OPTIONAL, 152 edge servers are encouraged to provide as much information as 153 possible. 155 o Exactly one parameter whose name is "ts", and whose value is an 156 sh-float indicating the measurement timestamp in seconds since 157 UNIX epoch. 158 o Optionally one parameter whose name is "alpn", and whose value is 159 an sh-string representing the ALPN protocol identifier [alpn-ids]. 160 o Optionally one parameter whose name is "cc_algo", and whose value 161 is sh-string, conveying the name of congestion control algorithm 162 used by the server for this connection. 163 o Optionally one parameter whose name is "cwnd", and whose value is 164 a sh-integer, conveying the size of the server's congestion window 165 [RFC5681] in packets. 166 o Optionally one parameter whose name is "rcv_space", and whose 167 value is a sh-integer, conveying the size of the receiver's window 168 in bytes. 169 o Optionally one parameter whose name is "dstport", and whose value 170 is a sh-integer, conveying the server's destination port of this 171 connection for correlation of measurements between requests. 172 o Optionally one parameter whose name is "mss", and whose value is a 173 sh-integer, conveying the size of the server's Maximum Segment 174 Size in bytes. 175 o Optionally one parameter whose name is "rtt", and whose value is 176 an sh-float, in milliseconds, indicating the server's estimate of 177 the Round-Trip Time from its transport layer. 178 o Optionally one parameter whose name is "rttvar", and whose value 179 is an sh-float, in milliseconds, indicating the server's estimate 180 of the variation of the Round-Trip Time [RFC6298] from its 181 transport layer. 182 o Optionally one parameter whose name is "send_rate", and whose 183 value is a sh-float, in kilobits per second, conveying the 184 server's calculation of the sending rate for this connection. 186 Here is an example of a header with a single set of metrics: 188 Transport-Info = ExampleEdge; ts=1567176968.69; alpn="h2"; cwnd=24; 189 rtt=250; mss=1460; rttvar=10; dstport=12345 191 Whilst it is understood that such metrics may only provide an 192 instantaneous view on the transport state, the Transport-Info header 193 is designed to allow for delivery of multiple timestamped entries in 194 a single header. 196 Here is an example of header with multiple entries, utilising the 197 structured header inner-list type: 199 Transport-Info = "edge-1.example.com"; ts=1567176968.69; alpn="h2"; cwnd=24; 200 rtt=250; mss=1452; rttvar=10; dstport=123451, 201 "edge-1.example.com"; ts=1567176969.97; alpn="h2"; cwnd=23; 202 rtt=255; mss=1452; rttvar=12; dstport=123451 204 If the end points support HTTP/2, and later, another technique to 205 increase temporal coverage for an ongoing session is for the client 206 to issue additional HEAD or OPTION * requests for a resource at the 207 same origin. This works with HTTP/2 and later as all requests to the 208 same origin utilise one TCP or QUIC connection. Whilst the HTTP 209 priorities can affect the allocation of capacity between streams, one 210 use-case for the Transport-Info header is for information regarding 211 sustained flows, such as media delivery, which tend consist of a 212 known limited number of flows to the same origin so the priorities 213 would not affect the calculations. 215 2.1. Utilisation of Transport-Info header metrics 217 In the case of TCP, calculation of the transport transmission rate is 218 possible using the cwnd and rtt, and knowledge of the mss. The 219 equation being as follows: 221 send_rate = 8 * send_window / rtt 223 Where send_window = min (cwnd * mss, rcv_space) 225 If the mss is not available then it is possible to perform the 226 calculation using an estimate of the mss, or a common value such as 227 1460 for IPv4. It understood there can be some variation for 228 different network and tunnelled paths (e.g. 1452 for IPv4 PPPoE) as 229 can been seen in recent studies [exploring-mtu], although the large 230 proportion of mss values fall within a range 1220-1460. The 231 send_window is preferably calculated using a minimum of the cwnd and 232 rcv_space, but if the rcv_space is not available it may be 233 approximated by just using the cwnd. 235 This equation maybe applied for other related window based transport 236 protocols (e.g. QUIC [I-D.ietf-quic-transport]) with similar 237 information, although it may need some modification. 239 The calculation of the send rate maybe performed at the server, or 240 may be left to the client to calculate as and when required. 242 3. Server side behaviour 244 With most web server deployments an origin server sits behind some 245 form of CDN, with varying levels of fan-out to a point where an edge 246 server is connected on the last mile to clients. The Transport-Info 247 header SHOULD only be inserted into an HTTP stream by the last hop 248 edge server that is connected to clients so that it conveys 249 information pertinent to the client's direct transport path. Also 250 the Transport-Info MUST not be cached. 252 _RFC Editor: please remove this section before publication_ 254 The provision of the Transport-Info header is possible using a number 255 of existing server systems that already provide support for such 256 metrics, which currently utilise operating system support for 257 tcp_info data structure which are available on Linux and BSD systems. 259 In terms of current implementations there is in-built support in 260 Nginx/Openresty using its variables "var.tcpinfo_rtt" etc. Apache 261 Traffic Server provides support using the TCPInfo plugin. Varnish 262 provides access to "tcp_info" using their "vmod_tcp" module. Node.js 263 has libraries such as "nodejs_tcpinfo" which provide support. Whilst 264 most of the implementations do not provide access to the TCP MSS it 265 is available via the underlying kernel tcp_info data structure so it 266 would be fairly straightforward to provide access to such 267 information. 269 4. Client side proxy considerations 271 In the case where a proxy services client requests, this proxy would 272 be configured according to local policy as to whether it passes 273 through, modifies or drops the Transport-Info header. This decision 274 can depend on a number of factors, including the utility of the 275 header given local network configuration, and also whether the header 276 might reveal unwanted information to end clients, since the 277 Transport-Info header would relate to the connection between the edge 278 CDN node and the proxy. 280 5. IANA Considerations 282 This specification registers the following entry in the Permanent 283 Message Header Field Names registry established by [RFC3864]: 285 o Header field name: Transport-Info 286 o Applicable protocol: http 288 o Status: standard 290 o Author/Change Controller: IETF 292 o Specification document(s): [this document] 294 o Related information: 296 6. Security Considerations 298 The content of the Transport-Info is largely available through other 299 techniques such as packet capture so it should not lead to security 300 issues. Certain metrics, such as the cwnd, may be considered as less 301 visible but since they are part of the transport layer they can 302 inferred. Any metrics that may be considered private should not be 303 sent in the header, or sent only over an encrypted connection. 305 In the case where clients are connected via a proxy then 306 organisations may wish modify or drop the header if they consider the 307 it might reveal unwanted information to end clients. 309 If the header is delivered over a transport protocol whose content 310 can be modified without detection then parties should be aware that 311 the header could be maliciously modified to alter the metrics values 312 which could result in the client making incorrect adaptations. 314 7. References 316 7.1. Normative References 318 [I-D.ietf-httpbis-header-structure] 319 Nottingham, M. and P. Kamp, "Structured Headers for HTTP", 320 draft-ietf-httpbis-header-structure-14 (work in progress), 321 October 2019. 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, 325 DOI 10.17487/RFC2119, March 1997, 326 . 328 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 329 Procedures for Message Header Fields", BCP 90, RFC 3864, 330 DOI 10.17487/RFC3864, September 2004, 331 . 333 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 334 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 335 . 337 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 338 "Computing TCP's Retransmission Timer", RFC 6298, 339 DOI 10.17487/RFC6298, June 2011, 340 . 342 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 343 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 344 May 2017, . 346 7.2. Informative References 348 [alpn-ids] 349 "Application-Layer Protocol Negotiation (ALPN) Protocol 350 ID", IANA , n.d., . 353 [exploring-mtu] 354 Custura, A., Fairhurst, G., and I. Learmonth, "Exploring 355 usable Path MTU in the Internet", Network Traffic 356 Measurement and Analysis Conference , April 2018, 357 . 359 [I-D.ietf-quic-transport] 360 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 361 and Secure Transport", draft-ietf-quic-transport-23 (work 362 in progress), September 2019. 364 [network-info-api] 365 Grigorik, I., "Network Information API", W3C , September 366 2019, . 368 [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP 369 Extended Statistics MIB", RFC 4898, DOI 10.17487/RFC4898, 370 May 2007, . 372 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 373 Specifications: ABNF", STD 68, RFC 5234, 374 DOI 10.17487/RFC5234, January 2008, 375 . 377 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 378 Protocol (HTTP/1.1): Message Syntax and Routing", 379 RFC 7230, DOI 10.17487/RFC7230, June 2014, 380 . 382 7.3. URIs 384 [1] https://github.com/bbc/draft-ohanlon-transport-info-header 386 Authors' Addresses 388 Piers O'Hanlon 389 British Broadcasting Corporation 391 Email: piers.ohanlon@bbc.co.uk 393 James Gruessing 394 British Broadcasting Corporation 396 Email: james.gruessing@bbc.co.uk