RE: stds-80220-requirements: Latency and packet error rates
The way that the proposed text is worded there are no requirements for
latency and PER. A reasonable person interpreting this wording could
claim that their proposal supports a real time applications, like
VoIP, with a one way delay of 2 day's with a PER of 90% and Non real
time applications could come with a one way delay of 4 day's and a PER
of 95%. Obviously the times and PER's shown are not realistic but it
serves to illustrate my point that there are upper bounds on what is
practical too support a particular service.
My suggestion is to take Anna's table for Latency and PER by diffServe
class (from the November meeting) and populate this with realistic
numbers. One thought is use numbers based on the most common
application for a particular diffServ class i.e. diffServ class 1 use
numbers for gaming applications.
It's hard to believe that equipment providers are designing networks to
support VoIP and gaming without having any targets for PER and latency.
-----Original Message-----
From: Branislav Meandzija [mailto:bran@arraycomm.com]
Sent: Friday, February 27, 2004 6: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.
>