1. Congestion Control Comments Resolution
December 2008
doc.: IEEE /1463r0
December 2008
Congestion Control Comments Resolution
Date:
Authors:
Bahareh Sadeghi (Intel)
Bahareh Sadeghi (Intel)

2. December 2008
doc.: IEEE /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
Bahareh Sadeghi (Intel)
Bahareh Sadeghi (Intel)

3. 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)

4. 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 s-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)

5. 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)

6. 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)

7. 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)

8. Proposed Text: 11B.10 Based on CIDs: 791-792 -369
December 2008
Proposed Text: 11B.10 Based on CIDs:
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)

9. December 2008
Proposed Text: 11B.10.1 Based on CIDs:
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)

10. 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 "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
Bahareh Sadeghi (Intel)

11. 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
Please provide feedback and comments
Bahareh Sadeghi (Intel)