Subject: [Diffserv] A question on a PDB definition

From: demir <[email-masked]>
Date: Mon, 19 Feb 2001 14:08:20 -0800 (PST)

What is the reason that a PDB is (only) defined for ideal conditions? /Or
this is not the case? It may be useful if a PDB has definitions for
failure conditions (i.e. traffic conditioning failures).

Alper K. Demir

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Feb 2001 16:50:37 -0600

> failure conditions (i.e. traffic conditioning failures).

I don't really understand your question. The PDB definition
document that we agreed on says:

"PDB attributes may be absolute or statistical and they
 may be parameterized by network properties. For example, a loss
 attribute might be expressed as "no more than 0.1% of packets will
 be dropped when measured over any time period larger than T", a
 delay attribute might be expressed as "50% of delivered packets
 will see less than a delay of d milliseconds, 30% will see a delay
 less than 2d ms, 20% will see a delay of less than 3d ms." A wide
 range of metrics is possible. In general they will be expressed
 as bounds or percentiles rather than as absolute values."

That clearly includes metrics for traffic that is dropped or unduly
delayed in the possible parameters of a PDB.

  Brian

---

From: demir <[email-masked]>
Date: Mon, 19 Feb 2001 15:20:17 -0800 (PST)

I am sorry for not being very clear with my question. My question is:
If a PDB should have definitions/handling mechanisms in case there are
failure conditions (i.e. at the edge of the network traffic conditioners
may fail). In that case, PDB attributes (given in the below paragraph
taken from PDB definitions draft) may change. It may be useful if a PDB
definition considers such failures (optionally), otherwise PDB
definition is defined for ideal conditions (i.e.no traffic conditioning
failures, traffic aggregate is in profile, etc...)

Alper K. Demir

---

From: Kathleen Nichols <[email-masked]>
Date: Tue, 20 Feb 2001 10:29:18 -0800

There is nothing that prohibits one from defining what a particular
PDB does in case of failure, but in many cases, this is more of
an operational or business decision, not a technical decision. In
general, in the case of failure, some sort of error should be generated.
It's probably better not to state what that error should be, an
operational matter, in what's meant to be a technical spec.

Were you trying to write a description with such a condition in
it and feeling constrained by the definition? Maybe if you could
be specific it would help.

	Kathie Nichols

---

From: Hermann DE MEER <[email-masked]>
Date: Tue, 20 Feb 2001 19:35:28 +0000

Demir, Kathie,

sorry to jump into this discussion.

But I find Demir's observation very crucial in defining
any (distributed) QoS architecture, or DiffServ architecture for
that matter. Understanding and specifying failure semantics may be
at least as important as characterising the "ideal conditions",
not only from an operational perspective but essentially so.

This is at least the understanding in our current DiffServ project
here at UCL. We are even tempted to believe that without a proper inclusion
of failure semantics, the concept of DiffServ at large may be challenged.

Hermann de Meer

---

From: Kathleen Nichols <[email-masked]>
Date: Tue, 20 Feb 2001 12:31:39 -0800

Hermann,

I can appreciate that understanding and specifying failure
semantics is important; I can't see what in my posting or
in the PDB def document in anyway says this is unimportant.
I think there is a desire to overload the notion of a PDB
specification. At the same time, I'm not sure enough care is
going into specifying even the "ideal conditions" in some cases.

Brian and I are attempting to separate what can be specified
at this point and what needs to be understood over some time
operationally. In addition, a good deal of failure condtiions
may have dependency on the current state of technology; we expect 
the current state to change. Thus, a PDB should be specified by 
its "ideal conditions". A service needs to include a lot more
operational understanding that is particular to a certain
network and its components and a particular technology. "Go
forth and experiment" has been the message that Brian and
I have been trying to put out for some time. There's just not
going to be any substitute for implementation and the understanding
gained that way. A PDB is just an aid in that process.

	Kathie

