David and All,
Long time ago I sent to the reflector a proposal to use LLC for
Congestion Management: LLC_CM.PDF.
I think you have to reconsider my proposal, because it 100% IEEE 802
and resolve the problem of the congestion management.
I have developed a complete, and extremely simple, network model, which
solve the problems of the current Ethernet and Internet, using a double
stack: TCP/IP and LLC/ETH to provide the network services, and using a
physical switching in the network nodes. The physical switching permits
to extend the link control through all the network, end to end, and do
the congestion management in cooperation between network nodes and
terminals. In my experience, there is no other way to do it.
This is described in a short article, that David already knows. I have
also a detailed description of the technique that I would like to share
with you. If you consider it interesting, I will prepare a presentation.
Best,
Jose Morales Barroso
jmb@ieee.org
David V James wrote:
Ben,
I think it is quite a stretch to take Hugh's proposal and begin
talking about ACK/NACK across a link in order to ensure
guaranteed delivery of frames.
Its a rather natural stretch for a bus designer, perhaps
closer to a yawn, but a certainly a stretch for a WAN designer.
the MAC Client can know if it is okay to withdraw a lower
priority request when a higher priority frame arrives.
We solved that in 802.17 by simply providing distinct
flow-control indications to the client, one for each class,
and passing a class parameter along with the frame.
Since the MAC-to-Client interface is all an abstraction,
anyway, this would seem to be a simpler approach.
The addition of guaranteed delivery to Ethernet, without
a well-defined problem to be solved,
I thought that was a well defined problem from the CM folks.
may add more complexity than many are willing to accept.
I don't think the problem is complexity: the 10G link has
_far_ more complexity, in gate count, power, Si area, etc.
That's based, of course, on the assumption of only on the
backplane or in the computer room. NACK/ACK doesn't perform
well on MANs and WANs, but the CM group seems to be more
computer-room centric in their concerns.
However, it is certainly a dramatic break from the past
Ethernet religions, as hence the "heretical" email title.
Much more likely to be done in another forum, where folks
are more experienced with backplanes. For example:
http://grouper.ieee.org/groups/msc/MSC_RBR/info.html
Respectfully,
DVJ
-----Original Message-----
From: owner-stds-802-3-cm@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-3-cm@LISTSERV.IEEE.ORG]On Behalf Of Benjamin Brown
Sent: Monday, May 16, 2005 5:26 PM
To: STDS-802-3-CM@LISTSERV.IEEE.ORG
Subject: Re: [8023-CMTF] Retry's on the link (some heretical thoughts)
Dr. James,
I think it is quite a stretch to take Hugh's proposal and begin
talking about ACK/NACK across a link in order to ensure
guaranteed delivery of frames.
The ACK/NACK that Hugh is referring to is between the
MAC and the MAC Client (e.g. inside a bridge) so that
the MAC Client can know if it is okay to withdraw a lower
priority request when a higher priority frame arrives. This
should certainly be allowed if the MAC hasn't started
processing the lower priority frame but the problem with
today's definition is that the MAC Client doesn't know
when the MAC has started. This addition can be used to
avoid adding multiple access points between the MAC
Client and the MAC.
Hugh's proposal seems sound and thoughtful, and will
be useful in patching up a long-standing issue between
these two abstractions. The addition of guaranteed
delivery to Ethernet, without a well-defined problem
to be solved, may add more complexity than many are
willing to accept.
Regards,
Ben
David V James wrote:
(This previously had a misleading subject line.
My appologies if you have received this twice.)
Larry,
Sorry, I wasn't very clear on the last email.
Thanks for the quick response; its helps to correct
my misspeaks early.
What I meant to describe was the activity on a full-duplex
Ethernet link, but I used the unfortunate PHY notation,
with unintended implications of buffers therein.
I intended to refer to the operation of:
1) Send your frame to the bridge.
2) Get back a NACK or ACK.
3) If a NACK is returned, then repeat from (1).
Of course, one wouldn't require ACK/NACK unless this
were desired to be a loss-less frame transmission.
This does indeed require some sort of staging buffer,
and possibly something to ensure the retry-after-NACK
success.
To constrain the staging buffer sizes, this is
mostly likely only applicable to the backplane
and/or computer room. Its also counter-productive
for most flows (I suspect), but possibly valuable
for critical controls and/or triggers in the
processor-cluster type of environments.
The staging buffer would be somewhere above the PHY.
I tend to prefer the MAC, but I suspect one could
also argue for the Client or a shim. For the moment,
I prefer to abstain from the "it goes here" arguments,
in favor of "does it work" or "does it help" emails.
The lossless benefits are not obtained with
bridge ports connecting to half-duplex or CSMACD
Ethernet, but nothing breaks and there aren't
too many of these.
Hope this helps clarify the intent.
Cheers,
DVJ
-----Original Message-----
From: Larry Rubin [mailto:larry.rubin@serverengines.com]
Sent: Monday, May 16, 2005 2:25 PM
To: 'David V James'; STDS-802-3-CM@LISTSERV.IEEE.ORG
Subject: RE: [8023-CMTF] May meeting materials uploaded
David,
If one were to speculate on the PHY handling ack/nack, then one might have
to also speculate on how much buffering is going on in the PHY.
-Larry
-----Original Message-----
From: owner-stds-802-3-cm@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-3-cm@LISTSERV.IEEE.ORG] On Behalf Of David V James
Sent: Monday, May 16, 2005 5:54 PM
To: STDS-802-3-CM@LISTSERV.IEEE.ORG
Subject: Re: [8023-CMTF] May meeting materials uploaded
Kevin (et. al.),
Its interesting that Hugh is considering ACK/NACK at the
MAC interface level.
One might speculate that is also appropriate at the
PHY-to-PHY level, rather than PAUSE. It then gives
the sender the options of sending other frames
(possibly even of the same priority), rather than
blocking when only one switch output queue becomes
full.
That's closer to the bus backplane model, and only
really useful within the backplane environment
(or possibly computer room, as long as the cable
is only a few frames long).
Probably works OK in that environment, though.
DVJ
-----Original Message-----
From: owner-stds-802-3-cm@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-3-cm@LISTSERV.IEEE.ORG]On Behalf Of Kevin Daines
Sent: Monday, May 16, 2005 1:39 PM
To: STDS-802-3-CM@LISTSERV.IEEE.ORG
Subject: [8023-CMTF] May meeting materials uploaded
All,
The materials for the 802.3ar Congestion Management Task Force May interim
meeting have been uploaded. The URL is included below for convenience:
http://www.ieee802.org/3/ar/public/0505/index.html
You will find that Hugh Barrass has submitted two presentations. In
addition, three presentations are included from last week's IEEE 802.1
interim meeting in Berlin. Hugh has been given permission by the respective
author's to present/review/highlight during our meeting in Austin.
As chair, I will structure the meeting so we spend the majority of time
trying to satisfy the TF objectives we've established and have committed to
802.3 WG we'd deliver on.
Hope to see you in Austin.
Kevin Daines
Chair, P802.3ar TF
--
-----------------------------------------
Benjamin Brown
178 Bear Hill Road
Chichester, NH 03258
603-491-0296 - Cell
603-798-4115 - Office
benjamin-dot-brown-at-ieee-dot-org
-----------------------------------------
|