[8023-CMTF] Retry's on the link (some heretical thoughts)
Title: Message
(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