Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess input burstiness

From: Anna Charny <[email-masked]>
Date: Fri, 01 Dec 2000 01:20:39 -0500

At 05:14 PM 11/30/00 -0800, demir wrote:
>Anna,
>
> > However the statement we were making was that the definition of a per-hop
> > behavior should *not* be left undefined in any case, and especially when
> > you put together conformant EF devices. In fact, Diffserv Architecture
> > explicitly says that a PHB definition should describe the behavior when
> > input constraints are violated:
>
>What about AF PHB? You may say that for AF PHB when input constraints are
>violated (Note: we might have different definitions for input
>constraints. I assumed trafic input constraints), packets are
>dropped. During congestion, behavior might end up, even, dropping
>"in" packets. there is no constraint on how much packet will be dropped
>or whatever. If you are talking about input parameters to define the
>functions of PHB, in AF PHB, there is no constraint how you assign
>threshold values of RIO or whatever. From my understanding, what you state
>above is not valid to me. Or, is there a point that I am missing here?
>

It seems to me that it is OK to drop the packets.  If packets are *always* 
dropped when the burst is exceeded, then the behavior is always defined and 
this is not an issue.  But *requiring* dropping may be excessively 
restrictive and imposes implementation constraints that are quite 
undesirable.  We still need to say what happens when the burst is exceeded 
but some or all excess packets are not dropped.   Currently the behavior is 
not defined in that case.

Anna

>Alper K. Demir

---------------------------------------
Anna Charny
Cisco Systems, Inc
300 Apollo Drive
Chelmsford, MA  01824
Tel. (978)-244-8172
Fax (978)-244-8126

_______________________________________________
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: Fri, 01 Dec 2000 11:45:28 -0600

Let's not go there - AF is so totally different that will just
confuse a discussion that is already complex enough.

   Brian

---

From: demir <[email-masked]>
Date: Fri, 1 Dec 2000 13:38:11 -0800 (PST)

Okay. As a side note, though, however a definition is defined, it should
apply to all cases.
What about the idea of using a much general EF PHB definition or the
previous one that I already posted. This can be a new PHB as BOUND PHB :)
bounded_vaule(i) < bound_value(i)

and each PDB defines above functions. Anna can define for input output
rate and burstiness and new proposal for its related PDB define as:
bounded_value(i) = D(i)
bound_value(i) = S*MTU/R+E(i)

All discussions related to EF PHB disaapper, PDB discussions start :)

Alper K. Demir

---

From: demir <[email-masked]>
Date: Fri, 1 Dec 2000 19:50:19 -0800 (PST)

> not defined in that case.

I don't see any difference between the solution trying to be redifined for
EF and and already defined AF PHB. However, EF PH behavior, somehow,
trying to go beyond and delay with "PDB-dependent" (you say topology
dependent) parameters. Let me put this way:
In general:
A_value_to_be_bounded_function(in parameters) < bound_function(in parameters)

In AF PHB case:
A reference given in the RFC of AF is RIO: bound_function uses 
max_threshold, and min_threshold and value_bounded_function is
avg_queue in order to provide "assured service".

There is nothing more on "topology-dependent" parameters. A PDB addresses
this issues.

In EF PHB case:

i) you, Anna: input and output rate are bounded and bound values.

Beyond that, in order to bound jitter, more input parameter is used. There
are topology-dependent parameters + burstiness issues. It is beyond AF
PHB.

ii) EFRESOLVE: D(i) - E(i) (delay variance) is being bounded in order to
bound jitter with toplogy-dependen parameters + burstiness issues.

