| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Brad, Thanks for this presentation. Perhaps the presentation lines up well with our objectives. Slide 5 states that 802.3x isn't used because it acts on all flows and removes control from the MAC Client. Our objectives suggest a rate limiter, rather than an on/off switch, in the MAC Control sublayer. While the rate limiter acts equally on all flows, the MAC Client has not lost control. Data still moves so the MAC Client can choose which packets to transmit. This results in the rate limiter not actually acting on all flows but only those flows that the MAC Client chooses to hold off while continuing to transmit other flows. Or... Perhaps the presentation doesn't line up well with our objectives because it suggests that there should only be a message passing protocol created with no actual rate limiting mechanism built into the link. This provides the MAC Client all the control so that it doesn't rely on 802.3 at all, except to actually exchange the message using the MA_CONTROL.request primitive in order to avoid the data path delays through the upper layers. Would you mind letting us know which direction you intended this presentation to lean? Are you going to suggest a change to our objectives or suggest some new ones? I'd hate to have someone sign on to this presentation as a supporter thinking one way and have others thinking differently. Thanks, Ben Booth, Bradley wrote:
-- ----------------------------------------- Benjamin Brown 178 Bear Hill Road Chichester, NH 03258 603-491-0296 - Cell 603-798-4115 - Office benjamin-dot-brown-at-ieee-dot-org (Will this cut down on my spam???) ----------------------------------------- |