idnits 2.17.1 draft-ietf-rmcat-eval-test-02.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 : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 226: '...enerated on the end-to-end path. MUST...' RFC 2119 keyword, line 317: '...These attributes MUST be well defined,...' RFC 2119 keyword, line 321: '...ue of such a set MUST be treated as di...' RFC 2119 keyword, line 435: '...test case, bitrate variation SHOULD be...' RFC 2119 keyword, line 447: '...didate proposals MAY show the effectiv...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 8, 2015) is 3153 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '300ms' is mentioned on line 1005, but not defined == Missing Reference: '1000ms' is mentioned on line 1005, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-rmcat-eval-criteria-03 == Outdated reference: A later version (-11) exists of draft-ietf-rmcat-wireless-tests-00 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Sarker 3 Internet-Draft Ericsson AB 4 Intended status: Informational V. Singh 5 Expires: March 11, 2016 Aalto University 6 X. Zhu 7 M. Ramalho 8 Cisco Systems 9 September 8, 2015 11 Test Cases for Evaluating RMCAT Proposals 12 draft-ietf-rmcat-eval-test-02 14 Abstract 16 The Real-time Transport Protocol (RTP) is used to transmit media in 17 multimedia telephony applications, these applications are typically 18 required to implement congestion control. The RMCAT working group is 19 currently working on candidate algorithms for such interactive real- 20 time multimedia applications. This document describes the test cases 21 to be used in the performance evaluation of those candidate 22 algorithms. 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 March 11, 2016. 41 Copyright Notice 43 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Structure of Test cases . . . . . . . . . . . . . . . . . . . 3 61 4. Recommended Evaluation Settings . . . . . . . . . . . . . . . 7 62 4.1. Evaluation metircs . . . . . . . . . . . . . . . . . . . 7 63 4.2. Path characteristics . . . . . . . . . . . . . . . . . . 8 64 4.3. Media source . . . . . . . . . . . . . . . . . . . . . . 9 65 5. Basic Test Cases . . . . . . . . . . . . . . . . . . . . . . 10 66 5.1. Variable Available Capacity with Single RMCAT flow . . . 10 67 5.2. Variable Available Capacity with Multiple RMCAT flows . . 13 68 5.3. Congested Feedback Link with Bi-directional RMCAT flows . 14 69 5.4. Competing Flows with Same RMCAT Algorithm . . . . . . . . 16 70 5.5. Round Trip Time Fairness . . . . . . . . . . . . . . . . 19 71 5.6. RMCAT Flow competing with a long TCP Flow . . . . . . . . 20 72 5.7. RMCAT Flow competing with short TCP Flows . . . . . . . . 23 73 5.8. Media Pause and Resume . . . . . . . . . . . . . . . . . 25 74 6. Other potential test cases . . . . . . . . . . . . . . . . . 26 75 6.1. Explicit Congestion Notification Usage . . . . . . . . . 26 76 6.2. Multiple Bottlenecks . . . . . . . . . . . . . . . . . . 26 77 7. Wireless Access Links . . . . . . . . . . . . . . . . . . . . 29 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 29 83 11.2. Informative References . . . . . . . . . . . . . . . . . 30 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 86 1. Introduction 88 This memo describes a set of test cases for evaluating candidate 89 RMCAT congestion control algorithm proposals, it is based on the 90 guidelines enumerated in [I-D.ietf-rmcat-eval-criteria] and the 91 requirements discussed in [I-D.ietf-rmcat-cc-requirements]. The test 92 cases cover basic usage scenarios and are described using a common 93 structure, which allows for additional test cases to be added to 94 those described herein to accommodate other topologies and/or the 95 modeling of different path characteristics. It is the intention of 96 this work to capture the consensus of the RMCAT working group 97 participants regarding the test cases upon which the performance of 98 the candidate RMCAT proposals should be evaluated. 100 2. Terminology 102 The terminology defined in RTP [RFC3550], RTP Profile for Audio and 103 Video Conferences with Minimal Control [RFC3551], RTCP Extended 104 Report (XR) [RFC3611], Extended RTP Profile for RTCP-based Feedback 105 (RTP/AVPF) [RFC4585], and Support for Reduced-Size RTCP [RFC5506] 106 apply. 108 3. Structure of Test cases 110 All test cases in this document follow a basic structure allowing 111 implementers to describe a new test scenario without repeatedly 112 explaining common attributes. The structure includes a general 113 description section that describes the test case and its motivation. 114 Additionally the test case defines a set of attributes that 115 characterize the testbed, i.e., the network path between 116 communicating peers and the diverse traffic sources. 118 o Define the test case: 120 * General description: describes the motivation and the goals of 121 the test case. 123 * Expected behavior: describe the desired rate adaptation 124 behaviour. 126 * Define a check-list to evaluate the desired behaviour: this 127 indicates the minimum set of metrics (e.g., link utilization, 128 media sending rate) that a proposed algorithm needs to measure 129 to validate the expected rate adaptation behaviour. It should 130 also indicate the time granularity (e.g., averaged over 10ms, 131 100ms, or 1s) for measuring certain metrics. Typical 132 measurement interval is 200ms. 134 o Define testbed topology: every test case needs to define an 135 evaluation testbed topology. Figure 1 shows such an evaluation 136 topology. In this evaluation topology, S1..Sn are traffic 137 sources. These sources generate media traffic and use either an 138 RMCAT candidate congestion control algorithm or other congestion 139 control algorithm designed for media, such as TFRC. R1..Rn are 140 the corresponding receivers. A test case can have one or more 141 such traffic sources (S) and corresponding receivers (R). The 142 path from the source to destination is denoted as forward and the 143 path from a destination to a source is denoted as backward. The 144 following basic structure of test case has been described from the 145 perspective of media generating endpoints attached on the left- 146 hand side of Figure 1. In this setup, media flows in forward 147 direction and corresponding feedback/control messages flow in the 148 backward direction. However, it is also possible to set up the 149 test with media flowing in both forward and backward directions. 150 In that case, unless otherwise specified by the test case, it is 151 expected that the backward path does not introduce any congestion 152 related impairments and has enough capacity to accommodate both 153 media and feedback/control messages. It should be noted that 154 depending on the test cases it is possible to have different path 155 characteristics in of the either directions. 157 o 159 +---+ +---+ 160 |S1 |====== \ Forward --> / =======|R1 | 161 +---+ \\ // +---+ 162 \\ // 163 +---+ +-----+ +-----+ +---+ 164 |S2 |=======| A |------------------------------>| B |=======|R2 | 165 +---+ | |<------------------------------| | +---+ 166 +-----+ +-----+ 167 (...) // \\ (...) 168 // <-- Backward \\ 169 +---+ // \\ +---+ 170 |Sn |====== / \ ======|Rn | 171 +---+ +---+ 173 Figure 1: Example of A Testbed Topology 175 In a laboratory testbed environment there may exist a significant 176 amount of traffic on portions of the network path between the 177 endpoints that is not desired for the purposes of these RMCAT 178 tests. Some of this traffic may be generated by other processes 179 on the endpoints themselves (e.g., discovery protocols) or by 180 other endpoints not presently under test. It is recommended not 181 to route traffic generated by endpoints that are not under test 182 through the test bed. Additionally, it is recommended to route 183 non-RMCAT traffic generated by the endpoints under test around the 184 bottleneck links specified herein. 186 o Define testbed attributes: 188 * Duration: defines the duration of the test. 190 * Path characteristics: defines the end-to-end transport level 191 path characteristics of the testbed in a particular test case. 192 Two sets of attributes describe the path characteristics, one 193 for the forward path and the other for the backward path. The 194 path characteristics for a particular path direction is 195 applicable to all the Sources "S" sending traffic on that path. 196 If only one attribute is specified, it is used for both path 197 directions, however, unless specified the reverse path has no 198 capacity restrictions and no path loss. 200 + Path direction: forward or backward. 202 + Bottleneck-link capacity: defines minimum capacity of the 203 end-to-end path 205 + Reference bottleneck capacity: defines a reference value for 206 the bottleneck capacity for test cases with time-varying 207 bottleneck capacities. All bottleneck capacities will be 208 specified as a ratio with respect to the reference capacity 209 value. 211 + One-way propagation delay: describes the end-to-end latency 212 along the path when network queues are empty, i.e., the time 213 it takes for a packet to go from the sender to the receiver 214 without encountering any queuing delay. 216 + Maximum end-to-end jitter: defines the maximum jitter that 217 can be observed along the path. 219 + Bottleneck queue type: for example, Droptail, FQ-CoDel, or 220 PIE. 222 + Bottleneck queue size: defines size of queue in terms of 223 queuing time when the queue is full (in milliseconds). 225 + Path loss ratio: characterizes the non-congested, additive, 226 losses to be generated on the end-to-end path. MUST 227 describe the loss pattern or loss model used to generate the 228 losses. 230 + Values for some characteristics are described in 231 [I-D.ietf-rmcat-eval-criteria]. 233 * Application-related: defines the traffic source behaviour for 234 implementing the test case 236 + Media traffic Source: defines the characteristics of the 237 media sources. When using more than one media source, the 238 different attributes are enumerated separately for each 239 different media source. 241 - Media type: Video/Voice 243 - Media flow direction: forward, backward or both. 245 - Number of media sources: defines the total number of 246 media sources 248 - Media codec: Constant Bit Rate (CBR) or Variable Bit Rate 249 (VBR) 251 - Media source behaviour: describes the media encoder 252 behavior. It defines the main parameters that affect the 253 adaptation behaviour. This may include but not limited 254 to: 256 o Adaptability: describes the adaptation options. For 257 example, in the case of video it defines the following 258 ranges of adaptation: bit rate, frame rate, video 259 resolution. Similarly, in the case of voice, it 260 defines the range of bit rate adaptation, the sampling 261 rate variation, and the variation in packetization 262 interval. 264 o Output variation : for a VBR encoder it defines the 265 encoder output variation from the average target rate 266 over a particular measurement interval. For example, 267 on average the encoder output may vary between 5% to 268 15% above or below the average target bit rate when 269 measured over a 100 ms time window. The time interval 270 over which the variation is specified must be 271 provided. 273 o Responsiveness to a new bit rate request: the lag in 274 time between a new bit rate request and actual rate 275 changes in encoder output. Depending on the encoder, 276 this value may be specified in absolute time (e.g. 277 10ms to 1000ms) or other appropriate metric (next 278 frame interval time). 280 - Media content: describes the chosen media sequences; For 281 example, test sequences are available at: [xiph-seq] and 282 [HEVC-seq]. 284 - Media timeline: describes the point when the media source 285 is introduced and removed from the testbed. For example, 286 the media source may start transmitting immediately when 287 the test case begins, or after a few seconds. 289 - Startup behaviour: the media starts at a defined bit 290 rate, which may be the minimum, maximum bit rate, or a 291 value in between (in Kbps). 293 + Competing traffic source: describes the characteristics of 294 the competing traffic source, the different types of 295 competing flows are enumerated in 296 [I-D.ietf-rmcat-eval-criteria]. 298 - Traffic direction: forward, backward or both. 300 - Type of sources: defines the types of competing traffic 301 sources. Types of competing traffic flows are listed in 302 [I-D.ietf-rmcat-eval-criteria]. For example, the number 303 of TCP flows connected to a web browser, the mean size 304 and distribution of the content downloaded. 306 - Number of sources: defines the total number of competing 307 sources of each media type. 309 - Congestion control: enumerates the congestion control 310 used by each type of competing traffic. 312 - Traffic timeline: describes when the competing traffic 313 starts and ends in the test case. 315 * Additional attributes: describes attributes essential for 316 implementing a test case which are not included in the above 317 structure. These attributes MUST be well defined, so that 318 other implementers are able to implement it. 320 Any attribute can have a set of values (enclosed within "[]"). Each 321 member value of such a set MUST be treated as different value for the 322 same attribute. It is desired to run separate tests for each such 323 attribute value. 325 The test cases described in this document follow the above structure. 327 4. Recommended Evaluation Settings 329 This section describes recommended test case settings and could be 330 overwritten by the respective test cases. 332 4.1. Evaluation metircs 334 To evaluate the performance of the candidate algorithms it is 335 expected to log enough information to visualize the following metrics 336 at a fine enough time granularity: 338 1. Flow level: 340 A. End-to-end delay for the RMCAT flow. 342 B. Variation in sending bit rate and goodput. Mainly observing 343 the frequency and magnitude of oscillations. 345 C. Packet losses observed at the receiving endpoint 347 D. Feedback message overhead 349 E. Convergence time. 351 2. Transport level: 353 A. Bandwidth utilization 355 B. Queue length (milliseconds at specified path capacity): 357 + average over the length of the session 359 + 5 and 95 percentile 361 + median, maximum, minimum 363 4.2. Path characteristics 365 Each path between a sender and receiver as described in Figure 1 have 366 the following characteristics unless otherwise specified in the test 367 case. 369 o Path direction: forward and backward. 371 o Reference bottleneck capacity: 1Mbps. 373 o One-Way propagation delay: 50ms. Implementers are encouraged to 374 run the experiment with additional propagation delays mentioned in 375 [I-D.ietf-rmcat-eval-criteria] 377 o Maximum end-to-end jitter: 30ms. Jitter models are described in 378 [I-D.ietf-rmcat-eval-criteria] 380 o Bottleneck queue type: Drop tail. Implementers are encouraged to 381 run the experiment with other AQM schemes, such as FQ-CoDel and 382 PIE. 384 o Bottleneck queue size: 300ms. 386 o Path loss ratio: 0%. 388 Examples of additional network parameters are discussed in 389 [I-D.ietf-rmcat-eval-criteria]. 391 For test cases involving time-varying bottleneck capacity, all 392 capacity values are specified as a ratio with respect to a reference 393 capacity value, so as to allow flexible scaling of capacity values 394 along with media source rate range. There exist two different 395 mechanisms for inducing path capacity variation: a) by explicitly 396 modifying the value of physical link capacity; or b) by introducing 397 background non-adaptive UDP traffic with time-varying traffic rate. 398 Implementers are encouraged run the experiments with both mechanisms 399 for test cases specified in Section 5.1, Section 5.2, and 400 Section 5.3. 402 4.3. Media source 404 Unless otherwise specified, each test case will include one or more 405 media sources as described below. 407 o Media type: Video 409 * Media codec: VBR 411 * Media source behaviour: 413 + Adaptability: 415 - Bit rate range: 150 Kbps - 1.5 Mbps. In real-life 416 applications the bitrate range can vary a lot depending 417 on the provided service, for example, the maximum bitrate 418 can be up to 4Mbps. However, for running tests to 419 evaluate the congestion control algorithms it is more 420 important to have a look at how they are reacting to 421 certain amount of bandwidth change. Also it is possible 422 that the media traffic generator used in a particular 423 simulator or testbed if not capable of generating higher 424 bitrate. Hence we have selected a suitable bitrate range 425 typical of consumer-grade video conferencing applications 426 in designing the test case. If a different bitrate range 427 is used in the test cases, the end-to-end path capacity 428 values will also need to be scaled accordingly. 430 - Frame resolution: 144p - 720p (or 1080p) 432 - Frame rate: 10fps - 30fps 434 + Variation from target bitrate: +/-5%. Unless otherwise 435 specified in the test case, bitrate variation SHOULD be 436 calculated over one (1) second period of time. 438 + Responsiveness to new bit rate request: 100ms 440 * Media content: The media content should represent a typical 441 video conversational scenario with head and shoulder movement. 442 We recommend to use Foreman video sequence. 444 * Media startup behaviour: 150Kbps. It should be noted that 445 applications can use smart ways to select an optimal startup 446 bitrate values for a certain network condition. In such cases 447 the candidate proposals MAY show the effectiveness of such 448 smart approach as an additional information for the evaluation 449 process. 451 o Media type: Audio 453 * Media codec: CBR 455 * Media bitrate: 20Kbps 457 5. Basic Test Cases 459 5.1. Variable Available Capacity with Single RMCAT flow 461 In this test case the bottleneck-link capacity between the two 462 endpoints varies over time. This test is designed to measure the 463 responsiveness of the candidate algorithm. This test tries to 464 address the requirements in [I-D.ietf-rmcat-cc-requirements], which 465 requires the algorithm to adapt the flow(s) and provide lower end-to- 466 end latency when there exists: 468 o an intermediate bottleneck 470 o change in available capacity (e.g., due to interface change, 471 routing change, abrupt arrival/departure of background non- 472 adaptive traffic). 474 o maximum Media Bit Rate is Greater than Link Capacity. In this 475 case, the application will attempt to ramp up to its maximum bit 476 rate, since the link capacity is limited to a value lower, the 477 congestion control scheme is expected to stabilize the sending bit 478 rate close to the available bottleneck capacity. This situation 479 can occur when the endpoints are connected via thin long networks 480 even though the advertised capacity of the access network may be 481 higher. 483 It should be noted that the exact variation in available capacity due 484 to any of the above depends on the under-lying technologies. Hence, 485 we describe a set of known factors, which may be extended to devise a 486 more specific test case targeting certain behaviour in a certain 487 network environment. 489 Expected behavior: the candidate algorithm is expected to detect the 490 path capacity constraint, converges to bottleneck link's capacity and 491 adapt the flow to avoid unwanted oscillation when the sending bit 492 rate is approaching the bottleneck link's capacity. The oscillations 493 occur when the media flow(s) attempts to reach its maximum bit rate, 494 overshoots the usage of the available bottleneck capacity, to rectify 495 it reduces the bit rate and starts to ramp up again. 497 Testbed topology: One media source S1 is connected to corresponding 498 R1. The media traffic is transported over the forward path and 499 corresponding feedback/control traffic is transported over the 500 backward path. 502 Forward --> 503 +---+ +-----+ +-----+ +---+ 504 |S1 |=======| A |------------------------------>| B |=======|R1 | 505 +---+ | |<------------------------------| | +---+ 506 +-----+ +-----+ 507 <-- Backward 509 Figure 2: Testbed Topology for Limited Link Capacity 511 To evaluate the performance of the candidate algorithms it is 512 expected to log enough information to visualize the metrics described 513 in Section 4.1 at a fine enough time granularity. 515 Testbed attributes: 517 o Test duration: 100s 519 o Path characteristics: as described in Section 4.2 521 o Application-related: 523 * Media Traffic: 525 + Media type: Video 527 - Media direction: forward. 529 - Number of media sources: One (1) 530 - Media timeline: 532 o Start time: 0s. 534 o End time: 99s. 536 + Media type: Audio 538 - Media direction: forward. 540 - Number of media sources: One (1) 542 - Media timeline: 544 o Start time: 0s. 546 o End time: 99s. 548 * Competing traffic: 550 + Number of sources : Zero (0) 552 o Test Specific Information: 554 * This test uses the following one way propagation delays of 50 555 ms and 100 ms. 557 * This test uses bottleneck path capacity variation as listed in 558 Table 1 560 * When using background non-adaptive UDP traffic to induce time- 561 varying bottleneck for the RMCAT flow, the physical path 562 capacity is 4Mbps and the UDP traffic source rate changes over 563 time as (4-x)Mbps, where x is the bottleneck capacity specified 564 in Table 1 566 +--------------------+--------------+-----------+-------------------+ 567 | Variation pattern | Path | Start | Path capacity | 568 | index | direction | time | ratio | 569 +--------------------+--------------+-----------+-------------------+ 570 | One | Forward | 0s | 1.0 | 571 | Two | Forward | 40s | 2.5 | 572 | Three | Forward | 60s | 0.6 | 573 | Four | Forward | 80s | 1.0 | 574 +--------------------+--------------+-----------+-------------------+ 576 Table 1: Path capacity variation pattern for forward direction 578 5.2. Variable Available Capacity with Multiple RMCAT flows 580 This test case is similar to Section 5.1. However in addition this 581 test will also consider persistent network load due to competing 582 traffic. 584 Expected behavior: the candidate algorithms is expected to detect the 585 variation in available capacity and adapt the media stream(s) 586 accordingly. The flows stabilize around their maximum bitrate as the 587 as the maximum link capacity is large enough to accommodate the 588 flows. When the available capacity drops, the flow(s) adapts by 589 decreasing its sending bit rate, and when congestion disappears, the 590 flow(s) are again expected to ramp up. 592 To evaluate the performance of the candidate algorithms it is 593 expected to log enough information to visualize the metrics described 594 in Section 4.1 at a fine enough time granularity: 596 Testbed Topology: Two (2) media sources S1 and S2 are connected to 597 their corresponding destinations R1 and R2. The media traffic is 598 transported over the forward path and corresponding feedback/control 599 traffic is transported over the backward path. 601 +---+ +---+ 602 |S1 |===== \ / =======|R1 | 603 +---+ \\ Forward --> // +---+ 604 \\ // 605 +-----+ +-----+ 606 | A |------------------------------>| B | 607 | |<------------------------------| | 608 +-----+ +-----+ 609 // \\ 610 // <-- Backward \\ 611 +---+ // \\ +---+ 612 |S2 |====== / \ ======|R2 | 613 +---+ +---+ 615 Figure 3: Testbed Topology for Variable Available Capacity 617 Testbed attributes: 619 Testbed attributes are similar as described in Section 5.1 except the 620 test specific capacity variation setup. 622 Test Specific Information: This test uses path capacity variation as 623 listed in Table 2 with a corresponding end time of 125 seconds. The 624 reference bottleneck capacity is 2Mbps. When using background non- 625 adaptive UDP traffic to induce time-varying bottleneck for RMCAT 626 flows, the physical path capacity is 4Mbps and the UDP traffic source 627 rate changes over time as (4-x)Mbps, where x is the bottleneck 628 capacity specified in Table 2. 630 +--------------------+--------------+-----------+-------------------+ 631 | Variation pattern | Path | Start | Path capacity | 632 | index | direction | time | ratio | 633 +--------------------+--------------+-----------+-------------------+ 634 | One | Forward | 0s | 2.0 | 635 | Two | Forward | 25s | 1.0 | 636 | Three | Forward | 50s | 1.75 | 637 | Four | Forward | 75s | 0.5 | 638 | Five | Forward | 100s | 1.0 | 639 +--------------------+--------------+-----------+-------------------+ 641 Table 2: Path capacity variation pattern for forward direction 643 5.3. Congested Feedback Link with Bi-directional RMCAT flows 645 RMCAT WG has been chartered to define algorithms for RTP hence it is 646 assumed that RTCP, RTP header extension or such would be used by the 647 congestion control algorithm in the backchannel. Due to asymmetric 648 nature of the link between communicating peers it is possible for a 649 participating peer to not receive such feedback information due to an 650 impaired or congested backchannel (even when the forward channel 651 might not be impaired). This test case is designed to observe the 652 candidate congestion control behaviour in such an event. 654 It is expected that the candidate algorithms is able to cope with the 655 lack of feedback information and adapt to minimize the performance 656 degradation of media flows in the forward channel. 658 It should be noted that for this test case: logs are compared with 659 the reference case, i.e, when the backward channel has no impairments 661 To evaluate the performance of the candidate algorithms it is 662 expected to log enough information to visualize the metrics described 663 in Section 4.1 at a fine-grained time intervals: 665 Testbed topology: One (1) media source S1 is connected to 666 corresponding R1, but both endpoints are additionally receiving and 667 sending data, respectively. The media traffic (S1->R1) is 668 transported over the forward path and corresponding feedback/control 669 traffic is transported over the backward path. Likewise media 670 traffic (S2->R2) is transported over the backward path and 671 corresponding feedback/control traffic is transported over the 672 forward path. 674 +---+ +---+ 675 |S1 |===== \ Forward --> / =======|R1 | 676 +---+ \\ // +---+ 677 \\ // 678 +-----+ +-----+ 679 | A |------------------------------>| B | 680 | |<------------------------------| | 681 +-----+ +-----+ 682 // \\ 683 // <-- Backward \\ 684 +---+ // \\ +---+ 685 |R2 |===== / \ ======|S2 | 686 +---+ +---+ 688 Figure 4: Testbed Topology for Congested Feedback Link 690 Testbed attributes: 692 o Test duration: 100s 694 o Path characteristics: 696 * Reference bottleneck capacity: 1Mbps. 698 o Application-related: 700 * Media Source: 702 + Media type: Video 704 - Media direction: forward and backward 706 - Number of media sources: Two (2) 708 - Media timeline: 710 o Start time: 0s. 712 o End time: 99s. 714 + Media type: Audio 716 - Media direction: forward and backward 718 - Number of media sources: Two (2) 720 - Media timeline: 722 o Start time: 0s. 724 o End time: 99s. 726 * Competing traffic: 728 + Number of sources : Zero (0) 730 o Test Specific Information: This test uses path capacity variations 731 to create congested feedback link. Table 3 lists the variation 732 patterns applied to the forward path and Table 4 lists the 733 variation patterns applied to the backward path. When using 734 background non-adaptive UDP traffic to induce time-varying 735 bottleneck for RMCAT flows, the physical path capacity is 4Mbps 736 for both directions and the UDP traffic source rate changes over 737 time as (4-x)Mbps in each direction, where x is the bottleneck 738 capacity specified in Table 4. 740 +--------------------+--------------+-----------+-------------------+ 741 | Variation pattern | Path | Start | Path capacity | 742 | index | direction | time | ratio | 743 +--------------------+--------------+-----------+-------------------+ 744 | One | Forward | 0s | 2.0 | 745 | Two | Forward | 20s | 1.0 | 746 | Three | Forward | 40s | 0.5 | 747 | Four | Forward | 60s | 2.0 | 748 +--------------------+--------------+-----------+-------------------+ 750 Table 3: Path capacity variation pattern for forward direction 752 +--------------------+--------------+-----------+-------------------+ 753 | Variation pattern | Path | Start | Path capacity | 754 | index | direction | time | ratio | 755 +--------------------+--------------+-----------+-------------------+ 756 | One | Backward | 0s | 2.0 | 757 | Two | Backward | 35s | 0.8 | 758 | Three | Backward | 70s | 2.0 | 759 +--------------------+--------------+-----------+-------------------+ 761 Table 4: Path capacity variation pattern for backward direction 763 5.4. Competing Flows with Same RMCAT Algorithm 765 In this test case, more than one RMCAT media flow shares the 766 bottleneck link and each of them uses the same congestion control 767 algorithm. This is a typical scenario where a real-time interactive 768 application sends more than one media flows to the same destination 769 and these flows are multiplexed over the same port. In such a 770 scenario it is likely that the flows will be routed via the same path 771 and need to share the available bandwidth amongst themselves. For 772 the sake of simplicity it is assumed that there are no other non- 773 RMCAT competing traffic sources in the bottleneck link and that there 774 is sufficient capacity to accommodate all the flows individually. 775 While this appears to be a variant of the test case defined in 776 Section 5.2, it focuses on the capacity sharing aspect of the 777 candidate algorithm. The previous test case, on the other hand, 778 measures adaptability, stability, and responsiveness of the candidate 779 algorithm. 781 Expected behavior: It is expected that the competing flows will 782 converge to an optimum bit rate to accommodate all the flows with 783 minimum possible latency and loss. Specifically, the test introduces 784 three media flows at different time instances, when the second flow 785 appears there should still be room to accommodate another flow on the 786 bottleneck link. Lastly, when the third flow appears the bottleneck 787 link should be saturated. 789 To evaluate the performance of the candidate algorithms it is 790 expected to log enough information to visualize the metrics described 791 in Section 4.1 at a fine enough time granularity: 793 Testbed topology: Three media sources S1, S2, S3 are connected to 794 respective R1, R2, R3. The media traffic is transported over the 795 forward path and corresponding feedback/control traffic is 796 transported over the backward path. 798 +---+ +---+ 799 |S1 |===== \ Forward --> / =======|R1 | 800 +---+ \\ // +---+ 801 \\ // 802 +---+ +-----+ +-----+ +---+ 803 |S2 |=======| A |------------------------------>| B |=======|R2 | 804 +---+ | |<------------------------------| | +---+ 805 +-----+ +-----+ 806 // \\ 807 // <-- Backward \\ 808 +---+ // \\ +---+ 809 |S3 |====== / \ ======|R3 | 810 +---+ +---+ 812 Figure 5: Testbed Topology for Multiple RMCAT Flows 814 Testbed attributes: 816 o Test duration: 120s 817 o Path characteristics: 819 * Reference bottleneck capacity: 3.5Mbps 821 * Path capacity ratio: 1.0 823 o Application-related: 825 * Media Source: 827 + Media type: Video 829 - Media direction: forward. 831 - Number of media sources: Three (3) 833 - Media timeline: New media flows are added sequentially, 834 at short time intervals. See test specific setup below. 836 + Media type: Audio 838 - Media direction: forward. 840 - Number of media sources: Three (3) 842 - Media timeline: New media flows are added sequentially, 843 at short time intervals. See test specific setup below. 845 * Competing traffic: 847 + Number of sources : Zero (0) 849 o Test Specific Information: Table 5 defines the media timeline for 850 both media type. 852 +---------+------------+------------+----------+ 853 | Flow IF | Media type | Start time | End time | 854 +---------+------------+------------+----------+ 855 | 1 | Video | 0s | 119s | 856 | 2 | Video | 20s | 119s | 857 | 3 | Video | 40s | 119s | 858 | 4 | Audio | 0s | 119s | 859 | 5 | Audio | 20s | 119s | 860 | 6 | Audio | 40s | 119s | 861 +---------+------------+------------+----------+ 863 Table 5: Media Timeline for Video and Audio media sources 865 5.5. Round Trip Time Fairness 867 In this test case, multiple RMCAT media flows share the bottleneck 868 link, but the end-to-end path latency for each RMCAT flow is 869 different. For the sake of simplicity it is assumed that there are 870 no other non-RMCAT competing traffic sources in the bottleneck link 871 and that there is sufficient capacity to accommodate all the flows. 872 While this appears to be a variant of test case 5.2, it focuses on 873 the capacity sharing aspect of the candidate algorithm under 874 different RTTs. 876 It is expected that the competing flows will converge to bit rates to 877 accommodate all the flows with minimum possible latency and loss. 878 Specifically, the test introduces five media flows at the same time 879 instance. 881 To evaluate the performance of the candidate algorithms it is 882 expected to log enough information to visualize the metrics described 883 in Section 4.1 at a fine enough time granularity: 885 Testbed Topology: Five (5) media sources S1,S2,..,S5 are connected to 886 their corresponding media sinks R1,R2,..,R5. The media traffic is 887 transported over the forward path and corresponding feedback/control 888 traffic is transported over the backward path. The topology is the 889 same as in Section 5.4. The end-to-end path delays are: 10ms for 890 S1-R1, 25ms for S2-R2, 50ms for S3-R3, 100ms for S4-R4, and 150ms 891 S5-R5, respectively. 893 Testbed attributes: 895 o Test duration: 300s 897 o Path characteristics: 899 * One-Way propagation delay for each flow: 10ms, 25ms, 50ms, 900 100ms, 150ms. 902 o Application-related: 904 * Media Source: 906 + Media type: Video 908 - Media direction: forward 910 - Number of media sources: Five (5) 911 - Media timeline: New media flows are added sequentially, 912 at short time intervals. See test specific setup below. 914 + Media type: Audio 916 - Media direction: forward. 918 - Number of media sources: Five (5) 920 - Media timeline: New media flows are added sequentially, 921 at short time intervals. See test specific setup below. 923 * Competing traffic: 925 + Number of sources : Zero (0) 927 o Test Specific Information: Table 6 defines the media timeline for 928 both media type. 930 +---------+------------+------------+----------+ 931 | Flow IF | Media type | Start time | End time | 932 +---------+------------+------------+----------+ 933 | 1 | Video | 0s | 299s | 934 | 2 | Video | 10s | 299s | 935 | 3 | Video | 20s | 299s | 936 | 4 | Video | 30s | 299s | 937 | 5 | Video | 40s | 299s | 938 | 6 | Audio | 0 | 299s | 939 | 7 | Audio | 10s | 299s | 940 | 8 | Audio | 20s | 299s | 941 | 9 | Audio | 30s | 299s | 942 | 10 | Audio | 40s | 299s | 943 +---------+------------+------------+----------+ 945 Table 6: Media Timeline for Video and Audio media sources 947 5.6. RMCAT Flow competing with a long TCP Flow 949 In this test case, one or more RMCAT media flows share the bottleneck 950 link with at least one long lived TCP flows. Long lived TCP flows 951 download data throughout the session and are expected to have 952 infinite amount of data to send and receive. This is a scenario 953 where a multimedia application co-exists with a large file download. 954 The test case measures the adaptivity of the candidate algorithm to 955 competing traffic. It addresses the requirement 3 in 956 [I-D.ietf-rmcat-cc-requirements]. 958 Expected behavior: depending on the convergence observed in test case 959 5.1 and 5.2, the candidate algorithm may be able to avoid congestion 960 collapse. In the worst case, the media stream will fall to the 961 minimum media bit rate. 963 To evaluate the performance of the candidate algorithms it is 964 expected to log enough information to visualize the following metrics 965 in addition to the metrics described in Section 4.1 at a fine enough 966 time granularity: 968 1. Flow level: 970 A. TCP throughput. 972 Testbed topology: One (1) media source S1 is connected to 973 corresponding media sink, R1. In addition, there is a long-live TCP 974 flow sharing the same bottleneck link. The media traffic is 975 transported over the forward path and corresponding feedback/control 976 traffic is transported over the backward path. The TCP traffic goes 977 over the forward path from, S_tcp with acknowledgement packets 978 flowing along the backward path from, R_tcp. 980 +--+ +--+ 981 |S1|===== \ Forward --> / =======|R1| 982 +--+ \\ // +--+ 983 \\ // 984 +-----+ +-----+ 985 | A |---------------------------->| B | 986 | |<----------------------------| | 987 +-----+ +-----+ 988 // \\ 989 // <-- Backward \\ 990 +-----+ // \\ +-----+ 991 |S_tcp|=== / \ ===|R_tcp| 992 +-----+ +-----+ 994 Figure 6: Testbed Topology for TCP vs RMCAT Flows 996 Testbed attributes: 998 o Test duration: 120s 1000 o Path characteristics: 1002 * Reference bottleneck capacity: 2Mbps 1004 * Path capacity ratio: 1.0 1005 * Bottleneck queue size: [300ms, 1000ms] 1007 o Application-related: 1009 * Media Source: 1011 + Media type: Video 1013 - Media direction: forward 1015 - Number of media sources: One (1) 1017 - Media timeline: 1019 o Start time: 5s. 1021 o End time: 119s. 1023 + Media type: Audio 1025 - Media direction: forward 1027 - Number of media sources: One (1) 1029 - Media timeline: 1031 o Start time: 5s. 1033 o End time: 119s. 1035 * Additionally, implementers are encouraged to run the experiment 1036 with multiple media sources. 1038 * Competing traffic: 1040 + Number and Types of sources : one (1), long-lived TCP 1042 + Traffic direction : forward 1044 + Congestion control: Default TCP congestion control. 1046 + Traffic timeline: 1048 - Start time: 0s. 1050 - End time: 119s. 1052 o Test Specific Information: None 1054 5.7. RMCAT Flow competing with short TCP Flows 1056 In this test case, one or more RMCAT media flow shares the bottleneck 1057 link with multiple short-lived TCP flows. Short-lived TCP flows 1058 resemble the on/off pattern observed in the web traffic, wherein 1059 clients (browsers) connect to a server and download a resource 1060 (typically a web page, few images, text files, etc.) using several 1061 TCP connections (up to 4). This scenario shows the performance of 1062 the multimedia application when several browser windows are active. 1063 The test case measures the adaptivity of the candidate algorithm to 1064 competing web traffic, it addresses the requirements 1.E in 1065 [I-D.ietf-rmcat-cc-requirements]. 1067 Depending on the number of short TCP flows, the cross-traffic either 1068 appears as a short burst flow or resembles a long TCP flow. The 1069 intention of this test is to observe the impact of short-term burst 1070 on the behaviour of the candidate algorithm. 1072 To evaluate the performance of the candidate algorithms it is 1073 expected to log enough information to visualize the following metrics 1074 in addition to the metrics described in Section 4.1 at a fine enough 1075 time granularity: 1077 1. Flow level: 1079 A. Variation in the sending rate of the TCP flow. 1081 B. TCP throughput. 1083 Testbed topology: The topology described here is same as the one 1084 described in Figure 6. 1086 Testbed attributes: 1088 o Test duration: 300s 1090 o Path characteristics: 1092 * Reference bottleneck capacity: 2.0Mbps 1094 * Path capacity ratio: 1.0 1096 o Application-related: 1098 * Media Source: 1100 + Media type: Video 1101 - Media direction: forward 1103 - Number of media sources: two (2) 1105 - Media timeline: 1107 o Start time: 5s. 1109 o End time: 299s. 1111 + Media type: Audio 1113 - Media direction: forward 1115 - Number of media sources: two (2) 1117 - Media timeline: 1119 o Start time: 5s. 1121 o End time: 299s. 1123 * Competing traffic: 1125 + Number and Types of sources : Ten (10), short-lived TCP 1126 flows. 1128 + Traffic direction : forward 1130 + Congestion algorithm: Default TCP Congestion control. 1132 + Traffic timeline: Each short TCP flow is modeled as a 1133 sequence of file downloads interleaved with idle periods. 1134 See test specific setup. Not all short TCPs start at the 1135 same time, 2 start in the ON state while 8 start in an OFF 1136 stats. The model for the idle times for the OFF state is 1137 discussed in the Short-TCP model. 1139 o Test Specific Information: 1141 * Short-TCP traffic model: 1143 + File sizes: uniform distribution between 100KB to 1MB 1145 + Idle period: the duration of the OFF state is derived from 1146 an exponential distribution with the mean value of 10 1147 seconds. 1149 5.8. Media Pause and Resume 1151 In this test case, more than one real-time interactive media flows 1152 share the link bandwidth and all flows reach to a steady state by 1153 utilizing the link capacity in an optimum way. At these stage one of 1154 the media flow is paused for a moment. This event will result in 1155 more available bandwidth for the rest of the flows and as they are on 1156 a shared link. When the paused media flow will resume it would no 1157 longer have the same bandwidth share on the link. It has to make 1158 it's way through the other existing flows in the link to achieve a 1159 fair share of the link capacity. This test case is important 1160 specially for real-time interactive media which consists of more than 1161 one media flows and can pause/resume media flow at any point of time 1162 during the session. This test case directly addresses the 1163 requirement number 5 in [I-D.ietf-rmcat-cc-requirements]. One can 1164 think it as a variation of test case defined in Section 5.4. 1165 However, it is different as the candidate algorithms can use 1166 different strategies to increase its efficiency, for example the 1167 fairness, convergence time, reduce oscillation etc, by capitalizing 1168 the fact that they have previous information of the link. 1170 To evaluate the performance of the candidate algorithms it is 1171 expected to log enough information to visualize the following metrics 1172 in addition to the metrics described in Section 4.1 at a fine enough 1173 time granularity: 1175 1. Flow level: 1177 A. Variation in sending bit rate and goodput. Mainly observing 1178 the frequency and magnitude of oscillations. 1180 Testbed Topology: Same as test case defined in Section 5.4 1182 Testbed attributes: The general description of the testbed parameters 1183 are same as Section 5.4 with changes in the test specific setup as 1184 below- 1186 o Other test specific setup: 1188 * Media flow timeline: 1190 + Flow ID: One (1) 1192 + Start time: 0s 1194 + Flow duration: 119s 1196 + Pause time: not required 1197 + Resume time: not required 1199 * Media flow timeline: 1201 + Flow ID: Two (2) 1203 + Start time: 0s 1205 + Flow duration: 119s 1207 + Pause time: at 40s 1209 + Resume time: at 60s 1211 * Media flow timeline: 1213 + Flow ID: Three (3) 1215 + Start time: 0s 1217 + Flow duration:119s 1219 + Pause time: not required 1221 + Resume time: not required 1223 6. Other potential test cases 1225 It has been noticed that there are other interesting test cases 1226 besides the basis test cases listed above. In many aspects, these 1227 additional test cases can help to further evaluate the candidate 1228 algorithm. They are listed as below. 1230 6.1. Explicit Congestion Notification Usage 1232 This test case requires to run all the basic test cases with the 1233 availability of Explicit Congestion Notification (ECN) [RFC6679] 1234 feature enabled. The goal of this test is to exhibit that the 1235 candidate algorithms does not fail when ECN signals are available. 1236 With ECN signals enabled the algorithms are expected to perform 1237 better than their delay based variants. 1239 6.2. Multiple Bottlenecks 1241 In this test case one RMCAT flow, S1->R2 traverse a path with 1242 multiple bottlenecks. As illustrated in Figure 7, the first flow 1243 (S1->R1) competes with the second RMCAT flow (S2->R2) over the link 1244 between A and B which is close to the sender side; again, that flow 1245 (S1->R1) competes with the third RMCAT flow (S3->R3) over the link 1246 between C and D which is close to the receiver side. The goal of 1247 this test is to ensure that the candidate algorithms work properly in 1248 the presence of multiple bottleneck links on the end to end path. 1250 Expected behavior: the candidate algorithm is expected to achieve 1251 full utilization at both bottleneck links without starving any of the 1252 three RMCAT flows. 1254 Forward ----> 1256 +---+ +---+ +---+ +---+ 1257 |S2 | |R2 | |S3 | |R3 | 1258 +---+ +---+ +---+ +---+ 1259 | | | | 1260 | | | | 1261 +---+ +-----+ +-----+ +-----+ +-----+ +---+ 1262 |S1 |=======| A |------>| B |----->| C |---->| D |=======|R1 | 1263 +---+ | |<------| |<-----| |<----| | +---+ 1264 +-----+ +-----+ +-----+ +-----+ 1266 1st 2nd 1267 Bottleneck (A->B) Bottleneck (C->D) 1269 <------ Backward 1271 Figure 7: Testbed Topology for Multiple Bottlenecks 1273 Testbed topology: Three media sources S1, S2, and S3 are connected to 1274 respective destinations R1, R2, and R3. For all three flows the 1275 media traffic is transported over the forward path and corresponding 1276 feedback/control traffic is transported over the backward path. 1278 Testbed attributes: 1280 o Test duration: 120s 1282 o Path characteristics: 1284 * Reference bottleneck capacity between A and B = 2Mbps. 1286 * Path capacity ratio between A and B: 1.0 1287 * Path capacity ratio between B and C: 4.0. 1289 * Path capacity ratio between C and D: 0.75. 1291 * One-Way propagation delay: 1293 1. Between S1 and R1: 100ms 1295 2. Between S2 and R2: 40ms 1297 3. Between S3 and R3: 40ms 1299 o Application-related: 1301 * Media Source: 1303 + Media type: Video 1305 - Media direction: Forward 1307 - Number of media sources: Three (3) 1309 - Media timeline: 1311 o Start time: 0s. 1313 o End time: 119s. 1315 + Media type: Audio 1317 - Media direction: Forward 1319 - Number of media sources: Three (3) 1321 - Media timeline: 1323 o Start time: 0s. 1325 o End time: 119s. 1327 * Competing traffic: 1329 + Number of sources : Zero (0) 1331 7. Wireless Access Links 1333 Additional wireless network (both cellular network and WiFi network) 1334 specific test cases are define in [I-D.ietf-rmcat-wireless-tests] 1336 8. Security Considerations 1338 Security issues have not been discussed in this memo. 1340 9. IANA Considerations 1342 There are no IANA impacts in this memo. 1344 10. Acknowledgements 1346 Much of this document is derived from previous work on congestion 1347 control at the IETF. 1349 The content and concepts within this document are a product of the 1350 discussion carried out in the Design Team. 1352 11. References 1354 11.1. Normative References 1356 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 1357 and K. Carlberg, "Explicit Congestion Notification (ECN) 1358 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 1359 2012, . 1361 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1362 Jacobson, "RTP: A Transport Protocol for Real-Time 1363 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1364 July 2003, . 1366 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1367 Video Conferences with Minimal Control", STD 65, RFC 3551, 1368 DOI 10.17487/RFC3551, July 2003, 1369 . 1371 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 1372 "RTP Control Protocol Extended Reports (RTCP XR)", RFC 1373 3611, DOI 10.17487/RFC3611, November 2003, 1374 . 1376 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1377 "Extended RTP Profile for Real-time Transport Control 1378 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 1379 10.17487/RFC4585, July 2006, 1380 . 1382 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1383 Real-Time Transport Control Protocol (RTCP): Opportunities 1384 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 1385 2009, . 1387 [I-D.ietf-rmcat-eval-criteria] 1388 Singh, V. and J. Ott, "Evaluating Congestion Control for 1389 Interactive Real-time Media", draft-ietf-rmcat-eval- 1390 criteria-03 (work in progress), March 2015. 1392 [I-D.ietf-rmcat-wireless-tests] 1393 Sarker, Z. and I. Johansson, "Evaluation Test Cases for 1394 Interactive Real-Time Media over Wireless Networks", 1395 draft-ietf-rmcat-wireless-tests-00 (work in progress), 1396 June 2015. 1398 11.2. Informative References 1400 [I-D.ietf-rmcat-cc-requirements] 1401 Jesup, R. and Z. Sarker, "Congestion Control Requirements 1402 for Interactive Real-Time Media", draft-ietf-rmcat-cc- 1403 requirements-09 (work in progress), December 2014. 1405 [xiph-seq] 1406 Xiph.org, , "Video Test Media", 1407 http://media.xiph.org/video/derf/ . 1409 [HEVC-seq] 1410 HEVC, , "Test Sequences", 1411 http://www.netlab.tkk.fi/~varun/test_sequences/ . 1413 Authors' Addresses 1415 Zaheduzzaman Sarker 1416 Ericsson AB 1417 Luleae, SE 977 53 1418 Sweden 1420 Phone: +46 10 717 37 43 1421 Email: zaheduzzaman.sarker@ericsson.com 1422 Varun Singh 1423 Aalto University 1424 School of Electrical Engineering 1425 Otakaari 5 A 1426 Espoo, FIN 02150 1427 Finland 1429 Email: varun@comnet.tkk.fi 1430 URI: http://www.netlab.tkk.fi/~varun/ 1432 Xiaoqing Zhu 1433 Cisco Systems 1434 510 McCarthy Blvd 1435 Milpitas, CA 95134 1436 USA 1438 Email: xiaoqzhu@cisco.com 1440 Michael A. Ramalho 1441 Cisco Systems, Inc. 1442 6310 Watercrest Way Unit 203 1443 Lakewood Ranch, FL 34202-5211 1444 USA 1446 Phone: +1 919 476 2038 1447 Email: mramalho@cisco.com