| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Ben, If I remember correctly Annex 4A allows a full-duplex MAC to be rate controlled by means of deference using CRS. Please correct me if I have anything wrong.
The advantage of opening up Clause 4 is that you can directly control IPG to something based on frame size rather than doing it indirectly through CRS. Also there is no support for half-duplex in Annex 4A and I believe new MAC implementations will want to continue to support this.
I think the reluctance to open up Clause 4 for EPON was because the serious proposals to do this were made late in the 802.3ah standards making process and due to a lack of enthusiasm for EPON in the wider 802.3 group.
However I am open-minded about this and willing to be convinced that using Annex 4A would be better if you can put the case.
Arthur.
From:
owner-stds-802-3-cm@listserv.ieee.org
[mailto:owner-stds-802-3-cm@listserv.ieee.org] On Behalf Of Benjamin Brown
Ben, My assumption is that this would be a Clause 4 change similar to ifsStretch. This is where it belongs from the implementation and architecture point of view. There would be no impact to PHYs or the RS if it was done here. It could be made optional so as not to impact existing MAC implementations. Having a clean and generic way of controlling IPG for rate control seems a very useful feature. The need for this became apparent in both 802.3ae and 802.3ah.
Arthur.
From: owner-stds-802-3-cm@listserv.ieee.org
[mailto:owner-stds-802-3-cm@listserv.ieee.org]
On Behalf Of Benjamin Brown
Hugh, I would be happy to review and comment on your presentation. I have implemented a solution for limited bit rate. I believe thebest way to do this is to define two 8 bit parameters to control theIPG. The first is multiplied with the length of the previouslytransmitted frame and the second plus 1 is divided with its length toproduce the IPG. The plus 1 is to prevent a divide by zero. This meets both Pat's requirement to fractionally increase the framesize based on data length and the requirement to slow down traffic moresubstantially. Using 8 bits for each parameter allows the rate to beslowed down by up to a factor of 255 with a granularity of 1/256. Alsothis is easy to implement. Arthur MarrisCadence Design Foundry UK LimitedThe Alba CampusLivingston, 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 ThalerSent: Thursday, December 09, 2004 10:47 PMTo: STDS-802-3-CM@listserv.ieee.orgSubject: Re: [8023-CMSG] Technical proposals Hugh, There is also the case of lumpy per data overhead - cases where there isx overhead added to a packet per every y bytes. An example would beadding FEC protection at the physical layer to packets as EPON does. Itis different from limited bit rate because there is extra overhead whenthe packet isn't a multiple of y. If we are willing to accept a solutionthat has a small lost throughput cost this could be handled by allowingthe constant per packet overhead and limited bit rate modes to be usedin 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 BarrassSent: Thursday, 09 December, 2004 11:28 AMTo: STDS-802-3-CM@listserv.ieee.orgSubject: 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 thatwe should consider. We may decide to support only 1 or 2 of them but Ithink it is important to consider all 3 carefully before we make adecision: 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. Thisrequires that the MAC control layer should force a larger minimum IPGbetween all packets transmitted. 2. Limited (payload) bit rate. This is the situation with where a media convertor is dealing with amedium that doesn't support the "power of 10" speeds that aretraditional for (most) Ethernet interfaces. Examples of this might beEthernet over DSL (including EFM) or Ethernet over SONET. Another classof application for this rate limiting would be Network Interface Cardsthat have limited bus bandwidth into the host system (this was theexample that I drew in barrass_1_0704.pdf slide 26). In this case theMAC control layer would adjust the IPG in a manner dependent on thepacket length. 3. Limited packet rate. This application has not been proposed or considered as yet but may beworth including. This rate limiting mechanism would be used to protect adevice that is unable to process packet headers at the full line ratepossible. This may be because it is unable to perform address lookup orpacket classification or may be due to another reason altogether. A MACcontrol layer could easily implement this type of rate control. I suggest that we could define all three types of rate control althougha "smart" definition should allow "non optimal" implementations tosacrifice corner case performance to reduce complexity. If I get the go ahead, I will prepare a presentation and I would welcomeassistance with reviewing and modifying it prior to the meeting. Hugh. Benjamin Brown wrote:
afterwards.
-------------------------------------------Benjamin Brown178 Bear Hill RoadChichester, NH 03258603-491-0296 - Cell603-798-4115 - Officebenjamin-dot-brown-at-ieee-dot-org(Will this cut down on my spam???)-----------------------------------------
-------------------------------------------Benjamin Brown178 Bear Hill RoadChichester, NH 03258603-491-0296 - Cell603-798-4115 - Officebenjamin-dot-brown-at-ieee-dot-org(Will this cut down on my spam???)----------------------------------------- |