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

December 2010 doc.: IEEE 802.11-10/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

Congestion Situation A: Solvable December 2010 Congestion Situation A: Solvable The Congestion Notification element described in 7.3.2.99 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

Congestion Situation B: Currently Unsolvable 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

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

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