idnits 2.17.1 draft-briscoe-conex-initial-deploy-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 (November 24, 2011) is 4509 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Seawall' is defined on line 391, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-conex-abstract-mech-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ConEx B. Briscoe 3 Internet-Draft BT 4 Intended status: Informational November 24, 2011 5 Expires: May 27, 2012 7 Initial Congestion Exposure (ConEx) Deployment Examples 8 draft-briscoe-conex-initial-deploy-01 10 Abstract 12 This document gives examples of how ConEx deployment might get 13 started, focusing on unilateral deployment by a single network. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on May 27, 2012. 32 Copyright Notice 34 Copyright (c) 2011 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Recap: Incremental Deployment Features of the ConEx 51 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. ConEx Components . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.1. Recap of Basic ConEx Components . . . . . . . . . . . . . 4 54 3.2. Per-Network Deployment Concepts . . . . . . . . . . . . . 4 55 4. Example Initial Deployment Arrangements . . . . . . . . . . . 5 56 4.1. Single Receiving Network Scenario . . . . . . . . . . . . 5 57 4.1.1. ConEx Functions in the Single Receiving Network 58 Scenario . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.1.2. Incentives to Unilaterally Deploy ConEx in a 60 Receiving Network . . . . . . . . . . . . . . . . . . 8 61 4.2. Mobile Network Scenario . . . . . . . . . . . . . . . . . 9 62 4.3. Scenario Internal to a Multi-Tenant Data Centre . . . . . 9 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 67 9. Informative References . . . . . . . . . . . . . . . . . . . . 10 68 Appendix A. Summary of Changes between Drafts . . . . . . . . . . 10 70 1. Introduction 72 This document gives examples of how ConEx deployment might get 73 started, focusing on unilateral deployment by a single network. 75 2. Recap: Incremental Deployment Features of the ConEx Protocol 77 The ConEx mechanism document [ConEx-Abstract-Mech] goes to great 78 lengths to design for incremental deployment in all the respects 79 below. It should be referred to for precise details on each of these 80 points: 82 o The ConEx mechanism is essentially a change to the source, in 83 order to re-insert congestion feedback into the network. 85 o Source-host-only deployment is possible without any negotiation 86 required, and individual transport protocol implementations within 87 a source host can be updated separately. 89 o Receiver modification may optionally improve ConEx for some 90 transport protocols with feedback limitations (TCP being the main 91 example), but it is not a necessity 93 o Proxies for the source and/or receiver are feasible (though not 94 necessarily straightforward) 96 o Queues and network forwarding do not require any modification for 97 ConEx. 99 o ECN is not required in the network for ConEx. If some network 100 nodes support ECN, it can be used by ConEx. 102 o ECN is not required at the receiver for ConEx. The sender should 103 nonetheless attempt to negotiate ECN-usage with the receiver, 104 given some aspects of ConEx work better the more ECN is deployed, 105 particularly auditing and border measurement. 107 o Given ConEx exposes information for IP-layer policy devices to 108 use, the design does not preclude possible innovative uses of 109 ConEx information by other IP-layer devices, e.g. forwarding 110 itself 112 o Packets indicate whether or not they support ConEx. 114 3. ConEx Components 116 3.1. Recap of Basic ConEx Components 118 [ConEx-Abstract-Mech] introduces the following components: 120 o The ConEx Wire Protocol 122 o Forwarding devices (unmodified) 124 o Sender (modified for ConEx) 126 o Receiver (optionally modified) 128 o Audit 130 o Policy Devices: 132 * Rest-of-Path Congestion Monitoring Devices 134 * Congestion Policers 136 [ConEx-Abstract-Mech] should be referred to for definitions of each 137 of these components and further explanation. 139 3.2. Per-Network Deployment Concepts 141 Network deployment-related definitions: 143 Internet Ingress: The first IP node a packet traverses that is 144 outside the source's own network. In a domestic network that will 145 be the first node downstream from the home access equipment. In 146 an enterprise network this is the provider edge router. 148 Internet Egress: The last IP node a packet traverses before reaching 149 the receiver's network. 151 ConEx-Enabled Network: A network whose edge nodes implement ConEx 152 policy functions. 154 Each network can unilaterally choose to use any ConEx information 155 given by those sources using ConEx, independently of whether other 156 networks use it. 158 Typically, a network will use ConEx information by deploying a policy 159 function at the ingress edge of its network to monitor arriving 160 traffic and to act in some way on the congestion information in those 161 packets that are ConEx-enabled. Actions might include policing, 162 altering the class of service, or re-routing. Alternatively, less 163 direct actions via a management system might include triggering 164 capacity upgrades, triggering penalty clauses in contracts or levying 165 charges between networks based on ConEx measurements. 167 Typically, a network using ConEx info will deploy a ConEx policy 168 function near the ingress edge and a ConEx audit function near the 169 egress edge. The segment of the path between a ConEx policy function 170 and a ConEx audit function can be considered to be a ConEx-protected 171 segment of the path. Assuming a network covers all its ingresses and 172 egresses with policy functions and audit functions respectively, the 173 network within this ring will be a ConEx-protected network. 175 Of course, because each edge device usually serves as both an ingress 176 and an egress, the two functions are both likely to be present in 177 each edge device. 179 4. Example Initial Deployment Arrangements 181 In all the deployment scenarios below, we assume that deployment 182 starts with some data sources being modified with ConEx code. The 183 rationale for this is that the developer of a scavenger transport 184 protocol like LEDBAT has a strong incentive to tell the network how 185 little congestion it is causing despite sending large volumes of 186 data. In this case the developer makes the first move expecting it 187 will prompt at least some networks to move in response--so that they 188 use the ConEx information to reward users of the scavenger protocol. 190 4.1. Single Receiving Network Scenario 192 The name 'Receiving Network' for this scenario merely emphasises that 193 most data is arriving from connected networks and data centres and 194 being consumed by residential customers on this access network. Some 195 data is of course also travelling in the other direction. 197 DSLAMs __ 198 /|/ ,-.Home-a 199 __/__| |-----( ) 200 ,-----. / \ | |--- `-' 201 ,---. / \ ,------P/ \|\__ 202 / \ ' Core '/| BRAS | __ 203 ( Peer )-->-|P | '------' /|/ 204 \ / | | _____| |--- 205 '---` ' '\,------./ | |--- 206 \ M / |BRAS | \|\__ 207 `-----' '------A\ __ 208 | P| \ /|/ 209 /|\ /|\ \__\_| |--- ,-. 210 ,---. ,---. / | |-----( ) 211 /Data \ / \ \|\__ `-'Home-b 212 ( Centre) ( CDN ) 213 \ / \ / Access Network 214 '---` '---` <-------------> 216 P=Congestion-Policer; M=Congestion-Monitor; A=Audit function 218 Figure 1: Single Receiving Network Scenario 220 Figure Figure 1 is an attempt to show the salient features of a ConEx 221 deployment in a typical broadband access provider's network (within 222 the constraints of ASCII art). Broadband remote access servers 223 (BRASs) control access to the core network from the access network 224 and vice versa. Home networks (and small businesses) connect to the 225 access network, but only two are shown. 227 In this diagram, all data is travelling towards the access network of 228 Home-b, from the Peer network, the Data centre, the CDN and Home-a. 229 Data actually travels in both directions on all links, but only one 230 direction is shown. 232 The data centre, core and access network are all run by the same 233 network operator, but each is the responsibility of a different 234 department with internal accounting between them. The content 235 distribution network (CDN) is operated by a third party CDN provider, 236 and of course the peer network is also operated by a third party. 238 This operator of the data centre, core and access network is the only 239 one in the diagram to have deployed ConEx monitoring and policy 240 devices at the edges of its network. However, it has not enabled ECN 241 on any of its network elements and neither has any other network in 242 the diagram. The operator has deployed a congestion policing 243 function (P) on the provider-edge router where the peer attaches to 244 its core, on the BRAS where the CDN attaches and on the other BRAS 245 where each of the residential customers like Home-a attach. On the 246 provider-edge router where the data centre attaches it has deployed a 247 congestion monitoring function (M). Each of these policing and 248 monitoring functions handles the aggregate of all traffic traversing 249 it, for all destinations. 251 The operator has deployed an audit function on each logical output 252 port of the BRAS for each end-customer site like Home-b. The Audit 253 function handles the aggregate of all traffic for that end-customer 254 from all sources. For traffic in the opposite direction (e.g. from 255 Home-b to Home-a, there would be equivalent policing (P) and audit 256 (A) functions in the converse locations to those shown. 258 Some content sources in the CDN and in the data centre are using the 259 ConEx protocol, but others are not. There is a similar situation for 260 hosts attached to the Peer network and hosts in home networks like 261 Home-a: some are sending ConEx packets at least for bulk data 262 transports, while others are not. 264 4.1.1. ConEx Functions in the Single Receiving Network Scenario 266 Within the BRAS there are logical ports that model the rate of each 267 access line from the DSLAM to each home network [TR-059]. They are 268 fed by a shared queue that models the rate of the downstream link 269 from the BRAS to the DSLAM (sometimes called the backhaul network). 270 If there is congestion anywhere in the set of networks in Figure 271 Figure 1 it is nearly always: 273 o either self-congestion in the queues into the logical ports 274 representing the access lines 276 o or shared congestion in the shared queue on the BRAS that feeds 277 them. 279 Any ConEx sources sending data through this BRAS will receive 280 feedback about these losses from the destination and re-insert it as 281 ConEx markings into the data. Figure 2 shows an example plot of the 282 loss levels that might be seen at different monitoring points along a 283 path between the data centre and home-b, for instance. The top half 284 of the figure shows the loss probability within the BRAS consists of 285 0.1% at the shared queue and 0.2% self-congestion in the logical 286 output port that models the access line, making 0.3% in total. This 287 upper diagram also shows whole path congestion as signalled by the 288 ConEx sender, which remains unchanged along the whole path at 0.3%. 290 The lower half of the figure shows (downstream congestion) = (whole 291 path) - (upstream congestion). Upstream congestion can only be 292 monitored locally where the loss actually happens (within the BRAS 293 output queues). Nonetheless, given there is rarely loss anywhere 294 else but within the BRAS, this limitation is not significant in this 295 scenario. The lower half of the figure also shows the location of 296 the policing and audit functions. Policing anywhere within or 297 upstream ofthe BRAS will be based on the downstream congestion level 298 of 0.3%. While Auditing within the BRAS but after all the queues can 299 check that the whole path congestion signalled by ConEx is no less 300 than the loss levels experienced within the BRAS itself. 302 Data centre-->|<--core-->|<------BRAS--------->|<--Home-- 303 | | 304 ^loss |<-Shared->|<-Access->| 305 |probability backhaul 306 | 307 0.3%|- - - - - - - - - - - - - - - - - - - - +----------------- 308 | whole path congestion | 309 | | 310 | |upstream 311 0.1%| +---------+congestion 312 | | 313 -O==============================+-----------------------------> 314 monitoring point 315 ^loss 316 |probability Policing Audit 317 | | | 318 | V | 319 0.3%|----------------O-------------+ | 320 | |downstream | 321 0.2%| +---------+ | 322 | congestion| | 323 | | | 324 | | V 325 -O----------------------------------------+====O============--> 326 monitoring point 328 Figure 2: Example plot of loss levels along a path 330 4.1.2. Incentives to Unilaterally Deploy ConEx in a Receiving Network 332 Even a sending application that is modified to use ConEx can choose 333 whether to send ConEx or Not-ConEx packets. Nonethelss, ConEx 334 packets bring information to a policer about congestion expected on 335 the rest of the path beyond the policer. Not-ConEx packets bring no 336 such information. Therefore a network that has deployed ConEx 337 policers will tend to rate-limit not-ConEx packets conservatively in 338 order to manage the unknown risk of congestion. In contrast, a 339 network doesn't normally need to rate-limit ConEx-enabled packets 340 unless they reveal a persistently high contribution to congestion. 341 This natural tendency for networks to favour senders that provide 342 ConEx information encourages senders to choose to use the ConEx 343 protocol whenever they can. 345 {ToDo: complete this section} 347 4.2. Mobile Network Scenario 349 Placeholder for summary of the scenario in a mobile network described 350 in [conex-mobile] 352 In mobile networks, both mobile terminals and mobile network 353 equipment are standardised by the 3GPP. If the 3GPP were to adopt 354 the ConEx protocol, it might mandate ConEx implementation for 355 compliant equipment. 357 {ToDo: Describe how a central traffic management box can arrange to 358 remotely view upstream congestion as it would be seen from the 359 interface with the mobile terminal.} 361 4.3. Scenario Internal to a Multi-Tenant Data Centre 363 A number of companies offer hosting of virtual machines on their data 364 centre infrastructure--so-called infrastructure as a service (IaaS). 365 A set amount of processing power, memory, storage and network are 366 offered. Although processing power, memory and storage are 367 relatively simple to allocate on the 'pay as you go' basis that has 368 become common, the network is less easy to allocate given it is a 369 naturally distributed system. 371 {ToDo: Complete this section.} 373 5. Security Considerations 375 6. IANA Considerations 377 This document does not require actions by IANA. 379 7. Conclusions 381 {ToDo} 383 8. Acknowledgments 384 9. Informative References 386 [ConEx-Abstract-Mech] Mathis, M. and B. Briscoe, "Congestion 387 Exposure (ConEx) Concepts and Abstract 388 Mechanism", draft-ietf-conex-abstract-mech-03 389 (work in progress), October 2011. 391 [Seawall] Shieh, A., Kandula, S., Greenberg, A., and C. 392 Kim, "Seawall: Performance Isolation in Cloud 393 Datacenter Networks", Proc 2nd USENIX Workshop 394 on Hot Topics in Cloud Computing , June 2010, 395 . 398 [TR-059] Anschutz, T., Ed., "DSL Forum Technical Report 399 TR-059: Requirements for the Support of QoS- 400 Enabled IP Services", September 2003. 402 [conex-mobile] Kutscher, D., Mir, F., Winter, R., Krishnan, 403 S., and Y. Zhang, "Mobile Communication 404 Congestion Exposure Scenario", 405 draft-kutscher-conex-mobile-00 (work in 406 progress), March 2011. 408 Appendix A. Summary of Changes between Drafts 410 Detailed changes are available from 411 http://tools.ietf.org/id/draft-briscoe-conex-initial-deploy-00.txt 413 From draft-briscoe-00 to draft-briscoe-01: Re-issued without textual 414 change. Merely re-submitted to correct a processing error causing 415 the whole text of draft-00 to be duplicated within the file. 417 Author's Address 419 Bob Briscoe 420 BT 421 B54/77, Adastral Park 422 Martlesham Heath 423 Ipswich IP5 3RE 424 UK 426 Phone: +44 1473 645196 427 EMail: bob.briscoe@bt.com 428 URI: http://bobbriscoe.net/