RE: stds-80220-requirements: Latency and packet error rates
Vince/John/Lai-King,
I definitely agree that the preferred solution is no Latency and Packet Error Rate requirement.
But, we need to come up with a formulation that works for everybody. So, I would maintain that my posting below is the best compromise between no requirement and a requirement that makes sense for our QoS solution that is DiffServ based. I hope we can converge or hear from others, so we can get a rough-consensus either way.
Regarding some of the questions regarding tying DSCPs to applications, here is a recent post of Fred Baker one of the author's of the IETF work-in-progress cited/paraphrased (I am copying Fred on this message, so he can chime in if necessary):
-------------------------------------------
> -----Original Message-----
> From: tsvwg-admin@ietf.org [mailto:tsvwg-admin@ietf.org]On Behalf Of
> Fred Baker
> Sent: Monday, March 01, 2004 12:25 AM
> To: Ken Carlberg
> Cc: tsvwg@ietf.org
> Subject: Re: [Tsvwg] draft-baker-diffserv-basic-classes-02.txt
>
At 04:43 PM 03/01/04, Ken Carlberg wrote:
>in taking the devil's advocate position, I'm curious as to the response of
>the authors to those that would object to the draft because it seems to be
>counter to the original diff-serv architecture tenet that code-points
>should not be "tied" to applications.
I thought that was the wrong position at the time, and I think so now.
Consider, if you will, the question of how one handles (this from the slide
Kwok showed, which is from a service provider customer, or the DISA class
proposal. Bottom line, there are very few uses of diff-serv technology that
work well as a service in a sense divorced from the application.
For example, I am asked by any number of edge networks and ISPs how to
identify peer-2-peer traffic, whether to shut it down, manage it, or turn
it into a service. There are various possible ways; none of them are "look
for the user to be asking for a service which is 'move lots of stuff from
here to there'". What they wind up looking for is a long-lived session that
generates a lot of traffic. They often do this by positioning a policer
that accepts traffic at a high rate for a short interval, but starts
marking traffic differently if the rate continues. This traffic may be
treated as more-drop-eligible, may be dropped entirely at an upstream
provider's point, may be charged for in a different manner, or etc.
Increasingly, the ISPs are telling me that they want to host the p2p server
as a service and as a result be in control of it. But bottom line, they are
worried about a class of applications that do something specific to their
network - usually in a manner that costs them money and needs to have
either a way to reduce it or to charge for it. This traffic differs
immensely from HTTP, SMTP, and such, even though they share the fundamental
characteristic of being elastic. So simply saying "well, it goes in the AF
service" isn't adequate. It needs to go into a specified instance of the AF
service - one of the AF classes - that is set aside to manage that traffic.
Voice and Video streams are also similar in the sense that they call for
admission and generate predictable data streams, but have significantly
different service requirements. I have any number of customers that come to
me looking for help in managing these.
And we could discuss the ieprep problem. Bottom line, they are not looking
for a "keep the government running" service. They are looking for an IM
service that gets emergency workers a high probability of delivery, a voice
service that gives them improved call quality or enhanced probability of
being able to make the call, and so on. This is not about some academic
concept of a kind of service, like EF or AF, but of a service to an
identified community using a class of applications that have specific
requirements. If we don't meet the needs of the applications in question,
we have had an interesting discussion, but we haven't helped anyone in any
measurable way.
I would rather fix the fundamental ivory-tower-error that said "DSCPs
identify services" and apply them to classes of traffic that my customers
find themselves trying to control, and make real recommendations about how
to control them.
>also, at that same meeting, Fred and another co-author worked on a draft
>that discussed the potential for an ingress code-point triggering a
>specific egress code-point -- a kind of asymetric phb marking (I'm not
>sure I articulated this well). does the diffserv-basic-classes draft
>cause problems with this asymetric marking approach
You are talking about Rei Atarashi's reflexive marking draft. No, that
actually takes the same model an interesting step. If we have folks who
come to, say, a web site using DSCPs indicating that they have different
service specifications, you want the replying traffic to use the same
service classes.
Understand that in this draft we are not proposing to eliminate private
service classes. We are proposing to use common code points and common
service definitions for a few common classes.
_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg
--------------------------------------------------------------------------------
Branislav
> -----Original Message-----
> From: Park Vincent [mailto:Park@flarion.com]
> Sent: Monday, March 01, 2004 12:51 PM
> To: Branislav Meandzija
> Cc: stds-80220-requirements@ieee.org
> Subject: 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.
> > > > >
> > > >
> > > >
> > >
> >
>