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

From: Jon Bennett <[email-masked]>
Date: Mon, 18 Dec 2000 14:24:07 -0500

Alessio,

> > 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 allthe 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.

That's odd, why is it that you would not want me to do so? It always seems
to be better to have a discussion based on facts, rather than assertions. If
you want to continue to support your argument through unsupported assertions
and opinions, I will just start posting documents till it becomes clear that
I am presenting factually true statements and you are making unsupported,
and unsupportable claims.

> 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. 

Now if rate is a service level parameter valid at the edge, then in a one
node network the edge is the network, hence rate is a parameter valid at a
single hop. As for nothing being able to be said about rate unless PQ is
used, this is a most unusual statement, particularly if you want to support
more than one instance of the EF service the only way to insure the
provisioning of a configured rate would be to use something other than PQ.

> 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".

Your argument is both circular and untrue. It has been shown that with
FIFO/PQ service that you do not have control over the burst accumulation on
a local level , and that only through network level controls can you achieve
such control. So a PHB can not make the guarantees that you want, this is a
proven fact.  Repeated assertions by you to the contrary can not change
this. I know very well how to build a device which will aggregate traffic
together in such a way that there is no burst accumulation, but to do that
requires NON-FIFO/NON-PQ service, and a huge S, which gets us back to why
you can not specify what you think you want to specify.

> Are we on the same page now?  

I am afraid that we are not even reading from the same book.

> 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. 

No, the low jitter is an end-to-end SERVICE, the provisioning of an output
rate IS the essence of the PHB as the RFC says.
 
   Creating such a service has two parts:

      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.

   The EF PHB provides the first part of the service.  The network
   boundary traffic conditioners described in [RFC2475] provide the
   second part.

I fail to see where in part 1) it mentions any concept of what the EF PHB is
other that a RATE guarantee.  The lack of jitter accumulation is a result of
the second part, which as I said before falls to the network level controls
and is therefore the property one might find in a PDB but not in a PHB,
which is why we decided not to put it in the PHB, because it does not belong
there.

jon

_______________________________________________
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:33:16 -0800 (PST)

Jon,
> which is why we decided not to put it in the PHB, because it does not belong

The lack of "delay bound" is also a result of the second part. It falls
into the network level controls if it is wanted to be achieved
"efficiently". According to your above statement, does "delay 
bound" belong there?

Alper K. Demir