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