It is beyond AF PHB. 
Somehow, I have feeling that both i and ii are approaching to a problem
from different directions and will have same solutions (It's just a
feeling, I'm not claiming more or anything).

I wonder why EF is going beyond. I'm sure if a PHB goes much beyond, It
would be easier to build PDBs on top of this. Is this an
"end-to-end" argument? 

Or am I completely in a wrong direction?

Alper K. Demir

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 02 Dec 2000 16:53:04 -0600

EFRESOLVE defines a rate and a bound. I don't see any relationship
to AF, which doesn't define either.

   Brian

---

From: demir <[email-masked]>
Date: Sat, 2 Dec 2000 22:02:20 -0800 (PST)

Brian,
I see a relationship (of course there is no relationship what they
define and what "parameters" and "basic building-blocs" (explained
later) they use. Otherwise, they would be the same thing) I explained it
step by step.
My disaggrement with Anna was about "In fact, Diffserv Architecture  
explicitly says that a PHB definition should describe the behavior when  
input constraints are violated:"-Anna.
I haven't seen such a constraint in any RFC. If there is, could you point
it out to me? 
- First of all, there is no "arrival" rate constraint for AF (I 
assume we both are agree on this). Actually, there is no constraint other
than constraints on how "queueing and discarding" is
performed. In general, "queuing, queue management and scheduling" are the
most "basic building blocks" where PHBs are built on top.
("rate" (input/output,configured input/output: max,min,avg, etc), "queue 
length" (max,min,avg,etc), "packet queue delay", MTU, "time" are among the
parameters to support the "mechanisms" used to construct "basic
building blocks" (What I mean is everything that can be calculated by a 
PHB itself- I am not sure about "delay variance" cause it may depend
on the network topology). As both RED is a "well-known" queue
management" mechanism used on "routers" to prevent" congestion
collapse" based on a "congestion avoidance" algorithm and it is on the way
to be standardized as an "active queue management" mechanism: AF PHB gives
both RIO and RED as example "mechanisms" for AF PHB. I assume AF PHB is
based on these facts in order to provide both "quantitative" and
"qualitative" service guarantees for where PDBs may be responsible.
- My point about the relationship is: What AF is trying to bound as a PHB
is AVG_QUEUE_LENGTH using max and min threshold values as bounding
parameters. In the first definition of EF (RFC-2598), what EF was trying
to bound as a PHB was ARRIVAL_RATE using DEPARTURE_RATE as bounding
parameter  when measured over any time interval equal to or longer than
the time it takes to send an output link MTU sized packet at the
configured rate. I guess you accept "bounding a papameter/parameters" is a
ralationship on a higher-level. What parameters they bound and what "mechanisms" 
they use will differ them.
- My objection: There is no objection related to "rate" used to define "EF
RESOLVE". However, there is an objection on a bound "delay variance". 
  i) It is not known that if a PHB can be satisfied using
"parameters" that are known by a PHB where "parameters" can be expressed
by a PHB  independent of network topology and a "parameter" can be
calculated by a PHB itself. I have *strong* belief that "delay
variance" on a hop is not one of them as "delay variance" depends on
network-topology dependent "parameters" if it is expressed in the most
efficient way (my intuition says it :) 
 ii) How to express "burstiness" is still going on (I guess).
- My result: A PHB should not use network-topology dependent
parameters. It should be "blind" to that. PDBs may use them whenever they
want :)
- I am aware of the fact that EF PHB is trying to bound "delay
variance". That's great. I hope someone would come up with a
"genious" idea to do that. However, a PHB shouldn't use a
topology-dependent parameter at all. Also, if there is no "current
aggrement" on a parameter, it shouln't be defined in a PHB. It *always*
can be defined in a PDB later.
-  "First, we want to start out by implementing a simple set of
   services, which are useful and easy to understand. At the same time,
   we should not embed these services into the mechanism, but should
   build a general mechanism that allows us to change the services as
   our experience matures."- D. Clark / J. Wroclawski, "An Approach to
   Service Allocation in the Internet"

Alper K. Demir

---

From: demir <[email-masked]>
Date: Sat, 2 Dec 2000 22:34:57 -0800 (PST)