> > be specific it would help.
....

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Feb 2001 15:06:04 -0600

I'm still confused. If you specify a traffic profile and a maximum
loss percentage *for that traffic profile* you have specified 
all you can about loss (taking loss as an example). You can't specify
what happens to packets outside the traffic profile without in effect 
extending the scope of the profile, which means you've now specified a
different (broader) PDB. That sounds like a recursion to me.

It's true that an SLS needs to state what happens to out-of-profile
packets, but that is not part of a PDB as this WG defined it.

  Brian

---

From: demir <[email-masked]>
Date: Tue, 20 Feb 2001 14:38:58 -0800 (PST)

Hi,

> operational matter, in what's meant to be a technical spec.

I think a PDB seems a top building block in Diffserv towards
operational/management and business decisions. I am unable to see why
"failure conditions" is not more of a technical decision (specifically for
a PDB definition). I don't argue if it be a "MUST" in a PDB
definition. However, I think it would be useful if a PDB definition has a
"section" where it may consider "failures" though not having any support.

P.S. I am not sure if there is a "fine line" between two above. I assume
not. Any helpful comments/clues are appreciated.

> be specific it would help.

No. Not at all. I hope to come to that stage :) Thank you very much.

Alper K. Demir

---

From: demir <[email-masked]>
Date: Tue, 20 Feb 2001 21:43:45 -0800 (PST)

Hi,
I have another question: Is there any reason why there is no
"edge(s)-to-edge(s) behaviour" (EEB) definition that is not part of the
Diffserv architecture /Or why a PDB is responsible for such a
behaviour? To me, it seems PHB-EEB-PDB layering might give more
flexibility. I am sorry if this was a discussion before I subscribed the
Diffserv.

Alper K. Demir

---

From: demir <[email-masked]>
Date: Tue, 20 Feb 2001 21:34:46 -0800 (PST)

I am agree with DE MEER. To me, In any QoS architecture, "failure",
"error" and "exception" handling is very crucial. I guess, this is an
"end-to-end argument". 

Alper K. Demir

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 21 Feb 2001 16:23:01 +0100

Demir,

IMO, a PDB is an edge-to-edge behaviour (where both edges reside in the 
same administrative domain)

MArcus

- --On Tuesday, February 20, 2001 9:43 PM -0800 demir <[email-masked]> wrote:

> Archive:
> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillis
> t.html
>

- --------------------------------------
Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 21 Feb 2001 16:26:52 +0100

Demir,

I would say this is a service issue. Behaviour in case of failure of 
equipment, etc needs to be dealt with in SLAs.

Marcus
- --On Tuesday, February 20, 2001 9:34 PM -0800 demir <[email-masked]> wrote:

>> here at UCL. We are even tempted to believe that without a proper
>> inclusion of failure semantics, the concept of DiffServ at large may be
>> challenged.
>>
>>
>>
>> Hermann de Meer
>>
>> >
>> > general, in the case of failure, some sort of error should be
>> > generated. It's probably better not to state what that error should
>> > be, an operational matter, in what's meant to be a technical spec.
>> >
>> > > If a PDB should have definitions/handling mechanisms in case there
>> > > are failure conditions (i.e. at the edge of the network traffic
>> > > conditioners may fail). In that case, PDB attributes (given in the
>> > > below paragraph taken from PDB definitions draft) may change. It may
>> > > be useful if a PDB definition considers such failures (optionally),
>> > > otherwise PDB definition is defined for ideal conditions (i.e.no
>> > > traffic conditioning failures, traffic aggregate is in profile,
>> > > etc...)
>> > >
>> > > Alper K. Demir
>> > >
>> > > > > What is the reason that a PDB is (only) defined for ideal
>> > > > > conditions? /Or this is not the case? It may be useful if a PDB
>> > > > > has definitions for failure conditions (i.e. traffic
>> > > > > conditioning failures).
>> > > >
>> > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/ma
>> > > illist.html
>> >
>> > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mail
>> > list.html
>> >
>>
>>
>>
>>
>>
>>
>
>

