310 likes | 394 Views
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.
E N D
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
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
Simple Experiment Januar 2011 communication possible heavy congestion routing path node configuration Slide 3 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
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
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
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
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
January 2011 Does this extension provide improvements? YES, But Not Always… Slide 9 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
Simple Experiment communication possible heavy congestion routing path node configuration Slide 10 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
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
Larger Topologies January 2011 • 40 mesh access points • 1,2,3,4 mesh portals Barbara Staehle, Uni Würzburg
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
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
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
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
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
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
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
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
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
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
January 2011 Effects of IMCC on the Uplink Throughput Slide 23 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
January 2011 Effects of IMCC on the Downlink Throughput Slide 24 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
January 2011 Effects of IMCC on the Uplink Fairness Slide 25 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
January 2011 Effects of IMCC on the Downlink Fairness Slide 26 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
January 2011 Effects of IMCC on the Intra-Mesh Packet Loss Slide 27 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
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
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
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
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
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