Subject: Re: [Diffserv] Comments on draft-ietf-diffserv-vw-pdb

From: "J. Noel Chiappa" <[email-masked]>
Date: Wed, 26 Jul 2000 18:34:22 -0400

> From: Brian E Carpenter <[email-masked]>

    > the kind of conformance criteria that Telcos have considered relevant
    > in the ATM world are irrelevant in the Internet. ... We do need some
    > types of guarantees to provide high service quality, but not ones that
    > remove any scope for flexibility in queuing mechanisms and tradeoffs.
    > Internet applications, including real time applications, simply aren't
    > that sensitive. 

I've been listening this this EF definition debate with half an ear for some
months (because completely understanding it would take more brain cycles than
I have to spare), and I have the following reaction:

It seems to me that some people might be trying to do too much with DiffServ
(and the EF PHB especially); in particular, trying to produce very strict
performance guarantees (by using DiffServ along with some path control
mechanism such as MPLS).

Strict performance guarantees were what the combination of IntServ and RSVP
was intended to produce; DiffServ was *originally* simply intended to allow
some traffic to get better service (under load conditions) than other traffic
(i.e. drop priorities and the like).

So perhaps the whole notion of needing to be able to tell whether a given
DiffServ box is *exactly* meeting some performance guarantee - which in turn
requires a very exact definition of the performance it it supposed to be
providing, which is the current hangup - is really not in the original spirit
of DiffServ?

	Noel

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Dave Hotlosz <[email-masked]>
Date: Thu, 27 Jul 2000 09:22:46 -0700

Hi,
Lots of emails lately :)
It seems to me that the PDB definition still defines a PHB not a DS domain
behavior. That is the real problem. And it only defines one type of PHB
behavior.

Just looking at these outakes...
.....

   We note that, given the virtual wire rate R, large packets mean
   longer periods and short packets mean shorter periods. However, the
   amount of work presented to an output link, in its nature, does not
   differ from the case when we have fixed size packets. Because of the
   strict ingress policing, the size of a packet can be considered as a
   quantum of service request over a short time scale.
......

Each ingress node's SLA determines how much data it pushes into a DS domain so
strict ingress policing is determined per DS domain ingress point. Works fine if
there is only one ingress point but that is not reality.

.......

    However, we note that, given the number of
   packets in the queue, the unfinished work and hence the queueing
   delay is larger due to larger packet lengths. Under the
   circumstances, we can relate the difference in queueing delays to
   the service quanta represented by different packet sizes. Although
   the arguments given in this paragraph requires further study, the
   impact of heterogeneous packet sizes should not be significant
   provided that packet sizes, in use for EF micro flows, do not vary
   wildly.
.......

I believe this PDB doc should be changed to a PHB doc. It should also define
seperate behavior for different packet sizes. Currently packet sizes can be as
large as 9K. Packet sizes will vary wildly. It would be foolish to ignore this
size packet and think that packet sizes will not grow larger.

In this PHB doc it would define hops geared toward certain traffic types and
sizes. Most smaller packets, less than 512 bytes are user responces and http
requests. These types of packets should take one path through a DS domain over
switches designed for optimal performance with this type of traffic.

It may also define a medium size path PHB say 512 to 1500 and a large size path
PHB for over 1500.

This does several things.

You now have greater controll over maximum delay times shorter packets
experience.

Larger packets do not get lost in queues full of small packets.

DS domain ingress points now have 3 different routes for different types of
packets. This is where a PDB doc is needed to describe using the different
routes through a DS domain from the ingress point. A PDB doc should describe
ingress and egress points as well as DS domain redundancy options. It should not
be used to define PHB.

Now there is also redundancy built into the DS domain as there are now three
routes. If one route failes one of the others can be used. Each PHB will handle
all types and sizes of traffic but are heavily optimised to serve it's primary
configured packet size.

You can also do some qualification of how well switches support thier primary
packet size PHB.

To sum it up I'd like to get back to PHB definitions and traffic conditioning
within the domain, not put everything into one doc for PDB which does not define
DS domain behavior but rather tries rather poorly to define PHB.

Just my opinion.

Thanks,
    Dave Hotlosz

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jul 2000 12:32:00 -0500

Dave,

I assume you are referring to draft-ietf-diffserv-pdb-vw-00.txt
That's a draft that claims to construct a PDB from an existing PHB.
You can assert that it has failed to do that, but you can't
logically assert that it ought to be turned into a PHB definition.

Just to be clear, a PDB is not meant to define the total behaviour
of a DS domain, but only the behaviour of one subset of the traffic
traversing that domain.

  Brian

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