Point/Counterpoint on Queue State Management November 2001 Point/Counterpoint on Queue State Management John Kowalski, Srini Kandala, Shugong Xu, Satoshi Terada, Minoru Takemoto, Yoshihiro Ohtani Sharp John Kowalski, et.al., Sharp

November 2001 Background We at Sharp have considered the Queue State Management vs. MAC signaling for TSPEC. We want a spec that is useful now AND can have a long, happy, productive life. So, here’s the argument, and our conclusions. John Kowalski, et.al., Sharp

Points/Counterpoints (1) November 2001 Points/Counterpoints (1) Queue State management does not, at present, provide a way to signal some L2 dependent parameters. However: All things being equal and there is a mechanism to transfer all necessary L2 parameters, then the 2 methods would be functionally the same. John Kowalski, et.al., Sharp

Points/Counterpoints (2) November 2001 Points/Counterpoints (2) We have MAC signaling now, and it’s complete enough (with added signaling being presented this week) for our purposes. We have it NOW and L3 signaling would have to be explicitly defined for AV and other non-internet applications= DELAY IN STANDARDIZATION. John Kowalski, et.al., Sharp

Points/Counterpoints (3) November 2001 Points/Counterpoints (3) We still Need some mechanism to signal delayed ACK/FEC from higher layers-regardless of method. But the MAC signaling exists right now. RSVP is an OPTIONAL part IPv6, and not widely deployed. John Kowalski, et.al., Sharp

Conclusions  TSPEC is here, functionally equivalent and November 2001 Conclusions  TSPEC is here, functionally equivalent and can be easily adapted to any higher layer signaling. More Definition is better than less!  John Kowalski, et.al., Sharp