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