Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model Draft 3

From: "Brijesh Kumar" <[email-masked]>
Date: Thu, 1 Jun 2000 11:30:52 -0400

In his previous mail, Brian E Carpenter writes
> > I am glad that you agree. I hope the authors will
> re-consider their use of
> > multiple Dropper objects (Absolute and Algorithmic) which,
> I think, is
> > unnecessary.
>
> That's not quite what I meant. I meant that personally I don't like
> the choice of word "absolute" - "unconditional" would be better IMHO.
> But there is a difference between an absolute dropper and an
> algorithmic dropper. (Well, OK, an absolute dropper is an
> algorithmic dropper whose algorithm is TRUE, but that's a very
> formal approach. It's much more intuitive to distinguish the two.)
>

Ok, I see what you meant.

In reality, so called Absolute Dropper is the only kind of Dropper
(free(pkt_buff)) - rest is all word play.  Here is a puzzle, if an Absolute
Dropper is the one that drops Absolutely and an Algorithmic Dropper drops
Algorithmically, what does a Dropper do ? ;-).

If choice has already been made, it does not really matter. My main comments
were with regards to including some explanation regarding ingress queueing
and egress classification and metering, and modeling the classifier and the
meter both with 1 to N, and M to N mappings.

Cheers,

--brijesh
Ennovate Networks Inc.

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

---

From: Mark Stewart <[email-masked]>
Date: Thu, 01 Jun 2000 17:04:41 -0400

> Grenville Armitage wrote:
>
> > Mark Stewart wrote:
> >         [..]
> > > This phenomena where a superset
> > > of old functionality is defined and terms are then needed to define "new" and
> > > "old" is common and always problematic. Placing a bundle of "explanations" at
> > > the front of every standard, in my opinion, detracts from rather than enhances
> > > their clarity.
> >
> > 'Dropper' by itself is an old (or at least intuitive) term.
> > Unfortunately in this case neither Absolute Dropper nor Algorithmic
> > Dropper are "old" terms. Of these two new terms, the former isn't
> > even particularly intuitive. Linguistic wierdness ought to be
> > flagged at the start of a document if it is new (and cannot
> > be modified post-Adelaide :-)
> >
> > cheers,
> > gja
>
> Hi Grenville
>
> On general principals I'm unhappy with the flag it at the front solution but I do
> agree that something
> should be done.
>
> Hunting around in a vain attempt to find a better place/solution I came across the
> following related
> issues. Can you ( or someone else ) shed some light on these for a newcomer like
> myself.
>
> Section 6.2 defines the absolute dropper and refers to section 6.6 on algorithmic
> droppers which dosen't seem to exist.
>
> Section 7.1 defines a queueing block as containing zero or more algorithmic
> droppers, but not an absolute dropper.
>
> Figure 5 Section 7.1.3 seems to preclude actions other than tail drop ( e.g. head
> drop )
>
> Is an algorithmic dropper intended to be an action element?
>
> My understanding was that the distinction between "absolute" and "algorthmic"
> droppers was simply to place
> a label on droppers which had a simple decision (i.e. oh the buffer is full) and
> those which had a more sophisticated
> decision ( that threshold has been reached, or a policing action having been
> reached). Is this correct or is something more
> fundamental going on here?
>
> Ciao
>
> Mark Stewart

---

From: Mark Stewart <[email-masked]>
Date: Fri, 2 Jun 2000 13:51:04 -0400 (EDT)

> > agree that something should be done.
>
> Are you happy with the definitions that I proposed last week to add to the
> glossary?

I believe the definitions hit the wrong target audience, I'm sorry. Whilst 
they are precise, someone who found them easy to understand would also have 
found the definitions in the body of the text clear and easy to follow. If 
I understand the difficulties correctly they can be sumariseds as:
* Unfortunate choice of names: i.e to an applied queueing theorist 
    like myself or someone of similar background they have existing and 
    different defintions.
* Did we need two different labels: I don't see a need to reopen this 
    debate but it appears a few people sort of did
* Confusion as to what the distinction was.

 I'd be happier with something of the nature of
 
Absolute	An action element which discards all packets arriving at
Dropper		it's input.

Algorithmic     A queueing element which may selectively discard packets
Dropper		arriving at it's input. It has one data input and one data 
		output. The decision to discard packets may be based upon 
                state information, and is possibly non-deterministic.

A question for my own edification, does an algorithmic dropper therefore 
use an absolute dropper?

> > Figure 5 Section 7.1.3 seems to preclude actions
> > other than tail drop ( e.g. head drop )
>
> Thanks - that wasn't the intent: I drew that picture thinking that the
> algorithmic dropper could be placed either ahead of or behind the FIFO
> element: the words or picture need to be clearer that head drop is
> explicitly permitted. One question still in my mind is whether the choice is
> between {headDrop, tailDrop, randomDrop} or whether {head, tail} was one
> choice and {deterministic, random} was an orthogonal choice. Am I getting
> confused about what the "randomness" applies to (is it w.r.t. *this packet*
> or is the choice of which packet to drop actually random?) Any opinions?
 
It does sound like you just confused yourself. There are certainly two randoms
in play here.
* a random decision which determines do I drop or not, and
* a random decision of which packet do I drop.
 
The first fits easily into the queueing block model described, but the second
does not seem so easy to me.

As an aside, I would hold a random decision of which flow (or aggregate of
flows) do I drop from, to be more likely in an implementation than selecting
a packet completely at random.

> Hope that helps,
> Andrew
 
Thanks Andrew it did help.

Mark Stewart
> 
> 
> --------------007452B7C1319D431F5912DB--
> 
>