RE: stds-80220-requirements: Latency and packet error rates
Branislav,
I think that the proposed text over steps the bounds of what should be
addressed in this requirements document. Identification of specific service
classes, the DSCPs with which they are marked, and the PHBs to which they are
mapped is truly a deployment issue. Note that the referenced document from
which much of the text below is excerpted only provides recommendations,
i.e., deployment guidelines to assist network operators or administrators to
configure QoS support mechanisms in a meaningful way. In my opinion, this
group should focus on the requirements of the air link that are needed to
support such services, NOT on a specific configuration. The requirements
needed to support such services are already adequately addressed in sections
4.1.12 and 4.4.1. By referencing the specific PHBs that should be supported
we already effectively address latency, jitter, loss, etc. How the PHBs are
used is well out of scope.
If for some reason the group feels that this level of specification is not
out of scope and is in fact required, I would caution against referencing
(and/or excerpting text from) an internet draft. As I'm sure you know,
internet drafts are only working documents (non-archival and subject to
change or even abandonment). The referenced internet draft changed
considerably between the last two versions and will likely continue to
evolve. Perhaps of even more concern is that if per chance the internet draft
is abandoned then the text below will be far from complete and thus would be
effectively meaningless. Also, note that the particular internet draft
referenced is not even formally the product of a working group at this point,
it appears to be a personal submission. I think that it is unwise to make any
assumptions regarding its potential progress through the standards process at
this point.
Here's a summary for those that got board reading. :) Re-read sections 4.1.12
and 4.4.1 to assess if they sufficiently address QoS requirements for an
802.20 PHY/MAC proposals.
-Vince
> -----Original Message-----
> From: owner-stds-80220-requirements@majordomo.ieee.org
> [mailto:owner-stds-80220-requirements@majordomo.ieee.org] On
> Behalf Of Branislav Meandzija
> Sent: Friday, February 27, 2004 7:55 PM
> To: Lai-King Tee; stds-80220-requirements@ieee.org
> Cc: Humbert, John J [NTK]
> Subject: RE: stds-80220-requirements: Latency and packet error rates
>
>
>
>
> We are seeking to use this time before the meeting for
> consensus building, INSTEAD of awaiting the face-to-face
> meeting for a debate among several options. So, we strongly
> request that you provide us with feedback on this proposal.
> Please let us know if you support it or, if not, what
> deficiencies you find with this proposal. We will make every
> effort to
> address the problem and find a solution that is acceptable to
> the vast majority (hopefully all) members of the CG. In this
> regard, please register your view if you care about this
> issue. In terms of building consensus, we can only interpret
> silence as 'don't care'.
>
> Branislav
>
> PROPOSED TEXT
> =============
>
> 4.1.7 Latency and Packet Data Rates
> -----------------------------------
> The system shall support a variety of traffic classes with
> different latency and packet error rates performance, in
> order to meet the end-user QoS requirements for the various
> applications, as recommended by ITU [2]. Based on the
> classification of traffic in accordance with the QoS
> architecture as described in Section 4.4.1 [3,4,5,6],
> appropriate latency and packet error rate performance targets
> can be associated with each class.
>
> While no absolute meaningful latency and packet data rates
> can be set as any specific numbers would be arbitrary and
> would only restrict possible service definitions in specific
> deployments, current work in progress within the IETF ( RFC
> Configuration Guidelines for DiffServ Service Classes,
> draft-baker-diffserv-basic-classes-02, expires August 2004)
> defines a framework for packet data rates and delay relative
> to DiffServ Classes. Thus, the following traffic classes
> shall be supported:
>
>
> Class Attributes of Traffic
> -----------------------------------------------------------
> Conversational | Two-way, low delay, low data loss
> | rate, sensitive to delay variations.
> -----------------------------------------------------------
> Streaming | Same as conversational, one-way,
> | less sensitive to delay. May require
> | high bandwidth.
> -----------------------------------------------------------
> Interactive | Two-way, bursty, variable
> | bandwidth requirements moderate
> | delay, moderate data loss rate
> | correctable in part.
> -----------------------------------------------------------
> Background | Highly tolerant to delay and data
> | loss rate has variable bandwidth.
> -----------------------------------------------------------
>
> Traffic classes shall be marked as follows:
>
>
> ------------------------------------------------------------------
> | Service | DSCP | DSCP |
> Application |
> | Class name | name | value | Examples
> |
>
> |===============+=========+=============+==========================|
> | Conversational| EF,CS5 |101010,101000| IP Telephony
> |
>
> |---------------+---------+-------------+--------------------------|
> | |AF31,AF32|011010,011100|Broadcast TV, Pay
> per view|
> | Streaming |AF33, CS4|011110,100000|Video
> surveillance |
>
> |---------------+---------+-------------+--------------------------|
> | Interactive |AF21,AF22|010010,010100|Client/server
> transactions|
> | |AF23, CS3|010110,011000|peer-to-peer
> signaling |
>
> |---------------+---------+-------------+--------------------------|
> | Background | DF,(CS0)| 000000 | Undifferentiated
> |
> | | | | applications
> |
>
> |---------------+---------+-------------+--------------------------|
>
>
> DiffServ QoS mechanisms that SHOULD be used are as follows
> for the supported
> traffic classes:
>
> ------------------------------------------------------------------
> | Service | DSCP | Conditioning at | PHB |
> Queuing| AQM|
> | Class | | DS Edge | Used |
> | |
>
> |===============+======+===================+=========+========+====|
> | Conversational|EF,CS5|Police using sr+bs | RFC3246
> |Priority| No |
>
> |---------------+------+-------------------+---------+--------+----|
> | | AF31 | Police using sr+bs| |
> | |
> | |------+-------------------| |
> | Yes|
> | | AF32 | Police sum using | |
> Rate | per|
> | Streaming | AF33 | sr+bs | RFC2597 |
> |DSCP|
> | |------+-------------------| |
> |----|
> | | CS4 |Police using sr+bs | |
> | No |
>
> |---------------+------+-------------------+---------+--------+----|
> | | AF21 | | |
> | Yes|
> | | AF22 | Using srTCM | |
> | per|
> | Interactive | AF23 | (RFC 2697) | RFC2597 |
> Rate |DSCP|
> | |------+-------------------| |
> |----|
> | | CS3 |Police using sr+bs | |
> | No |
>
> |---------------+------+-------------------+---------+--------+----|
> | Standard | DF | Not applicable | RFC2474 |
> Rate | Yes|
>
> |---------------+------+-------------------+---------+--------+----|
>
> > -----Original Message-----
> > From: owner-stds-80220-requirements@majordomo.ieee.org
> > [mailto:owner-stds-80220-requirements@majordomo.ieee.org]On
> Behalf Of
> > Lai-King Tee
> > Sent: Wednesday, February 18, 2004 1:40 PM
> > To: stds-80220-requirements@ieee.org
> > Cc: 'Humbert, John J [NTK]'
> > Subject: stds-80220-requirements: Latency and packet error rates
> >
> >
> > Dear all,
> >
> > During the meeting in Vancouver, the requirements CG ad hoc
> > have had some
> > discussions on the requirements for latency and packet error rates.
> > Unfortunately, we have not been able to come to a consensus on this
> > requirement. Please find attached a document which contains a
> > list of all
> > the proposed options since November 2003. This document
> > contains also the
> > alternatives as a result of the ad-hoc discussions in January.
> >
> > Please review the attached document for the various options on the
> > requirements for latency and packet error rate. Any questions,
> > (constructive) suggestions or comments are welcome. Thanks
> > very much for
> > your support.
> >
> > Best regards,
> > Anna.
> >
>
>