Subject: [Policy] RE: Inconsistencies in QDDIM -07 Draft

From: [email-masked]
Date: Wed, 29 May 2002 14:01:31 -0400

OK, but then how does a RED dropper get to a queue to watch if it doesn't
go via a CalculationService?  I didn't think we were using NextService for
this.

Regards,
Bob

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

                      "Andrea                                                                                                          
                      Westerinen"              To:       Robert Moore/Raleigh/IBM@IBMUS                                                
                      <andreaw@cisco.          cc:       "Policy@Ietf. Org" <[email-masked]>                                          
                      com>                     Subject:  RE: Inconsistencies in QDDIM -07 Draft                                        
                                                                                                                                       
                      05/29/02 01:34 PM                                                                                                

Bob, I think that the operative words in my email are "IF you define a
CalculationService, then ..."  Since CalculationService is a new concept
and may not be visibly instrumented, I did not want to make it mandatory.
Hence, the 0..n on the CalculationService, as related to a REDDropper.  I
think that the "one or more" wording in the Description is a cut and paste
error.

Andrea
      -----Original Message-----
      From: [email-masked] [mailto:[email-masked]]
      Sent: Wednesday, May 29, 2002 10:36 AM
      To: Andrea Westerinen
      Cc: Policy@Ietf. Org
      Subject: Re: Inconsistencies in QDDIM -07 Draft

      Hi Andrea,

      Busy editing QDDIM ....

      From CR 795:

      // ==================================================================
      // CalculationServiceForDropper
      // ==================================================================
      [Association, Experimental, Version ("2.7.0"),
      Description (
      "This association is a subclass of ServiceServiceDependency, "
      "and represents the reliance of a REDDropperService on one or "
      "more DropThresholdCalculationServices. The latter calculate "
      "average queue depth, based on the observed depths of a "
      "queue. The specific queue examined by each CalculationService "
      "is defined using the CalculationBasedOnQueue association.") ]
      class CIM_CalculationServiceForDropper : CIM_ServiceServiceDependency
      {
      [Override ("Antecedent"), Description (
      "A calculation service for the dropper.") ]
      CIM_DropThresholdCalculationService REF Antecedent;
      [Override ("Dependent"), Description (
      "The RED dropper which is dependent on average queue depth "
      "calculations by the Antecedent Service.") ]
      CIM_REDDropperService REF Dependent;
      };

      For the calculation service, the words say "one or more", but the
      cardinality says 0..n. You also propose 0..n for QDDIM, but I think
      that the words are correct here - the cardinality should be 1..n,
      since the only path to get from a RED dropper to a queue for it to
      examine is via a calculation service instance.

      Assuming that you'll say "Yes, of course," I've tentatively gone with
      1..n in the QDDIM update. You can still talk me out of this is you're
      quick.

      Otherwise, I've edited QDDIM as you've proposed in this note.

      Regards,
      Bob

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

      "Andrea Westerinen" <[email-masked]>

                               "Andrea                                     
                               Westerinen To: "Policy@Ietf. Org"           
                               "          <[email-masked]>, Robert        
                               <andreaw@c Moore/Raleigh/IBM@IBMUS          
                               isco.com>  cc:                              
                                          Subject: Inconsistencies in      
                                          QDDIM -07 Draft                  
                               05/14/02                                    
                               06:28 PM                                    

      In reading QDDIM very closely :-), I noticed some inconsistencies in
      the text in Section 3, in the formal class definitions in Section 4,
      and in the intent. Here are my observations and recommendations ...

      1. For RED droppers, I think that we wanted the following ...
      A REDDropperService can be related to many
      DropThresholdCalculationServices (many to many), but each
      CalculationService examines a single queue (many to one).

      2. This means that ...
      IF you define a DropThresholdCalculationService, you really MUST
      specify the queue that is examined. So, CalculationBasedOnQueue
      should have a cardinality of 1..1 on the QueuingService side
      (currently it has 0..1).
      AND
      A REDDropper MAY be associated with one or more CalculationServices
      (each looking at a specific queue). So, CalculationServiceForDropper
      should have a cardinality of 0..n on the
      DropThresholdCalculationService side (currently it is a mandatory 1).

      3. For a HeadTailDropperService, its determinations can also be based
      on several queues (as discussed at the bottom of page 23). So,
      HeadTailDropQueueBinding should have a cardinality of 1..n for the
      QueuingService (currently, it has mandatory 1). I agree that at least
      queue is mandatory - but more than one can be examined.

      Andrea

