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

Re: [802.3_EPOC] EPoC Weekly Working Group



This may indicate some significant ignorance on my part, but I was unaware that 802.3 specified performance requirements explicitly.  My assumption is that, from the perspective of 802.3bn, we focus on the standard.  When it comes to product definitions and cost trade-offs within a product, we can have that discussion another day, another time, and in another forum.

Ed

From: Marek Hajduczenia <marek.hajduczenia@xxxxxxxxx>
Reply-To: Marek Hajduczenia <marek.hajduczenia@xxxxxxxxx>
Date: Monday, August 13, 2012 11:49 AM
To: <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] EPoC Weekly Working Group

Steve,

 

Following the same approach, we will then change the way MAC works, MPCP and OAM, because they may be different in EPoC. That is all fine, but it is a different project altogether.

 

Marek

 

From: Shellhammer, Steve [mailto:sshellha@xxxxxxxxxxxx]
Sent: Monday, August 13, 2012 18:47
To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_EPOC] EPoC Weekly Working Group

 

Marek,

 

               The cost/complexity of the EPOC PHY may be very different than the EPON PHY.  EPON uses BPSK, while EPOC is likely to use a multicarrier (i.e. OFDM) PHY with high order modulation (1024QAM, 4096 QAM).

 

               So you may not “buy” that argument, however, a consumer may not “buy” a high cost/complexity CNU either. J

 

Steve

 

From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Monday, August 13, 2012 10:43 AM
To: Shellhammer, Steve; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_EPOC] EPoC Weekly Working Group

 

Steve,

 

I do not buy that argument. 10G-EPON ONUs support full 10G if it is available. I do not see the need to subdivide the allocated spectrum into chunks which will be then assigned to individual devices. This is not how EPON works.

 

Marek

 

From: Shellhammer, Steve [mailto:sshellha@xxxxxxxxxxxx]
Sent: Monday, August 13, 2012 18:42
To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_EPOC] EPoC Weekly Working Group

 

Ed and Marek,

 

               As the channel bandwidth increases well above 120 MHz, requiring the CNU to support very large bandwidth will add to the complexity and cost of the CNU.  It is not clear to me that if the channel bandwidth is say 3x120 = 360 MHz that requiring each CNU to support the entire bandwidth is a good trade-off.  I consider the CNU a consumer device and so I would expect its cost and complexity to be much less than the CLT.

 

               Is there some channel bandwidth at which we will no longer require the CNU to support the entire channel bandwidth?

 

Steve

 

From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Monday, August 13, 2012 10:24 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] EPoC Weekly Working Group

 

Ed,

 

That is precisely the point I was raising on the call today – EPON does not impose any limitations on bandwidth per ONU and furthermore, requires any single ONU to be able to absorb all bandwidth made available by the OLT. The EPoC should work the same way.

 

I think we reached a closure on the call on this point.

 

Marek

 

From: Edwin Mallette [mailto:edwin.mallette@xxxxxxxxx]
Sent: Monday, August 13, 2012 20:21
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] EPoC Weekly Working Group

 

Just to add on to Matt's thoughts here, our general model should be "what would EPON do?"  If EPON has a specific feature or general capability (like allowing a single LLID to utilize the entire available upstream) then EPoC should have have a similar capability.  We have already scoped out some of the capabilities of 10G-EPON (10Gb/s upstream for example.)

 

I would also agree with Matt that there would need to be some good reasons for scoping out some of the fundamental capabilities of EPON from EPoC.

 

Regards,

 

Ed

 

From: Matthew Schmitt <m.schmitt@xxxxxxxxxxxxx>
Reply-To: Matthew Schmitt <m.schmitt@xxxxxxxxxxxxx>
Date: Monday, August 13, 2012 11:09 AM
To: <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] EPoC Weekly Working Group

 

With regards to the 1 Gbps item in the Objectives (being discussed below), I recently responded to a question from Bill regarding that Objective.  I thought it might be worthwhile to share the thoughts I shared with him with the rest of the group.

 

