Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [8023-CMSG] Technical proposals



Ben,

    If opening Clause 4 is the right thing to do then I think this is the approach that should be taken.

 

    As you say there was difficulty in opening Clause 4 for P2MP in 802.3ah. I think this was because the originally drafted changes were deficient and MAC experts such as yourself were brought in too late in the standards making process.

 

   With 802.3ae Clause 4 was changed to accommodate IPG stretch in spite of widespread opposition to the WAN PHY. This was because the changes were properly drafted and no-one could question the expertise of the people bringing forward the changes. I think if the same people who were involved in the IPG stretch changes for 802.3ae were involved in similar changes for CM then I think they would get through 802.3.

 

Arthur.

 


From: owner-stds-802-3-cm@listserv.ieee.org [mailto:owner-stds-802-3-cm@listserv.ieee.org] On Behalf Of Benjamin Brown
Sent: Friday, December 10, 2004 4:54 PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Technical proposals

 


Arthur,

I'm not at all against your proposal - I suggested we do it this
way for 802.3ah but it didn't solve the P2MP problem and it
seemed that others were against it. That's the point I was trying
to make - opening Clause 4 may be the best place for this but
you may have a larger hurdle to jump; this clause is near and
dear to many of the "senior" members of this group. I'm not
saying it can't be done nor shouldn't be done, I just want everyone
to be aware of what they may be up against and to be very clean
about changes.

Ben

Arthur Marris wrote:

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
Sent: Friday, December 10, 2004 3:38 PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Technical proposals

 


Arthur,

Thanks for this. One comment though - 802.3ah chose to create a
new Annex 4A rather than clutter up Clause 4 with a generic ifsStretch.
This generic ifsStretch was part of 802.3ah for many of the early
drafts but as more people became aware of it, along with the realization
that it didn't solve the P2MP IPG issue, it was discarded. Feel free to
take a look at that, though. I was the author of it so I can try to explain
its intentions if desired.

Regards,
Ben

Arthur Marris wrote:

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
Sent: Friday, December 10, 2004 1:21 PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Technical proposals

 


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:
 
  
Peter,
 
I hope you don't mind that I opened your questions up
to the entire reflector. It helps me make an important
point.
 
Yes, I think that it is absolutely appropriate to consider
a solution for a pseudo-static rate limiter that accounts
for a difference in bit rate (e.g. 100M transmitting to 2M)
as well as a constant overhead (e.g. untagged transmitting
to tagged). Anything less than this would probably not
solve the problems of both of these kinds of networks.
 
Further, I advise participants that the Sacramento meeting
is indeed the appropriate time to bring technical proposals
for just such a solution. There is still plenty of time to put
some ideas on some slides. There is even time to start
sharing those ideas with other members of this task force
(yes, we're now a task force and no longer a study group)
to begin forming consensus. Consensus is what drives this
process and the responsibility for creating a consensus lies
entirely on the shoulders of every member of this task force.
The sooner we get proposals and start building consensus,
the sooner we can accept a baseline proposal, start writing
drafts and getting to the ballot process.
 
For now, I'll continue to be the repository for presentation
requests. I'll make sure that whoever stands in front of the
room in Sacramento is aware of your plans.
 
Regards,
Ben
 
Peter Jones wrote:
 
    
Benjamin,
 
I have a question based on what you said when you came to visit
802.17 (which is where I spend my time), and in conversation
      
afterwards.
  
It seems to me that are two main uses for the simple "rate limiting"
approach:
1)     a physical bit subrated link - e.g. only 45Mb/s on a 100Mb/s
link from a ethernet to DS3 media converter
2)     an encapsulating device - something that adds a fixed overhead
per packet like a provider bridge or a security device.
 
Do you think that these are both going to be addressed during the CM
work?
 
regards
peter
      
 
    
 
  

 

--
-----------------------------------------
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???)
-----------------------------------------

 

--
-----------------------------------------
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???)
-----------------------------------------



--
-----------------------------------------
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???)
-----------------------------------------