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

From: [email-masked]
Date: Wed, 29 May 2002 15:49:16 -0400

Andrea,

Just to be clear: you're asking whether to allow room in the model for a
"watches" linkage between a RED dropper and a queue that does not traverse
a CalculationService instance.  As best I can figure out, in such a case:

  - only one queue could be watched;
  - the watched queue would have to be the queue from which packets are
dropped;
  - there would be no smoothing of the current queue depth for the watched
queue, since this is what the CalculationService does.

I'm not saying yes or no - just asking whether this is in fact what you're
proposing.

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: [Policy] RE: Inconsistencies in QDDIM -07 Draft                           
                      Sent by: policy-                                                                                                 
                      [email-masked]                                                                                                   

                      05/29/02 02:17 PM                                                                                                

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

      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" <[email-masked]>

                                "Andrea                                    
                                Westerinen"       To: Robert               
                                <andreaw@cisco.   Moore/Raleigh/IBM@IBMUS  
                                com>              cc: "Policy@Ietf. Org"   
                                                  <[email-masked]>        
                                                  Subject: RE:             
                                05/29/02 01:34 PM 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:

                  //
                  ==================================================================

                  // 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" <[email-masked]>                          
                                                     To: "Policy@Ietf.     
                                                     Org" <policy@ietf.    
          05/14/02 06:28 PM                          org>, Robert          
                                                     Moore/Raleigh/IBM@IBM 
                                                     US                    
                                                     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

---

From: "Andrea Westerinen" <[email-masked]>
Date: Wed, 29 May 2002 12:52:35 -0700

Yes.
Andrea
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
  Sent: Wednesday, May 29, 2002 12:49 PM
  To: Andrea Westerinen
  Cc: Policy@Ietf. Org; [email-masked]
  Subject: RE: [Policy] RE: Inconsistencies in QDDIM -07 Draft

  Andrea,

  Just to be clear: you're asking whether to allow room in the model for a
"watches" linkage between a RED dropper and a queue that does not traverse a
CalculationService instance. As best I can figure out, in such a case:

  Regards,
  Bob

  Bob Moore

                "Andrea Westerinen" <[email-masked]>
                Sent by: [email-masked]
                05/29/02 02:17 PM

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

  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.

      -----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

                            05/29/02 01:34 PM

            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-----

              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

                                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

---

From: "Andrew Smith" <[email-masked]>
Date: Wed, 29 May 2002 13:54:43 -0700

Bob, Andrew,

Rather than inventing a special case for this, why not just use a
CalculationService instance that does a very simple calculation? Or is this
issue really just because people feel a need to be backwards-compatible with
an earlier draft?

Andrew Smith
  -----Original Message-----

  Andrea,

  Regards,
  Bob

  Bob Moore

      -----Original Message-----

      Regards,
      Bob

      Bob Moore

      Andrea
              -----Original Message-----

              Hi Andrea,

              Busy editing QDDIM ....

              From CR 795:

              //

              Regards,
              Bob

              Bob Moore

              2. This means that ...

              Andrea

---

From: "Andrea Westerinen" <[email-masked]>
Date: Wed, 29 May 2002 13:56:05 -0700

Let's just put a stake in the ground and say that you must have the
CalculationService if you have a REDDropper (Bob's 1..n cardinality).
Specificity is clearer and simpler than having multiple degrees of freedom.

Andea
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
Andrew Smith
  Sent: Wednesday, May 29, 2002 1:55 PM
  To: [email-masked]; Andrea Westerinen
  Cc: Policy@Ietf. Org
  Subject: RE: [Policy] RE: Inconsistencies in QDDIM -07 Draft

  Bob, Andrew,

  Andrew Smith
    -----Original Message-----

    Andrea,

    I'm not saying yes or no - just asking whether this is in fact what
you're proposing.

    Regards,
    Bob

    Bob Moore

        -----Original Message-----

        Regards,
        Bob

        Bob Moore

        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-----

                Hi Andrea,

                Busy editing QDDIM ....

                From CR 795:

                //
                "This association is a subclass of ServiceServiceDependency,
                "and represents the reliance of a REDDropperService on one
or "
                "more DropThresholdCalculationServices. The latter calculate

                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.

                Regards,
                Bob

                Bob Moore

                2. This means that ...

                Andrea