Should Parameterized QoS be Optional Month 2000 doc.: IEEE 802.11-00/xxx September 2002 Should Parameterized QoS be Optional Author: Matthew Sherman AT&T Labs - Research mjsherman@att.com Date: September 11, 2002 Matthew Sherman, AT&T Labs John Doe, His Company

Purpose Provide AT&T “view” of views on September 2002 Purpose Provide AT&T “view” of views on Optionality of polled /parameterized QoS Interoperability requirements Provide possible insights on straw polls from 09/10/02 Matthew Sherman, AT&T Labs

Background Two Types of QoS Two types of Access used for QoS September 2002 Background Two Types of QoS Parameterized - Requires TSPEC Prioritized - Classification at upper layers Two types of Access used for QoS Contention (E-DCF) Contention Free (HCF) QoS and Access Types are orthogonal Could mix and match in any way desired One mapping of QoS/Access types seems preferred Prioritized maps to Contention (E-DCF) Parameterized maps to Contention Free (HCF) No other mapping seems to be of interest Matthew Sherman, AT&T Labs

Background (Continued) September 2002 Background (Continued) To interoperate a QSTA and QAP must support same type of “QoS” Most discussion focuses on access aspects of QoS With current implied mappings this translates to requirements concerning other aspects as well What types of QoS should be supported in QAP and QSTA to guarantee interoperability? Depends on definition for interoperability Matthew Sherman, AT&T Labs

What does it mean to be interoperable? September 2002 What does it mean to be interoperable? Interoperability can occur on may levels TGe is a QoS standard Means we want to define interoperable QoS DCF does not provide interoperable QoS Depending on view point can define interoperable in different ways Has implications for functionality required for TGe Matthew Sherman, AT&T Labs

The Two Parts to a Standard September 2002 The Two Parts to a Standard Interface must be defined For instance, without defined interface can’t properly convey QoS needs between different vendors products Behavior may also be defined Given a set of inputs a QSTA/QAP may be required to act in a certain manner Eg. E-DCF scheduling behavior fully defined given access parameters Need to define required (mandatory) interface and behavior such that interoperable QoS is achieved Matthew Sherman, AT&T Labs

Factions in TGe Three factions in TGe September 2002 Factions in TGe Three factions in TGe Data oriented AV oriented Carrier / Infrastructure oriented Each faction has different perception of interoperability needs Matthew Sherman, AT&T Labs

Interoperability Arguments (Data) September 2002 Interoperability Arguments (Data) Don’t need hard core QoS ever Too complex anyway Differentiated service is enough Have lowest level of QoS everywhere Usually good enough Can always interoperate Make parameterized QoS optional at both ends Prioritized QoS mandatory at both ends Matthew Sherman, AT&T Labs

Interoperability Arguments (Carrier / Infrastructure) September 2002 Interoperability Arguments (Carrier / Infrastructure) Carrier specifies Access Point Can require options be used in all their AP’s Services not available outside their network Or differentiated as inferior Want devices (QSTA) which provide a “service” over carrier’s network to use carriers QoS Otherwise can’t make QoS Guarantees Parameterized QoS is easiest in QSTA STA must respond to poll STA must generate TSPEC (could be by rote) Make prioritized mandatory everywhere Make parameterized mandatory in STA AT&T’s Preference Matthew Sherman, AT&T Labs

Interoperability Arguments (AV / IP Phone) September 2002 Interoperability Arguments (AV / IP Phone) Mostly make Stations, not APs Need their QoS to run in presence of APs Mostly want parameterized / polled access If not supported by AP, can’t run their QoS Make prioritized mandatory everywhere Make parameterized mandatory in STA Matthew Sherman, AT&T Labs

One 802.11 Phone Vendor’s Example September 2002 One 802.11 Phone Vendor’s Example Uses DCF for 802.11 Phone Wanted PCF Could not find PCF AP vendor PCF was optional Don’t trust AP vendors to build Polling in if optional They didn’t the first time Matthew Sherman, AT&T Labs

Poll Results Fast Track Alternative QoS Proposal (Intel / Sharp) September 2002 Poll Results Fast Track Base 67% + Distributed Admissions 70% + Time based TSPEC 66% Optional AP Polling 37% Opt. Poll + Dist. Admin 40% Alternative QoS Proposal (Intel / Sharp) Base 46% + Flow Tags 36% Matthew Sherman, AT&T Labs

September 2002 Observations Intel / Sharp proposal did not establish Parameterized QoS / polling as mandatory Fast Track proposals with mandatory polling in AP all had high approvals Fast Track without polling mandatory did as bad as Intel / Sharp proposal Any way forward must have parameterized QoS mandatory in AP Makes sense since majority of participants provide STAs rather than APs Matthew Sherman, AT&T Labs