[RPRWG] Minutes of today's 2nd fairness adhoc

["David V James" <dvj@xxxxxxxxxxxx>]

**** Minutes of Fairness AdHoc ****

Todays meeting:

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 taken by DVJ


Next meeting:

Date: Wednesday, June 25, 2003 
Start Time: 10:00:00 AM Pacific Daylight Time 
End Time: 12:55:00 PM Pacific Daylight Time 
Parties: 15 
Dial-in Number: 1-702-835-5000 (Las Vegas, Nevada) 
Participant Access Code: 8021725 
 

Please let DVJ know if you want to be added to the
adhoc interest list. In the near future,
mailings will be limited to this list.
Current subscribers include:

   Leon Bruckman       leonb@xxxxxxxxxxxxx
   Stein Gjessing:     steing@xxxxxxxxx
   David James:        dvj@xxxxxxxxxxxx
   Kshitij Kumar       kkumar@xxxxxxxxxxxxxx
   John Lemon:         JLemon@xxxxxxxxxxxx
   Robert D. Love      rdlove@xxxxxxxx
   K. K. Ramakrishnan  kkrama@xxxxxxxxxxxxxxxx
   Yan Robichaud       yan@xxxxxxxxxxxxxxx
   Jon Schuringa:      jon.schuringa@xxxxxxxxxxxx
   Necdet Uzun:        nuzun@xxxxxxxxx

Attending:
   David James:        dvj@xxxxxxxxxxxx
   John Lemon:         JLemon@xxxxxxxxxxxx
   Stein Gjessing:     steing@xxxxxxxxx
   Jon Schuringa:      jon.schuringa@xxxxxxxxxxxx
   K. K. Ramakrishnan  kkrama@xxxxxxxxxxxxxxxx

Stein mentioned that the following may be of higher
level interest, since they related to Ethernet guarantees:
  RFC: 2814, 2816*

We deferred normalization of values in favor of discussing
the bandwidth guarantees.

On the topic of subclassA0.
  DVJ noted there was a problem.
  Jon noted there was not a problem.
  After discussion, Jon agreed there could be a problem.
  The concern is accumulated upstream traffic:
    250 upstream stations
    Use the basic STQ assumptions: hi=1/4 and lo=1/8
    Cumulative STQ traffic could block downstream
      single-queue station, for a long time, perhaps
      as large as (256*STQ*1/8)==>32*STQ.
  The solution could be:
    Use the downstream shaper to shape STQ&add traffic
  John Lemon noted that concrete scenario would help
    others to understand if this was indeed a problem.
Action items:
  DVJ,Stein,Jon to coolaborate on scenario
  Stein&Jon to coolaborate on simulation
  

On the topic of subclassA1.
  What is the supportable level of A1?
  KK: Use the basic STQ assumptions: hi=1/4 and lo=1/8
  The rationale is that 3/4 of the STQ is available.
  KK: rateA1<= (3/4*STQ)/FRTT; // Where FRTT is RTT
  Possibilities:
  - With STQ-depth based upstream throttle, support large
    levels of classA1 (and more STQs make it better)
  - Accept low levels of classA1 supportable traffic
    (and more STQs make it worse)
  Action items:
  - DVJ to make STQ-backpressure proposals in more detail
  - Jon to look at KK's presentation (Montreal, kkr_inter_01.ppt)
  - KK to make a tentative ballot comment proposal

John Lemon and KK left for 11:00 commitments
DVJ, Jon, & Stein continued the discussions:

On the topic of supportable classB levels.
  Jon--current spec mandates (classB+classA1)<stqCapacity
       ==>single queue station can support no classB
       ==>an STQ capacity of 5% of the link rate appears
          to restrict classA1 _and_ classB levels
  DVJ--the only classB capacity constraint should be:
       classB < (LINK_RATE-classA)

We toyed with the idea that classB would have to backoff
as the STQ fills, but perhaps at a higher depth than classC.
  Stein--the STQ is really there for classA1 guarantees,
         so this would subtract from this purpose.
  DVJ--this wouldn't work for single-queue stations.

So, some other form of classB backpressure is desired,
perhaps based on some "overriding" type of fairRate
distribution.

DVJ