Re: [8023-CMSG] Technical proposals
Hi,
Yes, it is a great idea to discuss this in next meeting.
I can volunteer to provide modeling data for these. (I have Excel
and Opnet model currently for #2 and #3 below).
About #1 below: Challenge is what packet size should be considered
for "large Min IPG". From data rate point of view, it should be
based on Maximum size packet (e.g. 1522). However, doing this
seriously affects small size packets (which may not cause the
constriction probably).
Hence the reason for #2 and #3?
I agree that #3 is a good requirement to consider.
Thanks,
- Manoj
-----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, December 09, 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
>
>