Gadi,
Rather than:
"Empower the
Ethernet frame tagged information, for improved congestion control
at L2 beyond MAC address."
maybe:
"Empower the
Ethernet standards with support for improved congestion control in 802.3 L2
subnets."
This avoids biasing the statement toward any
specific implementation.
Gary
-----Original
Message-----
From:
owner-stds-802-3-cm@listserv.ieee.org
[mailto:owner-stds-802-3-cm@listserv.ieee.org] On Behalf Of Gadi Lahat
Sent: Sunday, September 19, 2004
7:04 AM
To:
STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG]
Presentation feedback...
My comments are as
follows
I think this is a bit
extreme. For sure it is implemented. It is also part of products feature list .
I think you should add,
the future use of Ethernet in the backplane of switches.
consider adding something
along the line of
"Empower the
Ethernet frame tagged information, for improved congestion control
at L2 beyond MAC address. "
Thanks
Gadi
From: Booth, Bradley
[mailto:bradley.booth@INTEL.COM]
Sent: Friday, September 17, 2004
04:04
To:
STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG]
Presentation feedback...
Ben,
Here's an updated
presentation. Proposed objectives are at the end. I also rolled
Shimon's feedback into the proposed objectives. These objectives are
proposed as a replacement of the current set of objectives.
Again, feedback/support
is welcome.
Thanks,
Brad
From:
owner-stds-802-3-cm@listserv.ieee.org
[mailto:owner-stds-802-3-cm@listserv.ieee.org] On Behalf Of Benjamin Brown
Sent: Thursday, September 16, 2004
11:14 AM
To:
STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG]
Presentation feedback...
Brad,
Thanks for this presentation.
Perhaps the presentation lines up well with our objectives.
Slide 5 states that 802.3x isn't used because it acts on all flows
and removes control from the MAC Client. Our objectives
suggest a rate limiter, rather than an on/off switch, in the MAC
Control sublayer. While the rate limiter acts equally on all flows,
the MAC Client has not lost control. Data still moves so the MAC
Client can choose which packets to transmit. This results in the
rate limiter not actually acting on all flows but only those flows
that the MAC Client chooses to hold off while continuing to
transmit other flows.
Or...
Perhaps the presentation doesn't line up well with our objectives
because it suggests that there should only be a message passing
protocol created with no actual rate limiting mechanism built into
the link. This provides the MAC Client all the control so that it
doesn't rely on 802.3 at all, except to actually exchange the message
using the MA_CONTROL.request primitive in order to avoid
the data path delays through the upper layers.
Would you mind letting us know which direction you intended
this presentation to lean? Are you going to suggest a change to
our objectives or suggest some new ones? I'd hate to have someone
sign on to this presentation as a supporter thinking one way and
have others thinking differently.
Thanks,
Ben
Booth, Bradley wrote:
After
some of the discussion on the reflector in the last couple of days, I decided
to toss this presentation together for the September interim meeting. I'm
hoping that this articulates the issue and the value proposition a little
better. Feedback and support is greatly appreciated.
Thanks,
Brad
<<booth_1_0904_r0.2.ppt>>
--
-----------------------------------------
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???)
-----------------------------------------