Adenauerplatz 6
D-69115 Heidelberg
Germany

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Feb 2001 10:17:42 -0600

A PDB *is* the edge2edge behavior for an aggregate. It *isn't* a
complete service description, which is the problem on your other thread.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Feb 2001 10:24:31 -0600

One more time:

A PDB describes what happens to a given traffic aggregate. Therefore,
traffic that isn't part of the aggregate is not covered by a PDB definition.

Traffic that "fails" admission control  is presumably traffic that
a meter says is not part of the aggregate. *By definition* it is not
covered by the PDB. It will need to be covered by the SLS in some way
of course (dropped, demoted to BE, or whatever).

Please remember we are constructing the diffserv standards bottom-up.
First we did PHBs, now we are doing PDBs. Kathie and I tend to believe
we (the industry) need more experience before we can do a good job
on SLS's.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org
Non-IBM email: [email-masked]

---

From: Hermann DE MEER <[email-masked]>
Date: Wed, 21 Feb 2001 16:43:43 +0000

Brian, Kathy et al,

I am talking about in-profile traffic with traffic conditioning in place.

But, since there are imprecisions coming with the DiffServ model,
it seems obvious you cannot possibly guarantee performance/loss
measures under all (practical) circumstances within a domain, can you?
At least you would expect to observe a considerable variability in quality
due to repeatedly incurred aggregation/disaggregation effects, 
variable (unpredictable?) traffic matrices, variations in implementing PHBs,
local resource provisioning policies, etc. etc.

(I am not necessarily talking about hardware failures here, that may
  have additional detrimental effects)

Unless you have an extremely overprovisioned network segment, you
may always run some non-negligible risk of violating a specified quality level.
In addition to supporting QoS, DiffServ is about aggregation and
resource efficiency, after all.

Wouldn't  it therefore make sense to include exceptional conditions 
into a PDB spec as part of an abstract behavior of a traffic aggregate?
Defining the exceptional conditions may also lead to better 
understanding of the "normal operation", it seems.

--Hermann

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Feb 2001 11:30:56 -0600

Hermann,

Yes indeed - the Internet is a queuing system so of course it is not perfect.
That's exactly why I expect the parameters on real PDBs to be expressed
as percentiles. Even if we can define absolute bounds for certain PHBs,
these certainly won't survive as edge2edge bounds. So, for example
a PHB with bounded jitter <J_h will lead to a PDB whose jitter is <J_d for P%
of the time. And J_d and P will be experimental values, not calculated.
Does that capture what you mean?

  Brian

---

From: Hermann DE MEER <[email-masked]>
Date: Wed, 21 Feb 2001 19:09:03 +0000

Brian,

this is exactly what I mean.

But I am suggesting to go  (at least) one step further:
not only to express the parameter as percentiles but to
include a characterization of such an event, which may
be called a QoS segment fault, and its admissible impact on the
traffic aggregate into the PDB spec. In its weakest form, simply
a more or less informative indication would be useful

The significance of that is that e2e QoS may still be achievable
with (well-defined)  QoS segment faults if appropriate tolerance measure were
taken on the service level or somewhere else.

I know that the service def is not part of the PDB itself, but the 
inclusion of the concept of QoS segment faults into the PDB may
be useful ("later on") for service creation.

Otherwise you simply would have an undefined behavior in case
of that rare event which may, nevertheless, occur more or less regularly. This 
would seem quite undesirable and may break the whole chain more often than not.
(and more often than perhaps necessary)

--Hermann

---

From: demir <[email-masked]>
Date: Wed, 21 Feb 2001 12:15:03 -0800 (PST)

