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

Re: [802.3_EPOC] Agenda for this morning's meeting



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]
Sent: Tuesday, August 07, 2012 06:23
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Agenda for this morning's meeting

 

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]
Sent: 06 August 2012 09:30
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Agenda for this morning's meeting

 

Meeting notes and updated Action/Issues Register are attached.

 

Joe

 

From: Solomon, Joe [mailto:Joe_Solomon@xxxxxxxxxxxxxxxxx]
Sent: Monday, August 06, 2012 9:00 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: [802.3_EPOC] Agenda for this morning's meeting

 

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="">