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