Marcus and Brian,
To me, edge-to-edge behavior is integrated into PDB definition and the
major part of it. If a PDB is an edge-to-edge, then I would say PDB name
is misleading. Other job of a PDB is to orchestrate all traffic entering
into the domain from ingress and exiting from egress (orchestrating
traffic aggregates at the edge and inside of the domain). My question was
on the necessity of this integration. If there was another layer (I called
it edge-to-edge behavior, separated it from PDB definition and, now, we
have EEB and PDB layers). My question is: what is the reason of such
integration in the current PDB definition? To me, if (major) edge-to-edge
behavior (EEB) is seperated from PDB definition and a new PDB definition
is define, it might give more flexibility. May be not. If so, what are the
reasons if there is any? /Or am I adding/misinterpreting a PDB definition?

Alper K. Demir

On Wed, 21 Feb 2001, Marcus Brunner wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Demir,
> 
> -----BEGIN PGP SIGNATURE-----
> Version: Mulberry PGP Plugin v2.0
> Comment: processed by Mulberry PGP Plugin
> 
> iQA/AwUBOpPPRlhvF0PcuRgqEQIWbgCgkW9bBQJ7OflFMiW+ESt0dd2QiOkAn0He
> asg3F/aiB3yFTLXtw/5aXLsX
> =aLy+
> -----END PGP SIGNATURE-----
>

---

From: demir <[email-masked]>
Date: Wed, 21 Feb 2001 12:18:16 -0800 (PST)

To me, this is not only service issue. "Failure", "error" and
"exception" might change the behavior that is defined in a PDB. If it
happens, a PDB definition becomes inconsistent.

Alper K. Demir

On Wed, 21 Feb 2001, Marcus Brunner wrote:

> iQA/AwUBOpPQLVhvF0PcuRgqEQLubACcDmcQMcauWKYmetr4KRJdpzMxZo0AoNLD
> mfO7vWySlVu7VIV1iD1dj1GI
> =F+6c

---

From: demir <[email-masked]>
Date: Wed, 21 Feb 2001 12:22:41 -0800 (PST)

Brian,
I wasn't asking any question related to a complete service. I guess I
wasn't clear with my question. I also tried to clarify the problem of my
other thread. I clarified and emailed them, again. 

Alper K. Demir

---

From: demir <[email-masked]>
Date: Wed, 21 Feb 2001 12:27:20 -0800 (PST)

Brian,
My question is not for traffic that is not part of traffic aggregate
covered in a PDB definition. "Failure", "error", and "exception" might
have effects for "in-profile" traffic. This may create inconsistent PDB
definition in case of failures.

Alper K. Demir

---

From: demir <[email-masked]>
Date: Wed, 21 Feb 2001 12:39:30 -0800 (PST)

DE MEER wrote what I meant with this thread in a great way below. I am
agree with below lines.

Alper K. Demir

---

From: demir <[email-masked]>
Date: Wed, 21 Feb 2001 12:34:05 -0800 (PST)

Hi,
> local resource provisioning policies, etc. etc.

I think this is a further research. It seems with right sets of mechanisms
and engineering, it is possible to reach the limits of "integrated
services". Am I being too optimistic? 

> understanding of the "normal operation", it seems.

That's what I, also, wanted to say this.

Alper K. Demir

---

From: Hermann DE MEER <[email-masked]>
Date: Wed, 21 Feb 2001 21:12:07 +0000

Alper,

> services". Am I being too optimistic? 

although we seem to have agreed on important issues, I believe that
here you would be too optimistic, yes.

--Hermann

---

From: demir <[email-masked]>
Date: Wed, 21 Feb 2001 15:07:13 -0800 (PST)

Hermann,

> here you would be too optimistic, yes.

I assume this is a strong "intuitive" answer. Let's assume a very simple
and non-realistic scenario where future traffic is absolutely predictive
and doesn't change at all + network is overprovisioned (for the sake of 
the argument made in this thread, even there is no hardware and
software failures, no exceptions and errors, what a beautiful network :). 
I am unable to see what the challenge is for this simple and unrealistic
scenario if there is any (to provide QoS guarantees). I am aware of that
this is really at the other side of the specturum.
Going bact to our discussion, is there strong factors that I am unable to
see? Can you be a litle bit more specific, comments/clues/references?

