1. Proposed Change to 802.11 Intra-Mesh Congestion Notification Frame
December 2010
doc.: IEEE /1428r0
December 2010
Proposed Change to Intra-Mesh Congestion Notification Frame
Date:
Authors:
Barbara Staehle, Uni Würzburg
Barbara Staehle, Uni Würzburg

2. December 2010
doc.: IEEE /1428r0
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

3. Congestion Situation A: Solvable
December 2010
Congestion Situation A: Solvable
The Congestion Notification element described in supports a node 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 however still allowed to send packets to mesh STA B, as there is no congestion for link (B,A).
Barbara Staehle, Uni Würzburg

4. Congestion Situation B: Currently Unsolvable
December 2010
Congestion Situation B: Currently Unsolvable
The Congestion Notification element described in 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

5. Proposed Solution December 2010
Extend the format of the Congestion Notification element with the mesh destination in order to indicating 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 (only a few lines)
Barbara Staehle, Uni Würzburg

6. December 2010
doc.: IEEE /1428r0
December 2010
References
11-10/1428r0 M. Bahr, B. Staehle, D. Staehle: „Destination Address in Congestion Notification“
IEEE s Draft Standard D7.03
Barbara Staehle, Uni Würzburg
Barbara Staehle, Uni Würzburg