Re: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
Jorge, Eugene, et al.,
I think we are going in circles with this discussion. We already had
discussion on OLT doing per LLID traffic shaping and such, reaching no
conclusions at the time, except for the fact that it would be hard to
guarantee that existing OLTs could support such function.
That said, we have to remember that within the scope of our project we
cannot really go and change the way EPON works, or change requirements for
existing devices. Our PAR does not allow us to do so . so we have to tread
very carefully here. The only device we could employ to do such functions
would be the FCU, and even this device has only coax side interfaces in the
scope of our work .
Marek
From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
Sent: Friday, 11 January, 2013 07:50 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
Eugene,
I don't follow the relevance of this remark. Can you elaborate for me?
If the OLT can rate limit on a per LLID basis (which is on a ONU/CNU basis),
why is this not a workable approach for MMP? In other words, if the OLT can
already limit traffic to a specific rate on a per-LLID basis, which can't
this be the basis for having different channel capacities per ONU/CNU? I
know you reference the rata adaptation as being the barrier, but given that
the OLT can already control the specific allocation of traffic per LLID why
can't the FCU adjust the transmission rate and compensate with the different
use of time on the wire by removing idles, or filtering unneeded packets,
etc.
Thanks!
Jorge
From: <Dai>, Eugene Dai <Eugene.Dai@xxxxxxx>
Reply-To: Eugene Dai <Eugene.Dai@xxxxxxx>
Date: Friday, January 11, 2013 2:10 PM
To: EPoC Task Force <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
Duane: PCS layer does not have LLID info.
Eugene Dai PhD
Principle Transport Architect
COX Communications
Tel: 404-269-8014
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Friday, January 11, 2013 2:07 PM
To: Dai, Eugene (CCI-Atlanta); STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Cc: Duane Remein
Subject: RE: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
Eugene,
I believe if you rate adapt at the LLID level then there will be no
problems. The PHY then needs to set-up the 3-4 profile allocations for the
symbol according to the LLID distribution in its buffer (I'm assuming any
implementation must buffer data for two symbols, the one being sent and the
next one to be sent). We then need a very small channel (the PHY-Link, which
already exists) to communicate the boundaries between the profiles; this is
only 3-4 bytes of data for each symbol.
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx
Director, Access R&D
919 418 4741
Raleigh, NC
From: Dai, Eugene (CCI-Atlanta) [mailto:Eugene.Dai@xxxxxxx]
Sent: Friday, January 11, 2013 12:50 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
We have shown that MMP is not technically feasible for FDD case, especially
when rate adaption is concerned although not limited in this. We also gave
our observations that in TDD case one may put one MP per burst that may make
the rate adaption problem less restrictive for TDD. However, this is just an
observation; I haven't seen any contribution studying MMP with TDD yet.
Eugene
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Friday, January 11, 2013 12:29 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
Ed,
To your point - in this case, we should have SMP for FDD system and may have
MMP for TDD system.
Marek
From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]
Sent: Friday, 11 January, 2013 05:24 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] 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
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]
Sent: Tuesday, January 08, 2013 19:27
To: Garavaglia, Andrea; 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.
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]
Sent: Tuesday, January 08, 2013 5:41 AM
To: Ed (Edward) Boyd; 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>
mailto:ed.boyd@xxxxxxxxxxxx]
Sent: Tuesday, January 08, 2013 02:09
To: <mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
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.
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.
[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.
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.
[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.
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.
[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.
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.
[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.
d. 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.
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.
[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.
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.
[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.
d. 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.
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.
[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:
image005Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
image002Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
image003Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
image004Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
image006Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
image008Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description: image007
_____
<="" p="">
_____
_____
<="" 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
