| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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="">
|