Yong,
My understanding is as follows:
When a number of nodes have
simultaneous frames to transmit, all but at most one will succeed without
virtual non-destructive collision in PLCA, and deferred collided nodes will
contend retry, and all but one in the subsequent transmit opportunity will succeed by
transmitting uncontested into their own timeslot, again a virtual COL being used to force
deferral backoff and CRS being used to force deferral of transmission to the uncontested timeslot.
Reminder that all RX must be is delimited with a gap (both CRS and RXEN
if you will, inactive). Retry {0, or 1} slot time selection (for the first and only PLCA retry) does not matter, because
any TX without COL on the bus will result in timer expiration with 1 x slot-time
CRS continues after the virtual collision ends in order to cause collided nodes to defer until their timeslot arrives.
Nodes have at most one virtual collision, and one retry, where the first retry always succeeds.
Regards,
David D. Brandt
Senior Principal Engineer
Rockwell Automation - Advanced Technology
1201 South Second Street
Milwaukee, WI 53204-2496
414.382.4309
From: Yong Kim [mailto:yongkim.mail@xxxxxxxxx]
Sent: Wednesday, April 18, 2018 9:22 AM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_10SPE] CSMA/CD and PLCA interaction next steps
WRT to
Regarding your point 1:
"CSMA/CD MAC but with the random back-off parameter limited to always {0, 1}. No changes to MAC, except for the MAC parameter table, because these are all parameterized."
Antonio> This is not a requirement needed for PLCA, standard MACs are fine as they are.
PLCA way of work is enough to guarantee that MAC will back-off at maximum once.
YK> I will not belabor this point of disagreement again. Let's say we disagree, and the facts will clarify any confusion, misunderstanding, etc.
Regarding your point21:
"16 collision retry means max # of stations to be 16"
Antonio> With “# of stations” you mean the number of nodes? In this case there is no relationship between MAC collision retry and max number of stations.
YK>
IF you accept my assertion (so must ignore the disagreement above), THEN,
When a number of nodes have frame to transmit, all but one will succeed without collision in PLCA, and deferred nodes will contend, and all but one in the subsequent transmit
opportunity will succeed, again COL being used to force deferral. Reminder that all RX must be delimited with a gap (both CRS and RXEN if you will, inactive). Retry {0, or 1} selection does not matter, because any TX without COL on the bus will result in
timer expiration with 1 x slot-time. So incidentally # of stations that could always have tx opportunity with the same queued packet is related to # of retry. <== my opinion is that this is the best one could do without changing CSMA/CD MAC. Jury is out
whether changing MAC parameter table (as I suggested) would be acceptable, i.e. no change to the MAC.
Yong Kim, affiliation: NIO
On Wed, Apr 18, 2018 at 3:14 AM, Antonio Orzelli <antonio.orzelli@xxxxxxxxxxxxxx> wrote:
Hello Yong Kim,
Regarding your point 1:
"CSMA/CD MAC but with the random back-off parameter limited to always {0, 1}. No changes to MAC, except for the MAC parameter table, because these are all parameterized."
This is not a requirement needed for PLCA, standard MACs are fine as they are.
PLCA way of work is enough to guarantee that MAC will back-off at maximum once.
"16 collision retry means max # of stations to be 16"
With “# of stations” you mean the number of nodes? In this case there is no relationship between MAC collision retry and max number of stations.
Regards,
Antonio Orzelli
Yong, thanks for the clarification. I wasn’t sure what you meant on #1 – that whole discussion of ‘system’ had me thinking you were blurring the MAC/PHY lines, and I have to think
about a mod to the MAC parameter table in a PHY project. (if you have thoughts on this, contact me offline). My comments on scope were relevant to at least #2 and #3.
-george
From: Yong Kim [mailto:yongkim.mail@xxxxxxxxx]
Sent: Monday, April 16, 2018 2:33 PM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Cc: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_10SPE] CSMA/CD and PLCA interaction next steps
I think my inconsistent use of delimiters (numbering) caused some confusion.
Three choices that I outlined.
1. CSMA/CD MAC but with the random back-off parameter limited to always {0, 1}. No changes to MAC, except for the MAC parameter table, because
these are all parameterized. PLCA changes (minor, already suggested by the contributor) to introduce a small delay and a gap on RX. I don't believe there needs any other changes. 16 collision retry means max # of stations to be 16.
2. EPON-like P2MP, and this would NOT be covered by current PAR -- my suggestion was to move PLCA access control function (so significant change
to current proposal) to MAC control sublayer. No detail nor proposal nor any victim/contributor on the table.
3. 802.11 CSMA/CA MAC -- with 802.3cg PHY, conceptually. Would work. Would not be 802.3 project as George pointed out.
Yong Kim, affiliation: NIO
On Mon, Apr 16, 2018 at 1:46 PM, George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> wrote:
Before we get too deep into this, I need to remind everyone of scope. (I think Yong understands this well, and intends properly – just trying to gauge interest). 802.3cg is an
802.3 PHY project. This means that we need to stay at the PHY layer (which includes the stretch to the Reconciliation Sublayer), but stop short of the MAC.
This means, as we discussed early on that multidrop needed to live with the 802.3 MAC.
As we discussed at earlier stages of our project, within 802.3 we have the CSMA/CD MAC, half-duplex and full-duplex (which is often not even discussed as CSMA/CD anymore), and the
variation known as EPON. For information on EPON, please see the excellent discussion Marek gave us at
http://www.ieee802.org/3/10SPE/public/adhoc/Multiaccess%20in%20Ethernet%20Passive%20Optical%20Networks.pdf . I believe the general consensus was that the EPON MAC was more complexity than our applications would bear – however, it appears Yong disagrees
with this. We adopted the Reconciliation Sublayer known as PLCA to address some of the issues with just raw half-duplex CSMA/CD.
I would like to emphasize that we are at a point in our project where we are reasonably close to a working group ballot. We have adopted baselines. Please try to be specific (and
actionable) when you make suggestions, and try to keep them in scope.
Discussions of an 802.11 MAC or 802.11-like MAC or modifications to the 802.3 MAC would be outside our scope. Please take them offline to Yong.
-george
George Zimmerman, Ph.D.
Chair, IEEE P802.3cg 10 Mb/s Single Twisted Pair Ethernet Task Force
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications
george@xxxxxxxxxxxxxxxxxxxx
310-920-3860
From: Yong Kim [mailto:yongkim.mail@xxxxxxxxx]
Sent: Monday, April 16, 2018 1:12 PM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: [802.3_10SPE] CSMA/CD and PLCA interaction next steps
Hi all to those attended April 11 ad hoc.
So I moved on to looking at what may satisfy my concern.
And if you are still on disagreeing with my concern, this message would not be relevant to you.
1. RX good while TX with COL. And while you are at it, RX [from other nodes, so more of "full-duplex" like operation] while TX with or without
COL. <== CL4 and CL2 is COMPLETELY consistent with this, BUT my assertion is that this is not guaranteed (understatement) with broad set of installed base.
Discussion: If we could distinguish this CSMA/CD 10 Mbps *SYSTEM* that is to be used with PLCA from the legacy CSMA/CD 10 Mbps *SYSTEM*,
clearly enough, then we don't have any confusion WRT to PLCA PHY working with systems with old MAC. "System" is the keyword here, not "MAC". EPON has the respective MAC control sublayer and other sublayers, and when you see those, you know you need to augment
your system with Ethernet MAC with new capabilities. So the suggestion is to create new MAC parameter entry associated with this PLCA-like [set of] PHYs that has random back-off limit of 1, so MAC will retry up to 16 times (so hard limit of 16 nodes in PLCA
network) and always select between 0 and 1. This preserves the 1) intent of PLCA, which also eliminates capture effect 2) does not change the MAC (all nicely parameterized already.)
Oh, and we need to fix the inconsistencies in the standard in 802.1AC -- maintenance request.
Alternatively, EPON-like optimization would work just as well, and I do not believe will be too complex, and all of the PLCA (TDMA with a master)
objectives would be met and also provide clearer way to manage nodes AND provide additional access-priority related QoS.
And 3rd alternative would be to use 802.11 CSMA/CA access method with our PHY. The access method DOES work, has statistical access metrics well-studied,
and mature. I do not recommend this -- too high implementation cost relative to Ethernet MAC and you get little in deterministic access. There may be other options.
The intent of this message is to gather interests in the corrective next steps (i.e. MAC parameter method). Let me know (reply), or let us know
(reply-all). Thanks!
Yong Kim, affiliation: NIO
To unsubscribe from the STDS-802-3-10SPE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-10SPE&A=1
To unsubscribe from the STDS-802-3-10SPE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-10SPE&A=1
To unsubscribe from the STDS-802-3-10SPE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-10SPE&A=1
To unsubscribe from the STDS-802-3-10SPE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-10SPE&A=1
To unsubscribe from the STDS-802-3-10SPE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-10SPE&A=1
|