1 / 13

Should Parameterized QoS be Optional

This article explores AT&T's views on the optionality of polled/parameterized QoS and the interoperability requirements. It provides insights from a recent straw poll and discusses the factions' arguments and preferences.

kcorson
Download Presentation

Should Parameterized QoS be Optional

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. Should Parameterized QoS be Optional Author: Matthew Sherman AT&T Labs - Research mjsherman@att.com Date: September 11, 2002 Matthew Sherman, AT&T Labs

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

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

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

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

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

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

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

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

  10. 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 AP Matthew Sherman, AT&T Labs

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

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

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

More Related