Re: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
Marek,
Should we need to extend MPCP with new fields or messages a simple statement that reiterates that ONUs ignore these new fields (which are all reserved and specified to be ignored by all existing ONUs) covers your concern. If you built an ONU that claimed compliance and isn't should not be a problem that needs to be addressed by the Task Force.
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx
Director, Access R&D
919 418 4741
Raleigh, NC
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Monday, January 14, 2013 4:50 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
Hi Matt,
Thank you for answering the question.
I believe your reading to be quite dangerous, since it implies that existing equipment may become incompatible with the newly made changes. That is something that I believe nobody really wants and I am not sure everybody really understood the statements you quote below when the words were put on paper. Certainly, I'd vote against PAR if that is what was intended. Recall even that during the SG phase I presented a sketch of a potential draft outline (http://www.ieee802.org/3/epoc/public/jul12/hajduczenia_01_0712.pdf) and discussion at the time was geared towards a separate clause for MPCP, something that nobody disagreed at the time to (yes, I know it is not an approved beaseline and it is SG material only) and based on that understanding, my reading on what's in the PAR is different.
My understanding is that we take EPON as baseline and adapt it to operate over coax PHY. In the process, we extend MPCP as defined in EPON, to operate over coax PHY, but that adaptation essentially means that MPCP gets a new clause, its own place to live and be independent from EPON. This is my assumption. If during the process we discover that EPoC MPCP is a carbon copy of EPON MPCP, or changes could be localized into a clearly designated places, leaving no doubt as to what applies to EPON and what is EPoC specific, making changes to Clause 77 would be OK. However, my understanding is that we develop EPoC-specific MPCP clause in our future draft, and examine merger only and if possible.
I think interpreting the scope of this group to have an open mandate to go and make changes to spec that has been stable for a few years now is dangerous, at best, especially that there is just a small group of people involved in the development of original Clause 77 material.
Marek
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: Monday, 14 January, 2013 09:07 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
Marek,
A good (and fair) question.
I believe that the answer is that EPON MPCP is in scope (with restrictions), but that if we can restrict anything we do to the coax link (EPoC) that would be a good thing.
To come to that conclusion, I went back to the Objectives and the PAR to see if they would provide me with any guidance on the answer.
In the Objectives, it states that:
"Maintain compatibility with 1G-EPON and 10G-EPON, as currently defined in IEEE Std. 802.3 with minimal augmentation to MPCP and/or OAM if needed to support the new PHY."
Then in the PAR (section 5.2.b. Scope of the project), we have the following:
"It also extends the operation of Ethernet Passive Optical Networks (EPON) protocols, such as MultiPoint Control Protocol (MPCP) and Operation Administration and Management (OAM)."
In combination, I would take that to imply that if we need to make changes to MPCP in EPON (across the fiber link) to support what we're doing on the coax link (EPoC) that is okay (the PAR clearly puts this in scope), but only if whatever we do does not break compatibility with 1G and 10G devices sharing that optical port (the restriction from the Objectives). In other words, if we need to send a new message at the MAC Control Sublayer that is unique to EPoC over the fiber link we can, as long as it's not going to cause compatibility problems for any existing ONUs that might also be sharing that fiber link. Or if we need to modify an existing message we can, again only if it doesn't break the operation of existing devices.
Thanks.
Matt
From: Marek Hajduczenia <marek.hajduczenia@xxxxxxxxx<mailto:marek.hajduczenia@xxxxxxxxx>>
Date: Monday, January 14, 2013 11:55 AM
To: Matthew Schmitt <m.schmitt@xxxxxxxxxxxxx<mailto:m.schmitt@xxxxxxxxxxxxx>>, "STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>>
Subject: RE: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
Matt,
Just to clarity - are we talking about changing "EPON" MPCP, as defined in Clause 64 and Clause 77 or defining "EPoC" MPCP ? I already asked before, and got conflicting opinions from people
Marek
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: Monday, 14 January, 2013 06:53 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
Geoff,
I will agree that there is ambiguity in the term "minimal", as different people can very much interpret that in different ways. In fact, as one of the folks that worked on that language, it's worth pointing out that what I at least had in mind was actually "minimal necessary" -- in fact I probably said this verbally - although I didn't push to get it onto the page (so to speak). Regrettably it's become clear that not everyone saw it that way. Live and learn.
In the end, I believe that it will come down to whether or not we can convince 75% of the full 802.3 Working Group whether whatever changes the Task Force decides to make to MPCP - if any - constitute "minimal" or not. Only time will tell.
Thanks.
Matt
From: Geoff Thompson <thompson@xxxxxxxx<mailto:thompson@xxxxxxxx>>
Reply-To: "thompson@xxxxxxxx<mailto:thompson@xxxxxxxx>" <thompson@xxxxxxxx<mailto:thompson@xxxxxxxx>>
Date: Monday, January 14, 2013 11:06 AM
To: "STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>>
Subject: Re: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
Andrea-
What you claim is clear to you is not clear to me.
The CFI, PAR and 5 Criteria for EPoC were written and presented to 802.3 for approval on the basis that Ed lays out below.
Minimal augmentation means just that. Minimal.
Your opinion on that is not nearly as important as the collective opinion of 802.3 who will ultimately judge the draft against the currently approved PAR, 5 Criteria and Objectives.
If you want to do a project that is beyond the scope of the currently authorized project then I have no problem with that. The ways to do that are:
- to expand the scope of the PAR, readdress the 5 Criteria and get ia all approved by .3, 802 and the SASB
-OR-
- get a new PAR, 5 Criteria etc for the expansionist portion of EPoC and run it through the system.
Geoff
On 141//13 7:22 AM, Garavaglia, Andrea wrote:
Hi Ed,
Here the approved objective again, I believe it is obvious and clear to everybody that it is possible to apply changes to MPCP and OAM for CLT/CNU (coax part):
Maintain compatibility with 1G-EPON and 10G-EPON, as currently defined in IEEE Std. 802.3 with minimal augmentation to MPCP and/or OAM if needed to support the new PHY.
Thanks,
Andrea
From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]
Sent: Friday, January 11, 2013 18:24
To: Garavaglia, Andrea; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: MMP issues with the MAC Layer Solution
Hi Andrea,
This is where we continue to not agree. EPoC FDD is a PHY in my mind for the existing EPON MAC that exists in OLTs. It should not make changes above the PHY. There was the text about compatibility with 1G and 10G EPON. I'm saying that we can't make something compatible. I haven't come up with a way to make it compatible and I haven't seen anything that shows that it can be compatible.
Thanks,
Ed....
From: Garavaglia, Andrea [mailto:andreag@xxxxxxxxxxxxxxxx]
Sent: Friday, January 11, 2013 5:32 AM
To: Ed (Edward) Boyd; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: MMP issues with the MAC Layer Solution
Hi Ed,
Thanks for your reply, we try to address your questions/comments directly in the slides, so it is easier to discuss them - Nicola will present today during the call, let's try to have a constructive discussion.
Please allow me a couple of comments ahead: it is not intended from me to deny issues (sorry if I gave that impression), I am trying to address them instead showing how that can be overcome - I think it would be a pity to not even try to address them and I hope experts like you also contribute to the discussion in this spirit. In this regard, I believe it is beneficial to stick on the scope of the ad-hoc, which is about MMP in the coax portion of the network.
So we should not talk about MMP in OLT, rather MMP in CLT. Also we should not talk about channel bonding, TDD, etc., rather about MMP only.
Also we should not exclude MPCP augmentation for CLT/CNU, we should minimize them to make the system work - CLT is not a legacy OLT.
I hope we can both (all) agree on these points to profitably continue this discussion - thanks for your help.
Thanks,
Andrea
From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]<mailto:[mailto:ed.boyd@xxxxxxxxxxxx]>
Sent: Tuesday, January 08, 2013 19:27
To: Garavaglia, Andrea; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: MMP issues with the MAC Layer Solution
Andrea,
Thanks for the reply. We keep going back to the same issue and you continue to deny that they exist. The OLT needs new functionality defined for rate shaping and packet shuffling to use MMP. This functionality is not defined in the current devices and needs to be above the PHY. I don't see how you can argue against this point. It is a new EPON for EPoC. It is not just a PHY as promised. TDD, MMP, and packet bonding are not compatible with the current EPON above the XGMII.
The delay and jitter performance of the downstream is poor by adding the MMP and extremely poor if you add in the channel bonding that you propose. It requires two layers of buffering and packet sorting. I'm not sure how you meet the 3ms RTT jitter specification. Please show your proposed solution with the channel bonding so I can make sure that I understand it for the delay analysis.
&nbs p;
EPON is a single copy broadcast downstream. It is simple/fast and EPoC should be a coax PHY only below it. If an operator wants to get the last drop of efficiency on bad networks and they are willing to add complexity and delay for it, the DOCSIS 3.0/3.1 solution is a better fit.
Please see in-line below. Thanks.
Ed...
From: Garavaglia, Andrea [mailto:andreag@xxxxxxxxxxxxxxxx]<mailto:[mailto:andreag@xxxxxxxxxxxxxxxx]>
Sent: Tuesday, January 08, 2013 5:41 AM
To: Ed (Edward) Boyd; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: MMP issues with the MAC Layer Solution
Hi Ed,
Thanks for the summary.
Let's see if we can make a step forward in understanding better the concerns and how can they be addressed.
I inserted my feedback below, for further discussion.
Thanks,
Andrea
From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]
Sent: Tuesday, January 08, 2013 02:09
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: [802.3_EPOC] MMP issues with the MAC Layer Solution
Jorge, Duane, and All,
I have some concerns about reshuffling the packets in the MAC based on destination. Here are a few of the issues that I brought up at the last meeting.
Not a PHY layer solution.
It won't work with existing standard compliant EPON OLT MACs. I believe that this is out of scope for our project and it severely impacts the economic feasibility for EPoC.
[AG] I tend to agree that OLT is out of scope of this project; in fact we have CLT and CNU, and we cannot assume the CLT is an OLT.
That said, I fail to see why it should not work - in the example we have shown there is no change to 802.3 MAC and I cannot see any particular change in the MPCP parts either: simply the rate adaptation (which will be needed for coax and still have to be defined in details) will use different computation parameter based on the active profile(s). The function will be the same and will need to be parameterized anyway as the coax rate can be quite variable from case to case even with single profile.
[Ed] I don't understand your response. The solution proposed requires new OLT functionality and it is not compatible with existing OLTs. It doesn't matter where you define it outside of the PHY. It doesn't exist so it is not compatible and it requires additional define outside the scope of the project. EPON over Coax should leave EPON alone.
Higher layer solutions today assume point-to-point Ethernet with packet ordering happening at the bridging or routing layers. Having a packet reordering based on the destination of packets below the MAC with a variable delay goes against this direction.
[AG] In the solution we presented there is no reordering of packets, neither above nor below MAC. Simply the Multi-Point Transmission Controller apply a different algorithm (which I like to remind is as per today already proprietary and implementation dependent) when selecting which client to serve. This can be done by proper design of the scheduler which is listed in clause 77.2.1 ("The scheduling algorithm is implementation dependent, and is not specified for the case where multiple transmit requests happen at the same time."), and does not preclude any option and certainly allow an implementation to offer only single profile as well.
[Ed] In the current solution, the downstream MAC/PHY is a pass through device. There isn't shuffling of packets to group them. The shuffling is not reversed on the output so a packet is jitter. The scheduler has no definition and in fact, it does nothing. The proposed solution requires adding scheduler functionality that doesn't exist. It is not compatible for that reason.
The downstream right now looks exactly like point to point Ethernet. We shouldn't decrease the performance and break this model. It isn't perform like EPON or Ethernet. This is not fiber performance.
[AG] In term of throughput, I would see MMP closer to fiber performance than SMP, as in average a larger data rate will be available on the coax since there is no need to run at the speed of the slowest user. In term of latency/jitter there may be some small increase at application level based on the particular implementation of the algorithm and of the system parameters, but this is well below the target of the current PHY layer assumptions.
[Ed] The fiber has a fixed delay and data rate. This solution is not like Ethernet or EPON with QoS/packet ordering is handled at the higher layer. Shuffling and jittering packets in the MAC layer is a mess. The data rate is based on the amount of spectrum available and not the position of the modem in the network.
Jitters the downstream packets
For the MMP, I proposed a PHY layer solution with packet time stamping. I had the packet time stamping so packets would be in the same order at the CNU with a fixed delay.
The MAC layer solution doesn't provide this function so there are a few issues.
[AG] In the MAC solution the order of packet is not changed: at each CNU the same order will be received as transmitted. Also there is no jitter as all operations of selection of the MAC Client for transmission are made before MAC, in the Multi-Point Transmit controller - when a client is selected, its transmission will be enabled as today and no jitter is introduced - when the packet leaves the MAC, it reached the CNU counterpart after a fixed delay. Therefore there is no need to timestamp to support MMP in this solution.
[Ed] When you shuffle packets, the packets are jittered on the downstream. They do not enter and exit with the same delay. If you timestamp the packets and add a play out buffer at the output, you can remove the jitter. This adds delay but doesn't add the jitter.
Right now, the assumption is that there is almost 0 jitter in the downstream for the MEF 23H jitter specification (3ms RTT). I used the entire 3ms in my analysis for the upstream polling jitter and discovery windows. Any jitter in the downstream will require a higher upstream polling rate or violate the specification.
My analysis showed that a small pipe of 24MHz will have multiple milliseconds of delay and in the MAC solution, it is jitter. It is impossible to meet MEF23H for small pipes and the larger pipes will require higher upstream polling to make up for it.
[AG] As commented last meeting, if the pipe is very small, a single profile can be configured and used (in addition the parameters of the MMP implementation can also be tuned) - I believe 24 MHz is rather the exception than then rule for a system which is supposed to be running at speeds of 1 Gb/s and above. Question for MSO: are we expecting a lot of deployments using only such a small bandwidth or are these corner cases? Appropriate configuration applies in any case, so I cannot see this to be a real issue.
[Ed] As the pipe cuts in half, the efficiency is half or the delay is double. 24MHz is the smallest channel that we support and it shows that the solution isn't usable but it is going down on the way. Based on your channel bonding proposal, each of these channels would face this delay with its own shuffling logic so it is very messy.
Obviously performance monitoring protocols that work above the MAC will not work.
[AG] Could you explain why not? I expect a performance monitoring tool shall not assume how the system is implemented in the lower layers and shall actually work for various configurations and implementations.
[Ed] It is expected that the MAC/PHY has a fixed delay and performance. This solution varies the delay (by shuffling packets between stations) and data rate based on the other traffic. The priority of my traffic is not used to determine the order to the output.
GATE frame will break up the shuffled blocks of packets.
The scheduler in the OLT will send the GATE at the exact time that it should go out to decrease the RTT time to get the REPORT.
The scheduler is not aligned with the blocks of blocks out from the MAC so GATE frames will come out when another MMP block of packets is present.
[AG] According to the specification (see figure 77-4), the selection between GATE messages and data packets happens at the Control Multiplexer, which is in charge of prioritizing control frames (e.g. GATE) over data frames. In my understanding there is one instance of such control multiplexer for each MAC Client and whether a GATE or another frame is selected in there has nothing to do with the selection of the transmitting MAC Client itself by the multi-point transmit controller. Also the timing for the GATE messages is determined by the DBA agent, which is also proprietary and implementation dependent, I cannot see any issue in generating GATEs when they are needed, at most is a matter of optimizing proprietary algorithms to achieve better performance, something that should be done anyway.
Another short FEC termination will be needed for the GATE so the GATE frame can go out immediately. This will result in a lower efficiency based on the RATE of the upstream bursts. Based on the numbers in my presentation, it will significantly increase the data rate for GATE frames. Small bursts in the upstream are common with high data rate polling.
[AG] See above - all this is not needed, the control multiplexer still prioritize GATE messages over data and those are treated as any other frame of that profile.
If the GATE waits for its MMP block to come up, it will increase the RTT time for REPORT to GATE.
[AG] Maybe I am missing something here, but I do not see how this can be the case: to be able to send a REPORT, a GATE should first provide the CNU with corresponding grant - so the REPORT will be sent after getting the GATE and apart a possible delay of the very first message exchange when the CNU starts up, the RTT for REPORT to GATE (from XGMII at TX to XGMII at RX) remains the same and it is determined by the PHY processing and propagation time.
[Ed] I don't know how to explain this. The GATE frame comes out based on the scheduler. If it is not going in the MMP block that is currently going out, the MMP block needs to break up the FEC block or delay the GATE until the proper FEC block comes around. It is either very inefficient or it adds a millisecond or more to the schedulers delay to generate a GATE. This goes into the REPORT/GATE loop.
Small Pipes have long delays or poor efficiency.
As mentioned in my PHY solution, small pipes are inefficient or have long delays to support packet re-ordering.
If the pipe is 50% of the BW and the efficient is the same as a 1Gbps pipe, the delay for a block of packets would be doubled.
If the pipe is 50% of the BW and delay is constant, the overhead for the FEC would be doubled.
[AG] Again, the number of profiles and the choice to use one or more can be tuned accordingly, as well as the parameters of the MMP implementation can be properly selected. In our presentation we have shown examples of possible tuning and shown that the possible additional delay can be controlled.
[Ed] In short, we can't support MMP on smaller pipes.
Hope that helps as a starting point. I will try to be on the call at 6am. I can't imagine mixing this with the channel bonding proposal. The delay and jitter would be crazy and it would be very complex to implement. I think that the performance in the downstream shouldn't be compromised. Simple, cheap, fast, wide pipe is Ethernet.
Thanks,
Ed...
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: cid:image009.jpg@01CD505E.7B800DB0]
Edward Boyd | Sr Technical Director
Broadcom Corporation | (O) 707-792-9008 | (M) 707-478-1146
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image005]<http://www.linkedin.com/company/broadcom>[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image002]<http://twitter.com/#%21/broadcom>[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image003]<https://www.facebook.com/Broadcom>[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image004]<https://plus.google.com/109188783526874806673/posts#109188783526874806673/posts>[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image006]<https://www.youtube.com/user/BroadcomCorporation>[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image008]<http://blog.broadcom.com/>[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image007]<http://broadcom.com/>
________________________________
<="" p="">
________________________________
________________________________
<="" p="">
________________________________
________________________________
________________________________
<="" p="">
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
