(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
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
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
All,
The materials for the 802.3ar Congestion
Management Task Force May interim meeting have been uploaded. The URL
is included below for convenience:
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