Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[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 
-----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