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

Re: [802.3_10SPE] CSMA/CD and PLCA interaction next steps



Hi David,

Yes your statement is one of major disagreement point, although I don't see anything virtual about COL signal sent to the local MAC.
"Nodes have at most one virtual collision, and one retry, where the first retry always succeeds."

best,

Yong.

best regards,

Yong Kim, affiliation: NIO

On Wed, Apr 18, 2018 at 11:34 AM, David D. Brandt <ddbrandt@xxxxxxxxxxxxxxx> wrote:

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@LISTSERV.IEEE.ORG
Subject: Re: [802.3_10SPE] CSMA/CD and PLCA interaction next steps

 

Hi Antonio,

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. 

best,

 

Yong.

 


best regards,

Yong Kim, affiliation: NIO

 

On Wed, Apr 18, 2018 at 3:14 AM, Antonio Orzelli <antonio.orzelli@canovatech.com> 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

 

From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Monday, April 16, 2018 11:37 PM
To: STDS-802-3-10SPE@LISTSERV.IEEE.ORG


Subject: Re: [802.3_10SPE] CSMA/CD and PLCA interaction next steps

 

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@listserv.ieee.org
Subject: Re: [802.3_10SPE] CSMA/CD and PLCA interaction next steps

 

Hi George,

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.


best regards,

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@LISTSERV.IEEE.ORG
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!


best regards,

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


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