140 likes | 264 Views
December 2010. Proposed change to 802.11 Intra-Mesh Congestion Notification Element. Authors:. Date: 2010-12-08. Barbara Staehle, Uni Würzburg. December 2010. Abstract.
E N D
December 2010 Proposed change to 802.11 Intra-Mesh Congestion Notification Element Authors: Date: 2010-12-08 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
December 2010 Abstract This presentation provides a motivation for a small, simple extension of the Congestion Notification element. This extension allows a more flexible use of the Congestion Notification element for different intra-mesh congestion control mechanisms. The presentation and the corresponding submission 11-10/1428r0 address CIDs 28, 85, 204, 205. Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
December 2010 1. Local congestion monitoring & congestion detection 2. Local rate control 3. Congestion control signaling 4. Timer Parameterization FSM of a IEEE 802.11s node • monitor sending & receiving rates • monitor channel occupation • monitor buffer fill state congestion control signaling Local rate control local congestion monitoring and detection TCC & LSCC congestion detected done done CCNF received • stop all transmissions • reduce all transmissions by x% • stop transmissions to congested node only • reduce transmissions to congested nodes by x%, all others by z% TCC no congestion LSCC • broadcast CCNF • send CCNF to neighbors in routing tree • send CCNF to stations which cause congestion TCC & LSCC LSCC Implementation of IMCC • use network wide constant value • use node specific constant value • adapt timer network wide to load • adapt timer to node specific load TCC & LSCC Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
December 2010 Simulation Setup • 40 mesh access points, 4 mesh portals, static routing • 50 randomly generated network snapshots = station locations Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
Effects of IMCC on the Average Network Throughput December 2010 feasible maximum Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
Effects of IMCC on the Average Network Throughput December 2010 feasible maximum Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
Effects of IMCC on the Average Network Throughput December 2010 feasible maximum Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
Effects of IMCC on the Per Flow Throughput December 2010 feasible maximum feasible maximum Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
Effects of IMCC on the Per Flow Throughput December 2010 feasible maximum feasible maximum Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
Effects of IMCC on the Per Flow Throughput December 2010 feasible maximum feasible maximum Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
December 2010 Congestion Situation A: Solvable The Congestion Notification element described in 7.3.2.99 supports a link selective congestion control. Which 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). Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
December 2010 Congestion Situation B: Currently Unsolvable The Congestion Notification element described in 7.3.2.99 does, however, NOT support a flow 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. But as the format indicated in the standard does not provide the possibility to indicate that A should apply rate control only to packets destined for D and not for packets with mesh destination E, the congestion control causes an unnecessary throughput reduction. Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
December 2010 Proposed Solution • 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 = current functionality) • multiple Congestion Notification elements in a single Congestion Control Notification frame • full proposed normative text in 11-10/1428r0 (small changes only) Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg
December 2010 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/1428r0, Bahr, B. Staehle, D. Staehle: „Destination Address in Congestion Notification“, December 2010 • IEEE 802.11s Draft Standard D7.03 Barbara Staehle, Uni Würzburg Barbara Staehle, Uni Würzburg