idnits 2.17.1 draft-kuehlewind-spud-use-cases-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (July 3, 2015) is 3213 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 567, but not defined -- No information found for draft-trammell-stackevo-spud-req - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Kuehlewind 3 Internet-Draft B. Trammell 4 Intended status: Informational ETH Zurich 5 Expires: January 4, 2016 July 3, 2015 7 SPUD Use Cases 8 draft-kuehlewind-spud-use-cases-00 10 Abstract 12 The Substrate Protocol for User Datagrams (SPUD) BoF session at the 13 IETF 92 meeting in Dallas in March 2015 identified the potential need 14 for a UDP-based encapsulation protocol to allow explicit cooperation 15 with middleboxes while using new, encrypted transport protocols. 16 This document summarizes the use cases discuss at the BoF and thereby 17 proposes a structure for the description of further use cases. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 4, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Firewall Traversal . . . . . . . . . . . . . . . . . . . . . 3 55 3. State Lifetime Discovery . . . . . . . . . . . . . . . . . . 5 56 4. Low-Latency Service . . . . . . . . . . . . . . . . . . . . . 8 57 5. Application-Limited Flows . . . . . . . . . . . . . . . . . . 10 58 6. Service Multiplexing . . . . . . . . . . . . . . . . . . . . 13 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 62 10. Informative References . . . . . . . . . . . . . . . . . . . 15 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 65 1. Introduction 67 This document describe use cases for a common Substrate Protocol for 68 User Datagrams (SPUD) that could be used by an overlaying transport 69 or application to explicitely expose information to middleboxes or 70 request information from (SPUD-aware) middleboxes. 72 For each use case, we first describe a problem that can not be solved 73 with current protocols, or only solved inefficiently. We then 74 discuss which information should be exposed by which party to help 75 the described problem. We also discuss potential mechanisms to use 76 that exposed information at middleboxes and/or endpoints, in order to 77 demonstrate the feasibility of using the exposed information to the 78 given use case. The described mechanisms are not necessarily 79 proposals for moving forward, nor do they necessarily represent the 80 best approach for applying the exposed information, but should 81 illustrate and motivate the applicability of the exposed information. 83 In this document we assume that there is no pre-existing trust 84 relationship between the communication endpoints and any middlebox on 85 the path. Therefore we must always assume that information that is 86 exposed can be wrong or nobody will actually act based on the exposed 87 information. However, for the described use cases there should still 88 be a benefit, e.g if otherwise no information would be available. 90 Based on each mechanism, we discuss deployment incentives of each 91 involved party. There must be clear incentives for each party to 92 justify the proposed information exposure and at best an incremental 93 deployment strategy. Finally, we discuss potential privacy concerns 94 regarding the information to be exposed, as well as potential 95 security issues of the proposed mechanisms. 97 2. Firewall Traversal 99 2.1. Problem Statement 101 Today UDP is often blocked by firewalls, or only enabled for a few 102 well-known applications. However, this makes it hard to deploy new 103 services on top of UDP. 105 For a long time UDP has not been used much for high volume traffic 106 and therefore it was assumed that most UDP traffic is spam or attack 107 traffic. This is not true anymore. The volume of (good) UDP traffic 108 is growing, mostly due to voice and video (real-time) services, e.g. 109 RTCWEB uses UDP for data and media, where TCP is not suitable anyway. 111 Even if firewall administrators are willing to implement new rules 112 for UDP services, it is hard to track session state for UDP traffic. 113 As UDP is unidirectional, it is unknown whether the receiver is 114 willing to accept the connection. Further there is no way to figure 115 how long state must be maintained once established. To efficiently 116 establish state along the path we need an explicit contract, as is 117 done implicitly with TCP today. 119 2.2. Information Exposure 121 To maintain state in the network, it must be possible to easily 122 assign each packet to a session that is passing a certain network 123 node. This state should be bound to something beyond the five-tuple 124 to link packets together. In [I-D.trammell-spud-req] propose the use 125 of identifiers "tubes". This allows for differential treatment of 126 different packets within one five-tuple flow, presuming the 127 application has control over segmentation and can provide 128 requirements on a per-tube basis. Tube IDs must be hard to guess: a 129 tube ID in addition to a five-tuple as an identifier, given 130 significant entropy in the tube ID, provides an additional assurance 131 that only devices along the path or devices cooperating with devices 132 along the path can send packets that will be recognized by 133 middleboxes and endpoints as valid. 135 Further, to maintain state, the sender must explicitly indicate the 136 start and end of a tube to the path, while the receiver must confirm 137 connection establishment. This, together with the first packet 138 following the confirmation, provides a guarantee of return 139 routability; i.e. that the sender is actually at the address it says 140 it is. This impies all SPUD tubes must be bidirectional, or at least 141 support a feedback channel for this confirmation. Even though UDP is 142 not a bidirectional transport protocol, often services on top of UDP 143 are bidirectional anyway. Even if not, we only require one packet to 144 acknowledge a new connection. This is low overhead for this basic 145 security feature. This connection set-up should not impose any 146 additional start-up latency, so the sender must be also able to send 147 payload data in the first packet. 149 If a firewall blocks a SPUD packet, it can be beneficial for the 150 sender to know why the packet was blocked. Therefore a SPUD-aware 151 middlebox should be able to send error messages. Such an error 152 message can either be sent directly to the sender itself, or 153 alternatively to the receiver that can decide to forward the error 154 message to a sender or not. 156 2.3. Mechanism 158 A firewall or middlebox can use the tube ID as an identifier for its 159 session state information. If the tube ID is large enough it will be 160 hard for a non-eavesdropping attacker to guess the ID. 162 If a firewall receives a SPUD message that signals the start of a 163 connection, it can decide to establish new state for this tube. 164 Alternatively, it can also forward the packet to the receiver and 165 wait if the connection is wanted before establishing state. To not 166 require forwarding of unknown payload, a firewall might want to 167 forward the initial SPUD packet without payload and only send the 168 full packet if the connection has be accepted by the receiver. 170 The firewall must still maintain a timer to delete the state of a 171 tube if no packets were received for a while. However, if a end 172 signal is received the firewall can remove the state information 173 faster. 175 If a firewall receives a SPUD message which does not indicate the 176 start of a new tube and no state is available for this tube, it may 177 decide to block the traffic. This can happen if the state has 178 already timed out or if the traffic was rerouted. In addition a 179 firewall may send an error message to the sender or the receiver 180 indicatng that no state information are available. If the sender 181 receives such a message it can resend a start signal (potentially 182 together with other tube state information) and continue its 183 transmission. 185 2.4. Deployment Incentives 187 It is not expected that the provided SPUD information will enable all 188 generic UDP-based services to safely pass firewalls , however, for 189 new services that a firewall administrator is willing to allow, it 190 makes state handling easier. 192 For application developers that actually would like to use a new 193 transport services, there are today often only two choices; 194 encapsulation over UDP or over TCP. SPUD already provides 195 encapsulation over UDP as well as maintains (a few) additional 196 information about the network state. This shim layer can support 197 application developers to more easily implement new services. 199 2.5. Trust and Privacy 201 We proposed to limit the scope of the tube ID to the five-tuple. 202 While this makes the tube ID useless for session mobility, it does 203 mean that the valid ID space is sufficiently sparse to maintain the 204 "hard to guess" property, and prevents tube IDs from being misused to 205 track flows from the same endpoint across multiple addresses. This 206 limitation may need further discussion. 208 By providing information on the connection start up, SPUD only 209 exposes information that are often already given in the higher layer 210 semantics. Thus it does not expose additional information, it only 211 makes the information explicit and accessible without specific 212 higher-layer/application-level knowledge. 214 3. State Lifetime Discovery 216 3.1. Problem Statement 218 Even if the transport protocol implements a close-down mechanism or 219 SPUD explicitly provides an end of tube signal, a network device 220 cannot assume that these signals are provided reliably. Therefore 221 each network device that holds per-flow/per-tube state must implement 222 a mechanism to remove the state if no traffic that is matching this 223 state information has been observer for a while. Usually this is 224 realized by maintaining a timeout since the last observed packet. 226 An endpoint that wants to keep a connection open even if it is not 227 sending any data for a while might need to send heartbeat packets to 228 keep state alive that potentially is store somewhere on the network 229 path. However, the timeout period of the network device storing this 230 information is unknow to the endpoint. Therefore it has to send 231 heartbeat fairly rapidly, or might assume a default value of 150ms 232 that is commonly used today. 234 3.2. Information Exposure 236 SPUD can be used to request the timeout used by a middlebox. As 237 SPUD-enabled endpoint therefore sends a path-to-endpoint option that 238 is initialized with an non-valid value (e.g. 0) and midpoints can 239 update this information to the timeout value that is used to maintain 240 per-tube state. As multiple network devices might be on a path that 241 maintain per-tube state, the timeout information should only be 242 updated to the minimum value. A sender could also initial the 243 timeout value to the minimum heartbeat frequency it will use or the 244 maximum idle period (if known). 246 [Editor's note: Would it be necessary/useful to get a (separate) 247 confirmation from each middlebox that has understood and read this 248 SPUD information? Alternatively, it would maybe be useful signal the 249 proposed heartbeat period separately, however that's also complicated 250 because the endpoint might adapt it's heartbeat period based on the 251 timeout information...] 253 3.3. Mechanism 255 If a network device that uses a timeout to remove per-tube state 256 receives a SPUD timeout information request, it should expose its own 257 timeout value if smaller than the one already given in the SPUD 258 header. Alternatively, if a value is already given, it might decide 259 to use the given value as timeout for the state information of this 260 tube. 262 A SPUD sender can request the timeout used by network devices on path 263 to maintain state. If a minimum heartbeat frequency is used or the 264 maximum idle period is known, the sender might pre-set this value. 265 If the pre-set value is not changed, the sender does not know if 266 there is at least one SPUD-aware middlebox on the path that 267 understands the time-out information. In any case a sender must 268 always assume that there could be additional non-SPUD aware middlebox 269 that has a smaller timeout. Therefore even if the proposed timeout 270 is used for heartbeating, traffic can still be blocked due to removed 271 state. This is also the case if a middlebox did not correctly 272 indicate its timeout value, e.g. when the value is dynamically 273 changed to a smaller value if more state needs to be maintained. 274 However, usually the number of middleboxes on the path that hold per- 275 flow/tube state is low. Therefore the chance that the received 276 feedback indicates the right timeout value is high. 278 [Editor's note: Do we need a SPUD message that can be initialized by 279 the middlebox to let the endpoint know that the time has changed?] 281 A SPUD endpoint receiving a SPUD header with timeout information 282 should reflect this information to the sender with the next packet 283 that it will be sent (or after a short timeout). Therefore this 284 information should be requested with the first packet, that should 285 immediately trigger the receiver to at least send one packet. In 286 addition SPUD-aware nodes on the backward path are able to also 287 signal their timeout. 289 [Editor's note: Is it necessary to have an explicit SPUD heartbeat 290 packet, that should also be reflected by the receiver to keep state 291 on the backwards path alive..? And then request timeouts for the 292 forward and backward path separately?] 294 3.4. Deployment Incentives 296 Initially, if not widely deployed, there will be not much benefit to 297 using this extension. However, an endpoint can never be sure that 298 all middleboxes on the path that maintain state information based on 299 a timeout will expose this information (correctly). An endpoint must 300 always be prepared that traffic can be blocked (after an idle period) 301 and the connection must be restarted. This is the same today if 302 heartbeats are used. Therefore, SPUD will not help to simplify the 303 implementation but it will also no make it much more complicated as 304 only the heartbeat interval might be changed. 306 However, under the assumption that there are usually only a small 307 number of middbleboxes on one network path that hold (per-tube) state 308 information, it is likely that if information is exposed by a 309 middlebox, this information is correct and can be used. 311 The more SPUD gets deployed, the more often endpoints will be able to 312 set the heartbeat interval correctly. This will reduce the number of 313 unnecessary reconnects that cause additional latency. Further, an 314 endpoint might be able to request a higher timeout by pre-setting the 315 value. 317 Network nodes that understand the SPUD timeout information and expose 318 their timeouts are able to handle timeouts more flexibly, e.g. 319 announcing lower timeout values if space is sparse. Further if an 320 endpoint announces a low pre-set value because the endpoint knows 321 that it will only have short idle periods, the timeout interval could 322 be reduced. 324 3.5. Trust, Privacy and Security 326 [Editor's note: no trust needed here as discussed above... right? 327 And I currently don't see privacy issues here...?'] 329 [Editor's note: Make sure this is not a vector for simplified state 330 exhaustion attacks...? Don't think it's worse than TCP...? Any other 331 attacks?] 333 4. Low-Latency Service 335 4.1. Problem Statement 337 Networks are often optimized for low loss rates and high throughput 338 by providing large buffers that can absorb traffic spikes or rate 339 variations and always holding enough data to keep the link full. 340 This is beneficial for applications like high-priority bulk transfer, 341 where only the total transfer time is of interest. (High volume) 342 interactive application, such as video calls, however, have very 343 different requirements. Usually these application can tolerate 344 high(er) loss rates, as they anyway cannot wait for missing data to 345 be retransmitted, while having hard latency requirements necessary to 346 make their service work. 348 Large network buffers may induce high queuing delays due to greedy 349 cross traffic using loss-based congestion control that periodically 350 fills the buffer. In loss-based congestion control the sending rate 351 is periodically increased until a loss is observed to probe for 352 available bandwidth. Unfortunately, the queuing delay that is 353 indices by this probing can downgrade the quality of experience for 354 competing interactive applications or even make them simply unusable. 355 Further, to co-exist with greedy flows that use loss-based congestion 356 control, one has to react based on the same feedback signal (loss) 357 and implement about the same aggressiveness than these competing 358 flows. 360 4.2. Information Exposure 362 While large buffers that are able to absorb traffic spikes that are 363 often induced by short bursts are beneficial for some applications, 364 the queuing delay that might be induced by these large buffers is 365 very harmful to other applications. We therefore propose an explicit 366 indication of loss- vs. latency-sensitivity per SPUD tube. This 367 indication does not prioritize one kind of traffic over the other: 368 while loss-sensitive traffic might face larger buffer delay but lower 369 loss rate, latency-sensitive traffic has to make exactly the opposite 370 tradeoff. 372 Further, an application can indicate a maximum acceptable single-hop 373 queueing delay per tube, expressed in milliseconds. While this 374 mechanism does not guarantee that sent packets will experience less 375 than the requested delay due to queueing delay, it can significantly 376 reduce the amount of traffic uselessly sitting in queues, since at 377 any given instance only a small number of queues along a path 378 (usually only zero or one) will be full. 380 4.3. Mechanism 382 A middlebox may use the loss-/latency-sensitive signal to assign 383 packet to the appropriate service if different services are 384 implemented at this middlebox. Today's traffic, that does not 385 indicate a low loss or low latency preference, would still be 386 assigned to today's best-effort service, while a new low latency 387 service would be introduced in addition. 389 The simplest implementation of such a low latency service (without 390 disturbing existing traffic) is to manage traffic with the latency- 391 sensitive flag set in a separate queue. This queue either, in 392 itself, provides only a short buffer which induces a hard limit for 393 the maximum (per-queue) delay or uses an AQM (such as PIE/ CoDel) 394 that is configured to keep the queuing delay low. 396 In such a two-queue system the network provider must decides about 397 bandwidth sharing between both services, and might or might not 398 expose this information. Initially there will only be a few flows 399 that indicate low latency preference. Therefore at the beginning 400 this service might have a low maximum bandwidth share assigned in the 401 scheduler. However, the sharing ratio should be adopted to the 402 traffic load/number of flows in each service class over time. This 403 can be done manually by a network administrator or in an automated 404 way. 406 Applications and endpoints setting the latency sensitivity flag on a 407 tube must be prepared to experience relatively higher loss rates on 408 that tube, and might use techniques such as Forward Error Correction 409 (FEC) to cope with these losses. 411 If in addition the maximum per-hop delay is indicated by the sender, 412 a SPUD-aware router might drop any packet which would be placed in a 413 queue that has more than the maximum single-hop delay at that point 414 in time before queue admission. Thereby the overall congestion can 415 be reduced early instead of withdrawing the packet at the receiver 416 after it has blocked network resources for other traffic. 417 Alternatively, a SPUD-aware node might only remove the payload and 418 add a SPUD error message, to report what the problem is. 420 An endpoint indicating the maximum per-hop delay must be aware that 421 is might face higher loss rates under congestion than competing 422 traffic on the same bottleneck. Especially, packets might be dropped 423 due to the maximium per-hop delay indication before any congestion 424 notification is given to any other competing flows on the same 425 bottleneck. This should considered in the congestion reaction as any 426 loss should be consider as a sign for congestion. 428 4.4. Deployment Incentives 430 Application developers go to a great deal of effort to make latency- 431 sensitive traffic work over today's Internet. However, if large 432 delays are induced by the network, an application at the endpoint 433 cannot do much. Therefore applications can benefit from further 434 support by the network. 436 Network operators have already realized a need to better support low 437 latency services. However, they want to avoid any service 438 degradation for existing traffic as well as risking stability due to 439 large configuration changes. Introducing an additional service for 440 latency-sensitive traffic that can exist in parallel to today's 441 network service (or potentially fully replace today's service at some 442 point in future...) helps this problem. 444 4.5. Trust and Privacy 446 An application does not benefit from wronly indicating loss- or 447 latency-sensitivity as it has to make a tradeoff between low loss and 448 potential high delay or low delay and potential high loss. Therefore 449 there is no incentive for lying. A simple classification of traffic 450 in loss-sensitive and latency-sensitive does not expose privacy- 451 critical information about the user's behavior. 453 5. Application-Limited Flows 455 5.1. Problem Statement 457 Today, there are a large number of flows that are mostly application- 458 limited, where the application can adapt this limit to changing 459 traffic conditions. An example is unicast streaming video where the 460 coding rate can be adapted based on detected congestion or changing 461 link characteristics. This adaptation is difficult, since cross- 462 traffic (much of which uses TCP congestion control) will often probe 463 for available bandwidth more aggressively than the application's 464 control loop. Further complicating the situation is the fact that 465 rate adaptation may have negative effects on the user's quality of 466 experience, and should therefore be done infrequently. 468 5.2. Information Exposure 470 With SPUD, the sender can provide an explicit indication of the 471 maximum data rate that the current encoding needs. This can provide 472 useful information to the bottleneck to decide how to correctly treat 473 the corresponding tube, e.g. setting a rate limit or scheduling 474 weight if served from its own queue. 476 Further, a network node that imposes rate shaping could expose the 477 rate limit to the sender if requested. This would help the sender to 478 choose the right encoding and simplifies probing. If the rate 479 limited is changed the network node might want to signal this change 480 without being requested for it. 482 In addition, both the endpoint as well as a middlebox could announce 483 sudden changes in bandwidth demand/offer. While for the endpoint it 484 might be most important to indicate that the bandwidth demand has 485 increased, a middlebox could indicate if more bandwidth is 486 (currently) available. Note that this information should only be 487 indicated if the network node was previously the bottleneck/the out- 488 going link is fully loaded. Further, if the information that 489 bandwidth is available is provided to multiple endpoints at the same 490 time, there is a higher risk of overloading the network as all 491 endpoints might increase their rate at the same time. 493 [Editor's note: Should a middlebox even indicate how much capacity is 494 available.. or 1/n of the available capacity if indicated to n 495 endpoints? But there might be a new bottleneck now...] 497 5.3. Mechanism 499 If the maximum sending rate of a flow is exposed this information 500 could be used to make routing decision, if e.g. two paths are 501 available that have different link capacity and average load 502 characteristics. 504 Further, a network nodes, that receives an indication of the maximum 505 rate limit for a certain tube, might decide to threat this flow in an 506 own queue and prioritize this flow in order to keep the delay low as 507 long as the indicated rate limit is not exceeded. This should only 508 be done if there is sufficient capacity on the link (the average load 509 over a previous time period has be low enough to serve an additional 510 maximum traffic load as indicated by the rate limit) or the flow is 511 known to have priority, e.g. based on additional out-of-band 512 signaling. If the link, however, is currently congested, a middlebox 513 might choose to ignore this information or indicate a lower rate 514 limit. 516 If a network node indicates rate shaping, this information can be 517 used by the sender to choose its current data/coding rate 518 appropriately. However, a sender should still implement a mechanism 519 to probe ifor available bandwidth to verify the provided information. 520 As a certain rate limit is expected the sender should probe carefully 521 around this rate. 523 A network node might further indicate a different/lower rate limit 524 during the transmission. However, in this case, it might be easy for 525 an attacker to send a wrong rate limit, therefore an endpoint should 526 not change its data rate immediately, but might be prepared to see 527 higher losses rates instead. 529 If a sender receives an indication that more bandwidth is available 530 it should not just switch to a higher rate but probe carefully. 531 Therefore it might step-wise increase its coding rate or first add 532 additional FEC information which will increase the traffic rate on 533 the link and at the same time provide additional protection as soon 534 as the new capacity limit is reached. 536 A network node that receives an indication that a flow will increase 537 its rate abruptly, might prioritize this flow for a certain (short) 538 time to enable a smoother transition. [Editor's node: Need to figure 539 out if high loss/delay when the coding rate is increased is actually 540 a problem and if so further evaluate if short-term prioritization 541 helps.] 543 5.4. Deployment Incentives 545 By indicating a maximum sending rate a network operator might be able 546 to better handle/schedule the current traffic. Therefore the network 547 operator might be willing to support these kind of flows explicitly 548 by trying to serve the flow with the requested rate. This can 549 benefit the service quality and increase the user's satisfaction with 550 the provided network service. 552 If the maximum sending rate is known by the application, the 553 application might be willing to expose this information if there is a 554 chance that the network will try to support this flow by providing 555 sufficient capacity. 557 Currently application have no good indication when to change their 558 coding rate. Especially, increasing the rate is hard. Further, it 559 should be avoided to change the rate (forth and back) too often. An 560 indication if and how much bandwidth is available, is therefore 561 helpful for the application and can simplify probing (even though 562 there will still and always be an additional control loop needed to 563 react to congestion and for probing). 565 5.5. Trust, Privacy and Security 567 [TBD] [Editor's note: is there an attack possible by indicating a low 568 limit (from or to the application)? Note, that the application 569 should not rely on this information and still probe for more capacity 570 (if needed) and react to congestion!] 572 6. Service Multiplexing 574 6.1. Problem Statement 576 Many services rewuire multiple parallel transmissions to transfer 577 different kinds of data which usually have a clear priority between 578 each other. One example is WebRTC where the audio is most important 579 and should be higher prioritized than the video, while control 580 traffic might have the lowest priority. Further, some packets within 581 one flow might be more important than others within the same flow/ 582 tube, e.g. such as I-frames in video transmissions. However, today a 583 network will treat all packets the same in case of congestion and 584 might e.g. drop audio packets while video and control traffic are 585 still transmitted. 587 6.2. Information Exposure 589 A SPUD sender may indicate a lower priority relative to another tube 590 that is used in the same 5-tuple. 592 Similarly, a lower packet priority within one flow/tube could be 593 indicated to give one packet a low priority than other packets with 594 the same tube ID. This information can be used to preferentially 595 drop less inportant packets e.g. carrying information that could be 596 recovered by FEC or where missing data can be easily concealed. 598 Further, with a stronger integration of codec and transport 599 technology SPUD could even indicate more even finer grained priority 600 levels to provide automatic graceful degradation of service within 601 the network itself. 603 [Editor's note: do we want to also provide per-packet information 604 over spud? Or would all lower priority packets of one flow simply 605 below to a different tube? In this case can we send a SPUD start 606 message with more than on tube ID?] 608 6.3. Mechanism 610 Preferential dropping can be implemented by a router queue in case 611 packets need to be dropped due to congestion. In this case the 612 router might not drop the incoming packet but look for a packet with 613 the same tube ID that is already in the queue and has a lower 614 priority than to actual packet that should have been dropped. Note 615 that a middlebox should only drop a different packet if there is 616 currently a lower priority packet in the queue, because it otherwise 617 does not know whether it will every see a lower priority packet for 618 this flow. This could cause unfairness issues. Therefore a 619 middlebox might need to hold additional state, e.g. keeping position 620 of the last low priority packet of each tube in a separate table. 621 The chance that a low priority packet of the same or corresponding 622 tube currently sits in the queue, is lower the smaller the buffer is. 623 Therefore for low-latency, real-time services, there is a tradeoff. 625 Alternatively, the middlebox might queue the lower priority traffic 626 in a different queue. Using a different queue might be suitable for 627 lower flow priority but should not be used for lower priority packets 628 within the same flow as this can also lead to other issues such as 629 high reordering. Further, using a lower priority queue will not only 630 give higher priority to the traffic belong to the same service/sender 631 but also to all other competing flows. This is usually not the 632 intention. 634 [Editor's note: Does it makes sense to, in addition, rate-limit the 635 higher prirority flows to their current rate to make sure that the 636 bottleneck is not further overloaded...?] 638 If a sender has indicated lower priority to certain tubes and only 639 experiences losses/congestion for the lower priority tubes, the 640 sender should still not increase its sending for the higher priority 641 tube and might even consider to decrease the sending rate for the 642 higher prioroty tubes as well. Potentially a (delay-based) mechanism 643 for shared bottleneck detection should be used to ensure that all 644 transmissions actually share the same bottleneck. 646 6.4. Deployment Incentives 648 [Editor's note: similar as above -> support of interactive services 649 increases costumer satisfaction...] 651 6.5. Trust and Privacy 653 As only lower priority should be indicated, it is harder to use this 654 information for an attack. 656 [Editor's note: Do not really see any trust or privacy concerns 657 here...?] 659 7. Acknowledgements 661 This document grew in part out of discussions of initial use cases 662 for middlebox cooperation at the IAB SEMI Workshop and the IETF 92 663 SPUD BoF; thanks to the participants. 665 8. IANA Considerations 667 This memo includes no request to IANA. 669 9. Security Considerations 671 Security and privacy considerations for each use case are given in 672 the corresponding subsection. 674 10. Informative References 676 [I-D.trammell-spud-req] 677 Trammell, B. and M. Kuehlewind, "Requirements for the 678 design of a Substrate Protocol for User Datagrams (SPUD): 679 draft-trammell-stackevo-spud-req-00 (To be published 680 soon)", 2015. 682 Authors' Addresses 684 Mirja Kuehlewind 685 ETH Zurich 686 Zurich, Switzerland 688 Email: mirja.kuehlewind@tik.ee.ethz.ch 690 Brian Trammell 691 ETH Zurich 692 Zurich, Switzerland 694 Email: ietf@trammell.ch