| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
All, (Arthur, I don't mean to pick on you but your message gives me a good excuse for bringing this up!) I'm very happy to see this amount of discussion on these topics. In addition to considering the kinds of rate limiting you'd like to see, please also consider how these changes might be worded in the 802.3 standard. Would they impact Clause 4 / Annex 4A in a fashion similar to the way ifsStretch impacted Clause 4 or in another new way? Would they impact the RS/PHY below the MAC? Would there be a new Annex 31C? Would we create another MAC sublayer to be inserted above or below the MAC Control sublayer? How would this new sublayer play with the OAM and Link Aggregation sublayers? Adding functionality to a single implementation is very different from modifying the standard in a way that doesn't imply any particular implementation. Good luck! Ben Arthur Marris wrote: Hugh, I would be happy to review and comment on your presentation. I have implemented a solution for limited bit rate. I believe the best way to do this is to define two 8 bit parameters to control the IPG. The first is multiplied with the length of the previously transmitted frame and the second plus 1 is divided with its length to produce the IPG. The plus 1 is to prevent a divide by zero. This meets both Pat's requirement to fractionally increase the frame size based on data length and the requirement to slow down traffic more substantially. Using 8 bits for each parameter allows the rate to be slowed down by up to a factor of 255 with a granularity of 1/256. Also this is easy to implement. Arthur Marris Cadence Design Foundry UK Limited The Alba Campus Livingston, UK, EH54 7HH +44 (0)1506 595104 (desk) +44 (0)7901 855100 (cell) -----Original Message----- From: owner-stds-802-3-cm@listserv.ieee.org [mailto:owner-stds-802-3-cm@listserv.ieee.org] On Behalf Of Pat Thaler Sent: Thursday, December 09, 2004 10:47 PM To: STDS-802-3-CM@listserv.ieee.org Subject: Re: [8023-CMSG] Technical proposals Hugh, There is also the case of lumpy per data overhead - cases where there is x overhead added to a packet per every y bytes. An example would be adding FEC protection at the physical layer to packets as EPON does. It is different from limited bit rate because there is extra overhead when the packet isn't a multiple of y. If we are willing to accept a solution that has a small lost throughput cost this could be handled by allowing the constant per packet overhead and limited bit rate modes to be used in together. Regards, Pat -----Original Message----- From: owner-stds-802-3-cm@listserv.ieee.org [mailto:owner-stds-802-3-cm@listserv.ieee.org]On Behalf Of Hugh Barrass Sent: Thursday, 09 December, 2004 11:28 AM To: STDS-802-3-CM@listserv.ieee.org Subject: Re: [8023-CMSG] Technical proposals Ben & Peter, This was a very important point that I was planning to raise in January (if I get the chance :-) I consider that there are 3 distinct types of static rate limiting that we should consider. We may decide to support only 1 or 2 of them but I think it is important to consider all 3 carefully before we make a decision: 1. Constant (per packet) overhead. This is the same as the applications that Kevin (daines_cmsg_1_0409.pdf) outlined where a tag or encapsulation is added to each packet. This requires that the MAC control layer should force a larger minimum IPG between all packets transmitted. 2. Limited (payload) bit rate. This is the situation with where a media convertor is dealing with a medium that doesn't support the "power of 10" speeds that are traditional for (most) Ethernet interfaces. Examples of this might be Ethernet over DSL (including EFM) or Ethernet over SONET. Another class of application for this rate limiting would be Network Interface Cards that have limited bus bandwidth into the host system (this was the example that I drew in barrass_1_0704.pdf slide 26). In this case the MAC control layer would adjust the IPG in a manner dependent on the packet length. 3. Limited packet rate. This application has not been proposed or considered as yet but may be worth including. This rate limiting mechanism would be used to protect a device that is unable to process packet headers at the full line rate possible. This may be because it is unable to perform address lookup or packet classification or may be due to another reason altogether. A MAC control layer could easily implement this type of rate control. I suggest that we could define all three types of rate control although a "smart" definition should allow "non optimal" implementations to sacrifice corner case performance to reduce complexity. If I get the go ahead, I will prepare a presentation and I would welcome assistance with reviewing and modifying it prior to the meeting. Hugh. Benjamin Brown 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???) ----------------------------------------- |