Re: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
Marek,
Please see my response below.
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx
Director, Access R&D
919 418 4741
Raleigh, NC
-----Original Message-----
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Monday, January 14, 2013 1:45 PM
To: Duane Remein; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
Duane,
Let's not mix everything into a single batch, unless we want the cake to go
bad.
40G and 100G are multi-lane architectures, and I presented their overview
some time ago, including a potential for what "lane" can be when referring
to EPoC. If needed, we can have lanes, but there still is a point in the PCS
where processing will have to be done on an aggregate data stream, and not
on individual lanes. So you draw parallel too far in my opinion. Note that
40G / 100G does not look into data transmitted on each lane, but forwards it
with addition of FEC parity and markers, where needed. However, there is no
LLID hunting, complex processing, etc..., so these are far from being the
same.
DRR - I don't consider a < 400 gate Mux/demux "complex processing".
Next, as you know probably quite well, 1G-EPON and 10G-EPON are quite
different (not only in data rates) and what can be done in 1G-EPON
relatively painlessly, cannot be done in 10G-EPON without going into very
expensive electronics. There is a reason why FEC in 10G-EPON was
stream-based and not frame-based, and predictable performance was only one
of aspects of the decision taken. Thus drawing conclusions on EPoC from
1G-EPON is misplaced at best - we all know we cannot reuse 1G-EPON because
it does not provide necessary MAC rate to make EPoC future-proof enough.
DRR - not sure why your saying 1G-EPON uses "very expensive electronics" compared to 10G-EPON, perhaps you thinking of the frame based FEC buffering needed but no one has suggested anything similar to this. The point is that the PHY can easily be frame aware as it is in 1G-EPON.
Last, I'd like to see this "number of proposals". Neither of the ones I saw
so far is complete and all assume some sort of magic happens somewhere,
mostly in PCS, in one form or another. We cannot take a decision of this
magnitude on an incomplete proposal and hope for the best. This is something
I mentioned on the call before many times, and yet we (as a group) are being
pushed to take decision on faith and someone's beliefs. I am very
uncomfortable doing that, and I know that if pushed to a vote, I will not be
in favour of anything that puts extensive burden on the design complexity
without presenting the whole picture and at least conceptual implementation.
We do not need to select that particular implementation, but we need to have
reasonable confidence that what is being suggested is feasible without
running into complex and expensive solutions.
DRR - baselines are always adopted in pieces, EPoC will not be any different. We have yet to see a complete proposal for anything in EPoC but we have adopted some baseline proposals.
Marek
-----Original Message-----
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Monday, 14 January, 2013 06:31 PM
To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Cc: Duane Remein
Subject: RE: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
Marek,
Keep in mind that we're only talking about 4 different rates not some large
number.
On your item "d." about management. The way I would envision this working is
that the operator would provision up to 4 profiles available for use. The
PHY would discover which profile is usable for a given CNU (LLID) and pass
this information up to the upper layers. Placement in an LLID in a higher
performing profile (better than LCD) could be passed down from upper layers
or could be determined by the PHY and passed up.
On your question of how to separate different rate data stream I think a
number of proposals have been shown that suggest using LLID for this.
Certainly that is available at the RS layer to the PHY. Also from 1G EPON we
know that Ethernet frame boundaries are well known in the PHY given that the
1G-EPON PHY applies FEC to frames, not streams.
I would also like to observe that your statement "Multiple MAC instances all
connect to a single PHY and below XGMII there is a single data path" while
correct may be a little misleading. Both 100/40G each use multiple lanes,
admittedly for a single data path. But, I don't see a huge difference
between 10 lanes of 10G and 4 paths of something less than 10G. In fact it
might even be easier as we don't have to worry about skew in the 100's of
pico sec range that comes with a multi-lane PHY.
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx
Director, Access R&D
919 418 4741
Raleigh, NC
-----Original Message-----
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Monday, January 14, 2013 12:16 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
Jorge,
If I understand item [2] below correctly, what you inherently suggest is
that:
a. each MAC instance (see Figure 77–2) on the CLT operates at its own
specific data rate, be that a unicast, broadcast or multicast MAC.
b. broadcast profile would be shared by all CNUs connected to CLT port, just
like in EPON.
c. just like in EPON, we have one broadcast domain, i.e., all CNUs connected
to CLT port can receive on this profile
d. the modulation depth (and resulting data rate for the given MAC instance)
is fixed unless modified via management. We might need to figure out how
that data rate is established in the first place and how it plays with CLT -
CNU link capabilities, its discovery, etc.
Now, at the logical level that seems feasable, as long as we do not have to
enforce data rate across multiple LLIDs (e.g., single rate profile for
broadcast and unicast traffic, or other similar combinations). However, I am
concerned on how PCS is supposed to handle that. Multiple MAC instances all
connect to a single PHY and below XGMII there is a single data path. That
said, while individual data streams may exist with different effective
target rates, it is not clear to me how you suggest to separate individual
data streams for processing within PCS. Recall that each data stream would
require Idle Deletion function to operate at a different rate. Also, for
each profile FEC might be different as well. More, at the PCS level, we
cannot really rely on LLID information any more, since that would require
recovery of the frame structure after it has been passed through XGMII, or
alternatively some sort of lock hunting (with non-zero false lock
probability).
So while what you propose works fine above XGMII, the part that is most
interesting is not covered.
I can also imagine how it could be solved in PCS in TDD mode, where we have
time to switch from one data stream to another, but fail to see how that can
be done at 10G without any phase distortions or loss of data continuity
required for FDD mode. Perhaps I missed something, in which case I'd
appreciate a pointer.
Marek
-----Original Message-----
From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
Sent: Monday, 14 January, 2013 03:02 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
Ed,
Thanks!
Two follow-up questions:
1. OFDM inherently supports variable modulation rates. Regardless of the
discussion on MMP, I think that we would have to deal with a variable group
rate on the HFC side of the FCU. Or, do you think that we would have to
implement static modulation for the OFDM MCS?
2. The proposal for MMP that I am thinking of would not require that
modulation rates change except under command of the MSO. There would be a
maximum of 4 modulation rates in total, and a maximum of 2 modulation rates
used by each CNU, which would not change dynamically. Each CNU would use one
lowest common denominator (LDC) MCS for broadcast and multicast, and may use
an additional MCS for unicast traffic if the transmission media (i.e., SNR)
allowed it. So, for example, one CNU may have one LLID running the LCD at
256 QAM for broadcast and multicast and one LLID running at 1K QAM for
unicast, while another CNU might be running the same LCD LLID at 256 QAM but
the unicast LLID at 4K QAM, and a third CNU would run the LDC LLID and the
unicast LLID at 256 QAM. So, assuming that we implemented static assignments
of LLID modulation rates, would that be doable in your view?
Thanks!
Jorge
-----Original Message-----
From: Ed Boyd <ed.boyd@xxxxxxxxxxxx>
Date: Sunday, January 13, 2013 11:53 PM
To: "Salinger, Jorge" <Jorge_Salinger@xxxxxxxxxxxxxxxxx>
Cc: EPoC Task Force <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
>Jorge,
>
>I think that we have 2 threads here. Let me try to answer both.
>
>First, on the changes above the MAC. We can make changes that require
>additional software or configuration. These are minimal changes that
>allow existing standard compliant EPON devices to work over coax. A
>new channel bonding in the MAC, packet shuffling, or complex rate
>shaping is totally new hardware and makes unique solutions for EPON and
>EPoC. In my mind, a new above PHY solution does pass the 5 criteria
>and we don't support the project/standard.
>
>A strict rate limit per LLID and per FCU is easy to do on many systems.
>The variable group rate based on destination, packet order, different
>FEC sizes required for MMP is not possible without totally new hardware
>and I question that it is possible even then.
>
>Thanks
>Ed
>
>Sent from my iPhone
>
>On Jan 13, 2013, at 9:51 AM, "Salinger, Jorge"
><Jorge_Salinger@xxxxxxxxxxxxxxxxx> wrote:
>
>> Ed,
>>
>> Thanks! I appreciate the responses.
>>
>> In your note below you indicate that per-LLID rate limit or shaping
>>is available in EPON, but that per FCU shaping would be needed to
>>accommodate different rates to different CNUs within one FCU (did I
>>understand that right?).
>>
>> Assuming that's the case, in a separate Email thread you provide an
>>example for a different question on how that could be achieved. I
>>transcribed the example you provided below for reference, but here is
>>the important remark from your Email "a second layer of shaping is
>>added to limits all of the CNUs on a particular FCU to 1Gbps. Any one
>>of the CNUs can get a 1Gbps but the sum of their traffic won¹t exceed
1Gbps."
>>
>> So, if rate shaping could be applied per LLID and per FCU for the
>>collection of LLIDs served through that FCU, why is this not a
>>possible way in which MMP could be implemented?
>>
>> Thanks!
>> Jorge
>>
>> <<<transcript of example provided by Ed for a different Email
>> thread>>>
>>
>> Let¹s assume a 10Gbps PON feeding two FCUs with a 1Gbps Coax downstream
>>each. The CNU SLAs are limits set by the operator and the sum of all
>>of them greatly exceed the bandwidth of the coax. This is very common
>>for best effort traffic and sometimes for guaranteed. For example:
>>
>> FCU1-CNU 1: 100Mbps Guar + 1Gbps BE
>> FCU1-CNU 2: 100Mbps Guar + 1Gbps BE
>> FCU1-CNU 3: 100Mbps Guar + 1Gbps BE
>>
>> FCU2-CNU 3: 100Mbps Guar + 1Gbps BE
>> FCU2-CNU 4: 100Mbps Guar + 1Gbps BE
>> FCU2-CNU 5: 100Mbps Guar + 1Gbps BE
>>
>> For 1 Gbps coax, the SLAs are over 3Gbps so it will definitely
>>overflow both of the FCUs. To solve this issue, there must be a group
>>rate shaping limit. In this case, a second layer of shaping is added
>>to limits all of the CNUs on a particular FCU to 1Gbps. Any one of
>>the CNUs can get a 1Gbps but the sum of their traffic won¹t exceed 1Gbps.
>>As I mentioned in a previous email, it is possible to do this on many
>>but not all OLTs. In some cases, it might be handled by a switch on
>>the OLT PON blade. This will become a system specification issue for
>>the operator when selecting OLTs. Fixed rate is a simple to handle.
>>Here is the additional SLAs needed.
>>
>> All CNUs to FCU1 Group Rate limit 1Gbps.
>> All CNUs to FCU2 Group Rate limit 1Gbps.
>>
>>
>> From: Ed Boyd <ed.boyd@xxxxxxxxxxxx<mailto:ed.boyd@xxxxxxxxxxxx>>
>> Reply-To: Ed Boyd <ed.boyd@xxxxxxxxxxxx<mailto:ed.boyd@xxxxxxxxxxxx>>
>> Date: Friday, January 11, 2013 5:14 PM
>> To: EPoC Task Force
>><STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxx
>>E.O
>>RG>>
>> Subject: Re: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
>>
>> Jorge,
>>
>> Unlike Marek, I think that this is a great discussion and very useful.
>>
>> Yes, the OLT can set a rate limit on a per-LLID basis. This is very
>>common and available. As far as the standards are concerned, this
>>rate shaping happens above the MAC at the 802.1 or other switching layers.
>>With that said, having a rate limit on a per-LLID basis doesn¹t help
>>with MMP. If we sum up the rate limits of all of the LLIDs, it will
>>greatly exceed the bandwidth of the coax. It is required so there is
>>statistical gain. It wouldn¹t make sense to limit all of the LLIDs to
>>not exceed the bandwidth of the coax. It would be reserved fixed size
>>pipes for every LLID and there would be no statistical gain. Sounds
>>like SONET.
>>
>> MMP has a variable data rate for the entire downstream where the
>>output data rate is a based on modulation order and codeword size.
>>The codeword size is based on the PHY deciding to shorten the codeword
>>at the MMP boundaries. It seems very difficult to come up with a
>>shaping (idle insertion) for this function. For that reason, I
>>recommended back pressure from the PHY (also a MAC change) to get the
>>best
performance.
>>I think that another standard group is going in that direction as well.
>>
>> Thanks,
>> EdŠ
>>
>> From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
>> Sent: Friday, January 11, 2013 1:10 PM
>> To:
>>STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxx
>>.OR
>>G>
>> Subject: Re: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
>>
>> Jorge,
>>
>> I hate to get involved in this discussion any further, but I thought
>>the issue was not only rate limitation but also packet reordering, but
>>perhaps it is just my imperfect reading of the thread I stopped
>>following somewhere in the middle Š
>>
>> Marek
>>
>> From: Salinger, Jorge
>>[mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]<mailto:[mailto:Jorge_Salinge
>>r@C
>>ABLE.COMCAST.COM]>
>> Sent: Friday, 11 January, 2013 08:31 PM
>> To:
>>STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxx
>>.OR
>>G>
>> Subject: Re: [STDS-802-3-EPOC] MMP issues with the MAC Layer Solution
>>
>> Thanks Marek!
>>
>> Maybe I misunderstood, but I thought that this was functionality that
>>was already part of EPON. I guess I was mistaken? So, EPON as it
>>stands today does not include support for different rates on different
>>ONUs? In other words, as it stands today, do all LLIDs in all ONU need
>>to operate at the same data rate? And to make sure I am clear, can we
>>have some customers running at 10 Mbps, some at 100 Mbps, and some at
>>rates in between?
>>
>> Thanks!
>> Jorge
>>
>> From: Marek Hajduczenia
>><marek.hajduczenia@xxxxxx<mailto:marek.hajduczenia@xxxxxx>>
>> Date: Friday, January 11, 2013 2:58 PM
>> To: "Salinger, Jorge"
>><Jorge_Salinger@xxxxxxxxxxxxxxxxx<mailto:Jorge_Salinger@cable.comcast.
>>com
>>>>, EPoC Task Force
>>>><STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@LISTSERV.I
>>>>EEE
>>>>.ORG>>
>> Subject: 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<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxx
>>.OR
>>G>
>> 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<mailto:Eugene.Dai@xxxxxxx>>
>> Reply-To: Eugene Dai <Eugene.Dai@xxxxxxx<mailto:Eugene.Dai@xxxxxxx>>
>> Date: Friday, January 11, 2013 2:10 PM
>> To: EPoC Task Force
>><STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxx
>>E.O
>>RG>>
>> 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<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxx
>>.OR
>>G>
>> 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<mailto: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<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxx
>>.OR
>>G>
>> 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<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxx
>>.OR
>>G>
>> 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<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxx
>>.OR
>>G>
>> 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<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxx
>>.OR
>>G>
>> 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@xxxxxxxxxxxxx
>>.OR
>>G>
>> 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]<mailto:[mailto:andreag@qti.qualcomm.
>>com
>>]>
>> Sent: Tuesday, January 08, 2013 5:41 AM
>> To: Ed (Edward) Boyd;
>>STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxx
>>.OR
>>G>
>> 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@xxxxxxxxxxxxx
>>.OR
>>G>
>> 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:
>>image005][Description: Description: Description: Description:
>>Description: Description: Description: Description: Description:
>>Description: Description: Description: Description: Description:
>>Description: image002][Description: Description: Description:
>>Description: Description: Description: Description: Description:
>>Description: Description: Description: Description: Description:
>>Description: Description: image003][Description: Description:
>>Description: Description: Description: Description: Description:
>>Description: Description: Description: Description: Description:
>>Description: Description: Description: image004][Description:
>>Description: Description: Description: Description: Description:
>>Description: Description: Description: Description: Description:
>>Description: Description: Description: Description:
>>image006][Description: Description: Description: Description:
>>Description: Description: Description: Description: Description:
>>Description: Description: Description: Description: Description:
>>Description: image008][Description: Description: Description:
>>Description: Description: Description: Description: Description:
>>Description: Description: Description: Description: Description:
>>Description: Description: image007]
>>
>>
>>
>> ________________________________
>>
>> <="" p="">
>>
>> ________________________________
>>
>> ________________________________
>>
>> <="" p="">
>>
>> ________________________________
>>
>> <="" p="">
>>
>> ________________________________
>>
>> <="" p="">
>>
>> ________________________________
>>
>> ________________________________
>>
>> ________________________________
>>
>> <="" p="">
>>
>> ________________________________
>> <image001.jpg>
>> <image002.png>
>> <image003.png>
>> <image004.png>
>> <image005.png>
>> <image006.png>
>> <image007.png>
>> <image008.png>
________________________________________________________________________
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
________________________________________________________________________
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
________________________________________________________________________
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