P.S. I guess Brian will tell us this discussion doesn't belong here.

Alper K. Demir

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Feb 2001 16:59:34 -0600

Diffserv applies to diffserv domains and a PDB is defined from
one edge of a diffserv domain to another. EEB==PDB. QED.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Feb 2001 17:04:12 -0600

There's certainly nothing in the PDB definition that
prohibits including such things if they can be precisely
identified; this is clearly a matter for individual PDB authors.

   Brian

---

From: demir <[email-masked]>
Date: Wed, 21 Feb 2001 15:36:05 -0800 (PST)

Brian,

> one edge of a diffserv domain to another. EEB==PDB. QED.

Thank you very much for the great proof. Also, it helped me to see my
wrong claim that PDB name is misleading. I take it back :) I guess I
missed that traffic joining and leaving (entereng the domain from
different ingres, etc...) also is part of PDB definition. However, if no
traffic is joining and leaving a PDB instance, then it might be possible
to use same DSCPs and define a few PDBs that are different. I guess
current PDB definition doesn't have such a restriction. It is a Diffserv
domain issue.

Alper K. Demir

---

From: demir <[email-masked]>
Date: Wed, 21 Feb 2001 15:57:48 -0800 (PST)

Brian,
I would suggest a brief section on this issue in PDB definition draft. My
question didn't intend that the current PDB definition prohibits or it is
missing this issue. My intention was if PDB definition is a right place to
talk about this issue.

Alper K. Demir

---

From: demir <[email-masked]>
Date: Thu, 22 Feb 2001 03:37:14 -0800 (PST)

1) Abstract 
"EF is intended to provide a building block for low delay and low loss
services..."

"low jitter" phrase is missing in the abstract. Otherwise below line is
over-estimating EF.

   "The intent of the EF PHB is to provide a building block for low loss,
   low delay, and low jitter services."

Section 2.4. claims for "jitter bound" I assume "low delay" --> "low 
jitter". I guess this needs some more explanation in the draft.

2) Introduction

"In this context, jitter is defined as the variation between maximum and
minimum delay."

How do you define maximum and minimum delay? Can you be a little bit more
specific? Somewhere in section 2.4 minimum delay is given as zero (0). If
so, it seems it is only delay variation where delay is bounded for each
packet.

3) Introduction
   "To ensure that queues encountered by EF packets are usually short, it
   is necessary to ensure that the service rate of EF packets on a given
   output interface exceeds their arrival rate at that interface over  
   long and short time intervals,..."

  From section 2.1.
 
   "Intuitively, the definition of EF is simple: the rate at which EF
   traffic is served at a given output interface should be at least the
   configured rate R, over a suitably defined interval,..."

"long and short time interval" is relative and it is subset of "any time
interval" used at below lines and section 2.1. gives another definition
"suitably defined interval" (I guess this is related to ideal
departure time) that is subset of "any interval", too.

  From Introduction:
  
  "This specification defines a PHB in which EF
   packets are guaranteed to receive service at or above a configured
   rate and provides a means to quantify the accuracy with which this
   service rate is delivered over any time interval."

It sounds, it is a very little inconsistent. I am aware of that section
2.1 explains this inconsistency. I put a section from the old EF PHB
description in 4). Doesn't it capture the problem?

4) Section 2.1

"- EF traffic clearly cannot be served at rate R if there are no EF
  packets waiting to be served, but it may be impossible to
  determine externally whether EF packets are actually waiting to be
  served by the output scheduler. For example, if an EF packet has
  entered the router and not exited, it may be awaiting service, or
  it may simply have encountered some processing or transmission
  delay within the router."

