idnits 2.17.1 draft-yourtchenko-two-party-initial-window-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 (December 3, 2010) is 4893 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'COUNT' is mentioned on line 469, but not defined -- Looks like a reference, but probably isn't: '1' on line 591 -- Looks like a reference, but probably isn't: '4' on line 591 -- Looks like a reference, but probably isn't: '5' on line 592 -- Looks like a reference, but probably isn't: '6' on line 592 -- Looks like a reference, but probably isn't: '7' on line 592 -- Looks like a reference, but probably isn't: '8' on line 596 -- Looks like a reference, but probably isn't: '2' on line 596 -- Looks like a reference, but probably isn't: '3' on line 597 == Outdated reference: A later version (-08) exists of draft-ietf-tcpm-initcwnd-00 -- Obsolete informational reference (is this intentional?): RFC 2140 (Obsoleted by RFC 9040) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Yourtchenko 3 Internet-Draft A. Begen 4 Intended status: Standards Track A. Ramaiah 5 Expires: June 6, 2011 Cisco 6 December 3, 2010 8 TIE: Two-Party Selection of TCP Initial Congestion Window Estimate 9 draft-yourtchenko-two-party-initial-window-00 11 Abstract 13 There are several proposals on increasing the TCP initial congestion 14 window to a new hardcoded value and subsequent updates of this 15 hardcoded value. This document explores the mechanism of dynamically 16 determining the potentially unbounded Initial Window. This would 17 allow for the future growth after only one software upgrade of the 18 existing TCP stacks. Also this would allow automatic adjustment of 19 the Initial Window size depending on the connectivity properties of 20 the particular Internet host, while minimizing the retransmissions 21 that result from overly optimistic initial congestion window 22 selection. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 6, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 60 3. The Case for a Two-Party Adaptive Approach . . . . . . . . . . 4 61 4. How to Choose the Initial Congestion Window . . . . . . . . . 5 62 5. How to Update the Initial Congestion Window Estimate . . . . . 6 63 6. How to Communicate the ICWE . . . . . . . . . . . . . . . . . 8 64 7. How to Determine the Loss of the Initial Burst of Data . . . . 8 65 8. Simulation Results . . . . . . . . . . . . . . . . . . . . . . 9 66 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 10. Interoperability With the Hosts That Do Not Support TIE . . . 10 68 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 69 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 13. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 14. Simulation Code . . . . . . . . . . . . . . . . . . . . . . . 11 72 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 74 15.2. Informative References . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 There is a growing need to have the value of the initial congestion 80 window increased from the 2-4 segments RFC5681 [RFC5681] to bigger 81 values - in order to decrease the latency on the initial exchange in 82 client-server protocols like HTTP. This would have a big positive 83 impact on the short-lived connections. IW10 references page 84 [URL.IW10-references-page] has the references to some of the related 85 studies. 87 There are two alternative proposals that both talk about increasing 88 the initial congestion window. I-D.ietf-tcpm-initcwnd 89 [I-D.ietf-tcpm-initcwnd] proposes a fixed new value of 10, and 90 I-D.allman-tcpm-bump-initcwnd [I-D.allman-tcpm-bump-initcwnd] 91 proposes a fixed value of 6 as well as the schedule for the future 92 increases in the initial congestion window value. 94 The first of the two notes that there is a very modest increase in 95 retransmissions for most applications (0.3% to 0.7%, and for a 96 specific application that created multiple connections, it was 97 between 0.9% and 1.85%). Also that test data shows that slower 98 connections show noticeably bigger increase in retransmissions in 99 case of a bigger initial congestion window. 101 The second document specifies the initial congestion window of 6 102 segments, with the schedule for future increases in that value. 103 Although this value should result in a smaller impact than the value 104 of 10, the potential problem with the "predefined schedule" approach 105 is that it would force the upgrade cycles of the existing 106 installations. 108 There was also a proposal for Quick Start RFC4782 [RFC4782] in which 109 the nodes explicitly supply the desired rate of data. That proposal, 110 however, assumes the cooperation of all the routers across the path - 111 and in case the routers do not support this extension, the hosts will 112 use the full proposed bandwidth - therefore increasing the potential 113 for extra packet loss. 115 Another performance enhancement keeps the RTT and cwnd estimates in a 116 per-host cache RFC2140 [RFC2140] - implemented in a FreeBSD (and 117 reportedly in Linux and Solaris) TCP stack. The practice shows it is 118 a very useful enhancement, but it would not cater for the cases where 119 the hosts did not communicate before - as is the case for a lot of 120 client-server interactions on the Internet. 122 In this document we explore an alternative approach, in which the 123 initial congestion window would be probed over time by the Internet 124 host, and present the initial simulations that in the authors' 125 opinion illustrate the bigger flexibility of it. 127 We claim that choosing the initial congestion window value in an 128 adaptive manner is able to cope with networks and applications that 129 vary widely in their nature. There are networks that can easily 130 handle quite large (even larger than 10) initial congestion window 131 values, while there are others that still struggle with values of 132 2-4. There are applications that will greatly benefit from using 133 large initial congestion window values. For example, HTTP 134 transactions that tend to last for a short amount of time (often less 135 than 10 RTTs) will naturally favor larger initial congestion window 136 values since the download times could be reduced substantially. On 137 the other hand, HTTP transactions that will last longer (e.g., big 138 file downloads) are unlikely to see any improvement at all. For some 139 other types of applications, a larger initial congestion window 140 bundled with an aggressive sender or receiver window may do more harm 141 than benefit. While performance improvements can be observed 142 individually, the overall performance across the network may degrade. 143 One could suggest to set the initial congestion window values per 144 application, however, even within a single application (or 145 application-layer protocol), there could be enough variation that 146 warrants setting the initial congestion window value differently. 147 Furthermore, this could be seen as a layer violation. To follow the 148 KISS approach, we propose to determine the initial congestion window 149 value in an adaptive manner that takes the past observations into 150 account. For multi-interface hosts, the value could be specified per 151 interface. 153 There exist also some proposals like Adaptive Start 154 [URL.Adaptive-Start], which explore the change to the slow start 155 algorithm itself in order to optimize the case of short-lived 156 connections. Changes of that magnitude are out of scope for this 157 document - however, the mechanism described here could be used as 158 input for these alternative mechanisms as well. 160 2. Notational Conventions 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC2119 [RFC2119]. 166 3. The Case for a Two-Party Adaptive Approach 168 The use of hardcoded initial congestion window is attractive in its 169 simplicity. However, it has a drawback: to cater well for all the 170 deployments it either needs to be a "lowest common denominator" or 171 make a preference towards a better service for some scenarios at the 172 expense of others. The current initial congestion window has been in 173 place for a relatively long time - so it could have been incorporated 174 as one of the constraints into the design of networking components as 175 well as the design criterion for the networks themselves. 176 Unilaterally increasing this value could impose a choice on some of 177 the networks - observe the increased amount of retransmissions or 178 upgrade. A typical upgrade cycle in a network usually involves a 179 large amount of testing and verification by the network architecture 180 team - likewise, the change of the product design assumptions is also 181 a difficult and laborious process. We believe that the adaptive 182 approach to the initial congestion window would allow to adapt the 183 behavior of TCP to the de-facto capabilities of the equipment, not 184 otherwise. Additionally, the nature of adaptive algorithm would 185 allow for future growth - opening the room for more innovative 186 networking solutions. 188 One might argue that a single-party adaptive approach is enough. 189 According to the simulations, the difference in efficiency of a 190 single-party approach is where it is intuitively expected to be: in 191 the middle between the static value choice and the two party approach 192 that is proposed in this document. Arguably adding the second party 193 can be called an optimization - however, we think this optimization 194 is significant enough to discuss it separately. 196 4. How to Choose the Initial Congestion Window 198 We propose the choice of the initial congestion window to become part 199 of the standard three-way handshake - much like the choice of the 200 Maximum Segment Size (MSS). In the SYN segment, each host would 201 notify the other party of the value for the Initial Congestion Window 202 Estimate (ICWE) that they consider would be the best from their 203 perspective, and after completing the three-way handshake both would 204 select the minimum of the two values. This would allow to 205 incorporate the knowledge about the connectivity from both sides of 206 the connection and allow for a better performance without storing a 207 lot of state information - the knowledge about the initial congestion 208 window value will be distributed across all the communicating hosts, 209 and will be supplied and used just when it is needed. 211 Graphically the process can be depicted as follows: 213 TCP A TCP B 214 ----- ----- 215 | | 216 |--- TCP SYN, ICWE_A -----> | 217 | | 218 | <--- TCP SYNACK, ICWE_B -----| 219 | | 220 ICW_A = min(ICWE_A,ICWE_B) ICW_B = min(ICWE_A,ICWE_B) 221 | | 222 ... ... 224 The method of communication of the ICWE values is described in a 225 separate section below. 227 There are several assumptions that this method makes: 229 o "At least one of the sides has a component in the path that has 230 the significant impact on burst tolerance of the path across all 231 of the connections this node makes". This assumption is not 232 correct in all cases, however, it is a weaker assumption than the 233 one imposed by the fixed initial congestion window value - all 234 paths may tolerate the burst of X segments, where X is the initial 235 congestion window value. It is also weaker than the assumption 236 that the quality of one connection is always correlated to the 237 quality of another one - which the single-party mechanism makes. 239 o "The congestion tolerance properties of the path are symmetric". 240 This assumption is the result of the fact that both sides select 241 the common ICWE. This is obviously untrue for a significant 242 portion of cases (e.g., ADSL). However, the typical use case for 243 such environments is that the hosts will be most interested in the 244 best possible use of the capacities of the downstream path - i.e., 245 the ICWE will matter only in one direction. The adaptive nature 246 of the algorithm allows to find the good value for the initial 247 congestion window in case the use patterns are different. 249 5. How to Update the Initial Congestion Window Estimate 251 The operation of the host in the initial state starts with the 252 congestion window that is equal to the currently defined one (e.g 253 between 2 and 4 segments). From there on, the host will need to look 254 at the retransmission rate and make a decision whether to increment 255 the congestion window estimate or to decrement it. This decision 256 process needs to satisfy the following criteria: 258 o It MUST NOT be overly dynamic. The loss of the segments may be 259 caused either by the inherent properties of the path, temporary 260 congestion or by packet corruption as in the case of wireless 261 transmission. 263 o It MUST NOT be overly static. If the characteristics of the path 264 change, the host must be able to adapt to the new conditions on a 265 timescale that is closer to order of minutes than to order of 266 weeks. 268 o It MUST be conservative to avoid the negative effects on the 269 Internet as a whole. 271 For the purposes of the initial simulation experiments, the decision 272 process is naive: 274 o The party with the smaller ICWE is allowed to increment it if it 275 experienced no losses for the initial burst of traffic within the 276 N past connections. 278 o The party with the smaller ICWE MUST decrement it in case it 279 experienced loss on one of its connections. 281 o If there is no way to conclusively determine the presence or 282 absence of loss (e.g., a smaller amount of data than chosen ICWE 283 was sent over a connection), ICWE values on both sides MUST remain 284 unchanged. 286 The rationale in the second bullet point to decrement the smaller of 287 the two ICWE estimates, not the larger one, is as follows. Suppose 288 we have two parties - party A, which enjoys better connectivity and 289 can use larger initial congestion window values, and a party B that 290 uses smaller congestion window values. If they make a connection, 291 the ICWE proposed by B will be smaller and will be chosen for the 292 connection. If this estimate is inadequate - it is the 293 responsibility of B, since it was its ICWE that was chosen. 295 This also allows to not influence the connections between the well- 296 connected hosts by the connections from the hosts that have poorer 297 connectivity. 299 This algorithm may not necessarily satisfy all of the requirements 300 above in all cases. More experimentation is needed to find a better 301 mechanism. 303 {DISCUSS: if the connection experiences slow start several times, 304 can we count it as several slow starts ? The reliable detection/ 305 action in this case is only possible by one side - then only if the 306 sender had a smaller ICWE can anything be done. } 308 6. How to Communicate the ICWE 310 The first obvious choice of communicating the ICWE is introducing the 311 new TCP option. However, this approach is difficult in its practical 312 implementation because of the limited TCP option space. Instead, 313 another approach is proposed below. 315 Based on the observations, the TCP Window Size in the initial 316 segment's TCP header is an an even value. This means that the TCP 317 stack can signal to the peer its awareness about the adaptive initial 318 congestion window by setting the least significant bit to 1. Then, 319 the TCP Window field will contain the ICWE value sent by this peer. 321 Upon sending the ACKs for the data received, each side can then 322 communicate the TCP Window according to the TCP specification. 324 {discuss: setting the LSB to 1 for the window allows to have an 325 'update' for ICWE in some form, throughout the life of the 326 connection. Whether it is needed is a separate topic. Probably 327 not}. 329 An argument against such "LSB signaling" would be that we are 330 changing the semantics of the TCP Window field. However, this 331 equally goes about using TCP Window to clamp the initial congestion 332 window imposed by the other methods - because in that case it is no 333 longer an amount of data that the host is ready to receive, but the 334 amount of data that the host thinks the other party should transmit. 336 During the transmission, the ICWE is supposed to be encoded in the 337 same metric as TCP Window - e.g., in octets. This mechanism can help 338 with interoperability with the stacks that do not perform the 339 adaptive initial congestion window selection, but that are overly 340 optimistic with their congestion window. 342 7. How to Determine the Loss of the Initial Burst of Data 344 {FIXME: this section needs more brainstorming/work} 346 Determining the loss of the initial congestion window of data on the 347 side that has filled it by sending the data is simple - it can be 348 done by verifying if it did any retransmits of this data or not. 349 However, since the algorithm does not imply the communication between 350 the parties beyond the exchange of ICWEs in the very beginning of the 351 connection, both sides need to detect the congestion - and on the 352 receiver side of the burst it may not be easy. 354 {this is where the discussion is needed} 356 There may be a condition where the amount of data sent is smaller 357 than the initial congestion window - i.e., it is not possibly to 358 determine whether the ICWE estimate was right or wrong. In such 359 cases the values of the ICWE on both sides MUST remain unchanged. 361 8. Simulation Results 363 This section shows the results obtained using the simulation enclosed 364 in the Appendix A. 366 {FIXME: to be expanded, for now just pasting from the tcpm mail} 368 1) Static IW=10, access capacity 5..8, backbone capacity 8..15 370 ./a.out 10 0 1000 5 8 8 15 1 | grep round 372 Results from the round: loss: 423, headroom: 0, avg IW size: 10.000000 373 Results from the round: loss: 436, headroom: 0, avg IW size: 10.000000 374 Results from the round: loss: 423, headroom: 0, avg IW size: 10.000000 375 Results from the round: loss: 426, headroom: 0, avg IW size: 10.000000 377 2) One-side-adjustment of the IW: 379 ./a.out 10 1 1000 5 8 8 15 1 | grep round 381 Results from the round: loss: 66, headroom: 10, avg IW size: 6.380000 382 Results from the round: loss: 52, headroom: 14, avg IW size: 6.180000 383 Results from the round: loss: 62, headroom: 10, avg IW size: 6.350000 384 Results from the round: loss: 63, headroom: 9, avg IW size: 6.210000 386 3) Two-party adjustment of the IW: 388 ./a.out 10 1 1000 5 8 8 15 0 | grep round 390 Results from the round: loss: 1, headroom: 32, avg IW size: 5.420000 391 Results from the round: loss: 0, headroom: 37, avg IW size: 5.350000 392 Results from the round: loss: 1, headroom: 29, avg IW size: 5.350000 393 Results from the round: loss: 1, headroom: 41, avg IW size: 5.350000 394 Results from the round: loss: 0, headroom: 50, avg IW size: 5.290000 396 It needs noting that the value of N needs to be sufficiently large in 397 order to show the best results, below is the result with N=10: 399 ./a.out 10 1 10 5 8 8 15 0 | grep round 401 Results from the round: loss: 13, headroom: 27, avg IW size: 5.630000 402 Results from the round: loss: 12, headroom: 6, avg IW size: 5.690000 403 Results from the round: loss: 10, headroom: 16, avg IW size: 5.650000 404 Results from the round: loss: 12, headroom: 23, avg IW size: 5.680000 405 Results from the round: loss: 12, headroom: 13, avg IW size: 5.650000 407 We can see that the results are still better than the one-sided 408 judgement, however, they are of the same order of magnitude. 410 9. Conclusions 412 The choice of the best possible criteria for the increase/decrease of 413 the ICWE values is to be explored further, however, the initial 414 results show that the proposed algorithm provides the results better 415 than unilateral decision on the initial congestion window. 417 10. Interoperability With the Hosts That Do Not Support TIE 419 If one of the sides of the connection does support the method 420 mentioned in this document, and the other does not, then the side 421 supporting it MAY use its best judgement with respect to the initial 422 congestion window, namely the fixed increased initial congestion 423 window of 10 as described in I-D.ietf-tcpm-initcwnd 424 [I-D.ietf-tcpm-initcwnd]. However, in this case the hosts MUST 425 implement the appropriate mechanisms for fallback in case of the 426 losses due to this increased initial window similar to the ones 427 proposed by Joe Touch. 429 {FIXME: this section needs more discussion/further work} 431 11. Acknowledgements 433 Thanks to Philip Gladstone, Dan Wing, Preethi Natarajan, Stig Venaas 434 for the review and useful comments and suggestions. 436 12. IANA Considerations 438 None. 440 13. Security Considerations 442 The adaptive nature of this mechanism is a challenge in case of 443 malicious hosts who want to affect the peer's estimate for the future 444 connections. The malicious host would use the larger ICWE than the 445 party and then force the packet loss on the connection. This would 446 result in the decrease of the other party's ICWE for the subsequent 447 connections. 449 However, this would work only in case of low volume of the legitimate 450 connections - in case there is a high volume, the ICWE will quickly 451 return to the good value based on the other connections' 452 information. 454 {FIXME: There is potentially more of interesting things here. Needs 455 more work} 457 14. Simulation Code 459 The below code is enclosed so the readers can verify the results and 460 run their own experiments: 462 #include 464 #define COUNT 10 466 int access_capacity[COUNT]; 467 int backbone_capacity[COUNT][COUNT]; 468 int node_iw[COUNT]; 469 int node_noloss[COUNT]; 471 void fill_initial(int iw, int lac, int hac, int lbc, int hbc) { 472 int i, j; 473 for(i=0; i access_capacity[i]) { mincap = access_capacity[i]; } 513 if (mincap > access_capacity[j]) { mincap = access_capacity[j]; } 515 // loss occurs if iw is bigger than a minimum capacity. 516 loss = iw > mincap ? iw - mincap : 0; 518 // headroom is a measure of inefficiency - how much 519 // did we underuse the capacity of the path 520 headroom = iw < mincap ? mincap - iw : 0; 522 if (adjust) { 524 if (no_hint) { 525 if (loss) { 526 if(node_iw[i] > 2) { node_iw[i]--; } 527 } else { 528 node_noloss[i]++; 529 if(node_noloss[i] > loss_thresh) { node_iw[i] += 1; } 530 } 531 } else { 533 // A very simplistic mechanism of adapting the ICWE 534 // Loss = decrement the ICWE on the node 535 // that had a smaller ICWE 536 // No loss for more than loss_thresh 537 // consequtive connections = 538 // = increment the ICWE on the side 539 // that had the smaller ICWE. 540 if (loss) { 541 node_noloss[i] = node_noloss[j] = 0; 543 if (node_iw[i] < node_iw[j]) { 544 // node_iw[i] /= 2; 545 // if(node_iw[j] > 2) { node_iw[j] -= 1; } 546 if(node_iw[i] > 2) { node_iw[i] -= 1; } 547 } else { 548 // node_iw[j] /= 2; 549 // if(node_iw[i] > 2) { node_iw[i] -= 1; } 550 if(node_iw[j] > 2) { node_iw[j] -= 1; } 551 } 552 } else { 553 node_noloss[i]++; 554 node_noloss[j]++; 556 // no loss, can try incrementing the smaller side 557 if (node_iw[i] < node_iw[j]) { 558 if(node_noloss[i] > loss_thresh) { node_iw[i] += 1; } 559 } else { 560 if(node_noloss[j] > loss_thresh) { node_iw[j] += 1; } 561 } 562 } 563 } 564 } 566 printf(" result headroom: %d, loss: %d, " 567 "new iw %d = %d, new iw %d = %d\n", 568 headroom, loss, 569 i, node_iw[i], 570 j, node_iw[j]); 572 *rloss = loss; 573 *rheadroom = headroom; 574 } 576 int main(int argc, char **argv) { 577 int i = 0; 578 int loss, headroom; 579 int iws; 580 int closs, cheadroom; 581 int ciw; 582 int count = 100; 583 if(argc < 9) { 584 printf("usage: %d " 585 " " 586 " " 587 " " 588 "\n"); 589 exit(0); 590 } 591 fill_initial(atoi(argv[1]), atoi(argv[4]), 592 atoi(argv[5]), atoi(argv[6]), atoi(argv[7])); 593 while(1) { 594 iws = loss = headroom = 0; 595 for(i=0;i. 642 [URL.IW10-references-page] 643 "IW10 references page", 644 . 646 Authors' Addresses 648 Andrew Yourtchenko 649 Cisco 650 7 de Kleetlaan 651 Diegem 1831 652 Belgium 654 Phone: +32 2 704 5494 655 Email: ayourtch@cisco.com 657 Ali Begen 658 Cisco 659 181 Bay Street 660 Toronto, ON M5J 2T3 661 Canada 663 Email: abegen@cisco.com 664 Anantha Ramaiah 665 Cisco 666 170 Tasman Drive 667 San Jose, CA 95134 668 USA 670 Phone: +1 (408) 525-6486 671 Email: ananth@cisco.com