idnits 2.17.1 draft-fairhurst-tsvwg-transport-encrypt-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 02, 2017) is 2513 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1333, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-aqm-codel' is defined on line 1345, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ippm-6man-pdm-option' is defined on line 1361, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tcpm-accurate-ecn' is defined on line 1372, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 1448, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-aqm-codel-00 == Outdated reference: A later version (-06) exists of draft-ietf-aqm-fq-codel-00 == Outdated reference: A later version (-10) exists of draft-ietf-aqm-pie-00 == Outdated reference: A later version (-13) exists of draft-ietf-ippm-6man-pdm-option-10 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-03 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-00 == Outdated reference: A later version (-10) exists of draft-ietf-tcpm-dctcp-06 == Outdated reference: A later version (-20) exists of draft-ietf-tsvwg-l4s-arch-00 == Outdated reference: A later version (-25) exists of draft-mm-wg-effect-encrypt-11 == Outdated reference: A later version (-04) exists of draft-trammell-plus-statefulness-02 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 17 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG G. Fairhurst 3 Internet-Draft University of Aberdeen 4 Intended status: Informational June 02, 2017 5 Expires: December 02, 2017 7 The Impact of Transport Header Encryption on Operation and Evolution of 8 the Internet 9 draft-fairhurst-tsvwg-transport-encrypt-01 11 Abstract 13 This document describes the implications of applying end-to-end 14 encryption at the transport layer. It identifies some in-network 15 uses of transport layer header information that can be used with 16 transport header authentication,. It reviews the implication of 17 developing encrypted end-to-end transport protocols and examines the 18 implication of developing and deploying encrypted end-to-end 19 transport protocols. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 02, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Internet Transports and Pervasive Encryption . . . . . . . . . 4 56 2.1. Authenticating the Transport Protocol Header . . . . . . . 5 57 2.2. Encrypting the Transport Payload . . . . . . . . . . . . . 6 58 2.3. Encrypting the Transport Header . . . . . . . . . . . . . 6 59 2.4. Authenticating Transport Information and Selectively 60 Encrypting the Transport Header . . . . . . . . . . . . . 6 61 2.5. Adding transport information to network-layer Protocol 62 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3. Use of Transport Headers in the Network . . . . . . . . . . . 7 64 3.1. Use to Identify Flows and Packet Formats . . . . . . . . . 9 65 3.2. Measurements derived from Transport Header Information . . 9 66 3.2.1. Use to Characterise Traffic Rate and Volume . . . . . 9 67 3.2.2. Use of the Network-Layer DSCP . . . . . . . . . . . . 10 68 3.2.3. Measuring Loss Rate and Loss Pattern . . . . . . . . . 10 69 3.2.4. Measuring Throughput and Goodput . . . . . . . . . . . 10 70 3.2.5. Measuring Latency (Network Transit Delay and Jitter) . 10 71 3.2.6. Measuring Flow Reordering . . . . . . . . . . . . . . 12 72 3.3. Measurements derived from Network-Transport Information . 12 73 3.3.1. Use of IPv6 Network-Layer Flow Label . . . . . . . . . 12 74 3.3.2. Use Network-Layer Differentiated Services Code Point 75 Point (DSCP) . . . . . . . . . . . . . . . . . . . . . 12 76 3.3.3. Use of Explicit Congestion Marking . . . . . . . . . . 13 77 4. Transport Measurement . . . . . . . . . . . . . . . . . . . . 13 78 4.1. Point of Measurement . . . . . . . . . . . . . . . . . . . 14 79 4.2. Use by Operators to Plan and Provision Networks . . . . . 14 80 4.3. Service Performance Measurement . . . . . . . . . . . . . 15 81 4.4. Use for Network Diagnostics and Troubleshooting . . . . . 15 82 4.5. Acceptable Response to Congestion . . . . . . . . . . . . 16 83 4.5.1. Measuring Compliance of UDP Traffic . . . . . . . . . 16 84 4.5.2. Measuring Transport to Support Network Operations . . 17 85 5. Observing Transport Flows with Encrypted Transport Header Fiel 17 86 5.1. Transport Information at the Network Layer . . . . . . . . 17 87 5.2. An Observable Transport Flow Identifier . . . . . . . . . 17 88 5.2.1. A Method to Determine Header Format . . . . . . . . . 17 89 5.2.2. Use of a Transport as a Substrate . . . . . . . . . . 18 90 5.2.3. Support for Mobility and Flow Migration . . . . . . . 18 91 5.2.4. Flow Start and Stop . . . . . . . . . . . . . . . . . 18 92 5.3. Observable Transport Sequence Number . . . . . . . . . . . 19 93 5.4. Observable Transport Reception . . . . . . . . . . . . . . 19 94 5.5. Observable Transport Timestamps . . . . . . . . . . . . . 20 95 5.6. Observable ECN Transport Feedback Information . . . . . . 20 96 5.7. Other Observable Transport Fields . . . . . . . . . . . . 21 97 5.8. Interpretation of Transport Header Fields . . . . . . . . 21 98 5.9. Requirements for Transport Measurement . . . . . . . . . . 21 99 6. The Effect of Encrypting Transport Header Fields . . . . . . . 22 100 6.1. Independent Measurement . . . . . . . . . . . . . . . . . 22 101 6.2. Characterising "Unknown" Network Traffic . . . . . . . . . 23 102 6.3. Accountability and Internet Transport Portocols . . . . . 23 103 7. Implications on Evolution of the Internet Transport . . . . . 24 104 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 106 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 108 11.1. Normative References . . . . . . . . . . . . . . . . . . 28 109 11.2. Informative References . . . . . . . . . . . . . . . . . 28 110 Appendix A. Revision information . . . . . . . . . . . . . . . . . 32 111 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 113 1. Introduction 115 This document discusses the implications of end-to-end encryption 116 applied at the transport layer, and examines the impact on transport 117 protocol design, transport use, and network operations and 118 management. It also considers some anticipated implications on 119 transport and application evolution. 121 The transport layer is the first end-to-end layer in the network 122 stack. Despite headers having end-to-end meaning, some transport 123 headers have come to be used in various ways within the Internet. In 124 response to pervasive monitoring [RFC7624] revelations and the IETF 125 consensus that "Pervasive Monitoring is an Attack" [RFC7258], efforts 126 are underway to increase encryption of Internet traffic, which would 127 prevent visibility of transport headers. This have implications on 128 how network protocols are designed and used (e.g., [I-D.mm-wg-effect- 129 encrypt]). 131 Transport information that is sent without end-to-end authentication 132 could be modified by "middleboxes" - defined as any intermediary box 133 performing functions apart from normal, standard functions of an IP 134 router on the data path between a source host and destination host 135 [RFC3234]. When transport headers are modified by network devices on 136 the path, this can change the end-to-end protocol transport protocol 137 behaviour in a way that may have benefits (e.g., to user performance/ 138 cost) or may hinder (e.g., disrupting application experience). 139 Whatever the outcome, modification of packets by a middlebox was not 140 usually intended when the protocol was specified and is usually not 141 known by the sending or receiving endpoints. 143 Middleboxes have been deployed for a variety of reasons [RFC3234], 144 including protocol enhancement, proxies such as Protocol Enhancing 145 Proxies (PEPs) [RFC3135], TCP acknowledgement (ACK) enhancement 146 [RFC3449], use by application protocol caches [I-D.mm-wg-effect- 147 encrypt], application layer gateways [I-D.mm-wg-effect-encrypt], etc. 148 [I-D.dolson-plus-middlebox-benefits] summarizes some of the functions 149 provided by such middleboxes, and benefits that may arise when used 150 in a specific deployment scenarios. Such methods, which involve in- 151 network modification of transport headers, are not further discussed. 153 Transport protocols can be designed to encrypt or authenticate 154 transport header fields. Authentication methods at the transport 155 layer can detect any changes to an immutable header field that were 156 made by a network device along a path. These methods do not require 157 encryption of the header fields, and hence authenticated fields may 158 remain visible to network devices. A receiving transport endpoint 159 can use authentication to avoid accepting modified protocol headers. 160 This document therefore considers the case where transport header 161 fields are not altered as a packet traverses the network path. 163 Authentication methods have also been specified at the network layer, 164 and this also protects transport header fields. The network layer 165 itself can carry header fields that are increasingly being used to 166 help forwarding decisions reflect the need of transport protocols, 167 such the IPv6 Flow Label [RFC6437], the Differentiated Services Code 168 Point (DSCP) [RFC2474] and Explicit Congestion Notification (ECN) 169 [RFC3168]. 171 Encryption methods can hide information from an eavesdropper in the 172 network. Encryption can also help protect the privacy of a user, by 173 hiding data relating to user/device identity or location. Neither 174 authentication nor encryption methods prevent traffic analysis, and 175 usage needs to reflect that profiling of users and fingerprinting of 176 behaviour can take place even on encrypted traffic flows. 178 This document seeks to identify the implications of various 179 approaches to transport protocol authentication and encryption. 181 2. Internet Transports and Pervasive Encryption 183 End-to-end encryption can be applied at various protocol layers. It 184 can be applied above the transport to encrypt the transport payload. 185 One motive to use encryption is a response to perceptions that the 186 network has become ossified by over-reliance on middleboxes that 187 prevent new protocols and mechanisms from being deployed. This has 188 lead to a common perception that there is too much "manipulation" of 189 protocol headers within the network, and that designing to deploy in 190 such networks is preventing transport evolution. In the light of 191 this, a method that authenticates transport headers may help improve 192 the pace of transport development, by eliminating the need to always 193 consider deployed middleboxes [I-D.trammell-plus-abstract-mech], or 194 potentially to only explicitly enable middlebox use for particular 195 paths with particular middleboxes [RFC3135]. 197 Another perspective stems from increased concerns about privacy and 198 surveillance . Some Internet users have valued the ability to protect 199 identity and defend against traffic analysis, and have used methods 200 such as IPsec ESP and Tor [Tor]. Revelations about the use of 201 pervasive surveillance [RFC7624] have, to some extent, eroded trust 202 in the service offered by network operators, and following the 203 Snowden revelation in the USA in 2013 has led to an increased desire 204 for people to employ encryption to avoid unwanted "eavesdropping" on 205 their communications. Whatever the reasons, there are now activities 206 in the IETF to design new protocols that may include some form of 207 transport header encryption (e.g., QUIC [I-D.ietf-quic-transport]). 209 The use of transport layer authentication and encryption exposes a 210 tussle between middlebox vendors, operators, applications developers 211 and users. 213 o On the one hand, future Internet protocols that enable large-scale 214 encryption assist in the restoration of the end-to-end nature of 215 the Internet by returning complex processing to the endpoints, 216 since middleboxes cannot modify what they cannot see. 217 o On the other hand, encryption of transport layer header 218 information has implications to people responsible for operating 219 networks and researchers and analysts seeking to understand the 220 dynamics of protocols and traffic patterns. 222 Whatever the motives, a decision to use pervasive of transport header 223 encryption will have implications on the way in which design and 224 evaluation is performed, and which can in turn impact the direction 225 of evolution of the TCP/IP stack. 227 The next subsections briefly review some security design options for 228 transport protocols. 230 2.1. Authenticating the Transport Protocol Header 232 Transport layer header information can be authenticated. An 233 authentication method protects the integrity of immutable transport 234 header fields, but can still expose the transport protocol header 235 information in the clear, allowing in-network devices to observes 236 these fields. Authentication can not prevent in-network 237 modification, but can avoid accepting changes and avoid impact on the 238 transport protocol operation. 240 An example transport authentication mechanism is TCP-Authentication 241 (TCP-AO) [RFC5925]. This TCP option authenticates TCP segments, 242 including the IP pseudo header, TCP header, and TCP data. TCP-AO 243 protects the transport layer, preventing attacks from disabling the 244 TCP connection itself. TCP-AO may interact with middleboxes, 245 depending on their behavior [RFC3234]. 247 The IPSec Authentication Header (AH) [RFC4302] works at the network 248 layer and authenticates the IP payload. This therefore also 249 authenticates all transport headers, and verifies their integrity at 250 the receiver, preventing in-network modification. 252 2.2. Encrypting the Transport Payload 254 The transport layer payload can be encrypted to protect the content 255 of transport segments. This leaves transport protocol header 256 information in the clear. The integrity of immutable transport 257 header fields could be protected by combining this with 258 authentication methods (Section 2.1). 260 Examples of encrypting the payload include Transport Layer Security 261 (TLS) over TCP [RFC5246] [RFC7525] or Datagram TLS (DTLS) over UDP 262 [RFC6347] [RFC7525]. 264 2.3. Encrypting the Transport Header 266 The network layer payload could be encrypted (including the entire 267 transport header and payload). This method does not expose any 268 transport information to devices in the network, which also prevents 269 modification along the network path. 271 The IPSec Encapsulating Security Payload (ESP) [RFC4303] is an 272 example of encryption at the network layer, it encrypts and 273 authenticates all transport headers, preventing visibility of the 274 headers by in-network devices. Some Virtual Private Network (VPN) 275 methods also encrypt these headers. 277 2.4. Authenticating Transport Information and Selectively Encrypting 278 the Transport Header 280 A transport protocol design can encrypt selected header fields, while 281 also choosing to authenticate some or all of other fields in the 282 transport header. This allows only specific transport header fields 283 to be observable by network devices. End-to end authentication can 284 prevent an endpoint from undetected modification of the immutable 285 transport headers. 287 The choice of which fields to expose and which to encrypt is a design 288 choice for the transport protocol. Any selective encryption method 289 requires trading two conflicting goals for a transport protocol 290 designer to decide which header fields to encrypt. On the one hand, 291 security work typically employs a design technique that seeks to 292 expose only what is needed. On the other hand, there may be 293 performance and operational benefits in exposing selected information 294 to network tools. 296 Mutable fields in the transport header provide opportunities for 297 middleboxes to modify the transport behaviour (e.g., the extended 298 headers described in [I-D.trammell-plus-abstract-mech]). This 299 considers only immutable fields in the transport headers, that is, 300 fields that may be authenticated end-to-end across a path. 302 An example of a method that encrypts some, but not all, transport 303 information is UDP-in-GRE [RFC8086] when used with GRE encryption. 305 2.5. Adding transport information to network-layer Protocol Headers 307 The transport information can be made visible in a network-layer 308 header. This has the advantage that this information can then be 309 observed by in-network devices. This has the advantage that a single 310 header can support all transport protocols, but there may also be 311 less desirable implications of separating the operation of the 312 transport protocol from the measurement framework. 314 Some measurements may be made by adding additional packet headers 315 carrying operations, administration and management (OAM) information 316 to packets at the ingress to a maintenance domain (e.g., adding an 317 Ethernet protocol header with timestamps and sequence number 318 information using a method such as 802.11ag) and removing the 319 additional header at the egress of the maintenance domain. This 320 approach enables some types of measurements, but does not cover the 321 entire range of measurements described in this document. 323 Another example of a network-layer approach is the IPv6 Performance 324 and Diagnostic Metrics (PDM) Destination Option [I-D.ietf-ippm-6man- 325 pdm-option]. This allows a sender to optionally include a 326 destination option that caries header fields that can be used to 327 observe timestamps and packet sequence numbers. Transmission of the 328 packets with this option can be impacted by destination-options 329 processing by network devices. This information could be 330 authenticated by receiving transport endpoints when the information 331 is added at the sender and visible at the receiving endpoint, 332 although methods to do this have not currently been proposed. This 333 method needs to be explicitly enabled at the sender. 335 A drawback of using extension headers is that IPv4 network options 336 are often not supported (or are carried on a slower processing path) 337 and some IPv6 networks are also known to drop packets that set an 338 IPv6 header extension. Another disadvantage is that protocols that 339 separately expose header information do not necessarily have an 340 advantage to expose the information that is utilised by the protocol 341 itself, and could manipulate this header information to gain an 342 advantage from the network. 344 3. Use of Transport Headers in the Network 345 This section identifies ways that observable (non-encrypted) 346 transport header fields can be used by devices in the network. There 347 are a number of actors who can benefit from observing this 348 information. The list of actors who perform measurements include: 350 o Protocol developers and implementors of TCP/IP stacks; 351 o Researchers working on new mechanisms or new applications of 352 existing applications; 353 o Analysis researching the impact of mechanisms on network equipment 354 or specific network topologies; 355 o Staff supporting operation of a network. 357 One approach is to use active measurement using dedicated tools to 358 generate and measure test traffic. To test a transport path, such 359 tools need to be run from an endpoint, and most operators do not have 360 access to user equipment. There may also be costs associated with 361 running such tests. (e.g., the implications of bandwidth tests in a 362 mobile network are obvious.) Some tests (e.g. Response under load or 363 particular workloads) may perturb other traffic, and could require 364 dedicated access to the network segment. An alternative approach is 365 to use in-network techniques that observe transport packet headers in 366 operational networks to make the measurements. 368 Transport layer information can help identify whether the link/ 369 network tuning is effective and alert to potential problems that can 370 be hard to derive from link or device measurements alone. The design 371 trade offs for radio networks are often very different to those of 372 wired networks. A radio-based network (e.g., cellular mobile, 373 enterprise WiFi, satellite access/backhaul, point-to-point radio) has 374 the complexity of a subsystem that performs radio resource management 375 - with direct impact on the available capacity, and potentially loss/ 376 reordering of packets. The impact of the pattern of loss and 377 congestion, differs for different traffic types, correlation with 378 propagation and interference can all have significant impact on the 379 cost and performance of a provided service. The need for this type 380 of information is expected to increase as operators bring together 381 heterogeneous types of network equipment and seek to deploy 382 opportunistic methods to access radio spectrum. 384 In-network observation of transport protocol headers requires 385 knowledge of the format of the transport header: 387 o Flows, identified at the level required for monitoring. In IETF 388 transports, this is typically identified at the IP level by the 389 IPv4 protocol field or IPv6 next header field and at the transport 390 layer by the ports field (or other information); 391 o The protocol and version of the header that is being used. As 392 protocols evolve over time and there may be a need to introduce 393 new transport headers. This may require interpretation of 394 protocol version information or connection setup information; 395 o The position and syntax of any transport headers that need to be 396 observed. IETF transport protocols specify this information. 398 The following subsections describe various ways that observable 399 transport information may be utilised. 401 3.1. Use to Identify Flows and Packet Formats 403 Transport protocol header information can identify a flow and the 404 connection state of the flow, together with the protocol options 405 being used. In some usages, a low-numbered (well-known ) port that 406 can identify a protocol (although port information alone is not 407 sufficient to guarantee identification of a protocol). Transport 408 protocols, such as TCP and SCTP specify a standard base header that 409 includes sequence number information and other data, with the 410 possibility to negotiate additional headers at connection setup and 411 identified by an option number in the transport header. UDP-based 412 protocols sometimes do not use well-known ports but also can instead 413 be identified by signalling protocols or through the use of magic 414 numbers placed in the first byte(s) of the datagram payload. 416 3.2. Measurements derived from Transport Header Information 418 Various actors have a need to characterise the performance of link/ 419 network segments. Passive monitoring uses observed traffic to makes 420 inferences from transport headers to derive measurements. A variety 421 of open source and commercial tools can utilise this information. 422 Transport fields in the Real Time Protocol (RTP) header[RFC3550] 423 [RFC4585] can be observed to derive traffic volume measurements and 424 provide information on the progress and quality of a session using 425 RTP. Key performance indicators are retransmission rate, packet drop 426 rate, sector utilization level, a measure of reordering, peak rate, 427 the CE-marking rate, etc. Metadata is often important to understand 428 the context under which the data was collected, including the time, 429 observation point, and way in which metrics were accumulated. 431 Some Internet transports report summary performance data to the 432 network (e.g., RTCP feedback[RFC3550]). A user of summary measurement 433 data needs to trust the source of this data and the method used to 434 generate the summary information. 436 When encryption conceals information in packet headers, measurements 437 need to rely on pattern inferences and other heuristics grows, and 438 accuracy suffers [I-D.mm-wg-effect-encrypt]. 440 3.2.1. Use to Characterise Traffic Rate and Volume 442 Transport headers may be observed to derive volume measures per- 443 application, to characterise the traffic using a network segment and 444 pattern of network usage. This may be measured per endpoint or 445 aggregate of endpoint (e.g., by an operator to assess subscriber 446 usage). This can also be used to trigger measurement-based traffic 447 shaping and to implement QoS support within the network and lower 448 layers. Volume measures can be valuable for capacity planning 449 (providing detail of trends rather than the volume per subscriber). 451 3.2.2. Use of the Network-Layer DSCP 453 Applications and transports can expose their delivery expectations to 454 the network. The Differentiated Services Code Point (DSCP) field of 455 IPv4 and IPv6 packets allows endpoints to provide explicit 456 information that can be used in place of inferring traffic 457 requirements (e.g., instead of using a multi-field classifier to 458 infer QoS requirements from port information). 460 3.2.3. Measuring Loss Rate and Loss Pattern 462 Flow loss rate is often used as a metric for performance assessment 463 and to characterise the transport behaviour. There are various cause 464 of loss, including: corruption on a link (e.g., interference on a 465 radio link), buffer overflow (e.g., due to congestion), policing 466 (traffic management), buffer management (e.g. Active Queue 467 Management (AQM). Loss can be monitored at the interface level by 468 devices in the network. It is often important to understand the 469 conditions under which packet loss occurs, which usually means 470 relating loss to the traffic flowing on the network segment at the 471 time of loss. Understanding flow loss rate requires either 472 maintaining per flow packet counters or by observing sequence numbers 473 in transport headers. 475 Observation of transport feedback information (observing loss 476 reports, e.g. RTCP, TCP SACK) can also increase understanding of the 477 impact of loss and help identify cases where loss may have been 478 wrongly identified, or the transport did not require the lost packet. 479 It is sometimes more important to understand the pattern of loss, 480 than the loss rate - since losses can often occur as bursts, rather 481 than randomly timed events. Understanding the root cause of loss can 482 help an operator determine whether this requires corrective action. 484 3.2.4. Measuring Throughput and Goodput 486 The throughput observed by a flow can be determined even when a flow 487 is encrypted, providing the individual flow can be identified. 488 Goodput [RFC7928] is a measure of useful data exchanged (the ratio of 489 useful/total volume of traffic sent by a flow), which requires 490 ability to differentiate loss and retransmission of packets (e.g., by 491 observing packet sequence numbers in TCP or RTP). 493 3.2.5. Measuring Latency (Network Transit Delay and Jitter) 494 Latency is a key performance metric that impacts application response 495 time and user-perceived response time. It also often indirectly 496 impacts throughput and flow completion time. Latency determines the 497 reaction time of the transport protocol itself, impacting flow setup, 498 congestion control, loss recovery, and other transport mechanisms. 499 The observed latency can have many components [Latency]. Of these, 500 unnecessary/unwanted queuing in network buffers has often been 501 observed as a significant factor. Once the cause of unwanted latency 502 has been identified, this can often be eliminated, and determining 503 latency metrics is a key driver in the deployment of AQM [RFC7567], 504 DiffServ [RFC2474], and ECN [RFC3168] [RFC8087]. 506 To measure latency across a part of the path, an observation point 507 can measure the experienced round trip time (RTT) using packet 508 sequence numbers, and acknowledgements, or by observing header 509 timestamp information. Such information allows an observation point 510 in the network to determine not only the path RTT, but also to 511 measure the upstream and downstream contribution to the RTT. This may 512 be used to locate a source of latency, e.g., by observing cases where 513 the ratio of median to minimum RTT is large for a part of a path. 515 An example usage of this method could be to identify excessive 516 buffers and to deploy or configure Active Queue Management (AQM) 517 [RFC7567] [RFC7928]. Operators deploying such tools can effectively 518 eliminate unnecessary queuing in routers and other devices. AQM 519 methods need to be deployed at the capacity bottleneck, but are often 520 deployed in combination with other techniques, such as scheduling 521 [RFC7567] [I-D.ietf-aqm-fq-codel] and although parameter-less methods 522 are desired [RFC7567], current methods [I-D.ietf-aqm-fq-codel] [I-D 523 .ietf-aqm-codel] [I-D.ietf-aqm-pie] often cannot scale across all 524 possible deployment scenarios. The service offered by operators can 525 therefore benefit from latency information to understand the impact 526 of deployment and tune deployed services. 528 Some network applications are sensitive to packet jitter, and it can 529 be necessary to measure the jitter observed along a portion of the 530 path. The requirements to measure jitter resemble those for the 531 measurement of latency. 533 3.2.6. Measuring Flow Reordering 535 Significant flow reordering can impact time-critical applications and 536 can be interpreted as loss by reliable transports. Many transport 537 protocol techniques are impacted by reordering (e.g., triggering TCP 538 retransmission, or rebuffering of real-time applications). Packet 539 reordering can occur for many reasons (from equipment design to 540 misconfiguration of forwarding rules). 542 As in the drive to reduce network latency, there is a need for 543 operational tools to be able to detect misordered packet flows and 544 quantify the degree or reordering. Techniques for measuring 545 reordering typically observe packet sequence numbers. Metrics have 546 been defined that evaluate whether a network has maintained packet 547 order on a packet-by-packet basis [RFC4737] and [RFC5236]. 549 There has been initiatives in the IETF transport area to reduce the 550 impact of reordering withing a transport flow, possibly leading to 551 reduced the requirements for ordering. These have promise to 552 simplify network equipment design as well as the potential to improve 553 robustness of the transport service. Measurements of reordering can 554 help understand the level of reordering within deployed 555 infrastructure, and inform decisions about how to progress such 556 mechanisms. 558 3.3. Measurements derived from Network-Transport Information 560 This section describes transport information that is already 561 observable in network-layer header fields. 563 3.3.1. Use of IPv6 Network-Layer Flow Label 565 Endpoints should expose flow information in the IPv6 Flow Label field 566 of the network-layer header (e..g. [RFC8085]). This can be used to 567 inform network-layer queuing, forwarding (e.g., for equal cost multi- 568 path (ECMP) routing, and Link Aggregation (LAG)). This can provide 569 useful information to assign packets to flows in the data collected 570 by measurement campaigns. Although important to characterising a 571 path, it does not directly provide any performance data. 573 3.3.2. Use Network-Layer Differentiated Services Code Point Point 574 (DSCP) 576 Application should expose their delivery expectations to the network, 577 by setting the Differentiated Services Code Point (DSCP) field of 578 IPv4 and IPv6 packets. This can be used to inform network-layer 579 queuing and forwarding, and can also provide information on the 580 relative importance of packet information collected by measurement 581 campaigns, but does not directly provide any performance data. 583 This field provides explicit information that can be used in place of 584 inferring traffic requirements (e.g., by inferring QoS requirements 585 from port information via a multi-field classifier). The DSCP value 586 can therefore impact the quality of experience for a flow. 587 Observations of service performance need to consider this field when 588 a network path has support for differentiated service treatment. 590 3.3.3. Use of Explicit Congestion Marking 592 Explicit Congestion Notification (ECN)[RFC3168] uses a codepoint in 593 the network-layer header. This exposes the presence of congestion on 594 a network path to the transport and network layer. Use of ECN can 595 offer gains in terms of increased throughput, reduced delay, and 596 other benefits when used over a path that includes equipment that 597 supports an AQM method that performs Congestion Experienced (CE) 598 marking of IP packets [RFC8087]. 600 ECN CE-marks are visible to in-network devices on the transport path. 601 The reception of CE-marked packets can therefore be used to monitor 602 the presence and estimate the level of incipient congestion on the 603 upstream portion of the path from the point of observation (Section 604 2.5 of [RFC8087]). Because ECN marks carried in the IP protocol 605 header, measuring ECN can be much easier than metering packet loss. 606 However, interpreting the marking behaviour (i.e., assessing 607 congestion and diagnosing faults) requires context from the transport 608 layer (path RTT, visibility of loss - that could be due to queue 609 overflow, congestion response, etc) [RFC7567]. 611 Some ECN-capable network devices can provide richer (more frequent 612 and fine-grained) indication of their congestion state. Setting 613 congestion marks proportional to the level of congestion (e.g., DCTP 614 [I-D.ietf-tcpm-dctcp], and L4S [I-D.ietf-tsvwg-l4s-arch]). 616 AQM and ECN offer a range of algorithms and configuration options, it 617 is therefore important for tools to be available to network operators 618 and researchers to understand the implication of configuration 619 choices and transport behaviour as use of ECN increases and new 620 methods emerge [RFC7567] [RFC8087]. ECN-monitoring is expected to 621 become important as AQM is deployed that supports ECN [RFC8087] 623 Section 5.6 describes the transport layer feedback information that 624 accompanies the use of ECN. 626 4. Transport Measurement 627 The common language between network operators and application/content 628 providers/users is packet transfer performance at a layer that all 629 can view and analyze. For most packets, this has been transport 630 layer, until the emergence of QUIC, with the obvious exception of 631 VPNs and IPsec. When encryption conceals more layers in a packet, 632 people seeking understanding of the network operation need to rely 633 more on pattern inferences and other heuristics. The accuracy of 634 measurements therefore suffers, as does the ability to investigate 635 and troubleshoot interactions between different anomalies. For 636 example, the traffic patterns between server and browser are 637 dependent on browser supplier and version, even when the sessions use 638 the same server application (e.g., web e-mail access). Even when 639 measurement datasets are made available (e.g., from endpoints) 640 additional metadata, such as the state of the network, is often 641 required to interpret the data. Collecting and coordinating such 642 metadata is more difficult when the observation point is at a 643 different location to the bottleneck/device under evaluation. 645 Packet sampling techniques can be used to scale processing involved 646 in observing packets on high rate links. This only exports the 647 packet header information of (randomly) selected packets. The 648 utility of these measurements depends on the type of bearer and 649 number of mechanisms used by network devices. Simple routers are 650 relatively easy to manage, a device with more complexity demands 651 understanding of the choice of many system parameters. This level of 652 complexity exists when several network methods are combined. 654 This section discusses topics concerning transport measurement. 656 4.1. Point of Measurement 658 Often measurements can only be understood in the context of the other 659 flows that share a bottleneck. A simple example is the monitoring of 660 AQM. For example, FQ-CODEL [I-D.ietf-aqm-fq-codel], combines sub 661 queues (statistically assigned per flow), management of the queue 662 length (CODEL), flow-scheduling, and a starvation prevention 663 mechanism. Usually such algorithms are designed to be self-tuning, 664 but current methods typically employ heuristics that can result in 665 more loss under certain path conditions (e.g., large RTT, effects of 666 multiple bottlenecks [RFC7567]). 668 In-network measurements that can distinguish between upstream and 669 downstream metrics with respect to the measurement point. They are 670 particularly useful to locating the source of problems or to asses 671 the performance of a network segment and or particular device 672 configuration. 674 4.2. Use by Operators to Plan and Provision Networks 675 Traffic measurements (e.g. Traffic volume, loss, latency) is used by 676 operators to help plan deployment of new equipment and configurations 677 in their networks. Data is also important to equipment vendors who 678 need to understand traffic trends traffic and patterns of usage as 679 inputs to decisions about planning products and provisioning for new 680 deployments. This measurement information can also be correlated 681 with billing information when this is also collected by an operator. 683 A network operator supporting traffic that uses transport header 684 encryption may not have access to per-flow measurement data. Trends 685 in aggregate traffic can be observed and can be related this to the 686 endpoint addresses being used, but it may not be possible to 687 correlate patterns in measurements with changes in transport 688 protocols (e.g., the impact of changes in introducing a new transport 689 protocol mechanism). This increases the dependency on other indirect 690 sources of information to inform planning and provisioning. 692 4.3. Service Performance Measurement 694 Traffic measurements (e.g., traffic volume, loss, latency) can be 695 used by various actors to help understand the performance available 696 to users of a network segment. While active measurements may be used 697 in-network passive measurements can have advantages in terms of 698 eliminating unproductive traffic, reducing the influence of test 699 traffic on the overall traffic mix, and the ability to choose the 700 point of measurement Section 4.1. 702 4.4. Use for Network Diagnostics and Troubleshooting 704 Transport header information is useful for a variety of operational 705 tasks [I-D.mm-wg-effect-encrypt]: to diagnose network problems, 706 assess performance, capacity planning, management of denial of 707 service threats, and responding to user performance questions. These 708 tasks seldom involve the need to determine the contents of the 709 transport payload, or other application details. 711 A network operator supporting traffic that uses transport header 712 encryption can see only encrypted transport headers. This prevents 713 deployment of performance measurement tools that rely on transport 714 protocol information. Choosing to encrypt all information may be 715 expected to reduce the ability for networks to "help" (e.g., in 716 response to tracing issues, making appropriate Quality of Service, 717 QoS, decisions). For some this will be blessing, for others it may be 718 a curse. For example, operational performance data about encrypted 719 flows needs to be determined by traffic pattern analysis, rather than 720 relying on traditional tools. This can impact the ability of the 721 operator to respond to faults, it could require reliance on endpoint 722 diagnostic tools or user involvement in diagnosing and 723 troubleshooting unusual use cases or non-trivial problems. Although 724 many network operators utilise transport information as a part of 725 their operational practice, the network will not break because 726 transport headers are encrypted. 728 4.5. Acceptable Response to Congestion 730 Congestion control is a key transport function. Many network 731 operators implicitly accept that TCP traffic to comply with a 732 behaviour that is acceptable for use in the shared Internet. TCP 733 algorithms have been continuously improved over decades, and they 734 have reached a level of efficiency and correctness that custom 735 application-layer mechanisms will struggle to easily duplicate 736 [RFC8085]. A standards-compliant TCP stack provides congestion 737 control that is therefore judged safe for use across the Internet. 738 Applications developed on top of well-designed transports can be 739 expected to appropriately control their network usage, reacting when 740 the network experiences congestion, by back-off and reduce the load 741 placed on the network. This is the normal expected behaviour for TCP 742 and other IETF-defined transports. 744 Tools exist that can interpret the transport protocol header 745 information to help understand the impact of specific transport 746 protocols (or protocol mechanisms) on other traffic that shares their 747 network. An observation in the network can gain understanding of the 748 dynamics of a flow and its congestion control behaviour. Analysing 749 observed packet sequence numbers can be used to help build confidence 750 that an application flow backs-off its share of the network load in 751 the face of persistent congestion, and hence to understand whether 752 the behaviour is appropriate for sharing limited network capacity. 753 For example, it is common to visualise plots of TCP sequence numbers 754 versus time for a flow to understand how a flow shares available 755 capacity, deduce its dynamics in response to congestion, etc. 757 This has implications: 759 4.5.1. Measuring Compliance of UDP Traffic 761 The User Datagram Protocol (UDP) provides a minimal message-passing 762 transport that has no inherent congestion control mechanisms. 763 Because congestion control is critical to the stable operation of the 764 Internet, applications and other protocols that choose to use UDP as 765 an Internet transport must employ mechanisms to prevent congestion 766 collapse, avoid unacceptable contributions to jitter/latency, and to 767 establish an acceptable share of capacity with concurrent traffic 768 [RFC8085]. A network operator has no way of knowing the specific 769 methods used by a UDP application. 771 An operator needs tools to understand if such flows comply with their 772 congestion control expectations and therefore whether they need to 773 deploy methods such as rate-limited, transport circuit breakers or 774 other methods to enforce acceptable usage. UDP flows that expose a 775 well-known header by specifying the format of header fields. This 776 information can be observed to gain understanding of the dynamics of 777 a flow and its congestion control behaviour. For example, tools 778 exist to monitor various aspects of the RTP and RTCP header 779 information of real-time flows (see Section 3.2). 781 4.5.2. Measuring Transport to Support Network Operations 783 By correlating observations at multiple points along the path (e.g., 784 at the ingress and egress of a network segment), an observer can 785 determine the contribution of a portion of the path to an observed 786 metric (to locate a source of delay, jitter, loss, reordering, 787 congestion marking, etc). 789 Information provided by tools can help determine whether mechanisms 790 are needed in the network to prevent flows from acquiring excessive 791 network capacity. Operators can manage traffic flows (e.g., to 792 prevent flows from acquiring excessive network capacity under severe 793 congestion) by deploying rate-limiters, traffic shaping or network 794 transport circuit breakers [RFC8084]. 796 5. Observing Transport Flows with Encrypted Transport Header Fields 798 This section examines implications of encrypting specific transport 799 header information. 801 5.1. Transport Information at the Network Layer 803 Some transport information is made visible in the network-layer 804 protocol header. These header fields are not encrypted and can be 805 used to make flow observations. Endpoints should expose flow 806 information in the IPv6 Flow Label Section 3.3.1 in the network-layer 807 header. This can be used to inform network-layer queuing, forwarding 808 (e.g., for equal cost multi-path (ECMP) routing, and Link Aggregation 809 (LAG)). For transport measurement, this can provide useful 810 information to assign packets to flows in the data collected by 811 measurement campaigns, but does not directly provide any performance 812 data. Similarly the Differentiated Services CodePoint (DCSP) 813 indicates expected forwarding treatment Section 3.3.2. The ECN field 814 provides observable congestion data and can help inform measurement 815 of flow congestion Section 3.3.3. 817 5.2. An Observable Transport Flow Identifier 819 To measure and analyse a transport protocol, a measurement tool needs 820 to be able to identify traffic flows. Aggregation of sessions, and 821 persistent use of established transport flows by multiple sessions 822 means that a flow at the transport layer is not necessarily the same 823 as a flow seen at the application layer. This is usually not a 824 consequence. Data is measured for the aggregate transport flow. 826 Some measurement methods sample traffic, rather than collecting all 827 packets passing through a measurement point. These methods still 828 require a way to determine the presence, size and position of any 829 observable header fields - but may need to do this without observing 830 a protocol exchange for a connection setup. 832 5.2.1. A Method to Determine Header Format 833 If flow information is observed from transport headers, then there 834 needs to be a way to identify the format of the header Section 3.1. 835 Some IETF transport protocols are identified by an IP protocol number 836 (e.g. ,TCP, SCTP, UDP). All IETF-defined transport protocols include 837 a transport port field in their transport header. Higher layer 838 protocols (e.g., HTTP) can be sometimes be observed by a well-known 839 port value, which can be indicative of the protocol being 840 encapsulated, but there is no way to enforce this usage. This can be 841 used to configure decapsulation, alternatives include a "magic" 842 number placed at the start of each UDP datagram. 844 Once the protocol has been determined, the transport header can be 845 determined from a published specification. If multiple formats are 846 permitted, this may also require observing the protocol version being 847 used and possibly parameter negotiation at connection setup. 849 5.2.2. Use of a Transport as a Substrate 851 When a transport is used as a substrate, the transport provides an 852 encapsulation that allows another transport flow to be within the 853 payload of a transport flow. The transported protocol header may 854 provide additional information for multiplexing multiple flows over 855 the same 5-tuple. The UDP Guidelines [RFC8085] provides some 856 guidance on using UDP as a substrate protocol. If there is no 857 additional information about the protocol transported by the 858 substrate, this may be viewed as an opaque traffic aggregate, and 859 prevents transport measurement in the network. Examples include GRE- 860 in-UDP [RFC8086], SCTP-in-UDP. The GRE-in-UDP encapsulation may 861 include an encrypted payload, but does not encrypt the GRE protocol 862 header. 864 5.2.3. Support for Mobility and Flow Migration 866 With the proliferation of mobile connected devices, there is a stated 867 need for connection-oriented protocols to maintain connections after 868 a network migration by an endpoint. The ability and desirability of 869 in-network devices to track such migration depends on the context. 870 On the one hand, a load-balancer device in front of server may find 871 it useful to map a migrated connection to the same server endpoint. 872 On the other hand, a user performing migration to avoid detection may 873 prefer the network not to be able to correlate the different parts of 874 a migrating session. Care must then be exercised to make sure that 875 the information encoded by the endpoints is not sufficient to 876 identify unique flows and facilitate a persistent surveillance attack 877 vector [I-D.mm-wg-effect-encrypt]. 879 The impact of flow migration on measurement activities depends on the 880 data being measured, rate of migration and level of encryption that 881 is employed. Requirements for load balancing and mobility can lead 882 to complex protocol interactions. 884 5.2.4. Flow Start and Stop 886 Transports can expose that start and end of flows in a transport 887 header field (e.g., TCP SYN, FIN, RST). This can also help 888 measurement devices identify the start of flows, or to remove stale 889 flow information. This information is supplemental - flows can start 890 and end at any time, the Internet network layer provides only a best 891 effort service that allows alternate routing, reordering, loss, etc, 892 so a network measurement tool can not rely upon observing these 893 indicators. The time to complete a protocol connection and/or 894 session setup can be reported. 896 Flow information can provide in-network devices to manage their 897 forwarding state [I-D.trammell-plus-statefulness]. It can assist a 898 firewall in deciding which flows are permitted through a security 899 gateway, or to help maintain the network address translation (NAT) 900 bindings in a NAPT or application layer gateway. This information 901 may also find use in load balancers, where visibility of the 5-tuple 902 could assist in selecting a server [I-D.mm-wg-effect-encrypt]. 904 Access to flow information and an observable start/stop indication 905 [I-D.trammell-plus-statefulness] can avoid UDP middleboxes relying on 906 timeouts to remove old state. Without this middleboxes are unaware 907 when a particular flow ceases to be used by an application [RFC8085]. 908 This can lead to the state table entries not keeping state for less 909 time for flows that are not identifiable. 911 5.3. Observable Transport Sequence Number 913 The TCP or RTP sequence number can be observed in one direction (the 914 direction that carries data segments). An authenticated header 915 prevents this field being modified or terminated/split [RFC3135] by a 916 network device, but allows this still to be used to observe progress 917 of the network flow. 919 An incrementing sequence number enables detection of loss (either by 920 correlating ingress and egress value, or when assuming that all 921 packets follow a single path), duplication and reordering (with 922 understanding that not necessarily all packets of a flow follow the 923 same path, and reordering can complicate processing of observations). 924 Tools are widely available to interpret RTP and TCP sequence numbers, 925 ranging from open source tools to dedicated commercial packages. As 926 for TCP, use by in-network measurement devices needs to account for 927 the impact of load-balancing of flows, changes in forwarding 928 behaviour, measurement loss (rather than observed packet loss), etc. 930 5.4. Observable Transport Reception 931 Acknowledgement (ACK) data provides information about the path from 932 the network device to the remote endpoint. The information can help 933 identify packet loss (or the point of loss), RTT, and other network- 934 related performance parameters (e.g., throughput, jitter, 935 reordering). Unless this information is correlated with other data 936 there is no way to disambiguate the cause of impairments (congestion 937 loss, link transmission loss, equipment failure). 939 An in-network device must not modify the flow of end-to-end ACK data 940 when using an authenticated protocol. That is, must not use the in- 941 network methods described in [RFC3449]. This can impact the 942 performance and/or efficiency (e.g., cost) of using paths where the 943 return capacity is limited or has implications on the overall design 944 (e.g., using TCP with cellular mobile uplinks, DOCSIS uplinks). 946 The TCP stream can be observed by correlating the stream of TCP ACKs 947 that flow from a receiver in the return direction. Although these 948 ACKs are cumulative, and are not necessarily sent on the same path as 949 the forward data, when visible, their sequence can confirm successful 950 transmission and the path RTT. In the case of TCP they may also 951 indicate packet loss (duplicate ACKs). 953 An RTP session can provide reception information [RFC3550] [RFC4585] 954 feedback using the RTCP framework. This reception information and 955 can be observed by in-network measurement devices and can be 956 interpreted to provide a variety of quality of experience information 957 for the related RTP flow, as well as basic network performance data 958 (RTT, loss, jitter, etc). 960 5.5. Observable Transport Timestamps 962 The use of timestamps for latency and jitter measurements Section 963 3.2.5 is discussed in other sections of the current version of the 964 document. 966 5.6. Observable ECN Transport Feedback Information 968 Transport protocols that use ECN Section 3.3.3 need to provide ECN 969 feedback information in the transport header to inform the sender 970 whether packets have been received with an ECN CE-mark [RFC3819]. 971 This information can be in the form of feedback once each RTT 972 [RFC3819] or more frequent. The latter may involve sending a 973 detailed list of all ECN-marked packets (e.g., [I-D.ietf-tcpm- 974 accurate-ecn] and [RFC6679]). The detailed information can provide 975 detail about the pattern and rate of marking. The information 976 provided in these protocol headers can help a network operator to 977 understand the congestion status of the forward path and the impact 978 of marking algorithms on the traffic that is carried [RFC8087]. 980 IETF specifications for Congestion Exposure (CONVEX) [RFC7713] and 981 Per-congestion Notification (PCB) [RFC5559] are examples of 982 frameworks that monitor reception reports for CE-marked packets to 983 support network operations. 985 5.7. Other Observable Transport Fields 987 This section is not complete - later revision may determine other 988 fields or remove this section. 990 5.8. Interpretation of Transport Header Fields 992 Understanding and analysing transport protocol behaviour typically 993 demands tracking changes to the protocol state at the transport 994 endpoints. Although protocols communicate state information in their 995 protocol headers, a protocol implementation typically also contains 996 internal state that is not directly visible from observing transport 997 protocol headers. Effective measurement tools need to consider that 998 not all packets may be observed (due to drops at the capture tap or 999 because packets take an alternate route that does not pass the tap). 1000 Some flows of packets may also be encapsulated within a maintenance 1001 domain in other protocols, which further complicates analysis. 1003 Some examples of using network measurements of transport headers to 1004 infer internal TCP transport state information include: 1006 o The TCP congestion window (cwnd) and slow start threshold 1007 (ssthresh). Tools for analysing in-network performance of TCP may 1008 observe sequence number to infer the current congestion controller 1009 state. 1010 o The TCP RTT estimator and TCP Retransmission Time Out (RTO) value. 1011 This can be estimated by correlating sequence and acknowledgement 1012 numbers, or possibly by observing TCP timestamp options. 1013 o Use of pacing (and pacing rate) and use of methods such as 1014 Proportional Rate Reduction (PRR) and Congestion Window validation 1015 (CWV). This may be estimated from observing timing of segments 1016 with TCP sequence numbers. This is important to some congestion 1017 control mechanisms and can be important for applications that are 1018 rate limited or send traffic bursts. 1019 o Receiver window and flow control state. This may be inferred from 1020 information in TCP ACK segments. It is important to applications 1021 where the remote endpoint is resource constrained, or the path 1022 exhibits a large RTT. 1023 o Retransmission state and receiver buffer. This may be inferred 1024 from information in TCP ACK segments (especially when SACK blocks 1025 are provided), this can be important to the performance of 1026 applications that send traffic bursts. 1027 o Use of ACK delay and Nagle algorithm. This may be estimated from 1028 observing timing of segments with TCP sequence numbers, and is 1029 important to the performance of thin application flows. 1031 5.9. Requirements for Transport Measurement 1033 Transport measurement introduces the following requirements to 1034 identify the observable information: 1036 o Observable protocol type and version information is needed to 1037 identify the protocol being used when characterising the traffic, 1038 and to enable further observation of the flow. 1039 o Observable format information is needed to allow an observer to 1040 determine the presence of any observable header fields. 1041 o A published specification is needed to allow an observer to 1042 determine the size and position of any observable header fields so 1043 that these fields may be decoded by a measurement tool. 1044 o Observable flow start/stop information can assist some forms of 1045 measurement and has utility for middleboxes that track state. 1047 The need for in-network transport measurement introduces the 1048 following requirements for observable information in transport header 1049 fields: 1051 o Observable transport information to determine the progress of 1052 flows for each direction of communication. This requires 1053 observable packet numbers. 1054 o Observable transport information to determine loss, and understand 1055 the response to congestion for a network segment. This requires 1056 observable reception information (e.g., packet acknowledgment 1057 information). 1058 o Observable transport information is needed for more advanced 1059 measurement of latency, jitter, etc. This requires an observable 1060 field and a method to correlating return information with the 1061 observed field. This could utilise a packet number and/or 1062 transmission timestamp information. This information needs to be 1063 available in both directions of transmission. 1064 o Exposure of Transport ECN feedback provides a powerful tool to 1065 understand ECN-enabled AQM-based networks. (Forward ECN 1066 information is already observable in the network header). 1068 6. The Effect of Encrypting Transport Header Fields 1070 This section explores key implications of working with encrypted 1071 transport protocols. 1073 6.1. Independent Measurement 1075 Independent observation by multiple actors is important for 1076 scientific analysis. Encrypting transport header encryption changes 1077 the ability for other actors to collect and independently analyse 1078 data. Internet transport protocols employ a set of mechanisms. Some 1079 of these need to work in cooperation with the network layer - loss 1080 detection and recovery, congestion detection and congestion control, 1081 some of these need to work only end-to-end (e.g., parameter 1082 negotiation, flow-control. 1084 When encryption conceals information in the transport header, it 1085 could be possible for an applications to provide summary data on 1086 performance and usage of the network. This data could be made 1087 available to other actors. However, this data needs to contain 1088 sufficient detail to understand (and possibly reconstruct the network 1089 traffic pattern for further testing) and to be correlated with the 1090 configuration of the network paths being measured. Sharing 1091 information between actors needs also to consider the privacy of the 1092 user and the incentives for providing accurate and detailed 1093 information. Protocols that expose the state information used by the 1094 transport protocol in their header information (e.g., timestamps used 1095 to calculate RTT, packet numbers used to asses congestion and 1096 requests for retransmission) provide an incentive for the sending 1097 endpoint to provide correct information, increasing confidence that 1098 the observer understands the transport interaction with the network. 1099 This becomes important when considering changes to transport 1100 protocols, changes in network infrastructure, or the emergence of new 1101 traffic patterns. 1103 6.2. Characterising "Unknown" Network Traffic 1105 If "unknown" or "uncharacterised" traffic patterns form a small part 1106 of the traffic aggregate passing through a network device or segment 1107 of the network the path, the dynamics of the uncharacterised traffic 1108 may not have a significant collateral impact on the performance of 1109 other traffic that shares this network segment. Once the proportion 1110 of this traffic increases, the need to monitor the traffic and 1111 determine if appropriate safety measures need to be put in place. 1113 Tracking the impact of new mechanisms and protocols requires traffic 1114 volume to be measured and new transport behaviours to be identified. 1115 This is especially true of protocols operating over a UDP substrate. 1116 The level and style of encryption needs to be considered in 1117 determining how this activity is performed. On a shorter timescale, 1118 information may also need to be collected to manage denial of service 1119 attacks against the infrastructure. 1121 6.3. Accountability and Internet Transport Portocols 1123 Attention therefore needs to be paid to the expected scale of 1124 deployment of new protocols and protocol mechanisms. Whatever the 1125 mechanism, experience has shown that it is often difficult to 1126 correctly implement combination of mechanisms [RFC8085]. These 1127 mechanisms therefore typically evolve as a protocol matures, or in 1128 response to changes in network conditions, changes in network traffic 1129 or changes to application usage. 1131 The growth and diversity of applications and protocols using the 1132 Internet continues to expand - and there has been recent interest in 1133 a wide range of new transport methods, e.g., Larger Initial Window, 1134 Proportional Rate Reduction (PRR), congestion control methods based 1135 on measuring bottleneck bandwidth and round-trip propagation time, 1136 the introduction of AQM techniques and new forms of ECN response 1137 (e.g., Data Centre TCP, DCTP [I-D.ietf-tcpm-dctcp], and methods 1138 proposed for Low Latency Low Loss Scalable throughput, L4S). For 1139 each new method it is desirable to build a body of data reflecting 1140 its behaviour under a wide range of deployment scenarios, traffic 1141 load, and interactions with other deployed/candidate methods. 1143 Measurement therefore has a critical role in the design of transport 1144 protocol mechanisms and their acceptance by the wider community 1145 (e.g., as a method to judge the safety for Internet deployment. Open 1146 standards suggest that such evaluation needs to include independent 1147 observation and evaluation of performance data. 1149 7. Implications on Evolution of the Internet Transport 1151 The transport layer provides the first end-to-end interactions across 1152 the Internet. Transport protocols are layered directly over the 1153 network service and are sent in the payload of network-layer packets. 1154 However, this simple architectural view hides one of the core 1155 functions of the transport - to discover and adapt to the properties 1156 of the Internet path that is currently being used. The design of 1157 Internet transport protocols is as much about trying to avoid the 1158 unwanted side effects of congestion on a flow and other capacity- 1159 sharing flows, avoiding congestion collapse, adapting to changes in 1160 the path characteristics, etc., as it is about end-to-end feature 1161 negotiation, flow control and optimising for performance of a 1162 specific application. 1164 To achieve stable Internet operations the IETF transport community, 1165 has to date, relied heavily on measurement and insight provided from 1166 the wider community to understand the trade-offs and to inform 1167 selection of select appropriate mechanisms to ensure a safe, reliable 1168 and robust Internet since the 1990's. 1170 There are many motivations for deploying encrypted transports, and 1171 encryption of transport payloads. The increasing public concerns 1172 about the interference with Internet traffic have led to a rapidly 1173 expanding deployment of encryption to protect end-user privacy, in 1174 protocols like QUIC. At the same time, network operators and access 1175 providers, especially in mobile networks, have come to rely on the 1176 in-network functionality provided by middleboxes both to enhance 1177 performance and support network operations. This document has 1178 expanded upon the expected implications on operational practices when 1179 working with encrypted transport protocols, and offers insight into 1180 the potential benefit of authentication, encryption and techniques 1181 that require in-network devices to interpret specific protocol header 1182 fields. It presents a need for architectural changes and 1183 consideration of approaches to the way network transport protocols 1184 are designed when using encryption[Measure]. 1186 The use of encryption at the transport layer comes with implications 1187 that need to be considered: 1189 Troubleshooting and diagnostics. Encrypting all transport information 1190 eliminates the incentive for operators to troubleshoot what they 1191 cannot interpret: one flow experiencing packet loss looks like any 1192 other. When transport header encryption prevents decoding the 1193 transport header (if sequence numbers and flow ID are obscured), 1194 and hence understanding the impact on a particular flow or flows 1195 that share a common network segment. Encrypted traffic therefore 1196 implies "don't touch", and a likely first response will be "can't 1197 help, no trouble found", or the implication that this complexity 1198 comes with an additional operational cost [I-D.mm-wg-effect- 1199 encrypt]. 1201 Open verifyable data The use of transport header encryption may 1202 reduce the range of actors who can capture useful measurement 1203 data. This may in future restrict the information sources 1204 available to the Internet community to understand the operation of 1205 the network and transport protocols, necessary to inform 1206 standardisation and design decisions for new protocols, equipment 1207 and operational practices. There are dangers in a model where 1208 transport information is only observable at endpoints: i.e., at 1209 user devices and within service platforms and a need for 1210 independently captured data to develop open standards and 1211 stimulate research into new methods. 1213 Operational practice Published transport specifications allow 1214 operators to check compliance. This can bring assurance to those 1215 operating networks, often avoiding the need to deploy complex 1216 techniques that routinely monitor and manage TCP/IP traffic flows 1217 (e.g. Avoiding the capital and operational costs of deploying 1218 flow rate-limiting and network circuit-breaker methods). This 1219 should continue when encrypted transport headers are used, but 1220 methods need to confirm that the traffic produced conforms to the 1221 expectations of the operator or developer. 1223 Traffic analysis The use of encryption could make it harder to 1224 determine which transport methods are being used across a network 1225 segment and the trends in usage. This could impact the ability 1226 for an operator to anticipate the need for network upgrades and 1227 roll-out. It can also impact on-going traffic engineering 1228 activities. Although the impact in many case may be small, there 1229 are cases where operators directly support services (e.g., in 1230 radio environments, or to troubleshoot QoS-related issues) and the 1231 more complex the underlying infrastructure the more important this 1232 impact. 1234 Interactions between mechanisms An appropriate vantage point, coupled 1235 with timing information for the flow (fine-grained timestamps) is 1236 a valuable tool in benchmarking equipment/configurations and 1237 understanding non-trivial interactions. Encryption restricts the 1238 ability to explore interactions between functions at different 1239 protocol layers. This is a side-effect of not allowing a choice 1240 of the vantage point from which this information is observed. 1241 This can be important (e.g., in examining collateral impact of 1242 flows sharing a bottleneck, or where the intention is to 1243 understand the interaction between a layer 2 function (e.g., radio 1244 resource management policy, a channel impairment, an AQM 1245 configuration, a Per Hop Behaviour (PHB) or scheduling method) and 1246 a transport protocol). 1248 Common specifications Since the introduction of congestion control, 1249 TCP has continued to be the predominate transport, with a 1250 consistent approach to avoiding congestion collapse. There is a 1251 risk that the diversity of transport mechanisms could also 1252 increase, with incentives to use a wide range of methods, this is 1253 not in itself a problem, nor is this a direct result of 1254 encryption. Encryption of all headers places the onus on 1255 validation in the hands of developers. While there is little to 1256 doubt that developers will seek to produce high quality code for 1257 their target use, it is not clear whether there is sufficient 1258 incentive to ensure good practice that benefits the wide diversity 1259 of requirements from the Internet community as a whole. However, 1260 when encryption is used, this risk needs to be weighed against the 1261 reduced visibility of the interactions between traffic, the 1262 network and the mechanisms. Especially, if a development cycle 1263 focused on specific protocols/applications could offer incentives 1264 for optimisations that could prove suboptimal for users or 1265 operators that utilise a network segments with different 1266 characteristics than targeted by the developer. 1268 Restricting research and development The use of encryption may impede 1269 independent research into new mechanisms, measurement of 1270 behaviour, and development initiatives. Experience shows that 1271 high quality transport protocols are complicated to design and 1272 complex to deploy, and that individual mechanisms need to be 1273 evaluated while considering other mechanism, across a broad range 1274 of network topologies and with attention to the impact on traffic 1275 sharing the capacity. Adopting pervasive encryption of transport 1276 information could eliminate the independent self-checks that have 1277 previously been in place from research and academic contributors 1278 (e.g., the role of the IRTF ICCRG, and research publications in 1279 reviewing new transport mechanisms and assessing the impact of 1280 their experimental deployment). 1282 Pervasive use of transport header encryption can impact the ways that 1283 future protocols are designed and deployed. The choice of whether 1284 candidate transport designs should encrypt their protocol headers 1285 therefore needs to be taken based not just on security 1286 considerations, but also on the impact on operating networks and the 1287 constrictions this may place on evolution of Internet protocols. 1288 While encryption of all transport information can help reduce 1289 ossification of the transport layer, it could result in ossification 1290 of the network service. There can be advantages in providing a level 1291 of ossification of the header in terms of providing a set of open 1292 specified header fields that are observable from in-network devices. 1294 8. Acknowledgements 1296 The author would like to thank all who have talked to him face-to- 1297 face or via email. ... 1299 This work has received funding from the European Union's Horizon 2020 1300 research and innovation programme under grant agreement No 688421.The 1301 opinions expressed and arguments employed reflect only the authors' 1302 view. The European Commission is not responsible for any use that 1303 may be made of that information. 1305 9. IANA Considerations 1307 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 1309 This memo includes no request to IANA. 1311 10. Security Considerations 1313 This document is about design and deployment considerations for 1314 transport protocols. Authentication, confidentiality protection, and 1315 integrity protection are identified as Transport Features by 1316 RFC8095". As currently deployed in the Internet, these features are 1317 generally provided by a protocol or layer on top of the transport 1318 protocol; no current full-featured standards-track transport protocol 1319 provides these features on its own. Therefore, these features are 1320 not considered in this document, with the exception of native 1321 authentication capabilities of TCP and SCTP for which the security 1322 considerations in RFC4895. 1324 Like congestion control mechanisms, security mechanisms are difficult 1325 to design and implement correctly. It is hence recommended that 1326 applications employ well-known standard security mechanisms such as 1327 DTLS, TLS or IPsec, rather than inventing their own. 1329 11. References 1331 11.1. Normative References 1333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1334 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1335 RFC2119, March 1997, . 1338 11.2. Informative References 1340 [I-D.dolson-plus-middlebox-benefits] 1341 Dolson, D., Snellman, J., Boucadair, M. and C. Jacquenet, 1342 "Beneficial Functions of Middleboxes", Internet-Draft 1343 draft-dolson-plus-middlebox-benefits-03, March 2017. 1345 [I-D.ietf-aqm-codel] 1346 Nichols, K., Jacobson, V., McGregor, A. and J. Jana, 1347 "Controlled Delay Active Queue Management", Internet-Draft 1348 draft-ietf-aqm-codel-00, October 2014. 1350 [I-D.ietf-aqm-fq-codel] 1351 Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, 1352 J. and E. Dumazet, "FlowQueue-Codel", Internet-Draft 1353 draft-ietf-aqm-fq-codel-00, January 2015. 1355 [I-D.ietf-aqm-pie] 1356 Pan, R., Natarajan, P., Baker, F. and G. White, "PIE: A 1357 Lightweight Control Scheme To Address the Bufferbloat 1358 Problem", Internet-Draft draft-ietf-aqm-pie-00, October 1359 2014. 1361 [I-D.ietf-ippm-6man-pdm-option] 1362 Elkins, N., Hamilton, R. and m. mackermann@bcbsm.com, 1363 "IPv6 Performance and Diagnostic Metrics (PDM) Destination 1364 Option", Internet-Draft draft-ietf-ippm-6man-pdm- 1365 option-10, May 2017. 1367 [I-D.ietf-quic-transport] 1368 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1369 and Secure Transport", Internet-Draft draft-ietf-quic- 1370 transport-03, May 2017. 1372 [I-D.ietf-tcpm-accurate-ecn] 1373 Briscoe, B., Kuehlewind, M. and R. Scheffenegger, "More 1374 Accurate ECN Feedback in TCP", Internet-Draft draft-ietf- 1375 tcpm-accurate-ecn-00, December 2015. 1377 [I-D.ietf-tcpm-dctcp] 1378 Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L. 1379 and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion 1380 Control for Datacenters", Internet-Draft draft-ietf-tcpm- 1381 dctcp-06, May 2017. 1383 [I-D.ietf-tsvwg-l4s-arch] 1384 Briscoe, B., Schepper, K. and M. Bagnulo, "Low Latency, 1385 Low Loss, Scalable Throughput (L4S) Internet Service: 1386 Architecture", Internet-Draft draft-ietf-tsvwg-l4s- 1387 arch-00, May 2017. 1389 [I-D.mm-wg-effect-encrypt] 1390 Moriarty, K. and A. Morton, "Effect of Pervasive 1391 Encryption on Operators", Internet-Draft draft-mm-wg- 1392 effect-encrypt-11, April 2017. 1394 [I-D.trammell-plus-abstract-mech] 1395 Trammell, B., "Abstract Mechanisms for a Cooperative Path 1396 Layer under Endpoint Control", Internet-Draft draft- 1397 trammell-plus-abstract-mech-00, September 2016. 1399 [I-D.trammell-plus-statefulness] 1400 Kuehlewind, M., Trammell, B. and J. Hildebrand, 1401 "Transport-Independent Path Layer State Management", 1402 Internet-Draft draft-trammell-plus-statefulness-02, 1403 December 2016. 1405 [Latency] Briscoe, B., "Reducing Internet Latency: A Survey of 1406 Techniques and Their Merits", November 2014. 1408 [Measure] Fairhurst, G., Kuehlewind, M. and D. Lopez, "Measurement- 1409 based Protocol Design", June 2017. 1411 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 1412 "Definition of the Differentiated Services Field (DS 1413 Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 1414 10.17487/RFC2474, December 1998, . 1417 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. 1418 Shelby, "Performance Enhancing Proxies Intended to 1419 Mitigate Link-Related Degradations", RFC 3135, DOI 1420 10.17487/RFC3135, June 2001, . 1423 [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of 1424 Explicit Congestion Notification (ECN) to IP", RFC 3168, 1425 DOI 10.17487/RFC3168, September 2001, . 1428 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1429 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 1430 . 1432 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M. 1433 Sooriyabandara, "TCP Performance Implications of Network 1434 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 1435 December 2002, . 1437 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. 1438 Jacobson, "RTP: A Transport Protocol for Real-Time 1439 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1440 July 2003, . 1442 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 1443 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J. and L. 1444 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1445 RFC 3819, DOI 10.17487/RFC3819, July 2004, . 1448 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1449 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1450 December 2005, . 1452 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 1453 10.17487/RFC4302, December 2005, . 1456 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1457 4303, DOI 10.17487/RFC4303, December 2005, . 1460 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey, 1461 "Extended RTP Profile for Real-time Transport Control 1462 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 1463 10.17487/RFC4585, July 2006, . 1466 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S. 1467 and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 1468 10.17487/RFC4737, November 2006, . 1471 [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A. and R. 1472 Whitner, "Improved Packet Reordering Metrics", RFC 5236, 1473 DOI 10.17487/RFC5236, June 2008, . 1476 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1477 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1478 RFC5246, August 2008, . 1481 [RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) 1482 Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009, 1483 . 1485 [RFC5925] Touch, J., Mankin, A. and R. Bonica, "The TCP 1486 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1487 June 2010, . 1489 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1490 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1491 January 2012, . 1493 [RFC6437] Amante, S., Carpenter, B., Jiang, S. and J. Rajahalme, 1494 "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/ 1495 RFC6437, November 2011, . 1498 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P. 1499 and K. Carlberg, "Explicit Congestion Notification (ECN) 1500 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 1501 2012, . 1503 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1504 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1505 2014, . 1507 [RFC7525] Sheffer, Y., Holz, R. and P. Saint-Andre, "Recommendations 1508 for Secure Use of Transport Layer Security (TLS) and 1509 Datagram Transport Layer Security (DTLS)", BCP 195, RFC 1510 7525, DOI 10.17487/RFC7525, May 2015, . 1513 [RFC7567] Baker, F.Ed., and G. Fairhurst, Ed., "IETF 1514 Recommendations Regarding Active Queue Management", BCP 1515 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, . 1518 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1519 Trammell, B., Huitema, C. and D. Borkmann, 1520 "Confidentiality in the Face of Pervasive Surveillance: A 1521 Threat Model and Problem Statement", RFC 7624, DOI 1522 10.17487/RFC7624, August 2015, . 1525 [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 1526 Concepts, Abstract Mechanism, and Requirements", RFC 7713, 1527 DOI 10.17487/RFC7713, December 2015, . 1530 [RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N.Ed., and D. 1531 Ros, "Characterization Guidelines for Active Queue 1532 Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July 1533 2016, . 1535 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 1536 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, . 1539 [RFC8085] Eggert, L., Fairhurst, G. and G. Shepherd, "UDP Usage 1540 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1541 March 2017, . 1543 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X. and T. Herbert, "GRE-in- 1544 UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 1545 2017, . 1547 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 1548 Explicit Congestion Notification (ECN)", RFC 8087, DOI 1549 10.17487/RFC8087, March 2017, . 1552 [Tor] The Tor Project, ., "https://www.torproject.org", June 1553 2017. 1555 Appendix A. Revision information 1557 -00 This is an individual draft for the IETF community 1558 -01 This draft was a result of walking away from the text for a few 1559 days and then reorganising the content. Comments from the community 1560 are welcome on the text and recommendations. 1562 Author's Address 1564 Godred Fairhurst 1565 University of Aberdeen 1566 Department of Engineering 1567 Fraser Noble Building 1568 Aberdeen, AB24 3UE 1569 Scotland 1571 Email: gorry@erg.abdn.ac.uk 1572 URI: http://www.erg.abdn.ac.uk/