idnits 2.17.1 draft-wing-tsvwg-turn-flowdata-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 10, 2014) is 3516 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-11 == Outdated reference: A later version (-18) exists of draft-ietf-tsvwg-rtcweb-qos-02 == Outdated reference: A later version (-04) exists of draft-williams-peer-redirect-01 ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG D. Wing 3 Internet-Draft T. Reddy 4 Intended status: Standards Track Cisco Systems 5 Expires: March 14, 2015 B. Williams 6 Akamai, Inc. 7 R. Ravindranath 8 Cisco Systems 9 September 10, 2014 11 TURN extension to convey flow characteristics 12 draft-wing-tsvwg-turn-flowdata-01 14 Abstract 16 TURN server and the network in which it is hosted due to load could 17 adversely impact the traffic relayed through it. During such high 18 load event, it is desirable to shed some traffic but TURN server lack 19 requirements about the flows to prioritize them. This document 20 defines such a mechanism to communicate flow characteristics from the 21 TURN client to its TURN server. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 14, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Design considerations . . . . . . . . . . . . . . . . . . . . 3 60 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Sending a ChannelBind Request . . . . . . . . . . . . . . 4 62 4.2. Receiving a ChannelBind Request . . . . . . . . . . . . . 5 63 4.2.1. Conflict Resolution . . . . . . . . . . . . . . . . . 5 64 4.3. Receiving a ChannelBind Response . . . . . . . . . . . . 6 65 5. FLOWDATA format . . . . . . . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 9.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 Traversal Using Relay NAT (TURN) [RFC5766] is a protocol that is 77 often used to improve the connectivity of P2P applications. TURN 78 allows a connection to be established when one or both sides is 79 incapable of a direct P2P connection. A TURN server could be 80 provided by an enterprise network, an access network, an application 81 service provider or a third party provider. A TURN server could be 82 used to relay media streams, WebRTC data channels 83 [I-D.ietf-rtcweb-overview] , gaming, file transfer etc. A TURN 84 server and the network in which it is hosted could have insufficient 85 bandwidth or other characteristics that could adversely impact the 86 traffic relayed through it and need a mechanism to identify and 87 provide differentiated service to flows relayed through the TURN 88 server. 90 This specification provides a mechanism for the client to signal the 91 flow characteristics of a relay channel to the TURN server, so that 92 certain relay channels can receive service that is differentiated 93 from others. The TURN server authorizes the request and signals back 94 to the client that it can (fully or partially) accommodate the flow. 95 This sort of signaling will be useful for long-lived flows such as 96 media streams, WebRTC data channels etc traversing through the TURN 97 server. The TURN server can further communicate the flow information 98 to a number of on-path devices in its network using a Policy decision 99 Point (e.g. SDN controller). This way the network hosting the TURN 100 server can accommodate the flow. With this mechanism, a TURN client 101 can request the TURN server to provide certain characteristics for 102 the relayed channel on both legs (client-to-server, server-to-peer). 103 Applications using TURN as a communication relay would benefit from 104 such an arrangement as it would improve the Quality of Experience 105 (QOE) of the end user. 107 Note: It is not the intent of this document to advocate in favor of 108 prioritizing relayed candidates over host, server-reflexive 109 candidates, but to highlight the proposed mechanism only when TURN 110 server is selected for various reasons like privacy, ICE connectivity 111 checks with local host/server-reflexive candidates have failed etc. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 3. Design considerations 121 1. TURN client can choose to either use Send and Data indications or 122 channels to exchange data with its peer. For bandwidth intensive 123 applications (like video, audio, WebRTC data channels) using Send 124 indication or Data indication adds 36 bytes overhead to the 125 application data and substantially increases the bandwidth 126 required between the client and the server. Hence channels are 127 commonly used for bandwidth intensive applications to exchange 128 data. The other problem with using Send/Data indications is that 129 if the TURN server determines that a flow can only be partially 130 accommodated then this feedback cannot be conveyed back to the 131 client. Hence in this specification focuses on conveying the 132 flow characteristics only in ChannelBind request/response. 134 2. DSCP style markings can also help provide QOS, but has the 135 following limitations: 137 * DiffServ style packet marking can help provide QoS in some 138 environments but DSCP markings are often modified or removed 139 at various points in the network or when crossing network 140 boundaries. DSCP markings set by the client may be modified 141 or removed by the intervening network(s) before it reaches the 142 TURN server. 144 * DSCP values are site specific, with each site selecting its 145 own code points for each QoS level, hence it may not work 146 across domains. However [I-D.ietf-tsvwg-rtcweb-qos] 147 recommends default set of DSCP values for browsers when there 148 is no site specific information. 150 * TURN client may not be able to set DSCP values for outgoing 151 packets because of OS limitations. 153 * DSCP provides differentiated service only in the outgoing 154 direction of a flow. 156 The mechanism described in this document has none of the above 157 limitations and the following useful properties: 159 o Usable at the application level to the TURN client, without 160 needing operating system support. 162 o Robust metadata support, to convey sufficient information to the 163 TURN server about the flow. 165 4. Solution Overview 167 When a channel binding is initiated by the client, it may also 168 indicate certain characteristics of its flow to the TURN server. The 169 TURN server uses that information to prioritize the flow in its 170 network and signals back to the client that it can fully or partially 171 accommodate the flow. 173 This specification defines one new comprehension-optional STUN 174 attribute: FLOWDATA. If a TURN client wishes to signal the flow 175 characteristics of the relay channel it MUST insert this attribute in 176 ChannelBind request. This attribute if used MUST be sent only in the 177 ChannelBind request. Other specifications in future may extend this 178 attribute to be used in other STUN methods. The TURN server 179 determines if it can accommodate that flow, making configuration 180 changes if necessary to accommodate the flow, and returns information 181 in the FLOWDATA attribute indicating its ability to accommodate the 182 described flow. 184 4.1. Sending a ChannelBind Request 186 The TURN client sends ChannelBind request with the FLOWDATA STUN 187 attribute to signal the flow characteristics of the relay channel to 188 the TURN server. If the flow characteristics of a relay channel 189 change then the client MAY send ChannelBind request with an updated 190 FLOWDATA STUN attribute to refresh the binding. Similarly if the 191 binding is refreshed using ChannelBind request then the client can 192 also signal updated FLOWDATA STUN attribute if the flow 193 characteristics of the relay channel have changed. 195 4.2. Receiving a ChannelBind Request 197 When a TURN server receives a ChannelBind request that includes a 198 FLOWDATA attribute, it processes the request as per the TURN 199 specification [RFC5766] plus the specific rules mentioned below. 201 The TURN server will determine if it can provide the flow resources 202 requested by the client. The TURN server determines if the flow can 203 be fully or partially accommodated, it returns values in the FLOWDATA 204 fields that it can accommodate or returns 0 in those FLOWDATA fields 205 where it has no information. In other words if the request indicated 206 a low tolerance for delay but the TURN server determines that only 207 high delay is available, the FLOWDATA response indicates high delay 208 is available. The same sort of processing occurs on all of the 209 FLOWDATA fields of the response (upstream and downstream delay 210 tolerance, loss tolerance, jitter tolerance, minimum bandwidth, 211 maximum bandwidth). If the TURN server determines the flow can only 212 be partially accommodated and the client has also signaled CHECK- 213 ALTERNATE attribute [I-D.williams-peer-redirect] then the TURN server 214 MAY re-direct the client to an alternate TURN server that could 215 accommodate the flow characteristics conveyed by the client. 217 If the TURN server can accommodate the flow as described in the 218 FLOWDATA attribute, it sends a success response and includes the 219 FLOWDATA attribute filled in according to Section 5. The TURN server 220 SHOULD include the FLOWDATA attribute in ChannelBind response only 221 when the client had signaled FLOWDATA attribute in ChannelBind 222 request. 224 4.2.1. Conflict Resolution 226 It is possible that two hosts send requests with different thresholds 227 for delay or jitter in each direction for the same flow, and their 228 requests arrive at the same TURN server. If this occurs, it is 229 RECOMMENDED that the TURN server uses the stricter delay/loss 230 tolerance (that is, the lower tolerance to delay or jitter). The 231 diagram below depicts a conflict message flow. 233 TURN Client A TURN server TURN Client B 234 | | | 235 |-loss=med, delay=med---->|<-loss=hi, delay=hi----| 236 | | | 237 | (conflict!) | 238 | | | 239 | |--loss=med, delay=med->| 240 | | | 241 |<--loss=med, delay=med---| | 243 Figure 1: Message diagram, resolving conflict 245 In the above example if the TURN server has already responded to 246 client B before it receives the request from client A then the TURN 247 server can correct the conflict only when the client B refreshes the 248 binding. 250 4.3. Receiving a ChannelBind Response 252 When the client receives a ChannelBind success response, it proceeds 253 with processing the response according to the TURN specification 254 [RFC5766]. If the message does not include an FLOWDATA attribute, no 255 additional processing is required. The returned FLOWDATA attribute, 256 if present, indicates the accommodation of this flow the TURN server 257 will perform. This document does not define what the TURN client 258 might do with that information, but it could choose among several 259 TURN servers or use it for other purposes. 261 5. FLOWDATA format 263 This section describes the format of the new STUN attribute FLOWDATA. 264 FLOWDATA will have a type TBD-CA and length of 4 bytes. The FLOWDATA 265 attribute in the request has the following format. 267 0 1 2 3 268 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Attribute Type (TBD-CA) | Length (4) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | uDT | uLT | uJT | RSVD1 | dDT | dLT | dJT | RSVD2 | 273 +---------------------------------------------------------------+ 274 | Upstream Minimum Bandwidth | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Downstream Minimum Bandwidth | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Upstream Maximum Bandwidth | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Downstream Maximum Bandwidth | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 2: FLOWDATA attribute in request 285 Description of the fields: 287 uDT: Upstream Delay Tolerance, 0=no information available, 1=very 288 low, 2=low, 3=medium, 4=high. 290 uLT: Upstream Loss Tolerance, 0=no information available, 1=very 291 low, 2=low, 3=medium, 4=high. 293 uJT: Upstream Jitter Tolerance, 0=no information available, 1=very 294 low, 2=low, 3=medium, 4=high. 296 RSVD1: Reserved (7 bits), MUST be ignored on reception and MUST be 0 297 on transmission. 299 dDT: Downstream Delay Tolerance, 0=no information available, 1=very 300 low, 2=low, 3=medium, 4=high. 302 dLT: Downstream Loss Tolerance, 0=no information available, 1=very 303 low, 2=low, 3=medium, 4=high. 305 dJT: Downstream Jitter Tolerance, 0=no information available, 1=very 306 low, 2=low, 3=medium, 4=high. 308 RSVD2: Reserved (7 bits), MUST be ignored on reception and MUST be 0 309 on transmission. 311 Upstream Minimum Bandwidth: Measures bandwidth sent by the client. 312 Value is in octets per second. The value 0 means no information 313 is available. 315 Downstream Minimum Bandwidth: Measures bandwidth sent to the client. 316 Value is in octets per second. The value 0 means no information 317 is available. 319 Upstream Maximum Bandwidth: Measures bandwidth sent by the client. 320 Value is in octets per second. The value 0 means no information 321 is available. 323 Downstream Maximum Bandwidth: Measures bandwidth sent to the client. 324 Value is in octets per second. The value 0 means no information 325 is available. 327 Different applications have different needs for their flows. The 328 following table is derived from [RFC4594] to serve as a guideline for 329 tolerance to loss, delay and jitter for some sample applications. 330 The range 0 to 4 used for the fields in FLOWDATA attribute, meets the 331 need to convey the tolerance levels for the traffic serviced by the 332 service classes in the below table. 334 ------------------------------------------------------------------- 335 |Service Class | | Tolerance to | 336 | Name | Traffic Characteristics | Loss |Delay |Jitter| 337 |===============+==============================+======+======+======| 338 | Network |Variable size packets, mostly | | | | 339 | Control |inelastic short messages, but | Low | Low | High | 340 | | traffic can also burst | | | | 341 | | (e.g., OSPF) | | | | 342 |---------------+------------------------------+------+------+------| 343 | | Fixed-size small packets, | Very | Very | Very | 344 | Telephony | constant emission rate, | Low | Low | Low | 345 | | inelastic and low-rate flows | | | | 346 | | (e.g., G.711, G.729) | | | | 347 |---------------+------------------------------+------+------+------| 348 | Signaling | Variable size packets, some | Low | Low | High | 349 | | what bursty short-lived flows| | | | 350 |---------------+------------------------------+------+------+------| 351 | Multimedia | Variable size packets, | Low | Very | | 352 | Conferencing | constant transmit interval, | - | Low | Low | 353 | |rate adaptive, reacts to loss |Medium| | | 354 |---------------+------------------------------+------+------+------| 355 | Real-Time | RTP/UDP streams, inelastic, | Low | Very | Low | 356 | Interactive | mostly variable rate | | Low | | 357 |---------------+------------------------------+------+------+------| 358 | Multimedia | Variable size packets, |Low - |Medium| High | 359 | Streaming | elastic with variable rate |Medium| | | 360 |---------------+------------------------------+------+------+------| 361 | Broadcast | Constant and variable rate, | Very |Medium| Low | 362 | Video | inelastic, non-bursty flows | Low | | | 363 |---------------+------------------------------+------+------+------| 364 | Low-Latency | Variable rate, bursty short- | Low |Low - | High | 365 | Data | lived elastic flows | |Medium| | 366 |---------------+------------------------------+------+------+------| 367 | OAM | Variable size packets, | Low |Medium| High | 368 | | elastic & inelastic flows | | | | 369 |---------------+------------------------------+------+------+------| 370 |High-Throughput| Variable rate, bursty long- | Low |Medium| High | 371 | Data | lived elastic flows | |- High| | 372 |---------------+------------------------------+------+------+------| 373 | Standard | A bit of everything | 0 0 0 | 374 |---------------+------------------------------+------+------+------| 375 | Low-Priority | Non-real-time and elastic | High | High | High | 376 | Data | (e.g., network backup) | | | | 377 ------------------------------------------------------------------- 379 Figure 3: Flow characteristics 381 The FLOWDATA attribute in the response has the following format 383 0 1 2 3 384 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Attribute Type (TBD-CA) | Length (4) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | AuDT| AuLT| AuJT| RSVD1 | AdDT| AdLT| AdJT| RSVD2 | 389 +---------------------------------------------------------------+ 390 | Accommodated Upstream Minimum Bandwidth | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Accommodated Downstream Minimum Bandwidth | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Accommodated Upstream Maximum Bandwidth | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Accommodated Downstream Maximum Bandwidth | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Figure 4: FLOWDATA attribute in response 401 Description of the fields: 403 AuDT: Accommodated Upstream Delay Tolerance, 0=no information 404 available, 1=able to accommodate very low, 2=able to accommodate 405 low, 3=able to accommodate medium, 4=able to accommodate high. 407 AuLT: Accommodated Upstream Loss Tolerance, 0=no information 408 available, 1=able to accommodate very low, 2=able to accommodate 409 low, 3=able to accommodate medium, 4=able to accommodate high. 411 AuJT: Accommodated Upstream Jitter Tolerance, 0=no information 412 available, 1=able to accommodate very low, 2=able to accommodate 413 low, 3=able to accommodate medium, 4=able to accommodate high. 415 RSVD1: Reserved (7 bits), MUST be ignored on reception and MUST be 0 416 on transmission. 418 AdDT: Accommodated Downstream Delay Tolerance, 0=no information 419 available, 1=able to accommodate very low, 2=able to accommodate 420 low, 3=able to accommodate medium, 4=able to accommodate high. 422 AdLT: Accommodated Downstream Loss Tolerance, 0=no information 423 available, 1=able to accommodate very low, 2=able to accommodate 424 low, 3=able to accommodate medium, 4=able to accommodate high. 426 AdJT: Accommodated Downstream Jitter Tolerance, 0=no information 427 available, 1=able to accommodate very low, 2=able to accommodate 428 low, 3=able to accommodate medium, 4=able to accommodate high. 430 RSVD2: Reserved (7 bits), MUST be ignored on reception and MUST be 0 431 on transmission. 433 Accommodated Upstream Minimum Bandwidth: Bandwidth accommodated for 434 this flow. Value in bytes per second. 0 means no information is 435 available. 437 Accommodated Downstream Minimum Bandwidth: Bandwidth accommodated 438 for this flow. Value in bytes per second. 0 means no information 439 is available. 441 Accommodated Upstream Maximum Bandwidth: Bandwidth accommodated for 442 this flow. Value in bytes per second. 0 means no information is 443 available. 445 Accommodated Downstream Maximum Bandwidth: Bandwidth accommodated 446 for this flow Value in bytes per second, 0 means no information is 447 available. 449 6. Security Considerations 451 On some networks, only certain users or certain applications are 452 authorized to signal the priority of a flow. This authorization can 453 be achieved with STUN long-term authentication [RFC5389]. 455 7. IANA Considerations 457 This document defines the FLOWDATA STUN attribute, described in 458 Section 5. IANA has allocated the comprehension-optional codepoint 459 TBD-CA for this attribute. 461 8. Acknowledgement 463 Authors would like to thank Anca Zamfir and Charles Eckel for their 464 comments and review. 466 9. References 468 9.1. Normative References 470 [I-D.ietf-rtcweb-overview] 471 Alvestrand, H., "Overview: Real Time Protocols for 472 Browser-based Applications", draft-ietf-rtcweb-overview-11 473 (work in progress), August 2014. 475 [I-D.ietf-tsvwg-rtcweb-qos] 476 Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J. 477 Polk, "DSCP and other packet markings for RTCWeb QoS", 478 draft-ietf-tsvwg-rtcweb-qos-02 (work in progress), June 479 2014. 481 [I-D.williams-peer-redirect] 482 Williams, B. and T. Reddy, "Peer-specific Redirection for 483 Traversal Using Relays around NAT (TURN)", draft-williams- 484 peer-redirect-01 (work in progress), June 2014. 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, March 1997. 489 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 490 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 491 October 2008. 493 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 494 Relays around NAT (TURN): Relay Extensions to Session 495 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 497 9.2. Informative References 499 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 500 Guidelines for DiffServ Service Classes", RFC 4594, August 501 2006. 503 Authors' Addresses 505 Dan Wing 506 Cisco Systems 507 821 Alder Drive 508 Milpitas, California 95035 509 USA 511 Email: dwing@cisco.com 513 Tirumaleswar Reddy 514 Cisco Systems 515 Cessna Business Park, Varthur Hobli 516 Sarjapur Marathalli Outer Ring Road 517 Bangalore, Karnataka 560103 518 India 520 Email: tireddy@cisco.com 521 Brandon Williams 522 Akamai, Inc. 523 8 Cambridge Center 524 Cambridge, MA 02142 525 USA 527 Email: brandon.williams@akamai.com 529 Ram Mohan Ravindranath 530 Cisco Systems 531 Cessna Business Park 532 Sarjapur-Marathahalli Outer Ring Road 533 Bangalore, Karnataka 560103 534 India 536 Email: rmohanr@cisco.com