RE: stds-80220-requirements: Latency and packet error rates
Victor,
Great question. To paraphrase from the cited RFC:
The Conversational service class is RECOMMENDED for applications that
require real-time, very low delay, very low jitter and very low
packet loss for relatively constant-rate traffic sources (inelastic
traffic sources). This service class MUST be used for IP telephony
services.
The Streaming service class is RECOMMENDED for
applications that require near-real-time packet forwarding of
variable rate traffic sources that are not as delay sensitive as
applications using the Conversational service class. Such
applications include broadcast TV, streaming audio and video, video
(movies) on demand and surveillance video. In general, the
Streaming service class assumes that the traffic is
buffered at the source/destination and therefore, is less sensitive
to delay and jitter.
Branislav
> -----Original Message-----
> From: Victor Hou [mailto:vhou@broadcom.com]
> Sent: Friday, February 27, 2004 5:45 PM
> To: Branislav Meandzija; Lai-King Tee;
> stds-80220-requirements@ieee.org
> Cc: Humbert, John J [NTK]
> Subject: RE: stds-80220-requirements: Latency and packet error rates
>
>
> Branislav,
>
> In the table of traffic classes, I see attributes of "Streaming" as
> "Same as conversational," but then the attributes listed are
> significantly different from those of "Conversational." So for the
> "Streaming" class attributes, what specifically is the same as
> "Conversational?"
>
> Regards,
> Victor
>
> -----Original Message-----
> From: Branislav Meandzija [mailto:bran@arraycomm.com]
> Sent: Friday, February 27, 2004 4: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.
> >
>
>
>
>
>