[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.
1) Not a PHY layer solution.
a. 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.
b. 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. 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.
2) Jitters the downstream packets
a. 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.
b. The MAC layer solution doesn't provide this function so there are a few issues. 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.
c. 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.
d. Obviously performance monitoring protocols that work above the MAC will not work.
3) GATE frame will break up the shuffled blocks of packets.
a. 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.
b. 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.
c. 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.
d. If the GATE waits for its MMP block to come up, it will increase the RTT time for REPORT to GATE.
4) Small Pipes have long delays or poor efficiency.
a. As mentioned in my PHY solution, small pipes are inefficient or have long delays to support packet re-ordering.
b. 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.
c. If the pipe is 50% of the BW and delay is constant, the overhead for the FEC would be doubled.
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: 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: image005]<http://www.linkedin.com/company/broadcom>[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image002]<http://twitter.com/#!/broadcom>[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: image004]<https://plus.google.com/109188783526874806673/posts#109188783526874806673/posts>[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: image008]<http://blog.broadcom.com/>[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image007]<http://broadcom.com/>
________________________________________________________________________
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
