idnits 2.17.1 draft-irtf-panrg-path-properties-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: ---------------------------------------------------------------------------- No issues found here. 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 (September 07, 2020) is 1321 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-11 == Outdated reference: A later version (-28) exists of draft-ietf-alto-performance-metrics-12 == Outdated reference: A later version (-03) exists of draft-ietf-idr-performance-routing-02 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-29 == Outdated reference: A later version (-12) exists of draft-irtf-panrg-questions-07 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANRG T. Enghardt 3 Internet-Draft Netflix 4 Intended status: Informational C. Kraehenbuehl 5 Expires: March 11, 2021 ETH Zuerich 6 September 07, 2020 8 A Vocabulary of Path Properties 9 draft-irtf-panrg-path-properties-01 11 Abstract 13 Path properties express information about paths across a network and 14 the services provided via such paths. In a path-aware network, path 15 properties may be fully or partially available to entities such as 16 hosts. This document defines and categorizes path properties. 17 Furthermore, the document specifies several path properties which 18 might be useful to hosts or other entities, e.g., for selecting 19 between paths or for invoking some of the provided services. 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 https://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 March 11, 2021. 38 Copyright Notice 40 Copyright (c) 2020 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 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Use Cases for Path Properties . . . . . . . . . . . . . . . . 5 58 3.1. Path Selection . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Protocol Selection . . . . . . . . . . . . . . . . . . . 6 60 3.3. Service Invocation . . . . . . . . . . . . . . . . . . . 6 61 4. Examples of Path Properties . . . . . . . . . . . . . . . . . 6 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 7. Informative References . . . . . . . . . . . . . . . . . . . 10 65 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 68 1. Introduction 70 The current Internet architecture does not explicitly support 71 endpoint discovery of forwarding paths through the network as well as 72 the discovery of properties and services associated with these paths. 73 Path-aware networking, as defined in Section 1.1 of 74 [I-D.irtf-panrg-questions], describes "endpoint discovery of the 75 properties of paths they use for communication, and endpoint reaction 76 to these properties that affects routing and/or transmission". This 77 document defines such information as path properties, addressing the 78 first of the questions in path-aware networking 79 [I-D.irtf-panrg-questions]. 81 As terms related to paths have different meanings in different areas 82 of networking, first, this document provides a common terminology to 83 define paths, path elements, and path properties. Then, this 84 document provides some examples for use cases for path properties. 85 Finally, the document lists several path properties that may be 86 useful for the mentioned use cases. 88 Note that this document does not assume that any of the listed path 89 properties are actually available to any entity. The question of how 90 entities can discover and distribute path properties in a trustworthy 91 way is out of scope for this document. 93 2. Terminology 95 Node: An entity which processes packets, e.g., sends, receives, 96 forwards, or modifies them. A node may be physical or virtual, 97 e.g., a physical device or a service function provided as a 98 virtual element. A node may also be the collection of multiple 99 entities which, as a collection, processes packets, e.g., an 100 entire Autonomous System (AS). 102 Host: A node that generally executes application programs on behalf 103 of user(s), employing network and/or Internet communication 104 services in support of this function, as defined in [RFC1122]. 105 Note that hosts include both client nodes (e.g., running a web 106 browser) and server nodes (e.g., running a web server). 108 Link: A medium or communication facility that connects two or more 109 nodes with each other. A link enables a node to send packets to 110 other nodes. Links can be physical, e.g., a Wi-Fi network which 111 connects an Access Point to stations, or virtual, e.g., a virtual 112 switch which connects two virtual machines hosted on the same 113 physical machine. A link is unidirectional. As such, 114 bidirectional communication can be modeled as two links between 115 the same nodes in opposite directions. 117 Path element: Either a node or a link. For example, a path element 118 can be an Abstract Network Element (ANE) as defined in 119 [I-D.ietf-alto-path-vector]. 121 Path: A sequence of adjacent path elements over which a packet can 122 be transmitted, starting and ending with a node. A path is 123 unidirectional. Paths are time-dependent, i.e., the sequence of 124 path elements over which packets are sent from one node to another 125 may change. A path is defined between two nodes. For multicast 126 or broadcast, a packet may be sent by one node and received by 127 multiple nodes. In this case, the packet is sent over multiple 128 paths at once, one path for each combination of sending and 129 receiving node; these paths do not have to be disjoint. Note that 130 an entity may have only partial visibility of the path elements 131 that comprise a path and visibility may change over time. 132 Different entities may have different visibility of a path and/or 133 treat path elements at different levels of abstraction. For 134 example, a path may be given as a sequence of physical nodes and 135 the links connecting these nodes, or it may be given as a sequence 136 of logical nodes such as a sequence of ASes or an Explicit Route 137 Object (ERO). Similarly, the representation of a path and its 138 properties, as it is known to a specific entity, may be more 139 complex and include details about the physical layer technology, 140 or it may be more abstract and only consist of a specific source 141 and destination which is known to be reachable from that source. 143 Reverse Path: The path that is used by a remote node in the context 144 of bidirectional communication. 146 Subpath: Given a path, a subpath is a sequence of adjacent path 147 elements of this path. 149 Flow: An entity made of packets to which the traits of a path or set 150 of subpaths may be applied in a functional sense. For example, a 151 flow can consist of all packets sent within a TCP session with the 152 same five-tuple between two hosts, or it can consist of all 153 packets sent on the same physical link. 155 Property: A trait of one or a sequence of path elements, or a trait 156 of a flow with respect to one or a sequence of path elements. An 157 example of a link property is the maximum data rate that can be 158 sent over the link. An example of a node property is the 159 administrative domain that the node belongs to. An example of a 160 property of a flow with respect to a subpath is the aggregated 161 one-way delay of the flow being sent from one node to another node 162 over this subpath. A property is thus described by a tuple 163 containing the path element(s), the flow or an empty set if no 164 packets are relevant for the property, the name of the property 165 (e.g., maximum data rate), and the value of the property (e.g., 166 1Gbps). 168 Aggregated property: A collection of multiple values of a property 169 into a single value, according to a function. A property can be 170 aggregated over multiple path elements (i.e., a subpath), e.g., 171 the MTU of a path as the minimum MTU of all links on the path, 172 over multiple packets (i.e., a flow), e.g., the median one-way 173 latency of all packets between two nodes, or over both, e.g., the 174 mean of the queueing delays of a flow on all nodes along a path. 175 The aggregation function can be numerical, e.g., median, sum, 176 minimum, it can be logical, e.g., "true if all are true", "true if 177 at least 50\% of values are true", or an arbitrary function which 178 maps multiple input values to an output value. 180 Observed property: A property that is observed for a specific path 181 element, subpath, or path, e.g., using measurements. For example, 182 the one-way delay of a specific packet transmitted from one node 183 to another node can be measured. 185 Assessed property: An approximate calculation or assessment of the 186 value of a property. An assessed property includes the 187 reliability of the calculation or assessment. The notion of 188 reliability depends on the property. For example, a path property 189 based on an approximate calculation may describe the expected 190 median one-way latency of packets sent on a path within the next 191 second, including the confidence level and interval. A non- 192 numerical assessment may instead include the likelihood that the 193 property holds. 195 3. Use Cases for Path Properties 197 When a path-aware network exposes path properties to hosts or other 198 entities, these entities may use this information to achieve 199 different goals. This section lists several use cases for path 200 properties. Note that this is not an exhaustive list, as with every 201 new technology and protocol, novel use cases may emerge, and new path 202 properties may become relevant. 204 3.1. Path Selection 206 Entities can choose what traffic to send over which path or subset of 207 paths. A node might be able to select between a set of paths, either 208 if there are several paths to the same destination (e.g., in case of 209 a mobile device with two wireless interfaces, both providing a path), 210 or if there are several destinations, and thus several paths, 211 providing the same service (e.g., Application-Layer Traffic 212 Optimization (ALTO) [RFC5693], an application layer peer-to-peer 213 protocol allowing hosts a better-than-random peer selection). Care 214 needs to be taken when selecting paths based on path properties, as 215 path properties that were previously measured may not be helpful in 216 predicting current or future path properties and such path selection 217 may lead to unintended feedback loops. 219 Entities may select their paths to fulfill a specific goal, e.g., 220 related to security or performance. As an example of security- 221 related path selection, an entity may allow or disallow sending 222 traffic over paths involving specific networks or nodes to enforce 223 traffic policies. In an enterprise network where all traffic has to 224 go through a specific firewall, a path-aware host can implement this 225 policy using path selection, in which case the host needs to be aware 226 of paths involving that firewall. As an example of performance- 227 related path selection, an entity may prefer paths with performance 228 properties that best match its traffic requirements. For example, 229 for sending a small delay sensitive query, a host may select a path 230 with a short One-Way Delay, while for retrieving a large file, it may 231 select a path with high Link Capacities on all links. Note, there 232 may be trade-offs between path properties (e.g., One-Way Delay and 233 Link Capacity), and entities may influence these trade-offs with 234 their choices. As a baseline, a path selection algorithm should aim 235 to not perform worse than the default case most of the time. 237 Path selection can be done both by hosts and by entities within the 238 network: A network (e.g., an AS) can adjust its path selection for 239 internal or external routing based on path properties. In BGP, the 240 Multi Exit Discriminator (MED) attribute is used in the decision- 241 making process to select which path to choose among those having the 242 same AS PATH length and origin [RFC4271]; in a path aware network, 243 instead of using this single MED value, other properties such as Link 244 Capacity or Link Usage could additionally be used to improve load 245 balancing or performance [I-D.ietf-idr-performance-routing]. 247 3.2. Protocol Selection 249 When sending traffic over a specific path, an entity may select an 250 appropriate protocol or configure protocol parameters depending on 251 path properties. A host may cache state on whether a path allows the 252 use of QUIC [I-D.ietf-quic-transport] and if so, first attempt to 253 connect using QUIC before falling back to another protocol when 254 connecting over this path again. A video streaming application may 255 choose an (initial) video quality based on the achievable data rate 256 or the monetary cost of sending data (e.g., volume-base or flat-rate 257 cost model). 259 3.3. Service Invocation 261 Conversely to path or protocol selection, in addition to selecting a 262 protocol to use over a specific adjacent path element, an entity may 263 choose to invoke additional functions influencing the nodes to be 264 involved in the path. For example, a 0-RTT Transport Converter 265 [I-D.ietf-tcpm-converters] will be involved in a path only when 266 invoked by a host; such invocation will lead to the use of MPTCP or 267 TCPinc capabilities while such use is not supported via the default 268 forwarding path. Another example is a connection which is composed 269 of multiple streams where each stream has specific service 270 requirements. A host may decide to invoke a given service function 271 (e.g., transcoding) only for some streams while others are not 272 processed by that service function. 274 4. Examples of Path Properties 276 This Section gives some examples of path properties which may be 277 useful, e.g., for the use cases described in Section 3. 279 Path properties may be relatively dynamic, e.g., the one-way delay of 280 a packet sent over a specific path, or non-dynamic, e.g., the MTU of 281 an Ethernet link which only changes infrequently. Usefulness over 282 time differs depending on how dynamic a property is: The merit of a 283 momentary measurement of a dynamic path property diminishes greatly 284 as time goes on, e.g. the merit of an RTT measurement from a few 285 seconds ago is quite small, while a non-dynamic path property might 286 stay relevant for a longer period of time, e.g. a NAT typically stays 287 on a specific path during the lifetime of a connection involving 288 packets sent over this path. 290 From the point of view of a host, path properties may relate to path 291 elements close to the host, i.e., within the first few hops, or they 292 may include path elements far from the host, e.g., list of ASes 293 traversed. The visibility of path properties to a specific entity 294 may depend on factors such as the physical or network distance or the 295 existence of trust or contractual relationships between the entity 296 and the path element(s). 298 Furthermore, entities may or may not be able to influence the path 299 elements on their path and their path properties. For example, a 300 user might select between multiple potential adjacent links by 301 selecting between multiple available Wi-Fi Access Points. Or when 302 connected to an Access Point, the user may move closer to enable 303 their device to use a different access technology, potentially 304 increasing the data rate available to the device. Another example is 305 a user changing their data plan to reduce the Monetary Cost to 306 transmit or receive a given amount of data across a network. 308 Access Technology: The physical or link layer technology used for 309 transmitting or receiving a flow on one or multiple path elements. 310 If known, the Access Technology may be given as an abstract link 311 type, e.g., as Wi-Fi, Wired Ethernet, or Cellular. It may also be 312 given as a specific technology used on a link, e.g., 2G, 3G, 4G, 313 or 5G cellular, or 802.11a, b, g, n, or ac Wi-Fi. Other path 314 elements relevant to the access technology may include nodes 315 related to processing packets on the physical or link layer, such 316 as elements of a cellular backbone network. Note that there is no 317 common registry of possible values for this property. 319 Monetary Cost: The price to be paid to transmit or receive a 320 specific flow across a network to which one or multiple path 321 elements belong. 323 Service function: A service function that a path element applies to 324 a flow, see [RFC7665]. Examples of abstract service functions 325 include firewalls, Network Address Translation (NAT), and TCP 326 optimizers. Some stateful service functions, such as NAT, need to 327 observe the same flow in both directions, e.g., by being an 328 element of both the path and the reverse path. 330 Transparency: A node is transparent with respect to a protocol 331 header, payload, or both for a specific action if the node 332 performs this action independently of the given 333 (meta-)information. Actions can for example be blocking packets 334 or reading and modifying (other protocol) headers or payloads. An 335 IP router could be transparent for transport protocol headers such 336 as TCP and UDP, in contrast to a NAT that actively modifies TCP 337 and UDP header information. 339 Administrative Domain: The administrative domain, e.g., the IGP 340 area, AS, or Service provider network to which a path element 341 belongs. 343 Disjointness: For a set of two paths or subpaths, the number of 344 shared path elements can be a measure of intersection (e.g., 345 Jaccard coefficient, which is the number of shared elements 346 divided by the total number of elements). Conversely, the number 347 of non-shared path elements can be a measure of disjointness 348 (e.g., 1 - Jaccard coefficient). A multipath protocol might use 349 disjointness as a metric to reduce the number of single points of 350 failure. 352 Symmetric Path: Two paths are symmetric if the path and its reverse 353 path consist of the same path elements on the same level of 354 abstraction, but in reverse order. For example, a path which 355 consists of layer 3 switches and links between them and a reverse 356 path with the same path elements but in reverse order are 357 considered "routing" symmetric, as the same path elements on the 358 same level of abstraction (IP forwarding) are traversed in the 359 opposite direction. 361 Path MTU: The maximum size, in octets, of an IP packet that can be 362 transmitted without fragmentation. 364 Transport Protocols available: Whether a specific transport protocol 365 can be used to establish a connection over a path or subpath, 366 e.g., whether the path is QUIC-capable or MPTCP-capable, based on 367 cached knowledge. 369 Protocol Features available: Whether a specific protocol feature is 370 available over a path or subpath, e.g., Explicit Congestion 371 Notification (ECN), or TCP Fast Open. 373 Some path properties express the performance of the transmission of a 374 packet or flow over a link or subpath. Such transmission performance 375 properties can be measured or approximated, e.g., by hosts or by path 376 elements on the path, or they may be available as cost metrics, see 377 [I-D.ietf-alto-performance-metrics]. Transmission performance 378 properties may be made available in an aggregated form, such as 379 averages or minimums. Properties related to a path element which 380 constitutes a single layer 2 domain are abstracted from the used 381 physical and link layer technology, similar to [RFC8175]. 383 Link Capacity: The link capacity is the maximum data rate at which 384 data that was sent over a link can correctly be received at the 385 node adjacent to the link. This property is analogous to the link 386 capacity defined in [RFC5136] but not restricted to IP-layer 387 traffic. 389 Link Usage: The link usage is the actual data rate at which data 390 that was sent over a link is correctly received at the node 391 adjacent to the link. This property is analogous to the link 392 usage defined in [RFC5136] but not restricted to IP-layer traffic. 394 One-Way Delay: The one-way delay is the delay between a node sending 395 a packet and another node on the same path receiving the packet. 396 This property is analogous to the one-way delay defined in 397 [RFC7679] but not restricted to IP-layer traffic. 399 One-Way Delay Variation: The variation of the one-way delays within 400 a flow. This property is similar to the one-way delay variation 401 defined in [RFC3393] but not restricted to IP-layer traffic and 402 defined for packets on the same flow instead of packets sent 403 between a source and destination IP address. 405 One-Way Packet Loss: Packets sent by a node but not received by 406 another node on the same path after a certain time interval are 407 considered lost. This property is analogous to the one-way loss 408 defined in [RFC7680] but not restricted to IP-layer traffic. 409 Metrics such as loss patterns [RFC3357] and loss episodes 410 [RFC6534] can be expressed as aggregated properties. 412 5. Security Considerations 414 If nodes are basing policy or path selection decisions on path 415 properties, they need to rely on the accuracy of path properties that 416 other devices communicate to them. In order to be able to trust such 417 path properties, nodes may need to establish a trust relationship or 418 be able to verify the authenticity, integrity, and correctness of 419 path properties received from another node. 421 Security related properties such as confidentiality and integrity 422 protection of payloads are difficult to characterize since they are 423 only meaningful with respect to a threat model which depends on the 424 use case, application, environment, and other factors. Likewise, 425 properties for trust relations between nodes cannot be meaningfully 426 defined without a concrete threat model, and defining a threat model 427 is out of scope for this draft. Properties related to 428 confidentiality, integrity, and trust are orthogonal to the path 429 terminology and path properties defined in this document. Such 430 properties are tied to the communicating entities and protocols used 431 (e.g., client and server using HTTPS, or client and remote network 432 node using VPN) while the path is typically oblivious to them. 433 Intuitively, the path describes what function the network applies to 434 packets, while confidentiality, integrity, and trust describe what 435 function the communicating parties apply to packets. 437 6. IANA Considerations 439 This document has no IANA actions. 441 7. Informative References 443 [I-D.ietf-alto-path-vector] 444 Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang, 445 "ALTO Extension: Path Vector", draft-ietf-alto-path- 446 vector-11 (work in progress), July 2020. 448 [I-D.ietf-alto-performance-metrics] 449 WU, Q., Yang, Y., Lee, Y., Dhody, D., Randriamasy, S., and 450 L. Contreras, "ALTO Performance Cost Metrics", draft-ietf- 451 alto-performance-metrics-12 (work in progress), July 2020. 453 [I-D.ietf-idr-performance-routing] 454 Xu, X., Hegde, S., Talaulikar, K., Boucadair, M., and C. 455 Jacquenet, "Performance-based BGP Routing Mechanism", 456 draft-ietf-idr-performance-routing-02 (work in progress), 457 October 2019. 459 [I-D.ietf-quic-transport] 460 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 461 and Secure Transport", draft-ietf-quic-transport-29 (work 462 in progress), June 2020. 464 [I-D.ietf-tcpm-converters] 465 Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., 466 and B. Hesmans, "0-RTT TCP Convert Protocol", draft-ietf- 467 tcpm-converters-19 (work in progress), March 2020. 469 [I-D.irtf-panrg-questions] 470 Trammell, B., "Current Open Questions in Path Aware 471 Networking", draft-irtf-panrg-questions-07 (work in 472 progress), August 2020. 474 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 475 Communication Layers", STD 3, RFC 1122, 476 DOI 10.17487/RFC1122, October 1989, 477 . 479 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 480 Metrics", RFC 3357, DOI 10.17487/RFC3357, August 2002, 481 . 483 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 484 Metric for IP Performance Metrics (IPPM)", RFC 3393, 485 DOI 10.17487/RFC3393, November 2002, 486 . 488 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 489 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 490 DOI 10.17487/RFC4271, January 2006, 491 . 493 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 494 RFC 5136, DOI 10.17487/RFC5136, February 2008, 495 . 497 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 498 Optimization (ALTO) Problem Statement", RFC 5693, 499 DOI 10.17487/RFC5693, October 2009, 500 . 502 [RFC6534] Duffield, N., Morton, A., and J. Sommers, "Loss Episode 503 Metrics for IP Performance Metrics (IPPM)", RFC 6534, 504 DOI 10.17487/RFC6534, May 2012, 505 . 507 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 508 Chaining (SFC) Architecture", RFC 7665, 509 DOI 10.17487/RFC7665, October 2015, 510 . 512 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 513 Ed., "A One-Way Delay Metric for IP Performance Metrics 514 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 515 2016, . 517 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 518 Ed., "A One-Way Loss Metric for IP Performance Metrics 519 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 520 2016, . 522 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 523 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 524 DOI 10.17487/RFC8175, June 2017, 525 . 527 Acknowledgments 529 Thanks to the Path-Aware Networking Research Group for the discussion 530 and feedback. Specifically, thanks to Mohamed Boudacair for the 531 detailed review and various text suggestions, thanks to Brian 532 Trammell for suggesting the flow definition, and thanks to Adrian 533 Perrig and Matthias Rost for the detailed feedback. Thanks to Paul 534 Hoffman for the editorial changes. 536 Authors' Addresses 538 Theresa Enghardt 539 Netflix 541 Email: ietf@tenghardt.net 543 Cyrill Kraehenbuehl 544 ETH Zuerich 546 Email: cyrill.kraehenbuehl@inf.ethz.ch