Doesn't below lines taken from old EF PHB capture the problem? The
senteces after "but..." seems technology dependent. is it realy necessary
to be in EF PHB definition?

      "1) Configuring nodes so that the aggregate has a well-defined
         minimum departure rate. ("Well-defined" means independent of
         the dynamic state of the node.  In particular, independent of
         the intensity of other traffic at the node.)

      2) Conditioning the aggregate (via policing and shaping) so that
         its arrival rate at any node is always less than that node's
         configured minimum departure rate."

5) Is there only one algorithm/mechanism for "ideal departure time" to
achieve "any time interval"?

6) Section 2.1. 
   "Whereas the original EF definition did not provide any means to
   guarantee the delay of an individual EF packet, this property may be
   desired."

"the delay of an individual EF packet and jitter" if EF PHB is claiming
for "jitter" services (I assume it does because of section 2.4 delay and
jitter.

7) Section 2.4

"Since the minimum delay through the device is clearly at least zero, D
also provides a bound on jitter"

I guess this is: "Since EF PHB bound the delay as D,
(naturally/mathematically/theoritacally) D also provides a bound on
jitter" cause jitter is the second moment.

8) Section 2.4.
 
It seems to me that providing a tighter bound for jitter depends on
providing a tighter bound on D in general (instead of only E_p) for the
approach used for EH PHB in this draft.

Alper K. Demir

---

From: Hermann DE MEER <[email-masked]>
Date: Thu, 22 Feb 2001 11:48:48 +0000

Brian,

> Brian,
> I would suggest a brief section on this issue in PDB definition draft.

I would support such a move.

--Hermann

 My

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Feb 2001 09:35:24 -0600

Too late. It's already approved for RFC publication. But it
doesn't prevent PDB authors including such text if they know
what to write for their particular PDB.

  Brian

---

From: Kathleen Nichols <[email-masked]>
Date: Thu, 22 Feb 2001 10:17:50 -0800

demir wrote:
> "low jitter" phrase is missing in the abstract. 

...

The point was made by the authors of RFC 2598 that the approach taken
by the authors of the drafts leading to this did not have the same
jitter concerns as the orginal definition of the EF PHB. The WG decided
it preferred this new approach, thus, apparently, an EF PHB is desired
where low jitter is not one of the primary goals.

	Kathie

---

From: demir <[email-masked]>
Date: Thu, 22 Feb 2001 11:56:50 -0800 (PST)

Katie,
If you read the Introduction, you will see:
   "The intent of the EF PHB is to provide a building block for low loss,
   low delay, and low jitter services."

I was just pointing out either "low jitter" is missing in the abstract or
it is not part of the definition. I guess primary goals should be
consistent through out the document. Also, I wanted to point out, if "low
jitter" is being claimed then "low delay" --> "low jitter" needs a
little more further explanation in the draft.

Alper K. Demir

---

From: Kathleen Nichols <[email-masked]>
Date: Thu, 22 Feb 2001 14:38:30 -0800

....

I want to agree with Brian here. The PDB spec is not intended to
keep authors from putting *more* information in that they feel
is appropriate or useful for the technical understanding of that
PDB. It was more intended to give a general format and a sort of
"minimum standard" of what authors should be thinking of. The real
test of these is how they are received. 

	Kathie

---

From: Hermann DE MEER <[email-masked]>
Date: Thu, 22 Feb 2001 23:07:48 +0000

Brian and Kathy,

> test of these is how they are received. 

I thought it may be worthwhile to raise the issue as I am thinking
it important enough to be included in the PDB spec in terms of
a general format, as you put it. In particular
so as it may not be an obvious thing to look at by potential authors,
but perhaps worthwhile enough for them to be aware of, nevertheless. 
Importance may not always be related to visibility. 

"too late" is too late, of course.

thanks for considering anyway.

--Hermann

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Feb 2001 17:40:55 -0600

I would like to add that the point Alper and Hermann brought up
is important; it's just unfortunate that we didn't catch it
before we closed the PDB document.

   Brian