Based on my recollection of the discussions around that objective, I should clarify that the first part of that objective — the part about 1 Gbps — is NOT so much about setting a speed target for a device or even the system.  Rather, it is in effect a back-door way of specifying a requirement for spectral efficiency (I.e., bps/Hz).  So if you're looking at it as a pure speed target — that devices be able to achieve 1 Gbps — then I believe that is not the correct way of viewing that Objective.  That's not to say that devices shouldn't be able to achieve that (given enough bandwidth).  However, devices — and the system — should ideally be capable of much more.  How much more we'll need to work out, but personally I think that a device that maxes out its performance at 1 Gbps in the downstream would likely be of limited value.

 

Regarding the question of a single CNU being able to use the entire pipe (regardless of bandwidth), I believe that we should always be designing to allow a single device to use the entire bandwidth available for a given unit time.  If it turns out that's not possible, then there really needs to be a very good reason for not designing for this, and the number should be as close to the ideal as possible.  That doesn't mean you would necessary provision a service at that data rate, or that you'd expect a device to operate at that speed continuously for a long period of time, but it should be possible for at least a short time.

 

Technically, this second item is not addressed by any of the Objectives.  We can add it if the team feels its necessary, although I consider it best practice (plus we don't yet know if it's technically possible), so I'm inclined not to do so.

 

Thanks.

 

Matt

 

From: Marek Hajduczenia <marek.hajduczenia@xxxxxx>
Reply-To: Marek Hajduczenia <marek.hajduczenia@xxxxxx>
Date: Monday, August 13, 2012 7:55 AM
To: "STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] EPoC Weekly Working Group

 

Andrea,

 

Please find additional feedback inline

 

Marek

 

From: Garavaglia, Andrea [mailto:andreag@xxxxxxxxxxxx]
Sent: Monday, August 13, 2012 14:47
To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_EPOC] EPoC Weekly Working Group

 

Hi Marek,

Thanks a lot for your feedback – please see some answer below. Talk to you soon.

 

Thanks,

Andrea

 

PS. Please allow me a remark so that everybody understand -> when it is stated “you” in your reply, it shall be read it as “the group” as what I am doing here is not necessarily presenting Andrea’s view, rather what the group is converging on week by week, of course including your inputs.  

I hope that is clear and maybe if we all simply talk about what the slides say it is easier to understand each other – now updated with numbers even, for starters and veterans J

 

From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Monday, August 13, 2012 14:59
To: Garavaglia, Andrea; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_EPOC] EPoC Weekly Working Group

 

Dear Andrea et al.,

 

Slide number would be welcome, for starters J

[AG] It is included – attached again, it seems Adobe did not like it J

 

On slide 3, I think the question “Is 1 Gb/s PAR objective to individual CNU or on coax segment?” is poorly stated.

[AG] I let Bill commenting/refining on that – please see also past e-mail from him attached.

 

When you think of EPoC and EPoC bandwidth, it is bandwidth provided by the CLT port, and not per CNU. For example, if CLT supports the baseline conditions, it will provide 1 Gbit/s to be shared by any number of connected CNUs. It is the same as in EPON, really, where 1G-EPON OLT provides 1 Gbit/s link to connected ONUs. If there is 1 ONU, it will get full 1 Gbit/s, if there are more ONU connected, the bandwidth is shared. So really, the bandwidth in EPoC is not per coax segment (what is that, really?) but rather than CLT port. Then all discussions on how much bandwidth per CNU is available are moot, since it depends on distance, scheduling efficiency and number of connected CNUs. Operators have known this trade-off for quite some time, since it is the same in DOCSIS, EPON and any other multi-access technology. So I do not understand why we are making such a fuzz about it and trying to impose a new meaning / interpretation of available bandwidth in case of EPoC.

[AG] That is understood. The question in my understanding is: is the case of one single user attached to CLT and have a sustainable 1 Gb/s a use case to consider when counting for worst case scenarios, or not (i.e. it is a corner case)?

[mh0813] I am not sure whether that is relevant. We have a nominal data rate objective and then two corner cases. These have to be supported by the equipment. Whether an operator would deploy a CTL with a single CNU connected to it or not does not change the bandwidth requirements and objectives.

 

