Subject: RE: [Diffserv] Diffserv MIB - droppers

From: Andrew Smith <[email-masked]>
Date: Thu, 1 Jun 2000 13:34:20 -0700

This doesn't really help me figure out what the *network manager* needs to
have accessible in the MIB for *network management* purposes. What we need
the MIB to describe is what the knobs are and what effect they have on the
device behaviour from a macroscopic point of view.

So what we need are peoples' opinions as to:
 - what are the *common* knobs
 - what are they used for, operationally, in a multi-vendor network of
Diffserv devices which potentially implement different algorithms within the
Precedence, EF and AF specifications. 

This, as opposed to a list of the union of all configurable parameters that
might exist in total in existing real implementations, is what the MIB
should contain.

Andrew

> -----Original Message-----
> From: jamal [mailto:[email-masked]]
> Sent: Wednesday, May 31, 2000 6:31 PM
> To: Kathleen Nichols
> Cc: [email-masked]
> Subject: Re: [Diffserv] Diffserv MIB - droppers
> 
> 
> 
> Kathie,
> 
> On Wed, 31 May 2000, Kathleen Nichols wrote:
> 
> > One of the problems with getting too specific about
> > how people set/interpret the various RED parameters
> > can be seen in two of your recent emails to the list.
> > 
> 
> [..]
> 
> So in general i agree with you but it seems tricky to ignore some
> implementation specifics in the case of some _very important_
> parameters. 
> 
> ones i have seen being kicked around are:
> 
> -  the time constant, w or some concept used for its derivation can be
> visualized/represented in a variety of ways to the network manager: 
>   +as a floating point number, 
>   +as the negative log 2 number, 
>   +as a "queue sampling time"  
>   +and as i just described in my earlier post using the 
> "burst" parameter. 
> 
> - the drop probability; 
> +if you time sample offline then it is possible to say to the 
> data path
> "drop after x packets" (refering to Van's presentation to 
> NANOG which i
> think is the scheme Fred is preaching)
> +if you use the ns-like implementation then in the simple case you do
> actually roll the dice in the fast path
> 
> So the dilema is: you cant leave these parameters out and 
> neither can you
> ignore the existence of "implementation specifics"
> If inter-operability is key then there should be some 
> compromise; imagine
> multiple vendor boxes and some poor ISP network manager 
> trying to get a
> service created inter-operating them ;-<
> 
> cheers,
> jamal
> 
> 
> 
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

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

---

From: Fred Baker <[email-masked]>
Date: Thu, 01 Jun 2000 13:47:22 -0700

At 01:34 PM 6/1/00 -0700, Andrew Smith wrote:
>have accessible in the MIB for *network management* purposes.

yes. I have been ignoring this thread until it came up with something specific.

---

From: jamal <[email-masked]>
Date: Sat, 3 Jun 2000 10:12:40 -0400 (EDT)

> device behaviour from a macroscopic point of view.

I agree. 

That was to provide a view inside that black box i.e what is behind them
knobs. The ones i mentioned are causing the most chaos. 
I mentioned it because it seems everybody who is/was trying hard to define
the "knobs" getting  religious about something from that set.

cheers,
jamal