Brian,
As a note: I know that I am refering RIO as if it is a AF PHB
(Actually, it is only known candidate to be used for AF PHB). It will not
change the relationship that I gave in my previous email. In general, AF
PHB is trying to provide different levels of "forwarding assurance". RIO
achieves this by using RED where avg_queue is bounded with max and min
threshold values. There may exist other mechanisms to achieve the goal of
AF PHB. However, I don't think that they will achieve it without bounding
any "parameter". Otherwise, it will result with "best-effort" service if
related PDB doesn't take any action at the edge of the network.
Moreover, you may claim that RED is a "congection avoidance" mechanism
used in the "routers" for AF PHB. I think "congestion control and
avoidance" are "concepts" that can be used in a QoS Architecture to
provide levels of service. In AF PHB, it is described as "different levels
of forwarding assurance". In order to give "different levels of forwarding
assurance", one should define "different levels of drop". As
"randomness" goes to "uniformity", "random drop" may result with "fair
drop". That's how I see AF PHB. I assume this still keeps the relationship
I gave in my previous email if you agree on it.

Alper K. Demir

---

From: demir <[email-masked]>
Date: Sun, 3 Dec 2000 00:19:53 -0800 (PST)

Hi,
I have a simple suggestion to support "Queueing and Discarding
Behavior" for EF PHB where "Queuing and Discarding" Behavior MAY be
supported (something like defined in AF PHB)
Someone may ask why?: because the range of services that can be supported
can be wider.
Someone may ask why do I need "congestion avaidance" for a EF PHB: First
of all, it's not a service. If you don't want to deal with it 1) you don't
have to implement it 2) If you implement it, but don't want to deal with
it: min_threshold=max_threshold=buffer_size or if you have a power to
disactivate it in your implementation, you can do it.
3) Trafic conditioners may fail. If input/output rate constraint is not
chosen, and input rate becomes an important value, then "congestion
collapse" might be a problem. Still, one can have a choice to deal with it
or leave it out. 4) It is sad that EF PHB has only one DSCP and no "levels
of forwarding assurance". If it did, there could have been much more range
of services. Someone might say, it's AF PHB's job to do it: It is a
forwarding assurance for EF packets where EF PHB constraints are
performed.

Someone might say it doesn't make much more sense to provide range of
services on top of EF PHB: If it doesn't don't use it. If it does, use
it. You are not required to do it. It's just a MAY. However, you never
know what will happen in the future. If AF PHB is not too strict about
the "drop levels" and "classes", it could have been a buildnig block for
EF PHB with it's additional constraints with additional DSCPs.

Again:

Any comments?

Alper K. Demir

---

From: demir <[email-masked]>
Date: Sun, 3 Dec 2000 03:21:27 -0800 (PST)

Hi,
I think the EF PHB defined in RFC-2598 is perfectly fine. A PHB does not
have to deal with "delay variance" bound that is topology dependent when
it is trying to be defined in an "efficient" way. There is always a gap to
define a new PHB when someone comes up with a "proof" that can provide
"delay variance" bound using only non-topology dependent
"parameters". Also a "parameter" should have a definition where it has a
accepted definition.
A PDB can have additional constraints such as the one defined in EF PHB:
D(i) - E(i) < S*MTU/R
As a PDB is build on top of a PHB, all topology dependent parameters
(Diffserv domain topology) are welcome to be used and defined however the
designer of PDB wants :)
All PHBs and PDBs requiring "state" information in the core of the
network should be excluded from Diffserv. I think Diffserv is
"core-stateless" QoS architecture. It either doesn't keep any state at
the core or "state" is carried through packets (this is not the
architecture being defined by IETF's Diffserv. As far as I know CMU is 
working on it). I assume a "stateful" QoS architecture based on PHB and
PDB building blocks can use "state" on PHBs and/or PDBs and/or carry the
"state" information through network packets. I assume "stateless" QoS
architectures might emerge when bandwidth is plentiful and a domain is
"over-provisioned" and it is known that network traffic won't have any
effect on the "over-provisioned" network. Otherwise, it will have only
"best-effort" service. 
Any comment is appreciated.

Alper K. Demir

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Dec 2000 11:48:49 -0600

This is a fundamental change to the EF PHB and I don't think
we have seen any evidence of a widespread desire for that; all
that is on the table is repairing a defect in 2598.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Dec 2000 11:46:34 -0600

You might want to check guideline G4 in RFC 2475. But please let's
not distract attention from EF by discussing AF at this time.

