[RPRWG] Tomorrow's fairness adhoc
Fairness Adhoc:
A reminder of our next meeting, listed below:
Date: Wednesday, June 18, 2003
Start Time: 10:00:00 AM Pacific Daylight Time
End Time: 12:00:00 PM Pacific Daylight Time
(although reservation is good till 12:55)
Parties: 15
Dial-in Number: 1-702-835-5000 (Las Vegas, Nevada)
Participant Access Code: 8021717
Minutes of the last meeting are also attached.
Jon has agreed to present his material, clarifying
the problems he identified at the last meeting.
Unfortunately, Necdet is vacationing for the next
few weeks, so we will be absent his expertise.
From recent discussions, I believe this will show
problems listed below:
1) SubclassA0 -- to work, downstream shaper must also
be applied to the STQ entries. I recalled this
concern when talking with Jon.
2) SubclassA1 -- to be bounded by current equations,
shaper depth warnings must be transmitted upstream.
3) SubclassB -- to allow STQ-independent levels, some
form of upstream warning is also needed.
Please let me know if you want to be added to the
adhoc interest list. Contents currently include:
David James: dvj@xxxxxxxxxxxx
Necdet Uzun: nuzun@xxxxxxxxx
John Lemon: JLemon@xxxxxxxxxxxx
Stein Gjessing: steing@xxxxxxxxx
Jon Schuringa: jon.schuringa@xxxxxxxxxxxx
Robert D. Love rdlove@xxxxxxxx
Leon Bruckman leonb@xxxxxxxxxxxxx
Kshitij Kumar kkumar@xxxxxxxxxxxxxx
Yan Robichaud yan@xxxxxxxxxxxxxxx
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: David V James [mailto:dvj@xxxxxxxxxxxx]
>> Sent: Wednesday, June 11, 2003 11:15 AM
>> To: Rpr GroupOf Ieee
>> Subject: 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
>>
>>