RE: stds-80220-requirements: Latency and packet error rates
Branislav,
I am in fact suggesting that 4.1.7 is not needed. I don't mean to discount
your proposed text more than the other options. I actually dislike that idea
of associating specific performance measures with IETF standard track PHBs
even more. Many talented and intelligent individuals participated in (and
continue to participate in) the IETF standardization effort for DiffServ,
including the specification of the handful of standards track PHBs. I don't
think it is appropriate for 802.20 associate such hard criteria with these
PHBs when the IETF has chosen not to.
Also worthy of note is the fact that the IETF has not mandated the use of
specific DSCP and/or DSCP->PHB mappings for any specific purpose. They have
also reserved a significant fraction of the DSCP space for experimental/local
use. In short, they have left a enormous amount of flexibility in how
DiffServ technology and components may be deployed and used in practice. I
think this is consistent with IETF approach to standardization--where they
tend to standardize the mechanisms that enable interoperability but not how
they are used.
Additional comments inline below...
-Vince
> -----Original Message-----
> From: Branislav Meandzija [mailto:bran@arraycomm.com]
> Sent: Monday, March 01, 2004 12:59 PM
> To: Park Vincent
> Cc: stds-80220-requirements@ieee.org
> Subject: 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?
>
[VP] Does the group truly want more guidance (or more specific requirements)
on packet latency and error rates? I have not proposed text, because I am not
convinced that more detail in this area is what the group as a whole wants
(although, it is clearly what some individuals or sub-groups want). It is
truly difficult to discern the difference sometimes...and if the group as
whole is in support of adding more detail here then I must apologize for not
being more constructive. At the moment I hope that I am only one of many that
believe the requirements document has become bloated and over specified in
many sections. Creating such a document is a good way to set a bar that no
proposal will reach. I believe it is better to set the bar lower, and allow
multiple proposal to over achieve in various respects (especially in areas
for which a specific requirement is difficult to define). Proposal can still
be differentiated based on how they comparatively perform, even if a specific
requirement was not decided.
> 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.
>
[VP] The proposed text that concerned me reads "Thus, the following traffic
classes shall be supported:..." and "Traffic classes shall be marked as
follows:...". These sound like requirements.
> > 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.
>
[VP] Sorry, I guess I still don't see why this useful in this requirements
document. If an operator wishes to mark a class with a different DSCP or map
it to a different PHB, that should be fine. Why should it break a requirement
if they choose to do so?
> >
> > 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.
[VP] It is good that you mention it is work in progress. My concern is more
in the sense that you make use of specific details that may change or be
dropped over time. Also, its probably best not to refer to it as an "RFC" (I
noticed this somewhere in the proposed text as well).
>
> 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.
>
[VP] I'm definitely not suggesting that we start from scratch, it would be a
huge task and in my opinion a needless one.
> 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.
>
[VP] I is not my intent to cast doubt on the veracity of the internet draft
or in any way question its goodness. I actually know Fred and have very high
regard for his technical abilities. I suspect that the other authors are also
well qualified. My point is more that we don't how the internet draft will
progress. We don't even know the intent of the authors. Will the internet
draft be published as an Informational RFC? Will the internet draft be
adopted by a working group and if so how will it evolve and change as it
progresses? Even if it is adopted by a working group...what will be the end
goal...Informational RFC, BCP RFC or standards track RFC? Finally, even if
any of the above sounds like an acceptable outcome...it may take years to
happen. It's a good doc to watch and/or contribute to, but likely not to
incorporate into an 802.20 requirements document.
> >
> > 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.
[VP] I think my preference is clear...none of the above. Sections 4.1.12 and
4.4.1 are sufficient.
> >
> > -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.
> > > >
> > >
> > >
> >
>