idnits 2.17.1 draft-fu-rmcat-wifi-test-case-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 8 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([I-D.ietf-rmcat-eval-test], [I-D.draft-sarker-rmcat-cellular-eval-test-cases]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (July 6, 2015) is 3210 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 745, but not defined == Unused Reference: 'I-D.ietf-avtcore-rtp-circuit-breakers' is defined on line 993, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rmcat-eval-criteria' is defined on line 999, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rmcat-cc-requirements' is defined on line 1009, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtcweb-use-cases-and-requirements' is defined on line 1021, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-avtcore-rtp-circuit-breakers-05 == Outdated reference: A later version (-14) exists of draft-ietf-rmcat-eval-criteria-01 == Outdated reference: A later version (-10) exists of draft-ietf-rmcat-eval-test-01 == Outdated reference: A later version (-09) exists of draft-ietf-rmcat-cc-requirements-04 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-14 Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Fu 3 Internet-Draft X. Zhu 4 Intended status: Informational M. Ramalho 5 Expires: January 7, 2016 W. Tan 6 Cisco Systems 7 July 6, 2015 9 Evaluation Test Cases for Interactive Real-Time Media over Wi-Fi 10 Networks 11 draft-fu-rmcat-wifi-test-case-01 13 Abstract 15 An increasing proportion of multimedia communication applications, 16 including real-time interactive voice and video, are transported over 17 Wi-Fi networks (i.e., wireless local area networks following IEEE 18 802.11 standards) today. It is therefore important to evaluate 19 candidate congestion control schemes designed in the RMCAT Working 20 Group over test cases that include Wi-Fi access links. This draft 21 serves such a purpose, and is complementary to 22 [I-D.ietf-rmcat-eval-test] and 23 [I-D.draft-sarker-rmcat-cellular-eval-test-cases] 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 7, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Test Scenarios with Wired Bottlenecks . . . . . . . . . . . . 4 62 3.1. Single RMCAT Flow over Wired Bottleneck . . . . . . . . . 4 63 3.2. Bidirectional RMCAT Flow over Wired Bottleneck . . . . . 5 64 3.3. RMCAT Flow Competing with Long TCP over Wired Bottleneck 7 65 4. Bottleneck over Wireless Network . . . . . . . . . . . . . . 8 66 4.1. Adaptive rate selection with single RMCAT flow . . . . . 8 67 4.2. Multiple RMCAT Flows Sharing the Wireless Downlink . . . 10 68 4.3. Multiple RMCAT Flows Sharing the Wireless Uplink . . . . 12 69 4.4. Multiple Bi-Directional RMCAT Flows Sharing the Wireless 70 Bottleneck . . . . . . . . . . . . . . . . . . . . . . . 14 71 4.5. Multiple RMCAT and TCP Flows Sharing the Wireless Uplink 15 72 4.6. Multiple RMCAT and TCP Flows Sharing the Wireless 73 Downlink . . . . . . . . . . . . . . . . . . . . . . . . 17 74 4.7. Multiple Bi-Directional RMCAT and TCP Flows Sharing the 75 Wireless Bottleneck . . . . . . . . . . . . . . . . . . . 19 76 5. Other potential test cases . . . . . . . . . . . . . . . . . 21 77 5.1. Wi-Fi Roaming . . . . . . . . . . . . . . . . . . . . . . 21 78 5.2. Wi-Fi/Cellular Switch . . . . . . . . . . . . . . . . . . 22 79 5.3. EDCA/WMM usage . . . . . . . . . . . . . . . . . . . . . 22 80 5.4. Legacy 802.11b Effects . . . . . . . . . . . . . . . . . 22 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 84 7.2. Informative References . . . . . . . . . . . . . . . . . 23 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 87 1. Introduction 89 Given the prevalence of Internet access links over Wi-Fi, it is 90 important to evaluate candidate RMCAT congestion control solutions 91 over Wi-Fi test cases. Such evaluations should also highlight the 92 inherent different characteristics of Wi-Fi networks in contrast to 93 Wired networks: 95 o The wireless radio channel is subject to interference from nearby 96 transmitters, multipath fading, and shadowing, causing 97 fluctuations in link throughput and sometimes an error-prone 98 communication environment 100 o Available network bandwidth is not only shared over the air 101 between cocurrent users, but also between uplink and downlink 102 traffic due to the half duplex nature of wireless transmission 103 medium. 105 o Packet transmessions over Wi-Fi are susceptible to contentions and 106 collisions over the air. Consequently, traffic load beyond a 107 certain utilization level over a Wi-Fi network can introduce 108 frequent collisions and significant network overhead. This, in 109 turn, leads to excessive delay, retransmission, loss and lower 110 effective bandwidth for applications. 112 o The IEEE 802.11 standard (i.e., Wi-Fi) supports multi-rate 113 transmission capabilities by dynamically choosing the most 114 appropriate modulation scheme for a given received singal 115 strength. A different choice of Physical-layer rate will lead to 116 different application-layer throughput. 118 o Presence of legancy 802.11b networks can significantly slow down 119 the the rest of a modern Wi-Fi Network, since it takes longer to 120 transmit the same packet over a slower link than over a faster 121 link. [Editor's note: maybe include a reference here instead.] 123 o Handover from one Wi-Fi Access Point (AP) to another may cause 124 packet delay and loss. 126 o IEEE 802.11e defined EDCA/WMM (Enhanced DCF Channel Access/Wi-Fi 127 Multi-Media) to give voice and video streams higher priority over 128 pure data applications (e.g., file transfers). 130 As we can see here, presence of Wi-Fi network in different different 131 network topologies and traffic arrival can exert different impact on 132 the network performance in terms of video transport rate, packet loss 133 and delay that, in turn, effect end-to-end real-time multimedia 134 congestion control. 136 Currently, the most widely used IEEE 802.11 standards are 802.11g and 137 802.11n. The industry is moving towards 802.11ac and, potentially, 138 802.11ad. IEEE 802.11b is legency standard, and 802.11a has not been 139 widely adopted. Throughout this draft, unless otherwise mentioned, 140 test cases are described using 802.11g mostly due to its wide 141 availability both in test equipments and network simulation platform. 142 Whenever possible, it is recommended to extend some of the 143 experiments to 802.11ac so as to reflect a more mordent Wi-Fi network 144 setting. 146 Since Wi-Fi network normally connects to a wired infrastructure, 147 either the wired network or the Wi-Fi network could be the 148 bottleneck. In the following section, we describe basic test cases 149 for both scenarios separately. 151 2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described RFC2119 [RFC2119]. 157 3. Test Scenarios with Wired Bottlenecks 159 The test scenarios below are intended to mimic the set up of video 160 conferencing over Wi-Fi connections from the home. Typically, the 161 Wi-Fi home network is not congested and the bottleneck is present 162 over the wired home access link. Although it is expected that test 163 evaluation results from this section are similar to those from the 164 all-wired test cases (draft-sarker-rmcat-eval-test), it is worthwhile 165 to run through these tests as sanity checks. 167 3.1. Single RMCAT Flow over Wired Bottleneck 169 This test case is designed to measure the responsiveness of the 170 candidate algorithm when the Wi-Fi hop of the connection is 171 uncongested. 173 Figure 1 illustrates topology of this test. 175 uplink 176 +-------------->+ 177 +----+ +----+ +----+ +----+ 178 | S |))))))))))| AP |==========| B |=========| R | 179 +----+ +----+ +----+ +----+ 181 Figure 1: Single Flow over Wired Bottleneck 183 Testbed attributes: 185 o Test duration: 100s 187 o Path characteristics: 189 * Uplink capacity: 1Mbps 191 * One-Way propagation delay: 50ms. 193 * Maximum end-to-end jitter: 30ms 195 * Bottleneck queue type: Drop tail. 197 * Bottleneck queue size: 300ms. 199 * Path loss ratio: 0%. 201 o Application-related: 203 * Media Traffic: 205 + Media type: Video 207 + Media direction: forward. 209 + Number of media sources: One (1) 211 + Media timeline: 213 - Start time: 0s. 215 - End time: 99s. 217 * Competing traffic: 219 + Number of sources : Zero (0) 221 Expected behavior: the candidate algorithm is expected to detect the 222 path capacity constraint, converges to bottleneck link's capacity and 223 adapt the flow to avoid unwanted oscillation when the sending bit 224 rate is approaching the bottleneck link's capacity. Oscillations 225 occur when the media flow(s) attempts to reach its maximum bit rate, 226 overshoots the usage of the available bottleneck capacity, to rectify 227 it reduces the bit rate and starts to ramp up again. 229 3.2. Bidirectional RMCAT Flow over Wired Bottleneck 231 This test case is designed to evaluate performance of the candidate 232 algorithm when lack of enough feedback. 234 +----+ +----+ 235 | R1 |)))))) /=====| S1 | 236 +----+ )) uplink // +----+ 237 )) +-------------->+ // 238 +----+ +----+ +----+ +----+ 239 | S2 |))))))))))| AP |==========| B |========| R2 | 240 +----+ +----+ +----+ +----+ 241 +<--------------+ 242 downlink 244 Figure 2: One Bi-directional Flow over Wired Bottleneck 246 Testbed attributes: 248 o Test duration: 100s 250 o Path characteristics: 252 * uplink capacity: 1Mbps 254 * One-Way propagation delay: 50ms. 256 * Maximum end-to-end jitter: 30ms 258 * Bottleneck queue type: Drop tail. 260 * Bottleneck queue size: 300ms. 262 * Path loss ratio: 0%. 264 o Application characteristics: 266 * Media Traffic: 268 + Media type: Video 270 + Media direction: forward and backward. 272 + Number of media sources: Two (2) 274 + Media timeline: 276 - Start time: 0s. 278 - End time: 99s. 280 * Competing traffic: 282 + Number and Types of sources : zero (0) 284 Expected behavior: It is expected that the candidate algorithms is 285 able to cope with the lack/noise of feedback information and adapt to 286 minimize the performance degradation of media flows in the forward 287 channel. 289 3.3. RMCAT Flow Competing with Long TCP over Wired Bottleneck 291 This test case is designed to measure the performance of the 292 candidate algorithm when lack of enough feedback. 294 +----+ +----+ 295 | S1 |)))))) /=====| R1 | 296 +----+ )) uplink // +----+ 297 )) +-------------->+ // 298 +-------+ +----+ +----+ +-------+ 299 | S_tcp |))))))))))| AP |==========| B |========| R_tcp | 300 +-------+ +----+ +----+ +-------+ 301 +<--------------+ 302 downlink 304 Figure 3: RMCAT vs. TCP over Wired Bottleneck 306 Testbed attributes: 308 Test duratiion: 100s 310 Path characteristics: 312 * uplink capacity: 1Mbps 314 * One-Way propagation delay: 50ms. 316 * Maximum end-to-end jitter: 30ms 318 * Bottleneck queue type: Drop tail. 320 * Bottleneck queue size: 300ms. 322 * Path loss ratio: 0%. 324 Application-related: 326 * Media Traffic: 328 + Media type: Video 330 + Media direction: forward. 332 + Number of media sources: One (1) 334 + Media timeline: 336 - Start time: 0s. 338 - End time: 99s. 340 * Competing traffic: 342 + Types of sources : long-lived TCP 344 + Number of sources: One (1) 346 + Traffic direction : forward 348 + Congestion control: Default TCP congestion control [TBD]. 350 + Traffic timeline: 352 - Start time: 0s. 354 - End time: 119s. 356 Expected behavior: the candidate algorithm should be able to avoid 357 congestion collapse, and get fair share of the bandwidth. In the 358 worst case, the media stream will fall to the minimum media bit rate. 360 4. Bottleneck over Wireless Network 362 These test cases assume that the wired portion along the media path 363 are well-provisioned. The bottleneck is in the Wi-Fi network over 364 wireless. This is to mimic the enterprise/coffee-house scenarios. 366 4.1. Adaptive rate selection with single RMCAT flow 368 Since morden IEEE 802.11 standards supports far higher data rates 369 than the maximum requirements of individual RMCAT flows, in this test 370 the legacy standard 802.11b is chosen to test the single RMCAT flow 371 case. 802.11b Adaptive rate selection can operate at 11 Mbps in terms 372 of PHY-layer transmission rate, and falls back to 5.5 Mbps, 2 Mbps, 373 and 1 Mbps when the wireless client moves away from the access point. 375 [Editor's Note: we may want to move this section to Section 5.4 376 instead.] 378 uplink 379 +-------------->+ 380 +----+ +----+ +----+ +----+ 381 | S |))))))))))| AP |==========| B |=========| R | 382 +----+ +----+ +----+ +----+ 384 Figure 4: One RMCAT Flow over Wireless Bottleneck 386 Testbed attributes: 388 Test duratiion: 100s 390 Path characteristics: 392 * Wired path capacity: 100Mbps 394 * Wi-Fi PHY Rate: 1Mbps (PHY rate) 396 * One-Way propagation delay: 50ms. 398 * Maximum end-to-end jitter: 30ms 400 * Bottleneck queue type: Drop tail. 402 * Bottleneck queue size: 300ms. 404 * Path loss ratio: 0%. 406 Application characteristics: 408 * Media Traffic: 410 + Media type: Video 412 + Media direction: forward and backward. 414 + Number of media sources: One (1) 416 + Media timeline: 418 - Start time: 0s. 420 - End time: 99s. 422 * Competing traffic: 424 + Number and Types of sources : zero (0) 426 Test Specific Information: 428 * This test will change the distance between station and AP (need 429 some experiment), and incur the adaptive rate selection 430 variation as listed in Figure 5. 432 +---------------------+----------------+------------+----------------+ 433 | Variation pattern | Path direction | Start time | PHY-layer rate | 434 | index | | | | 435 +---------------------+----------------+------------+----------------+ 436 | One | Forward | 0s | 5.5 Mbps | 437 | Two | Forward | 40s | 2 Mbps | 438 | Three | Forward | 60s | 1 Mbps | 439 | Four | Forward | 80s | 2 Mbps | 440 +---------------------+----------------+------------+---------------+ 442 Figure 5: Adaptive rate variation pattern for uplink direction 444 Expected behavior: The rate adaptation algorithm run at application 445 level should follow the adaptation in 802.11 mac layer. 447 4.2. Multiple RMCAT Flows Sharing the Wireless Downlink 449 This test case is for studying the impact of contention on competing 450 RMCAT flows. Specifications for IEEE 802.11g with a physical-layer 451 transmission rate of 54 Mbps is chosen. Not that retransmission and 452 MAC-layer headers and control packets may be sent at a lower link 453 speed. The total application-layer throughput (reasonable distance, 454 low interference and small number of contention stations) for 802.11g 455 is around 20 Mbps. Consequently, a total of 16 RMCAT flows are 456 needed for saturating the wireless interface in this experiment. 458 uplink 459 +----------------->+ 460 +----+ +----+ 461 | R1 |)))))) /=====| S1 | 462 +----+ )) // +----+ 463 )) // 464 +----+ +----+ +----+ +----+ 465 | R2 |))))))))))| AP |==========| B |========| S2 | 466 +----+ +----+ +----+ +----+ 467 ...... ...... 468 )) \\ 469 +----+ )) \\ +----+ 470 |R16 |)))))) \=====|S16 | 471 +----+ +----+ 472 +<-----------------+ 473 downlink 475 Figure 6: Multiple RMCAT Flows Sharing the Wireless Downlink 477 Testbed attributes: 479 o Test duratiion: 100s 481 o Path characteristics: 483 * Wired path capacity: 100Mbps 485 * Wi-Fi PHY Rate: 54Mbps (PHY rate) 487 * One-Way propagation delay: 50ms. 489 * Maximum end-to-end jitter: 30ms 491 * Bottleneck queue type: Drop tail. 493 * Bottleneck queue size: 300ms. 495 * Path loss ratio: 0%. 497 o Application characteristics: 499 * Media Traffic: 501 + Media type: Video 503 + Media direction: backward. 505 + Number of media sources: Sixteen (16) 507 + Media timeline: 509 - Start time: 0s. 511 - End time: 99s. 513 * Competing traffic: 515 + Number and Types of sources : Zero (0) 517 Expected behavior: All RMCAT flow should get fair share of the 518 bandwidth. Overall bandwidth usage should be no less than same case 519 with TCP flows (using TCP as performance benchmark). The delay and 520 loss should be within acceptable range for real-time multimedia flow. 522 4.3. Multiple RMCAT Flows Sharing the Wireless Uplink 524 This test case is different with the previous section with mostly 525 downlink transmissions. When multiple clients attempt to transmit 526 video packets uplink over the wireless interface, they introduce more 527 frequent contentions and potentially collisions. As a results, the 528 per-client throught is expected to be lower than the downlink-only 529 scenario. 531 uplink 532 +----------------->+ 533 +----+ +----+ 534 | S1 |)))))) /=====| R1 | 535 +----+ )) // +----+ 536 )) // 537 +----+ +----+ +----+ +----+ 538 | S2 |))))))))))| AP |==========| B |========| R2 | 539 +----+ +----+ +----+ +----+ 540 ...... ...... 541 )) \\ 542 +----+ )) \\ +----+ 543 |S16 |)))))) \=====|R16 | 544 +----+ +----+ 545 +<-----------------+ 546 downlink 548 Figure 7: Multiple RMCAT Flows Sharing the Wireless Uplink 550 Testbed attributes: 552 o Test duratiion: 100s 554 o Path characteristics: 556 * Wired path capacity: 100Mbps 558 * Wi-Fi PHY Rate: 54Mbps (PHY rate) 560 * Maximum end-to-end jitter: 30ms 562 * One-Way propagation delay: 50ms. 564 * Bottleneck queue type: Drop tail. 566 * Bottleneck queue size: 300ms. 568 * Path loss ratio: 0%. 570 o Application characteristics: 572 * Media Traffic: 574 + Media type: Video 576 + Media direction: forward and backward. 578 + Number of media sources: Sixteen (16) 580 + Media timeline: 582 - Start time: 0s. 584 - End time: 99s. 586 * Competing traffic: 588 + Number and Types of sources : Zero (0) 590 Expected behavior: All RMCAT flow should get fair share of the 591 bandwidth, and the overall bandwidth usage should no less than same 592 case with TCP flows (use TCP as performance benchmark). The delay 593 and loss should be in acceptable range for real-time multimedia flow 594 (might need rtp circuit breaker to guarantee that?). 596 4.4. Multiple Bi-Directional RMCAT Flows Sharing the Wireless 597 Bottleneck 599 This one differs with previous contention cases because Wi-Fi share 600 bandwdith between uplink and downlink. 602 uplink 603 +----------------->+ 604 +----+ +----+ 605 | R1 |)))))) /=====| S1 | 606 +----+ )) // +----+ 607 )) // 608 ...... ...... 609 +----+ +----+ +----+ +----+ 610 | R8 |))))))))))| AP |==========| B |========| S8 | 611 +----+ +----+ +----+ +----+ 612 ...... ...... 613 )) \\ 614 +----+ )) \\ +----+ 615 |S16 |)))))) \=====|R16 | 616 +----+ +----+ 617 +<-----------------+ 618 downlink 620 Figure 8: Multiple Bi-Directional RMCAT Flows Sharing the Wireless 621 Bottleneck 623 Testbed attributes: 625 o Test duratiion: 100s 627 o Path characteristics: 629 * Wired path capacity: 100Mbps 631 * Wi-Fi PHY Rate: 54Mbps (PHY rate) 633 * One-Way propagation delay: 50ms. 635 * Maximum end-to-end jitter: 30ms 637 * Bottleneck queue type: Drop tail. 639 * Bottleneck queue size: 300ms. 641 * Path loss ratio: 0%. 643 o Application characteristics: 645 * Media Traffic: 647 + Media type: Video 649 + Media direction: forward and backward. 651 + Number of media sources: Sixteen (16), 8 for uplink, 8 for 652 downlink. 654 + Media timeline: 656 - Start time: 0s. 658 - End time: 99s. 660 * Competing traffic: 662 + Number and Types of sources : zero (0) 664 Expected behavior: All (uplink/downlink) RMCAT flow should get fair 665 share of the bandwidth, and the overall bandwidth usage should no 666 less than same case with TCP flows (use TCP as performance 667 benchmark). The delay and loss should be in acceptable range for 668 real-time multimedia flow (might need rtp circuit breaker to 669 guarantee that?). 671 4.5. Multiple RMCAT and TCP Flows Sharing the Wireless Uplink 673 This case having both long lived TCP and RMCAT sharing the uplink at 674 the same time. This is for testing how RMCAT competing with long 675 lived TCP flow in a congested Wi-Fi network. 677 uplink 678 +----------------->+ 679 +----+ +----+ 680 | S1 |)))))) /=====| R1 | 681 +----+ )) // +----+ 682 )) // 683 ...... ...... 684 +----+ +----+ +----+ +----+ 685 | S8 |))))))))))| |==========| |========| R8 | 686 +----+ | | | | +----+ 687 | AP | | B | 688 +--------+ | | | | +--------+ 689 | S1_tcp |))))))| | | |========| R1_tcp | 690 +--------+ +----+ +----+ +--------+ 691 ...... ...... 692 )) \\ 693 +--------+ )) \\ +--------+ 694 | S8_tcp |)))) \=====| R8_tcp | 695 +--------+ +--------+ 696 +<-----------------+ 697 downlink 699 Figure 9: Multiple RMCAT and TCP Flows Sharing the Wireless Uplink 701 Testbed attributes: 703 o Test duratiion: 100s 705 o Path characteristics: 707 * Wired path capacity: 100Mbps 709 * Wi-Fi PHY Rate: 54Mbps (PHY rate) 711 * One-Way propagation delay: 50ms. 713 * Maximum end-to-end jitter: 30ms 715 * Bottleneck queue type: Drop tail. 717 * Bottleneck queue size: 300ms. 719 * Path loss ratio: 0%. 721 o Application characteristics: 723 * Media Traffic: 725 + Media type: Video 727 + Media direction: forward. 729 + Number of media sources: Eigth (8). 731 + Media timeline: 733 - Start time: 0s. 735 - End time: 99s. 737 * Competing traffic: 739 + Type of sources: long-live TCP. 741 + Number of sources : Eight (8) 743 + Traffic direction : forward 745 + Congestion control: Default TCP congestion control [TBD]. 747 + Traffic timeline: 749 - Start time: 0s. 751 - End time: 99s. 753 Expected behavior: All RMCAT flows should get comparable share of the 754 network bandwidth with respect to competing TCP flows. The overall 755 bandwidth usage should no less than same case with TCP flows (use TCP 756 as performance benchmark). The delay and loss should be in 757 acceptable range for real-time multimedia flow (might need rtp 758 circuit breaker to guarantee that?). 760 4.6. Multiple RMCAT and TCP Flows Sharing the Wireless Downlink 762 This case having both long lived TCP and RMCAT on the downlink at the 763 same time. This is for testing how RMCAT competing with long lived 764 TCP flow in crowed Wi-Fi network. This differs from test scenario in 765 the previous section becauase less contention on the Wi-Fi network 766 because most media data is sent from AP to stations. 768 uplink 769 +----------------->+ 770 +----+ +----+ 771 | R1 |)))))) /=====| S1 | 772 +----+ )) // +----+ 773 )) // 774 ...... ...... 775 +----+ +----+ +----+ +----+ 776 | R8 |))))))))))| |==========| |========| S8 | 777 +----+ | | | | +----+ 778 | AP | | B | 779 +--------+ | | | | +--------+ 780 | R1_tcp |))))))| | | |========| S1_tcp | 781 +--------+ +----+ +----+ +--------+ 782 ...... ...... 783 )) \\ 784 +--------+ )) \\ +--------+ 785 | R8_tcp |)))) \=====| S8_tcp | 786 +--------+ +--------+ 787 +<-----------------+ 788 downlink 790 Figure 10: Multiple RMCAT and TCP Flows Sharing the Wireless Downlink 792 Testbed attributes: 794 o Test duratiion: 100s 796 o Path characteristics: 798 * Wired path capacity: 100Mbps 800 * Wi-Fi PHY Rate: 54Mbps (PHY rate) 802 * One-Way propagation delay: 50ms. 804 * Maximum end-to-end jitter: 30ms 806 * Bottleneck queue type: Drop tail. 808 * Bottleneck queue depth: 300ms. 810 * Path loss ratio: 0%. 812 o Application characteristics: 814 * Media Traffic: 816 + Media type: Video 818 + Media direction: backward. 820 + Number of media sources: Eight (8). 822 + Media timeline: 824 - Start time: 0s. 826 - End time: 99s. 828 * Competing traffic: 830 + Number of sources: Eight (8). 832 + Types of sources : long-lived TCP. 834 + Traffic direction : forward 836 + Congestion control: Default TCP congestion control. 838 + Traffic timeline: 840 - Start time: 0s. 842 - End time: 99s. 844 Expected behavior: All RMCAT flows should get comparable share of the 845 network bandwidth with respect to competing TCP flows. The overall 846 bandwidth usage should no less than same case with TCP flows (use TCP 847 as performance benchmark). The delay and loss should be in 848 acceptable range for real-time multimedia flow (might need rtp 849 circuit breaker to guarantee that?). 851 4.7. Multiple Bi-Directional RMCAT and TCP Flows Sharing the Wireless 852 Bottleneck 854 This case having both long lived TCP and RMCAT on the both direction 855 at the same time. This is for testing how RMCAT competing with long 856 lived TCP flow in a congested Wi-Fi network. This differs from 857 previouss cases as both uplink and downlink flows share the same 858 wireless bottleneck. 860 uplink 861 +----------------->+ 862 +----+ +----+ 863 | S1 |)))))) /=====| R1 | 864 +----+ )) // +----+ 865 )) // 866 ...... ...... 867 +----+ +----+ +----+ +----+ 868 | R8 |))))))))))| |==========| |========| S8 | 869 +----+ | | | | +----+ 870 | AP | | B | 871 +--------+ | | | | +--------+ 872 | S1_tcp |))))))| | | |========| R1_tcp | 873 +--------+ +----+ +----+ +--------+ 874 ...... ...... 875 )) \\ 876 +--------+ )) \\ +--------+ 877 | R8_tcp |)))) \=====| S8_tcp | 878 +--------+ +--------+ 879 +<-----------------+ 880 downlink 882 Figure 11: Multiple Bi-Directional RMCAT and TCP Flows Sharing the 883 Wireless Bottleneck 885 Testbed attributes: 887 o Test duratiion: 100s 889 o Path characteristics: 891 * Wired path capacity: 100Mbps 893 * Wi-Fi PHY Rate: 54Mbps (PHY rate) 895 * One-Way propagation delay: 50ms. 897 * Maximum end-to-end jitter: 30ms 899 * Bottleneck queue type: Drop tail. 901 * Bottleneck queue size: 300ms. 903 * Path loss ratio: 0%. 905 o Application characteristics: 907 * Media Traffic: 909 + Media type: Video 911 + Media direction: forward and backward. 913 + Number of media sources: Eight (8). Four (4) forward, Four 914 (4) backward 916 + Media timeline: 918 - Start time: 0s. 920 - End time: 99s. 922 * Competing traffic: 924 + Number of sources : Eight (8). Four (4) forward, Four (4) 925 backward. 927 + Type of sources: long-live TCP. 929 + Traffic direction : forward and backward. 931 + Congestion control: Default TCP congestion control. 933 + Traffic timeline: 935 - Start time: 0s. 937 - End time: 99s. 939 Expected behavior: All RMCAT flows should get comparable share of the 940 network bandwidth with respect to competing TCP flows. The overall 941 bandwidth usage should no less than same case with TCP flows (use TCP 942 as performance benchmark). The delay and loss should be in 943 acceptable range for real-time multimedia flow (might need rtp 944 circuit breaker to guarantee that?). 946 5. Other potential test cases 948 5.1. Wi-Fi Roaming 950 Wi-Fi roaming need scanning, authentication and re-association which 951 will cause packet drops and delay, and interrupt the network 952 connection. RMCAT congestion control algorithms should at least 953 recover (if affected by the transition process) after roaming. 955 5.2. Wi-Fi/Cellular Switch 957 The phone can switch automatically between Wi-Fi and Cellular network 958 when the other is not available, and some phones like "Samsung 959 Galaxy" have smart network switch to switching to network has better 960 connectivity automatically. Unlike Wi-Fi Roaming, such kind of 961 switch might or might not interrupt the network connection, and might 962 change the route. RMCAT congestion control should be able to cope 963 with the changes. 965 5.3. EDCA/WMM usage 967 EDCA/WMM is prioritized QoS with four traffic classes (or Access 968 Categories) with differing priorities. RMCAT flow should have better 969 performance (lower delay, less loss) with EDCA/WMM enabled when 970 competing against non-interactive background traffic (e.g., file 971 transfers). When most of the traffic over Wi-Fi is dominated by 972 media, however, turning on WMM may actually degrade performance. 973 This is a topic worthy of further investigation. 975 5.4. Legacy 802.11b Effects 977 When there is 802.11b devices connected to modern 802.11 network, it 978 may affect the performance of the whole network. Additional test 979 cases can be added to evaluate the affects of legancy devices on the 980 performance of RMCAT congestion control algorithm. 982 6. IANA Considerations 984 There are no IANA impacts in this memo. 986 7. References 988 7.1. Normative References 990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 991 Requirement Levels", BCP 14, RFC 2119, March 1997. 993 [I-D.ietf-avtcore-rtp-circuit-breakers] 994 Perkins, C. and V. Singh, "Multimedia Congestion Control: 995 Circuit Breakers for Unicast RTP Sessions", draft-ietf- 996 avtcore-rtp-circuit-breakers-05 (work in progress), 997 February 2014. 999 [I-D.ietf-rmcat-eval-criteria] 1000 Singh, V. and J. Ott, "Evaluating Congestion Control for 1001 Interactive Real-time Media", draft-ietf-rmcat-eval- 1002 criteria-01 (work in progress), March 2014. 1004 [I-D.ietf-rmcat-eval-test] 1005 Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test 1006 Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat- 1007 eval-test-01 (work in progress), March 2015. 1009 [I-D.ietf-rmcat-cc-requirements] 1010 Jesup, R., "Congestion Control Requirements For RMCAT", 1011 draft-ietf-rmcat-cc-requirements-04 (work in progress), 1012 April 2014. 1014 [I-D.draft-sarker-rmcat-cellular-eval-test-cases] 1015 Sarker, Z., "Evaluation Test Cases for Interactive Real- 1016 Time Media over Cellular Networks", . 1019 7.2. Informative References 1021 [I-D.ietf-rtcweb-use-cases-and-requirements] 1022 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 1023 Time Communication Use-cases and Requirements", draft- 1024 ietf-rtcweb-use-cases-and-requirements-14 (work in 1025 progress), February 2014. 1027 Authors' Addresses 1029 Jiantao Fu 1030 Cisco Systems 1031 707 Tasman Drive 1032 Milpitas, CA 95035 1033 USA 1035 Email: jianfu@cisco.com 1037 Xiaoqing Zhu 1038 Cisco Systems 1039 12515 Research Blvd., Building 4 1040 Austin, TX 78759 1041 USA 1043 Email: xiaoqzhu@cisco.com 1044 Michael A. Ramalho 1045 Cisco Systems 1046 8000 Hawkins Road 1047 Sarasota, FL 34241 1048 USA 1050 Phone: +1 919 476 2038 1051 Email: mramalho@cisco.com 1053 Wei-Tian Tan 1054 Cisco Systems 1055 725 Alder Drive 1056 Milpitas, CA 95035 1057 USA 1059 Email: dtan2@cisco.com