Proposed Resolutions of Some Comments Related to TSPEC Parameters May 2003 doc.: IEEE 802.11-03/229r1 July 2004 Proposed Resolutions of Some Comments Related to TSPEC Parameters John M. Kowalski July, 2004 John Kowalski, Sharp Labs Tan Pek-Yew, Matsushita Electric Ind.

Comments Addressed and Why: July 2004 Comments Addressed and Why: del Prado 1, del Prado 2, Kerry 1, Kerry 2, Kandala 50 These parameters relate to the Surplus Bandwidth Allowance (SBA). This presentation will show why it is important to accept Kandala 50, and to decline del Prado 1, del Prado 2, and Kerry 1 and Kerry2. Unless the signaling for the SBA is made to be mandatory for certain types of streams, there will be no clearly defined normative behavior that is of any practical use for polled access. The alternatives mentioned request that partially redundant information be added, which does not provide a clearly defined normative behavior. Furthermore accepting del Prado 1, del Prado 2, Kerry 1 and Kerry 2 would unnecessarily delay deployment of the standard, and would not reflect what implementers are actually implementing. The standard should represent what is being built. John Kowalski, Sharp Labs

About del Prado 2 and Kerry1 July 2004 About del Prado 2 and Kerry1 Comment on Kerry 1: “With CE applications such as video they are reasonably tolerant to frame loss conditions but an HC may drop an admitted stream due to frame loss conditions. To guarantee interoperability and better expression of traffic stream requirements, acceptable frame loss rate for the traffic stream will need to be communicated between HC and a QSTA.” Actually the HC should not, by itself drop an admitted stream. Implementations actually being built do not do this. Kerry 1 proposes an “acceptable frame loss rate,” but this is obviously not needed. del Prado 2 proposes adding this parameter for the opposite reason- so the HC can drop a stream! But again, the HC does not do this, it is not recommended and real implementations do not do this. Nothing is mentioned in the comment as to what the scheduler would actually do with said parameter. By itself, this parameter does absolutely nothing to define normative scheduler behavior. Furthermore, the Surplus Bandwidth Allowance already ensures that acceptable frame loss rates can always be maintained and provides other benefits the “Frame Loss Rate” parameter cannot. This is why Sharp considered this approach and subsequently rejected this before the presentation made in the September 2002 IEEE meeting. Hence it is recommended to decline these comments. Using bullet point 2 as the explanation for declining the comment. John Kowalski, Sharp Labs

About del Prado 1 and Kerry2 July 2004 About del Prado 1 and Kerry2 del Prado 2 states (Kerry 2 has similar intent): “The Surplus Bandwidth Allowance parameter is one of the parameters that shall be specified to a non-zero value in the TSPEC element. However this parameters is not needed by a scheduler to generate a schedule. Only the first three parameters are needed (MSDU size, Data Rate and PHY rate). The surplus bandwidth allowance should be optional.” There is no way unless the SBA or something like it is used to deal with the following problem: John Kowalski, Sharp Labs

Why the SBA is needed: consider case of 2 streams without SBA: July 2004 Why the SBA is needed: consider case of 2 streams without SBA: Available Bandwidth QAP can starve streams. Stream 1 : bad channel Stream 2 is OK. Time John Kowalski, Sharp Labs

July 2004 Comment on SBA: Some normative behavior is needed to prevent the QAP from starving one stream at the expense of another- this is the recommended behavior for the scheduler, and is in fact what all known implementations are doing. With the SBA there is a “guarantee” that one stream cannot starve another below its SBA. SBA is chosen based on application requirements for frame error, delay and rate. SBA is the ratio of “imperfect” over the air time to “perfect” over the air time, and has been fixed since September 2002. As such, its nominal value should be unity, as stated in D8.0. Implementers do not seem to have had problems implementing this. John Kowalski, Sharp Labs

July 2004 Comment on Kandala 50 Comment on SBA outlines the preceding argument; it also applies to the Minimum PHY rate. Recommends for streams in which rates and delay are specified, SBA and Minimum PHY rate should be mandatory. Again, this is what implementers are doing, and it means there is at least minimal observable normative scheduler behavior. 802.11e’s polled access capabilities will be essentially useless for CE applications without it. Thus we should accept Kandala 50. John Kowalski, Sharp Labs

July 2004 Conclusions: Suggested changes to the text by del Prado and Kerry do absolutely nothing to enhance the 802.11e specification, and their suggestions would only make the standard harder to implement, test, and certify. Accepting those comments would only delay deployment of the standard, would not reflect what implementers are actually building, and would go against the whole point of doing the standard in the first place, and would not serve the interests of Sponsors who would like to see this standard completed in a timely fashion. John Kowalski, Sharp Labs

July 2004 Motions Move to decline del Prado 1 and Kerry2 for reasons stated in Bullet Point 3, slide 7, and all bullet points on slide 6 of this presentation. Move to decline del Prado 2 and Kerry1 for reasons stated on slide 3, bullet point 2. Move to accept the suggested resolution in Kandala 50. John Kowalski, Sharp Labs