1 / 31

Motivation for Extending the 802.11 Intra-Mesh Congestion Notification Element

Motivation for Extending the 802.11 Intra-Mesh Congestion Notification Element. Authors:. Date: 2011-01-19. Slide 1. Barbara Staehle, Uni Würzburg. Barbara Staehle, Uni Würzburg. January 2011. January 2011. Abstract.

gazit
Download Presentation

Motivation for Extending the 802.11 Intra-Mesh Congestion Notification Element

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Motivation for Extending the 802.11 Intra-Mesh Congestion Notification Element Authors: Date: 2011-01-19 Slide 1 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  2. January 2011 January 2011 Abstract This presentation provides the motivation for the extension of the Congestion Notification element described in IEEE 802.11-10/1429r1 and IEEE 802.11-10/1428r2. It contains results clarifying if, how, and where such an extension allows additional beneficial CC algorithms and performance improvements. The presentation addresses CID 1314. Slide 2 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  3. Simple Experiment Januar 2011 communication possible heavy congestion routing path node configuration Slide 3 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  4. January 2011 Considered IMCC Algorithms • TCC (Total Congestion Control) • receivers of Congestion Control Notification Frame (CCNF) stop all transmissions • LSCC (Link Selective Congestion Control) • receivers of Congestion Control Notification Frame (CCNF) stop all transmissions to the sender of CCNF • PSCC (Path Selective Congestion Control) • receivers of Congestion Control Notification Frame (CCNF) stop all transmissions to the sender of the CCNF that are destined to the destination given in the contained Congestion Notification elements (CNE). • Congestion Notification elements are indirectly propagated • since receiver of CCNF stops some transmissions, it might become congested itself • if receiver of CCNF gets congested it will send a CCNF as well. Slide 4 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  5. Congestion Situation A Link selective congestion control is helpful in the situation depicted below: C is not able to forward packets from mesh STA B fast enough over link (C,D) and consequently sends a Congestion Notification element to mesh STA B. This causes B to apply local rate control as specified in 11C.11 in order to avoid a waste of mesh resources. In turn, B can not forward the packets from A fast enough and will send a Congestion Notification element to mesh STA A. Despite the congestion detected at mesh STA B, E is still allowed to send packets to mesh STA B, as there is no congestion for link (B,A). December 2010 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  6. Congestion Situation B The Congestion Notification element described in 7.3.2.99 of D7.0 does, however, NOT support a path selective congestion control which would be necessary to avoid the waste of mesh resources in the situation depicted below. Due to the same reasons as before, B has to use the Congestion Notification element to cause A to apply local rate control as specified in 11C.11 in order to avoid a waste of mesh resources. However, B could still forward packets from mesh STA A to mesh STA E. In order to avoid an unnecessary throughput reduction by the congestion control, the Congestion Notification element has to indicate that A should apply rate control only to packets destined for D and not for packets with mesh destination E. This was not possible in D7.0 but is possible with the extension of the format of the Congestion Notification element in D8.0 December 2010 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  7. Congestion Notification element extension of D8.0 Extend the format of the Congestion Notification element with the mesh destination in order to indicate which path causes the congestion. “The Destination Mesh STA Address field is represented as a 48-bit MAC address and is set to the address of the mesh destination for which the intra-mesh congestion control shall be applied. It is set to the broadcast address if the intra-mesh congestion control shall be applied to all destinations.” (i.e. broadcast address = functionality as in D7.0) multiple Congestion Notification elements in a single Congestion Control Notification frame additions to 11C.11.2 Congestion Control Signalling Protocol to accommodate extension full proposed normative text in 11-10/1428r2 December 2010 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  8. January 2011 Does this extension provide improvements? YES, But Not Always… Slide 9 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  9. Simple Experiment communication possible heavy congestion routing path node configuration Slide 10 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  10. January 2011 Per Flow Throughputs no Congestion Control feasible without extension only feasible with extension uplink downlink Slide 11 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  11. Larger Topologies January 2011 • 40 mesh access points • 1,2,3,4 mesh portals Barbara Staehle, Uni Würzburg

  12. January 2011 January 2011 Simulation Setup • 40 mesh access points, 1,2,3,4 mesh portals, static routing • 50 x 4 randomly generated network snapshots = station locations • 3 runs of 30 sec duration per network snapshot • constant traffic pattern, static routing  small variances for runs in one topology  95% confidence intervals not shown as near to 0 • BUT: variances between the topologies node configuration Slide 13 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  13. Effects of IMCC on the Total Network Throughput January 2011 January 2011 each point = sum of all flow throughputs averaged over 3 runs Slide 14 Barbara Staehle, Uni WürzburgBarbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  14. Effects of IMCC on the Total Network Throughput January 2011 January 2011 Slide 15 Barbara Staehle, Uni WürzburgBarbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  15. Effects of IMCC on the Total Network Throughput January 2011 January 2011 Slide 16 Barbara Staehle, Uni WürzburgBarbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  16. Effects of IMCC on the Total Network Throughput January 2011 January 2011 Slide 17 Barbara Staehle, Uni WürzburgBarbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  17. Effects of IMCC on the Total Network Throughput January 2011 January 2011 Slide 18 Barbara Staehle, Uni WürzburgBarbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  18. Effects of IMCC on the Total Network Throughput January 2011 January 2011 Slide 19 Barbara Staehle, Uni WürzburgBarbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  19. Effects of IMCC on the Total Network Throughput January 2011 January 2011 Slide 20 Barbara Staehle, Uni WürzburgBarbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  20. Effects of IMCC on the Total Network Throughput January 2011 January 2011 Slide 21 Barbara Staehle, Uni WürzburgBarbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  21. January 2011 Effects of IMCC on the Total Network Throughput each bar = averaged over all topologies + all runs 95% confidence intervals Slide 22 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  22. January 2011 Effects of IMCC on the Uplink Throughput Slide 23 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  23. January 2011 Effects of IMCC on the Downlink Throughput Slide 24 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  24. January 2011 Effects of IMCC on the Uplink Fairness Slide 25 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  25. January 2011 Effects of IMCC on the Downlink Fairness Slide 26 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  26. January 2011 Effects of IMCC on the Intra-Mesh Packet Loss Slide 27 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  27. January 2011 Situation-dependent Additional Benefit of PSCC Large • tree-like traffic patterns (access networks) • non-tree routing structures (intra-mesh traffic) • large networks • heterogeneous traffic demands Small • small networks where every transmission contends with the bottleneck link Slide 28 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  28. January 2011 Example where PSCC shows no Additional Benefit bottleneck link, node configuration Slide 29 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

  29. Summary • PSCC (based on the extension of the Congestion Notification element) provides improvements about TCC and LSCC in many cases. • PSCC is always at least as good as TCC and LSCC • PSCC provides better fairness than TCC and LSCC • degree of improvement depends on topology and traffic pattern Barbara Staehle, Uni Würzburg

  30. CID 1314 • comment: The congestion control signalling is modified without having enough justification (such as simulation results). The benefit of the proposed method needs to be shown. Otherwise, the newly proposed scheme should be removed. • commenter‘s proposed resolution: As in comment • resolution: The modifications of the congestion notification element have been justified by doc 11-11/xxxx. No changes have to be made to the draft. • resolution code: Reject. (because no changes to draft) Barbara Staehle, Uni Würzburg

  31. References Desheng Fu, Barbara Staehle, Rastin Pries, Dirk Staehle, „On the Potential of IEEE 802.11s Intra-Mesh Congestion Control“, MSWiM, October 2010, Bodrum, Turkey 11-10/1429r1, B.Staehle, D. Staehle, M. Bahr: Proposed change to 802.11 Intra-Mesh Congestion Notification Element, December 2010 11-10/1428r2, M. Bahr, B. Staehle, D. Staehle, D. Harkins: „Destination Address in Congestion Notification“, December 2010 IEEE 802.11s Draft Standard D7.03 IEEE 802.11s Draft Standard D8.0 December 2010 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg

More Related