Re: [802.3_EPOC] EPoC Weekly Working Group

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

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)?

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 1^st 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.

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.

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.

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