Thanks
   Brian

> I haven't seen such a constraint in any RFC. If there is, could you point
...

---

From: demir <[email-masked]>
Date: Mon, 4 Dec 2000 14:33:35 -0800 (PST)

Brian,
I agree that this is a fundamental change. However, it is a MAY and will
not affect the table. I assume "repairing a defect" should also consider
"repairing failures" (trafic conditioners) and "service range". What I am
suggestion is a more general mechanism which is a super set of current
one.

Alper K. Demir

---

From: demir <[email-masked]>
Date: Mon, 4 Dec 2000 15:15:42 -0800 (PST)

Brian,
I didn't know that discussions are on per problem basis. I am pointing out
a "PHB" definition issue. I am talking about a problem of the current
architecture (where some MAYs won't have any effect on the current):

It seems to me that G4 along with other guideslines are
restrictive. Services (expected) are being embedded into the PHB
mechanisms. You may say that that's how we designed. In that case, I
can't say more than:  Some MAYs won't have any effect on the current
architecture. They will provide more "generality". The "beauty" of
Diffserv Architecture is "It is scalable and the architecture defined
supports qualitative services" (I am not saying that
scalability and qualitative services are unique to Diffserv
Architecture). Let's not embed services into the mechanisms. EFRESOLVE is
one of them. That's how I see it. Our experience will mature. That's why
PDBs are defined (that's what I thought).

Alper K. Demir

---

From: John Schnizlein <[email-masked]>
Date: Tue, 05 Dec 2000 15:53:34 -0500

Alper,

Quoting from the int-serv approach does not justify applying
this approach to the (intentionally different) diff-serv approach.
Diffserv chose to define a small set of mechanisms first, not services.
My impression was that there was an implicit agreement to risk 
whether or not (or just how) useful services could be built from them.

It seems to me that your choices are to accept the diffserv approach
or find a rough consensus to change the strategy of the working group.

At 03:15 PM 12/04/2000 -0800, demir wrote:
>... I am pointing out a "PHB" definition issue. 
>I am talking about a problem of the current architecture 
>(where some MAYs won't have any effect on the current):
>
>mechanisms. 

It may very well be that the EF PHB should specify that bursts larger
than what an individual hop can accommodate must be dropped. The
reason this is not specified is because people might think it requires
implementing the meter to measure this in core devices that can be
guaranteed through the configuration of the domain that they never get
too large a burst. Saying that the result of too large a burst is not
defined seems to me an adequate compliance with (informational) RFC 2475.
We should not imply that burst meters are required on the inputs of
the core ("interior nodes").

John

---

From: demir <[email-masked]>
Date: Tue, 5 Dec 2000 21:52:44 -0800 (PST)

John,
> this approach to the (intentionally different) diff-serv approach.
John,
What I quoted is NOT an "approach", It is a "fundamental
design issue" (That's how I see it). I don't know if this "fundamental  
design issue" was around before IntServ. I assume it was, because there
have been a lot of "thinkers". If you read the "Fundamental Design Issues
for the Future Internet.", IEEE Journal on Selected Areas in
Communications, Vol 13, No. 7, pp. 1176-1188, September 1995, Scott
Shenker", you can get more info. Does anyone know if it is the
"first" paper addressing this issue?

> whether or not (or just how) useful services could be built from them.

That's what I am arguing about. I agree that Diffserv chose to define a
small set of mechanisms first, not services. That's how a QoS architecture
should be. I am arguing about this "implicit agreement" if there is
such a thing. If there is, it should be an "explicit aggrement". How I 
see it is now is that it is an "explicit aggreement and they are on
the RFCs of Diffserv. What I am saying is this can be
"relaxed and generalized". It won't change anything on the current
work. It will leave an "open window". This should be the
"philosophy" behind any architecture (I think). Let me quoto a very new
lines that David Clark posted it today.
"If you are building a network to hook together computer applications, 
where there may be a large number, and "you" may not even know what 
some of them are, building the response into the network layer will 
not work as well."- David Clark.
Could you point me out a reference about "useful services". Is there such
an aggrement on them? I assume not. If there is, probably, "application
level" is done. If "application level is done", the most efficient way to
bild the netwotk would be is that to hook up the "services" into the
"mechanisms". I think this won't happen. If it does, I guess "the limits
of human brain will have been reached". And if this happens, lots of
"ifs" wil go on and go on, finally, "everthing will be bounded". This is
against the "evolution" and let's not go there.

Alper K. Demir

---

From: Kathleen Nichols <[email-masked]>
Date: Wed, 06 Dec 2000 15:01:53 -0800

demir wrote:
... I agree that Diffserv chose to define a
> such a thing. If there is, it should be an "explicit aggrement". 

I may be missing the point here, but I think if you read the diffserv
charter, this is made explicit:
http://ietf.org/html.charters/diffserv-charter.html

or, at least, our intent in that charter, approved by the IESG, was to
be explicit in what diffserv was about and was to accomplish. Perhaps
we are not as clear as we'd like to be?

...orking group.
> > >restrictive. Services (expected) are being embedded into the PHB

So somethign I'd like to say here is to be careful in equating the
pre-diffserv terminology that Clark and Wroclawski used to the
terminology that's been defined since the WG was chartered. Clark's
use of "mechanism" is analogous to what we call the per-hop forwarding
behavior or PHB. "Mechanism" was objected to, particularly by vendors,
because it sounded too much like "implementation" which they objected
to having specified. 

I hope we are not embedding expected services into PHB definitions. This
was why we took the approach we did for RFC 2598, though we had a
particular
service in mind. There are "SHOULDs" that allow one to relax things. On
the other hand, when a particular "service" IS in mind, it would be well
to have a PHB available that will implement it. Particularly if there
is commercial interest in such a "service".

	Kathie

---

From: demir <[email-masked]>
Date: Wed, 6 Dec 2000 17:40:18 -0800 (PST)

Kathie,
> because it sounded too much like "implementation" which they objected

Exactly. That's how I refered it.

> is commercial interest in such a "service".
- My general point was about "what you hope". To me, EFRESOLVE has a risk
of embedding services into EF PHB. S term is very risky (Intuitively, I
feel that bounding delay at a hop in an efficient way might be a
problem). Not does only it might depend on "network topology", but also it
closely depends on the "scheduling" mechanisms used in a hop (This can be
okay for a hop. I still see it as "embedding services" into the PHB. If
someone comes up with a "bright" idea to achieve this goal on a PHB, that
would be great. PDBs can handle it in the future because, the current EF
PHB doesn't have any risk.
- My suggestion: To keep the current  EF PHB the way it is. 
- I emailed a new suggestion that EF MAY have "queuing and 
discard" behavior for EF PHB (my previous email). This won't change the
current trend. It will leave an open window for "qualitative" services and
it will help when "trafic conditioners" fail. Brian refered it as
"fundamental" change (I assume he refered as "fundamental change" for
EF). I agree. However, it would have been nice. If someone doesn't like
it, he/she doesn't use it in a Diffserv domain. 
- Toplogy dependent parameters should be avoided ina PHB.
- Currently, unaccepted terminology such as "burstiness" should be avoided
in a PHB definition. PDBs can do that however they like. 
- I think current EF PHB is fine.

Alper K. Demir

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Dec 2000 11:01:21 -0600

And don't forget that DiffServ totally inverts the meaning of the words
"service" and "behavior" compared to IntServ. 

  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: Kathleen Nichols <[email-masked]>
Date: Thu, 07 Dec 2000 14:06:33 -0800

demir wrote:
...
> PHB doesn't have any risk.

Hmm, okay, I don't see it that way. I don't think EF resolve adds
topology dependence. It does break out more parameters in how you
write/think of the boundedness of the PHB's delay variation, but that 
doesn't change things fundamentally. In fact, it does clarify them.
I'm glad you like the original EF PHB, but even as a co-author, I
have to say that EFresolve lays things out more clearly. Still, I
think the words in the 2598 should make the intent clear and with
EFresolve making a clearer definition of the bound, this is a good
thing.

> it, he/she doesn't use it in a Diffserv domain.

I'm afraid I've missed that email, but I believe I agree with Brian.
We've
had these discussions before.

> - Toplogy dependent parameters should be avoided ina PHB.

Yes, I agree. If there IS topology dependence it should be in a PDB.
But I don't think EFresolve is dependent on network topology.

> - I think current EF PHB is fine.

Since the EFresolve team defined what they meant by "burstiness", I
don't have a problem with this. It's basically saying that the vendor
has to expose the buffer available if there are simultaneous arrivals.

Again, I'm glad you think the current EF PHB is fine, but I think the
EFresolve version is equivalent. And I hope I'm not so enamored of
words I've co-authored that I can't accept their clarifications!

	Kathie

---

From: demir <[email-masked]>
Date: Thu, 7 Dec 2000 16:46:10 -0800 (PST)

Katie,
> EFresolve making a clearer definition of the bound, this is a good
I am not saying EFRESOLVE adds "topology dependence. S term has a risk if
one wants to bound the delay in an "efficient" way. As Anna pointed out,
It is a "philosolphical" change. That's how I see it. And the easiest way
to achieve this is:
	D(i) < max_delay_bound(i)
	max_delay_bound(i) = a_constant
This is not efficient. Current EFResolve has the same problem when
scheduling mechanisms are not embedded/misinterpreted/etc into calculation
of S(i). 

> We've had these discussions before.

Then, sorry to bring it up again. I wasn't aware of. I thought "leaving an
open window" would have been nice.

> But I don't think EFresolve is dependent on network topology.

It might not. But if someone "realy" wants to achieve D(i) - S(i),
"he" could face with this peoblem. This all has been discussed I guess. I
don't know what the current aggrement is. Any idea?

> has to expose the buffer available if there are simultaneous arrivals.

What is "exposing buffer"?

> EFresolve version is equivalent. And I hope I'm not so enamored of

I guess I can't see the "equivalance". With current EF PHB, one might end
up defining a PDB using the ideas from EFResolve. Is it "equivalent"? Or/
am I missing a point here?

Alper K. Demir

---

From: John Wroclawski <[email-masked]>
Date: Fri, 8 Dec 2000 20:25:14 -0500

>"service" and "behavior" compared to IntServ.

This is true. Just wanted to note that the text snippet quoted below 
was using meanings much closer to the diffserv terminology than the 
intserv terminology. (BTW not intentionally; we meant to stick as 
close to intserv terminology as we could so as not to create the 
inversion you point out, but screwed up.)

It does seem to me that there is a difference of tone between EF and 
the other PHB's, in that EF _was_ proposed "with a particular service 
in mind", so it seems completely reasonable to be sure that the 
definition is above all well and carefully suited for that service. 
Nothing wrong with that, particularly if the service is a widely 
popular one.

In contrast, the AF precursor we wrote about was proposed with the 
goal of being a flexible building block for a wider range of less 
closely related services. Examples include olympic, quantitative 
capacity profiles, a statistically strong low-delay service, etc. For 
a PHB with this bias, the definition ought to be targeted more at 
wide reuse than at having a particular service in mind. But I don't 
think this difference in bias makes such a PHB either more or less 
appropriate than a PHB that needs to be narrowly targeted to do what 
it was designed for. They're just different critters, is all.

John

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

---

From: demir <[email-masked]>
Date: Fri, 8 Dec 2000 19:23:08 -0800 (PST)

> it was designed for. They're just different critters, is all.

I agree with that. It seems to me that AF PHB is a "base" behavior. A "MAY
to let EF PHB or others use AF PHB as a "base" PHB won't change the
behavior of EF or others If they choose not to use it as a "base". It
will leave an "open" window to them to provide "statistical" services if
an experimenter choses to play with it. People who needs
"only" "service" don't choose it at all. If one chooses, I think it might
"help" in the case of "traffic conditioning failures" and be a "more
general mechanism" for "richer range of services". I guess I can't see
what's wrong with this if there is. (General point is: "object-oriented
approach on using PHBs).

Alper K. Demir