1 / 10

Terminology Corrections and Improvements for the TGe Draft

Terminology Corrections and Improvements for the TGe Draft. Michael Fischer Intersil Corporation 4242-3 Medical Drive San Antonio, TX 78229 voice: +1-210-614-4096 fax: +1-210-614-8192 mfischer@choicemicro.com. Background.

yelle
Download Presentation

Terminology Corrections and Improvements for the TGe Draft

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Terminology Corrections and Improvements for the TGe Draft Michael Fischer Intersil Corporation4242-3 Medical DriveSan Antonio, TX 78229voice: +1-210-614-4096fax: +1-210-614-8192mfischer@choicemicro.com Michael Fischer, Intersil

  2. Background • This submission deals with the terms used to describe the QoS functionality, rather than the QoS functionality itself. • Missing or imprecise terminology was a major contributor to many of the items that yielded many, non-equivalent comments on Letter Ballot 27. • It will be much less work to fix the terminology before the next letter ballot than to have tens or hundreds of ballot comments on each of these topics. • While working on the D1.3 draft, I encountered several cases where there was an important concept that needed to be mentioned but which had no name by which to do so. • Adding new basic terminology is problematical under our rules • Presenting the new definitions is simple, but presenting all places where these terms may be used might require submission of a whole revised draft. • Therefore, this submission includes the definitions, and seeks to empower the editor to make appropriate use of the new terms when generating the revised draft. Michael Fischer, Intersil

  3. Conflicting Meanings for "EAP" • In TGe "EAP" is an acronym for "Enhanced Access Point" • In TGi "EAP" is an acronym for "Extensible Authentication Protocol" • The TGi meaning of EAP is consistent usage in IETF documents which predate both TGe and TGi • PROPOSED SOLUTION: • Change "EAP" to "QAP" • For consistency, change "ESTA" to "QSTA" • MOTION 270-1: • Move to empower the TGe editor to replace all instances of "EAP" with "QAP" and all instances of "ESTA" with "QSTA" in the next revision of the TGe draft, and to update the corresponding acronym definitions by replacing "enhanced" with "QoS". Michael Fischer, Intersil

  4. Inconsistent Constraints on TXOP Usage • A TXOP is a time interval with a defined maximum duration during which a WSTA may initiate frame exchange sequences by transmissions on the WM. • A WSTA may obtain a TXOP either by winning an instance of EDCF contention or by receiving a QoS (+)CF-Poll from the HC. • In D1.3 a TXOP due to receipt of a QoS (+)CF-Poll may be used to send one or more frame exchange sequences, whereas a TXOP due to winning EDCF contention may be used to send only one frame exchange sequence. • This asymmetry resulted from the relevant rules being contained in different submissions, by different authors, adopted into the draft at the same session. • This was not the original intention in the HCF concept. • The TXOP has restricted temporal extent, and there is no apparent reason to place restrictions on the content of a TXOP based on how it was obtained. • PROPOSED SOLUTION: • Remove the restriction on the number of frame exchange sequences that are allowed in a TXOP resulting from EDCF contention. Michael Fischer, Intersil

  5. Text Changes for TXOP Usage • Replace the first paragraph of 9.10.3 with: • A TXOP obtained by winning EDCF contention may be used to send one or more frame exchange sequences with total medium occupancy time not exceeding the TXOP limit from the QoS parameter set element in the beacon. A TXOP obtained by receiving a QoS (+)CF-Poll may be used to send one or more frame exchange sequences with total medium occupancy not exceeding the TXOP limit specified in the QoS Control field of the QoS (+)CF-Poll frame. Each TXOP results in a CFB that consists of one or more frame exchange sequences with the sole time-related restriction being that the final sequence shall end not later than the TXOP limit. MSDUs may be fragmented in order to fit within TXOPs. • MOTION 270-2: • Move to empower the TGe editor to remove the EDCF-specific restriction on TXOP usage by replacing the first paragraph of 9.10.3 with the version on slide 5 of document 01/270r0, and by changing wording on TXOP usage restrictions elsewhere in the TGe draft as may be necessary to make the revised TGe draft consistent with this replaced paragraph. Michael Fischer, Intersil

  6. New Term for a Sequence of CFBs • A CFB is the set of frame exchange sequences initiated by a given ESTA during a single TXOP. • All of the frames during a CFB are separated by SIFS or PIFS. • Normative text would be simpler if we add a term that refers to a set of medium activity, initiated by the HC, which appears to be a single instance of WM usage a viewed by a (non-hidden) (E)STA. • PROPOSED SOLUTION: • Define a "Controlled Access Period" with acronym "CAP." A CAP is a set of sequential frame exchange sequences, with no embedded interframe spaces longer than PIFS, starting with a transmission by the HC, an potentially including one or more CFBs by WSTAs that receive QoS (+)CF-Polls from the HC. • MOTION 270-3: • Move to empower the TGe editor to add the definition of Controlled Access Period and acronym CAP as given on slide 6 of document 01/270r0, and to use this term where appropriate in the revised TGe draft. Michael Fischer, Intersil

  7. Excessive Scope of "Traffic Category" • The term "traffic category" was introduced in the discussions leading up to the Scottsdale Compromise in order to have a term without connotations from prior proposals or other standards by which to refer to sets of QoS traffic which may receive differential handling. • The phrase "priority or traffic category" appears in several places in D1.3 as a holdover from the Scottsdale Compromise and QoS Baseline • Every MPDU handled by an ESTA has a priority, even non-QoS frames which have an implicit priority of "best effort." • Having a field named "TCID" which sometimes contains a priority and sometimes does not has proven confusing (in LB27) to many readers. • In order to produce a normative description which is understandable by people who were not involved in its creation, we need some new terms to designate particular kinds of traffic identifiers. • PROPOSED SOLUTION: … see the following 3 slides Michael Fischer, Intersil

  8. New Terms for Traffic Indentification (1) • Define a new term "traffic identifier" with acronym "TID" to refer to the information used by the MAC to distinguish MSDUs belonging to sets that may receive differential handling. • The traffic identifier is provided to the MAC as an integer value in the priority parameter of MA-UNITDATA.request primitives at ESTAs. • Define a new term "traffic stream" with acronym "TS" to refer to a set of MSDUs to be handled by the MAC in accordance with a particular traffic specification. • A traffic stream is identified by a "TSID." • The acronym for "traffic specification" is always "TSPEC." • Restrict the scope of "priority" and of "traffic category" as follows: • Use "priority" to refer to actual prioritization activities within the MAC. • Use "traffic category" to refer to a set of otherwise unrelated MSDUs to be handled by the MAC using a particular (but no necessarily unique) priority. • The term "TCID" is used specifically for a traffic category under this definition. Michael Fischer, Intersil

  9. New Terms for Traffic Indentification (2) • Bits 15-12 of the QoS Control field become the "TID field" • The contents of this field are referred to as a "TID" in cases where either a TCID or a TSID may be used. • TID values are in the range 0-15 • The contents of this field are referred to as a "TCID" in cases which pertain specifically to MSDUs which are identified as belonging to a traffic category, and do not pertain to MSDUs which are identified as belonging to a traffic stream. • TCID values are in the range 0-7 • The contents of this field are referred to as a "TSID" in cases which pertain specifically to MSDUs which are identified as belonging to a traffic stream, and do not pertain to MSDUs which are identified as belonging to a traffic category. • TSID values are in the range 8-15 • For consistency, the "TCA field" is renamed to be the "TAID field" Michael Fischer, Intersil

  10. New Terms for Traffic Indentification (2) • MOTION 270-4: • Move to empower the TGe editor to add definitions of "traffic identifier" and "traffic stream" and the corresponding acronyms "TID" and "TS" to as given on slides 8 and 9 of document 01/270r0 ; to incorporate the restricted definitions and usage of "traffic category" and "priority" as given on slides 8 and 9 of document 01/270r0; to change any remaining instances of "TS" meaning traffic specification to "TSPEC" in the TGe draft; to change "TCA" to "TAID" in the TGe draft; and to update frame formats and behavioral descriptions in all clauses of the TGe draft to make consistent use of these new and changed terms. Michael Fischer, Intersil

More Related