Congestion Control Comments Resolution December 2008 doc.: IEEE 802.11-08/1463r0 December 2008 Congestion Control Comments Resolution Date: 2008-12-10 Authors: Bahareh Sadeghi (Intel) Bahareh Sadeghi (Intel)

December 2008 doc.: IEEE 802.11-08/1463r0 December 2008 Abstract This presentation provides an update on the status of Congestion control related comments and proposes resolutions for them. Comments addressed: All the comments marked MAC M-CC, and identical comments 420-422 Bahareh Sadeghi (Intel) Bahareh Sadeghi (Intel)

Background History of Congestion Control in TGs December 2008 Background History of Congestion Control in TGs Congestion control protocol was originally introduced as a complete solution, including mechanisms for congestion detection, and congestion resolution After extensive discussions within TGs, it was decided that Congestion control is required One solution can not be optimized for different mesh applications addressed by TGs. Hence, in May 2007: An extensible framework was unanimously agreed upon and included in the draft, where Signaling messages for congestion control is defined Future/vendor-specific definition of optimized solution for different mesh applications is allowed. There is one congestion control protocol active in each mesh network Bahareh Sadeghi (Intel)

Congestion Control Comments Resolution Status December 2008 Congestion Control Comments Resolution Status There are 40 comments labeled MAC M-CC 11 closed 29 open The proposed resolutions attached in the file XXX.xls based on 11-08-0493-29-000s-lb-126-comment-resolutions.xls 16 accepts 8 counters 5 rejects There are 2 identical comments labeled General G-Discovery related to congestion control Current status: closed Updated resolution is required for these identical comments. See slides 10 Bahareh Sadeghi (Intel)

Rejected Comments December 2008 The comments which are recommended for rejection are: Complete the congestion control protocol Do not define the signaling Remove congestion control Based on the background provided at the beginning of this slide deck, it is recommended to reject these comments However, The framework is clarified and cleaned up based on these and other comments such that more clarity is reached: Default congestion control protocol is renamed to what it really is: signaling congestion control protocol It is clarified that the null (no) congestion control scheme can be the default mechanism in a mesh network Congestion Control signaling protocol is the signaling framework, extensible as required by any future/vendor-specific congestion control scheme. Bahareh Sadeghi (Intel)

Current Text: 11B.10 December 2008 11B.10 Intra-mesh congestion control Intra-Mesh congestion control is based on three main mechanisms: Local congestion monitoring and congestion detection, congestion control signaling, and local rate control. While MPs may support multiple congestion control protocols, there is only one congestion control protocol active in a particular mesh network at a time, signaled in the Congestion Control Mode Identifier field of the Mesh Configuration element. The default congestion control protocol specifies congestion control signaling. Specific algorithms for local congestion monitoring and congestion detection are beyond the scope of the default congestion control protocol. Similarly, local rate control algorithms are beyond the scope of the default congestion control protocol. Note: This standard defines a congestion control framework by specifying the congestion control signaling as a default protocol while allowing for inclusion of more advanced or alternative congestion control schemes through the Conges-tion Control Mode Identifier in the Mesh Configuration element. Bahareh Sadeghi (Intel)

Current Text: 11B.10.1 December 2008 11B.10.1 Default Congestion Control Protocol The default congestion control protocol defined in this standard does not specify the exact conditions that would trigger congestion control signaling; congestion control signaling is triggered after congestion is detected at an MP through local congestion monitoring (details of which are beyond the scope of this standard). The default congestion control protocol defines congestion control signaling which consists of a Congestion Control Notification frame. An MP that detects congestion may transmit a Congestion Control Notification frame. The frame contains the Congestion Notification Element, which specifies the expected duration of the congestion per AC as estimated by the congested MP. Other information elements may be included in the Congestion Control Notification frame. Note: An MP which receives a Congestion Control Notification frame may choose to adjust its frame rate to the sender of the Congestion Control Notification frame in the identified congested AC(s) for the duration specified in the Congestion Notification element. Reduction of frame rate to a congested MP avoids waste of the mesh resources for transmission of packets which with high probability will not be handled/forwarded by the congested MP. Bahareh Sadeghi (Intel)

Proposed Text: 11B.10 Based on CIDs: 791-792 -369 December 2008 Proposed Text: 11B.10 Based on CIDs: 791-792 -369 11B.10 Intra-mesh congestion control Intra-Mesh congestion control is based on three main mechanisms: Local congestion monitoring and congestion detection, congestion control signaling, and local rate control. At any given time, there is only one congestion control protocol active in a particular mesh network, signaled in the Congestion Control Mode Identifier field of the Mesh Configuration element. This standard specifies the congestion control signaling protocol. Note: This standard defines a congestion control framework by specifying the congestion control signaling as a default protocol while allowing for inclusion of more advanced or alternative congestion control schemes through the Congestion Control Mode Identifier in the Mesh Configuration element. Bahareh Sadeghi (Intel)

December 2008 Proposed Text: 11B.10.1 Based on CIDs: 792-896-329-690-691-1927-328-273-330 11B.10.1 Congestion Control Signaling Protocol The congestion control signaling protocol specifies the signaling messages used with Intra-mesh congestion control. Specific algorithms for local congestion monitoring and congestion detection are beyond the scope of the congestion control signaling protocol. Similarly, local rate control algorithms are beyond the scope of the congestion control signaling protocol. Congestion control signaling consists of a Congestion Control Notification frame and is triggered after congestion is detected at an MP through local congestion monitoring (details of which are beyond the scope of the congestion control signaling protocol). An MP that detects congestion may transmit a Congestion Control Notification frame. An MP that detects congestion and the incoming traffic source causing this congestion may transmit a Congestion Control Notification frame to the MPs of its traffic source. The Congestion Control Notification frame may be transmitted to other neighboring MPs. The frame contains the Congestion Notification Element, which specifies the expected duration of the congestion per AC as estimated by the congested MP. Note: local policies/mechanisms to be implemented in an MP, may be required to ensure timely transmission of the congestion control signaling messages and to avoid transmission of stale messages which can reduce network efficiency. Note: An MP which receives a Congestion Control Notification frame may choose to adjust its frame rate, defined by the number of transmitted frames per a unit of time, to the sender of the Congestion Control Notification frame in the identified congested AC(s) for the duration specified in the Congestion Notification element. Reduction of frame rate to a congested MP avoids waste of the mesh resources for transmission of packets which with high probability will not be handled/forwarded by the congested MP. Bahareh Sadeghi (Intel)

Identical Comments 420-422 December 2008 Comment: Current Resolution: There seems to be a discrepancy between (c) and the mesh profile definition in section 11B.1.3. "if and only if" means that the conditions have to be met before an MP is considered a neighbor MP. The mesh profile doesn't contain the "congestion control Current Resolution: See CID 422/420. Congestion control is optional. Delete item "c." under item "3." in 11B.1.4 Issue: It is required that only one congestion control be active in a mesh network at any given time (11B-10). It is true that congestion control is optional, but if there is a mesh network with a congestion control protocol active, then all the nodes should comply to that; it is similar to optional path selection mechanisms. Removing item “c” allows for having different congestion control protocols running at the same time in a mesh network. Not having all MPs comply to the same congestion control scheme in a network (even if it means some have no congestion control) can result in significant performance degradation/unfairness in the network. Proposed updated resolution: reject the identical comments 420-422. Bahareh Sadeghi (Intel)

Summary Proposed resolution for all MAC M-CC comments December 2008 Summary Proposed resolution for all MAC M-CC comments Also proposed change to the resolution of identical comments 420-422 Please provide feedback and comments Bahareh Sadeghi (Intel)