| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Andrea, Thank you for the feedback. I would certainly prefer we do not deal with EPON, consider EPON performance, delay, jitter etc. It has been done before and this group cannot change it without going through a change of scope. Such work, while interesting from scientific point of view, might be good for a publication in a magazine, but does not affect in any way how EPoC PHY should be operating. My suggestion would be to drop it from consideration and focus on EPoC CLT – CNU only, which should be complex enough to keep us working for the months to come. Marek From: Garavaglia, Andrea [mailto:andreag@xxxxxxxxxxxx] Hi Marek, Thanks for the comment, please see below my reply inline. Thanks, Andrea From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx] Andrea, I do not know why people keep bringing in something “MAC delay”. The only delay in 802.3 MAC is related with serialization of data received from above the MAC. Nothing more. Nothing else. I am not sure what additional “MAC implications” you reference but if there any, it is not an 802.3 MAC we are talking about. Potentially, you might be referring to MAC Control, which is a separate beat altogether. Please clarify [AG] Yes, maybe bad naming, please check slide 4 of delay model ongoing deck for explanation “The MPCP/MAC components considers the additional delay due to the resource allocation and depends primarily on scheduling/ polling cycles, the number of transmitters and min/max burst sizes, report cycle”. This point is to consider in the overall delay model issues like the one reported by Ed Boyd in his presentation (for example slides 9/10) and further discussed on Thursday in SD offline (see e.g. slide 5, 10/11) – I attach here both decks for your convenience. On the EPON delay component itself – I am not sure what this exercise is supposed to give to EPoC as a project. It will not help reach decisions for designing EPoC PHY in any way. All we need to do is nail down the delay budget for the EPoC PHY / link and leave EPON alone. It is done and changing it is not within the scope of EPoC project. Yes, Saif can now go after me because I speak again of the scope. I do. A project without a scope never ends and has always one more thing to do before it is over. This is not the way 802.3 works. [AG] As illustrated in slide 4, the focus is on coax PHY for EPoC – I think that is clear to everybody. I am fine to remove the further bullet on the optical part if there are concerns/confusion and we prefer so. Marek From: Garavaglia, Andrea [mailto:andreag@xxxxxxxxxxxx] Thanks Marek for your feedback, Let me try to clarify what maybe was not well evident to who did not attend the call: the exercise we are doing is a delay (and efficiency) model to improve the spreadsheet according to the receive feedback (this is captured in slide 3). In that regard, a key component is the PHY delay of the coax portion from which we have started. Another key component is MAC implications related to EPoC, which we will work on after PHY model is stable – this is where our effort is going. Eventually, as desire was expressed in that direction, additional delays due to EPON and OCU can be added on top but I share the same opinion that it is not meant to enter into the detail of such part – in fact, OCU model suggested by Saif (see slide 4) is to just have a delay parameter each one can configure based on own scenario/implementation/interest. I hope that is clear and common understanding for everybody – I am open to further suggestions otherwise. Thanks, Andrea From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx] Joe, When reading the notes (and I apologize in advance for not being able to participate in the calls, trying to take some time off until the 9th of August), I get the impression that we are getting into way too many details when considering delay budget, focusing on items which are clearly outside the scope of the project. Encryption, for once, is defined in 802 by 802.1X and it lies above layers of 802.3, and as such, we do not specify them. We can freely discuss what we believe the “right” number is, but at the end of the day, it is implementation dependent and does not affect the work we have to do. That said, why do we even need to bother with encryption delay? The other thing that concerns me is the constant attempt to calculate the delay budget between OLT and CNU. Please understand, the delay budget and jitter budget for EPON part of that link is well known and bounded under 802.3av and there is nothing that this project can do to change it. For us, it is fixed. We can take the maximum value and that is the most we can do. There is no analysis needed here, the values are already in the standard. The only part of the link we should be concerned with is the CLT to CNU. The way it is going right now, we are pretty much on the way to write a product spec, rather than a standard. Perhaps my impressions are incorrect, but I base them only on the notes, not having the benefit of the participation on the call. Regards Marek From: Solomon, Joe [mailto:Joe_Solomon@xxxxxxxxxxxxxxxxx] Meeting notes and updated Action/Issues Register are attached. Joe From: Solomon, Joe [mailto:Joe_Solomon@xxxxxxxxxxxxxxxxx] Team, Proposed agenda for this morning is below: 1. EPoC Performance Model Updates – Andrea G. 2. EPoC List of Definitions – Marek H. 3. EPoC Draft Outline – Marek 4. Review/update open actions/issues Joe Solomon Senior Technical Writer Comcast – T + PD Access Technology 303-242-7037 <="" p=""> <="" p=""> <="" p=""> |