| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
We've had this discussion in the past and it gets ignored or over
ridden at the next meeting, but I'll put it forward one last time.
What we've proposed for #1 below is either too little to be useful and
would violate #3 if it were modified to actually perform a useful
funciton. The current proposal performs static rate limiting at layer 2 by throttling the IPG to reduce all traffic being transmitted from the MAC based on an undefined congestion signaling mechanism. A computer connects to a network, which means it communicates with more than one device up stream. If the WAN device throttles my 1GB Ethernet MAC back to 500K I'd be rather disappointed with performance on connections to my printer, and media center. Unfortunately, as simple and benign as this proposal seems, in reality, static rate limiting is only useful if it is done on a, per connection or per session basis. Any given layer 2 connection has many of these. In fact the problem is that the number is un-bounded. Since Layer 3 is where connections, and sessions are established, the only logical place for a static rate limiting mechanism to exist is above layer 3, NOT IN THE MAC! Unless of course you want to violate objective #3 below. Need I remind us all that the ATM guys tried this and lost to Ethernet when it came to cost, complexity and scalability. The problem is that there are folks with diverse needs who want to have a congestion management funciton over Ethernet. One, all encompasing layer 2 solution won't fit all of their needs. What we could be doing, is defining some primitive MAC layer functions that would facilitate a variety of fabric management solutions that could be implemented on top of Ethernet. If we bother to look at the needs of those who've come to meetings in the past, it would be obvious that they need session/connection level rate limiting and we simply can't do this at layer 2 in Ethernet without it becoming something more like ATM, PCI-Express, etc.. I'd propose that we discuss how the MAC can help with the following: 1. Supporting in band congestion signaling ( pushing congestion messages to the head of queue) 2. Link utilization threshold alarms There's complexity in what I've just proposed above as well. The MAC layer at best, can only expect to communicate primitive status to a higher layer management agent. We need to keep any mechanism we propose simple, such that it doesn't add to cost, complexity or latency. This can be done, but not without involving (or God forbid even embracing) other standards out of the purview of the IEEE, and there in lies our problem. If we want to blissfully believe that throtting all traffic from a MAC layer solves our problem, we can claim success and move forward, in spite of the fact that we have no idea what the actual mechanism is that will be controling this feature. On the other hand are we truly putting the necessary rigor into this standard by doing so? -m.hathaway Kevin Daines wrote:
-- Michael Hathaway Pico Innovations Voice: 512-327-9563 Fax: 877-408-0059 Email: mhathaway@picoinnovations.com |