---

From: "Andrea Westerinen" <[email-masked]>
Date: Wed, 29 May 2002 11:17:32 -0700

In the original incarnations of QDDIM, we had NextService only, for a
REDDropper.  The problem was that the Dropper did not have to base its
calculations only on the queue from which it dropped.  So,
CalculationService was defined to describe the calculations separate from
the queue to drop.  We did not mandate the existence of the calculation
definitions before, so I did not want to do that now.  However, I am not
religious about this one - mandating the association (based on cardinality)
does force specificity.

Do others have an opinion on this?
Andrea
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
  Sent: Wednesday, May 29, 2002 11:02 AM
  To: Andrea Westerinen
  Cc: Policy@Ietf. Org
  Subject: [Policy] RE: Inconsistencies in QDDIM -07 Draft

  Regards,
  Bob

  Bob Moore

        To: Robert Moore/Raleigh/IBM@IBMUS
        cc: "Policy@Ietf. Org" <[email-masked]>
        Subject: RE: Inconsistencies in QDDIM -07 Draft

  Bob, I think that the operative words in my email are "IF you define a
CalculationService, then ..." Since CalculationService is a new concept and
may not be visibly instrumented, I did not want to make it mandatory. Hence,
the 0..n on the CalculationService, as related to a REDDropper. I think that
the "one or more" wording in the Description is a cut and paste error.

  Andrea
      -----Original Message-----
      From: [email-masked] [mailto:[email-masked]]
      Sent: Wednesday, May 29, 2002 10:36 AM
      To: Andrea Westerinen
      Cc: Policy@Ietf. Org
      Subject: Re: Inconsistencies in QDDIM -07 Draft

      Hi Andrea,

      Busy editing QDDIM ....

      From CR 795:

      For the calculation service, the words say "one or more", but the
cardinality says 0..n. You also propose 0..n for QDDIM, but I think that the
words are correct here - the cardinality should be 1..n, since the only path
to get from a RED dropper to a queue for it to examine is via a calculation
service instance.

      Assuming that you'll say "Yes, of course," I've tentatively gone with
1..n in the QDDIM update. You can still talk me out of this is you're quick.

      Regards,
      Bob

      Bob Moore

                            05/14/02 06:28 PM

            To: "Policy@Ietf. Org" <[email-masked]>, Robert
Moore/Raleigh/IBM@IBMUS
            cc:
            Subject: Inconsistencies in QDDIM -07 Draft

      In reading QDDIM very closely :-), I noticed some inconsistencies in
the text in Section 3, in the formal class definitions in Section 4, and in
the intent. Here are my observations and recommendations ...

      1. For RED droppers, I think that we wanted the following ...
      A REDDropperService can be related to many
DropThresholdCalculationServices (many to many), but each CalculationService
examines a single queue (many to one).

      2. This means that ...
      IF you define a DropThresholdCalculationService, you really MUST
specify the queue that is examined. So, CalculationBasedOnQueue should have
a cardinality of 1..1 on the QueuingService side (currently it has 0..1).
      AND
      A REDDropper MAY be associated with one or more CalculationServices
(each looking at a specific queue). So, CalculationServiceForDropper should
have a cardinality of 0..n on the DropThresholdCalculationService side
(currently it is a mandatory 1).

      3. For a HeadTailDropperService, its determinations can also be based
on several queues (as discussed at the bottom of page 23). So,
HeadTailDropQueueBinding should have a cardinality of 1..n for the
QueuingService (currently, it has mandatory 1). I agree that at least queue
is mandatory - but more than one can be examined.

      Andrea