RE: QDDIM Question

I also could live with any of these, but we do have to pick one.  The
property is not quite usable, as is.
Andrea
  -----Original Message-----
  From: [email protected] [mailto:[email protected]]
  Sent: Wednesday, May 15, 2002 7:45 AM
  To: Andrea Westerinen
  Cc: Policy@Ietf. Org
  Subject: Re: QDDIM Question


  Well, you'd think so, wouldn't you? But then you wonder
  what it means for an instance of QueuingService to
  surface this one piece of state information to CIM in,
  say, bytes, while feeding queue-depth information to a
  RED dropper that has its thresholds specified in packets.
  Note that QDDIM says on page 15 that the job of modelling
  state has really not been done, and hence that this
  CurrentQueueDepth property is something of an anomaly.
  So maybe it's OK to have a queue that will only tell *us*
  its current depth in bytes, yet is perfectly willing to
  tell a dropper its current depth in packets.

  I see three choices we might make:

  - Remove the current depth property from QueuingService,
  and have it wait for the rest of the state model.
  - Pick a unit for it, either bytes or packets, and
  define it to always have that as its unit.
  - Add a units enum as you suggest.

  I could live with any of these.

  Regards,
  Bob

  Bob Moore
  Advanced Design and Technology
  Application Integration Middleware Division
  IBM Software Group
  +1-919-254-4436
  [email protected]

  "Andrea Westerinen" <[email protected]>





                "Andrea Westerinen" <[email protected]>
                05/15/02 10:16 AM


        To: "Policy@Ietf. Org" <[email protected]>, Robert
Moore/Raleigh/IBM@IBMUS
        cc:
        Subject: QDDIM Question



  Don't you need a DepthUnits enum for QueuingService.CurrentQueueDepth as
we
  have in the REDDropperService for the thresholds?

  Andrea