Regarding the performance model. I fear that the level of detail you try to go into in the slide deck cannot be really simulated (or even approximated reliably) using Excel model. Given the self-similar nature of user traffic, combined with scheduling model and QoS enforcement, to reliably evaluate the system performance one would have to build at least a cure simulator tool, accounting for queuing delay, through-stack delay and scheduling delays, something that cannot be estimated using limited tools that Excel provides. My fear is that we will spend a lot of time on this model, have discussions on something that will eventually turn out to be of very limited use to progress EPoC process forward. Yes, we can consider line efficiency, to compare transmission efficiency with various FEC, encoding or interleaving solutions, but the effect of scheduling and queuing on overall system performance is very hard to estimate in such a simplified model. Just FYI, some more comprehensive analysis of EPON delay were done by Glen and myself for both 1G-EPON and 10G-EPON systems, and the obtained results cannot be accounted for using simple Excel models. There are stochastic effects in play in shared media systems which you cannot really capture in formulas.

[AG] What we are trying to gain insight here is not the precise model, but the 1st approximation which can be played with in simple sheet (see formulas on page 11 – I guess those are fairly well run on excel too). The detail modeling is not in the scope and there is no preclusion for surely companies to build a more details and sophisticated simulator and present results in case we will design performance requirements. The ambition is simply to update the current spreadsheet with what listed as feedback in slide 3, which to me looks feasible – but I am open to further simplify it.

[mh0813] I think what we will end up is not even 1st approximation, but rather approximation 0.01. When comparing analytical models for EPON performance with simulations and real-world measurements, it is clear that models come close to observed performance only for very specific cases, while simulations come very close for all / most of the cases. I fear that we might draw incorrect conclusions based on the model that is inherently flawed

 

Further, on slide 5 you show various reference architectures. I would like to remind you (and others) that the scope of this project is quite strictly limited and examining OCU delay, EPON delay etc., is not within our work scope at this time. I would certainly like to see option c) removed. If you want to model some sort of optical backhaul, remember that it can be also P2P fiber, or any other P2P technology for that matter. EPON that you show in option c) is just one of possible options. In either case, it does not matter, since it is just a fixed delay component for EPoC, nothing more.

[AG ] The slide is just capturing the comments made offline and it is up for discussion today (that is why it is in red) – your inputs in the call are welcome. Personally, I am fine to remove case (c) and I see your point.

 

Slide 7 contains some interesting new terms, like E_bits and I_bits – are these intended to be defined anywhere?

[AG] Yes, will add the definition – it is just an abbreviation for information bits and encoded bits, so there is a differentiation of the encoding/decoding operations.

[mh0813] I would suggest using terms from EPON, which required similar concepts. Adding new terms without any needs is never welcome.

 

Slide 14 – the assumptions about the scheduling model you have there allow you to simplify the model with a non-scheduled, dedicated link with 1/N capacity of overall EPoC link. The average delay will be exactly the same. No need to account for scheduling in such a situation, unless you want to model a real scheduling model, which shares bandwidth among CNUs in a non-equal fashion, depending on report and gate mechanism. But in that case, Excel model is not sufficient and simulations should be employed.

[AG] Note that slides from 12 onwards (sorry J) are not up for comments yet as stated in the e-mail below, this is work in progress. They will revised/removed/modified and the presented if we still find those parts relevant on later time.

[mh0813] The observation is still valid, though …

 

Marek

 

From: Garavaglia, Andrea [mailto:andreag@xxxxxxxxxxxx]
Sent: Monday, August 13, 2012 13:30
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] EPoC Weekly Working Group

 

Resending as PDF (size was too large).

 

Andrea

 

From: Garavaglia, Andrea
Sent: Monday, August 13, 2012 14:12
To: 'Salinger, Jorge'; EPoC Study Group
Subject: RE: EPoC Weekly Working Group

 

Hi all,

Please find attached the status report slides for today’s call. I hope last week we got sorted out most questions on scope and so we can keep it shorter this week, here my proposal for discussion:

-          Briefly confirm on the scope (added a disclaimer on slide 2 and included new slide 5 – there were comments to remove the last case)

-          Slides 8-10 are new for completing FDD upstream modeling (on the same line as downstream) – can briefly touch on that if needed

-          Slide 11 includes formulas for FDD PHY and some related considerations/notes – this is the main one to review

-          The rest is ongoing work – we will not discuss it today

 

Thanks,

Andrea

 

 


 


<="" p="">

 


<="" p="">

 


 


<="" p="">