Subject: RE: [Diffserv] RE: Yesterday's EF discussion

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Mon, 18 Dec 2000 18:38:21 -0000

> Its funny, I am also familiar with those things as well, and having
> actually
> heard Van explain the operation of the BANDWIDTH brokers in Internet2 I do
> see the dependence on the rate bound. But you know something, it doesn't
> really matter what Van thinks since the RFC is a product of the WG and not
> his personal property. If you wish I can start posting references to all
> the
> Internet2 project documentation that specifies the BANDWIDTH broker
> operation and the SLA guarantees in terms of RATES and not in terms of
> jitter, would you like me to do that?
> 
No, thanks. We can try and discuss anyway.

The SLA is a service level specification 
stipulated between two diffserv domains. 
Rate is a service level parameter, valid at 
the edge.
Nothing can be said about the rate 
configured (if no PQ is used)
within the domain, and that the rate 
guarantee per se is what is needed within 
the domain. 

The diffserv domain guarantees that EF traffic
delivered at that edge from a foreign domain with
specified bounds on burstiness (close to zero) and rate
(the virtual wire rate), gets delivered at the egress
as if sent over a wire (or approximate that ideal
behaviour).

The way this is possible is via PHB that allows 
aggregation of a number of customer networks 
in a way that they do not affect one another. 
This is possible via a PHB
that provides strict guarantees in terms 
of delay variation across a hop.  
This is the only way that allows aggregation
without uncontrolled burst accumulation, 
that would result in the service not being delivered 
end to end to the customer network
asking for a "virtual wire".

So, back to our issue, the per hop guarantee is a delay 
variation guarantee. Whether that is achieved via a color 
aware configured rate, priority Queuing with non 
EF traffic starvation protection, this is entirely 
dependent on the router instance selected by the operator. 
There are a lot of other knobs that may be used to deliver a
delay variation bound, and it would not be wise to specify 
all of them.
So, output Rate is one of the knobs to achieve the per hop delay 
variation guarantee, if we like. But not what should 
be used to describe the PHB.
By the way, it is clear that low per hop fixed delay 
values are desirable, but the virtual wire per se does 
not specify a universally acceptable delay value 
(that is, the length of the virtual wire is not going to be
mandated by the standard:).

Are we on the same page now?  This is what Van meant,
what EFRESOLVE is, and what I suggest the WG should 
ask the spec to specify.  The fact that Van in the 
original version stated that the output rate 
(delivered with some tight constrains) on an interface 
cannot be lower than the input is a truism, but not 
what the PHB is in essence. 

alessio

_______________________________________________
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: demir <[email-masked]>
Date: Wed, 20 Dec 2000 06:11:13 -0800 (PST)

Alessio,
> asking for a "virtual wire".

A PHB should not be intended for a specific PDB or what so ever. What is
the use of PHB-PDB layering? If what EF PHB is intended for is "VW" then
rename it as EF PDB" based on "NO PHB". "Burst accumulation" is result of
the "traffic" coming from "edge". The question is "if it is "appropriate
"to control burst accumulation on a PHB". The answer is obvious. Accepting
"inefficient ways" is another "issue". I see mixture of different
"concepts" in above statements. Are you talking about a PHB, PDB, service,
or combined all together?

> delay variation bound, and it would not be wise to specify 

To me, "delay variation" is not a per hop gurantee. However, if a "PHB"
wants to support that guarantee, it has to learn whether it is allowed to
keep "state" or not. If it does, there is no problem. If it doesn't, then
it should learn if it is allowed to achieve it "efficiently". If it does,
there is no problem. If it doesn't, "good-bye". Delay variation is
"by-product" of "configured-rate" or "priority queuing" and "EF traffic
starvation protection" is not "enough" to achieve it. "Scheduling" should
also be controled. "Delay-variation" guarantee is a good thing. However,
it requires very "fine-granularities". Where and how is another "issue".

> mandated by the standard:).

These are the "statements" I have made above and during the
"EF" discussions as you made here. If something is worth having
(desirable), then everybody who are willing to pay for it wants to have
it. The question is "if it is worth supporting on a PHB". What is "low per
hop fixed delay"? D(i) = 0.0 is very good to me. I can achieve this if one
is willing not to receive any packet. I assume "delay guarantee" is
desirable comming along with "packet loss rate". "Delay guarantee" has to
deal with similar things as "delay variance guarantee". 

Alper K. Demir