RE: stds-80220-requirements: Latency and packet error rates
Vince,
The part which is unclear from your response is which one of the options to the "4.1.7 Latency and Packet Error Rates" requirement do you prefer? It appears you are saying that the QoS requirements formulated in 4.1.12 and 4.4.1 make 4.1.7 unnecessary? I have no problem with that but the group is seriously discussing arbitrary kind of formulations such as
----
Traffic classes Expedited Forwarding (EF) AssuredForwarding (AF) Best Effort(BE)
Latency ~ 30 ms (TBR) ~ 30 ms – 10 s (TBR) >> 10 s (TBR)
Packet Error Rate for
Error Tolerant Applications 3 x 10-2 10-2 – 2.5 x 10-1 (TBR) 2.5 x 10-1 (TBR)
Packet Error Rate for
Error Intolerant Applications 5 x 10-13 (TBR) 5 x 10-13 – 8 x 10-5 (TBR) 8 x 10-5
-----
So then, if you were to address the group's desire for more guidance on delay and packet error rates with respect to DiffServ classes, and you couldn't just simply say that is already implied by the DiffServ PHBs, how would you formulate the requirement?
See my comments in-line.
Branislav
> -----Original Message-----
> From: Park Vincent [mailto:Park@flarion.com]
> Sent: Monday, March 01, 2004 7:50 AM
> To: Branislav Meandzija
> Cc: stds-80220-requirements@ieee.org
> Subject: 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.
Not really, the text states that these are recommendations.
> 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.
Correct, the text states
"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 ..."
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.
I partially agree. The text selects 4 classes and defines them more
specifically using the IETF work in progress.
>
> 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.
The text is referenced as "work-in-progress" as recommended by the IETF. Do you find any errors or omissions in the cited text?
>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.
True. Again, the IETF specifies that internet drafts can be referenced as "work-in-progress". Are there any specific problems that you see with the RFC.
More generally, is your preference to define something ourselves from scratch? The authors of the RFC include distinguished IETF and DiffServ veterans, including a former IETF Chair.
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.
This kind of casts doubt on the veracity of the technical material contained in the RFC. That is unfortunate, as from my reading the document is of very high quality. It would be a great effort to create something of similar quality from scratch within the context of this group. As it is OK to cite IETF Work in progress I would suggest you focus on the drafts content and not IETF status.
>
> 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.
Please summarize your recommendation/preferences in the context of the proposal made or formulate a new one that you feel could be agreeable to the group.
>
> -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 Error 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.
> > >
> >
> >
>