Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [RPRWG] Minutes of today's adhoc (restricted classB allocations, deficient or not)




Harry,

With regards to the following:
**** single-queue designs cannot support _any_ classB, which
**** may not be what some in the working group have expected.

I had hoped this might garner your attention.
My understanding was that our objectives were:
  a) classB allocations can be supported by single-queue
     or dual-queue implementations.
  b) classB allocations are limited to (linkRate-classA),
     regardless of STQ size or single-queue implementation.

However, Necdet's opinions appeared to be that classB is like
classA1, and is therefore subject to the similar limitations,
as follows:
  c) classB allocations cannot be supported by single-queue.
  d) classB allocations are limited to (capacityA1-classA1)
     on dual-queue implementations, where the capacityA1
     value is dependent on the STQ size.

I wanted to raise the visibility of this issue, since I
believe that objectives (a) and (b) are shared by WG members,
and (c) and (d) are artifacts of a deficient specification.

I would prefer to fix the protocols so that we achieve (a&b),
rather than cope with (c&d), but I'm only one WG member.

I don't think it will be all that hard to correct deficiencies
of the fairness-eligible protocols, with respect to upper-class
(classB-CIR and classA) interactions. However, to do so, we
need to transition from denial-to-refinement design phases.

DVJ

David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
      +1.650.856.9801
Cell: +1.650.954.6906
Fax:  +1.360.242.5508
Base: dvj@xxxxxxxxxxxx


-----Original Message-----
From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Harry Peng
Sent: Saturday, June 21, 2003 8:17 AM
To: David V James; Rpr GroupOf Ieee
Subject: RE: [RPRWG] Minutes of today's adhoc


Dave,
Going through your minutes, and I see a calling card.
I would like to understand the assertion that
"**** single-queue designs cannot support _any_ classB, which
**** may not be what some in the working group have expected."


Regards,
Harry


-----Original Message-----
From: David V James [mailto:dvj@xxxxxxxxxxxx]
Sent: Wednesday, June 11, 2003 2:15 PM
To: Rpr GroupOf Ieee
Subject: [RPRWG] Minutes of today's adhoc



All,
Minutes follow.
DVJ
David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
      +1.650.856.9801
Cell: +1.650.954.6906
Fax:  +1.360.242.5508
Base: dvj@xxxxxxxxxxxx
Minutes of Fairness AdHoc
**** Note: Please contact DVJ is you would like to continue
**** receiving these minutes, since the distribution list
**** may be pruned in the future
**** Preliminary, not yet refiewed by attending members ****
Date: Wednesday, June 11, 2003
Start Time: 9:00:00 AM Pacific Daylight Time
End Time: 11:00:00 AM Pacific Daylight Time
          (although we have phone lines till 11:55)
Dial-in Number: 1-702-835-5000 (Las Vegas, Nevada)
Participant Access Code: 80217611
Attending:
  David James: dvj@xxxxxxxxxxxx
  Necdet Uzun: nuzun@xxxxxxxxx
Known interest:
  John Lemon: JLemon@xxxxxxxxxxxx
  Stein Gjessing: steing@xxxxxxxxx
  Jon Schuringa: jon.schuringa@xxxxxxxxxxxx
Preliminary agenda:
* Survey of attendees: areas of concern
* Normalized external behaviors
  (fairRate= fractionLinkRate/weight)
* Upstream classC shaper behaviors.
* Upper class traffic interactions
  (is classA _really_ guaranteed?)
* Well defined interface
  (conservative and aggressive as 2 examples)


Concerns were first addressed, yielding the following:
  * (Necdet) Any change may have impact on the protocols
    be sure that nothing is broken by the change
  * (Necdet) We do not want to see silicon change
  * (DVJ) Upper class traffic guarantees should be ensured
  * (all) Computable/verifiable
    - MAX_JITTER (currently not well specified)
    - A station's sustainable classA1 add traffic
      based on that station's STQ size and other
      fairness parameters that may affect it)
    - A station's sustainable classB add traffic
      Necdet: based on that station's STQ size
        and other fairness parameters that may affect it.
      DVJ: should be up to (LINK_RATE-classA)
  * Decouple algorithm from implementation details
  * Normalize to link rate, the external published parameters
Constraints were addressed; we agreed that constraints would include:
  * Use only the hop-by-hop fairness message with current content,
    but could expand to define some reserved values as needed.



First topic (since it seemed easy) was normalization of advertised values
* Goals (somewhat conflicting):
  - Normalization of fairRate  (65535==FULL_SCALE) and external-visible
values
  - Internal values need not be normalized; these are not visible to others.
  - The goal is to specify the time constants, not the implementation HW.
  - (DVJ) Normalization should specify a minimum accuracy
  - (Necdet) Normalization should facilitate simple HW
    multiplies are easiest if by a power of two
* Concept of normalization factors
  - The value of 1.0 corresponds to LINK_RATE
* Possible implementation examples (we didn't get to these in detail):
  // Higher-rate interval is currently 100us
  // Lower-rate interval is currently 400us
  // Maximum is all that needs be specified
  // Should be extensible to higher and lower link rates
  byteAverage= bytesInAgingInterval*(1.0/bytePerAgingInterval);  //
Currently 100us and 400us
  // Computed once each byteAverage interval
  time0Average= time0Average -
(time0Average-byteAverage)*filter0Coefficient;
  // Computed once each TBD interval (or more frequently)
  // Distributed once each advertisement interval
  time1Average= time1Average -
(time1Average-byteAverage)*filter1Coefficient;
  // With implementation illustration of:
  time1Average= time1Average -
(time1Average-time0Average)*filter2Coefficient;
* We tabled this in favor of discussing service guarantees


Service guarantees:
ClassA0 guarantees
  These appear to work, is the STQ never overflows, assuming uniform
allocation
  (although DVJ may need more reflection time).
ClassA1 guarantees:
  * We agreed that 64 (i.e. many) upstream stations with partially full STQs
    can happen and has to be addressed.
  * (DVJ) Not sure this has any solution that provides gurantees
  * The downstream station buffer need to be large enough
    to hold the cumulative traffic from all upstream stations.
    For N=64 upstream stations effectively reduces classA1 capacity
    of a given STQ size by a significant factor, perhps 64 for
    a fixed size of STQ
  * (DVJ) I belive that some (myself included) felt that the
    presence of additional STQs could only help (not hinder)
    the amount of supportable classA1. That is why it has not
    been included in the equations for MAX_JITTER.
  * (DVJ) This also severely restricte the low-limit thresholds
    for N (many) stations, to lesss than 1/N of the STQ.
ClassB guarantees:
  * (DVJ) The assumption was that classB= (LINK_RATE-classA) is
    the upper bound, from my perspective.
  * (Necdet) The sum of (classA1+classB) supportable levels is
    based on the size of STQ.
**** The difference between the previous two perceptions needs
**** broader review! The second interpretation could imply that
**** single-queue designs cannot support _any_ classB, which
**** may not be what some in the working group have expected.


Would be nice if added stations did not reduce classA1 capacity
  * (DVJ) Communicate level of STQ filling to upstream stations
    Upstream stations back-off their STQ retransmissions until
    their STQ has reached a comparable level.
  * (Necdet) They tried something like this previously.
    The affect of equality of fairness appeared in simulations
    Any solution should consider the concern that an
    upstream or downstream stations could have have an advantage
      This apparently was a concern even in the presence of
      constant classA1 traffic
AhHoc chair and scribe,
DVJ