Re: [STDS-802-3-EPOC] [802.3_EPOC] Synchronization Eval Criteria for EPoC - Presentation for Jan. 8 Eval Criteria Ad Hoc Call
Thanks! Just wanted to be sure.
On Jan 8, 2013, at 9:38 PM, "Salinger, Jorge" <Jorge_Salinger@xxxxxxxxxxxxxxxxx> wrote:
> Yes, you are right. We keep on saying that IEEE develops the PHY, but what we mean is the PHY and the MAC. So, what I meant is above the PHY and MAC.
>
> Thanks!
> Jorge
>
>
> ----- Original Message -----
> From: Finkelstein, Jeff (CCI-Atlanta) [mailto:Jeff.Finkelstein@xxxxxxx]
> Sent: Wednesday, January 09, 2013 12:23 AM
> To: Salinger, Jorge
> Cc: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
> Subject: Re: [STDS-802-3-EPOC] [802.3_EPOC] Synchronization Eval Criteria for EPoC - Presentation for Jan. 8 Eval Criteria Ad Hoc Call
>
> By "above the PHY" do you mean in the MAC? If so isn't that still covered under 802.3?
>
> On Jan 8, 2013, at 8:38 PM, "Salinger, Jorge" <Jorge_Salinger@xxxxxxxxxxxxxxxxx> wrote:
>
>> Yeap, I agree that 802 has been incredibly successful in developing Ethernet and all its variants over the years. We have all benefited extensively by the work 802 has done.
>>
>> And EPoC should not be an exception to this success. We should all make sure of that as we develop the extensions to the 802.3 standard for EPoC.
>>
>> There is a lot to be said for keeping things simple. I'm just concerned that in doing so the outcome not end up being a PHY that is less efficient than other alternatives, such as DOCSIS.
>>
>> As we develop the EPoC System and Device specs at CL we can include functionality above the PHY, but for some of it we need to have the appropriate hooks in the PHY.
>>
>> Anyway, you are completely right in that a great deal of the success of Ethernet is due to its simplicity and scalability over the years.
>>
>> Thanks!
>> Jorge
>>
>>
>> ----- Original Message -----
>> From: Jones, Douglas
>> Sent: Tuesday, January 08, 2013 11:00 PM
>> To: Salinger, Jorge; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
>> Subject: RE: [STDS-802-3-EPOC] [802.3_EPOC] Synchronization Eval Criteria for EPoC - Presentation for Jan. 8 Eval Criteria Ad Hoc Call
>>
>>
>> Think of it this way.
>>
>> Let IEEE 802 do what it is good at, which is Ethernet. Thank-goodness 802 has done what they have done with Ethernet over the years. Talk about monumental, could you imagine a world without Etherent ?
>>
>>
>> Let CableLabs do what it is good at in creating interface specification.
>>
>>
>> We should allow each forum to do what they are best at, without breaking either process.
>>
>>
>> dj
>>
>> -----Original Message-----
>> From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
>> Sent: Tuesday, January 08, 2013 7:15 PM
>> To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
>> Subject: Re: [STDS-802-3-EPOC] [802.3_EPOC] Synchronization Eval Criteria for EPoC - Presentation for Jan. 8 Eval Criteria Ad Hoc Call
>>
>> Marek and all,
>>
>> I just want to make an observation with respect to the objective of this ad-hoc, and make a plead to how we work together to achieve each other's goals.
>>
>> In the Email thread below, you stated "a valuable contribution, but adopting such requirements without even knowing if they are achievable, is at least premature".
>>
>> But, the objective of this ad-hoc is precisely to establish requirements that the final solution must support in order to be useful. This is precisely, I think, what Bill is doing: define a service requirement for EPoC. If we wait until we know what EPoC can do and support, how do we know that we designed what was intended. There are and will be other such requirements that EPoC must support in order to be useful as a technology for MSOs, which in the end are the ones that will buy and deploy this equipment.
>>
>> I mention this because I've struggled myself with making the point that we don't have precise objectives for EPoC. We have the objectives defined during the Study Group phase, but those are very high-level and almost strictly to get approval without controversy. But there are many other things that we want EPoC to be able to do, which are not being brought up as requirement for multiple reasons.
>>
>> As an MSO, I'm not used to this approach. We normally define very clear service requirements up-front, and then start the spec process. Instead, this almost seems to be the exact opposite.
>>
>> And, while I'm at it, another thing I hear constantly is "let's keep EPoC simple, like Ethernet is". Well, that works well for most, maybe all, the applications of Ethernet where the standard defines the medium, etc. That's not the case here, where the standard will need to work in the most efficient way possible in the media that exists (i.e., the HFC network and the capacity allocated within it). I agree that this won't result in the most cost effective equipment possible to implement, but it will result in something that is deployable and is the most cost effective from a service deployment perspective.
>>
>> I guess we still have a ways to go to culturally and technically educate each other. We will all have to learn to compromise more than we are used to perhaps. As for myself, I'm trying to do that. But in addition I have so far really learned that this is a very challenging process, but likely will be an equally rewarding effort.
>>
>> Best regards,
>> Jorge
>>
>>
>> ----- Original Message -----
>> From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
>> Sent: Tuesday, January 08, 2013 06:24 PM
>> To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
>> Subject: Re: [STDS-802-3-EPOC] [802.3_EPOC] Synchronization Eval Criteria for EPoC - Presentation for Jan. 8 Eval Criteria Ad Hoc Call
>>
>> Thank you David,
>>
>> For those interested in more details, please look at the presentation on
>> .3bf given already to this TF in March 2012 (link:
>> http://grouper.ieee.org/groups/802/3/epoc/public/mar12/hajduczenia_01_0312.p
>> df). Note the persistent lack of the word "time stamp" in this document as
>> well as in 802.3-2012, Clause 90. We do not do any time stamping in 802.3bf.
>>
>>
>> Marek
>>
>> -----Original Message-----
>> From: Law, David [mailto:dlaw@xxxxxx]
>> Sent: Tuesday, January 08, 2013 23:14
>> To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
>> Subject: Re: [STDS-802-3-EPOC] [802.3_EPOC] Synchronization Eval Criteria
>> for EPoC - Presentation for Jan. 8 Eval Criteria Ad Hoc Call
>>
>> Hi Marek,
>>
>> I believe that your description of the operation IEEE Std 802.3bf-2011 -
>> which now can be found in Clause 90 'Ethernet support for time
>> synchronization protocols' of IEEE Std 802.3-2012 - is entirely correct. As
>> stated in subclause 90.2 'Overview', 'The goal of this clause is to provide
>> an accurate indication of the transmission and reception initiation times of
>> all packets, as required to support various time synchronization protocols,
>> e.g., IEEE Std 1588-2008, and IEEE Std 802.1AS.'.
>>
>> As stated in subclause IEEE Std 802.3-2012 subclause 90.7 'Data delay
>> measurement', 'The transmit path data delay is measured from the input of
>> the beginning of the SFD at the xMII to its presentation by the PHY to the
>> MDI. The receive path data delay is measured from the input of the beginning
>> of the SFD at the MDI to its presentation by the PHY to the xMII.'.
>>
>> PHY registers provided maximum transmit path data delay, minimum transmit
>> path data delay, maximum receive path data delay and minimum receive path
>> data delay (for example see IEEE Std 802.3-2012 subclauses 45.2.1.104
>> through 45.2.1.106) which allow the calculation of the transmit and receive
>> path data delay variation. The critical value is this delay variation - not
>> the absolute delays. The greater the variation - these lower the accuracy of
>> the time synchronization.
>>
>> Any proposal - such as the proposals we were talking about on today's call -
>> will have to be evaluated in respect to transmit and receive path data delay
>> variation to determine the accuracy of the time synchronization it will
>> provide.
>>
>> Best regards,
>> David
>>
>> -----
>>
>> From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
>> Sent: 08 January 2013 22:05
>> To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
>> Subject: Re: [STDS-802-3-EPOC] [802.3_EPOC] Synchronization Eval Criteria
>> for EPoC - Presentation for Jan. 8 Eval Criteria Ad Hoc Call
>>
>> Bill,
>>
>> If I recall correctly, 802.3bf does not deal with time stamping, especially
>> not with MPCP time stamping. All it does it provides indication of passage
>> of packets through the xMII, which can be then correlated with transmission
>> of selected packets across PHY. That combined with information on PHY delay
>> stored in 802.3bf registers provides enough information to calculate precise
>> residence time for the station.
>>
>> So, I am confused what is really meant by "using a timestamping mechanism
>> for MPCP packets over EPoC similar to the method described in both 802.3bf
>> and 802.1as Clause 13". I think there is some misunderstanding as to what
>> 802.3bf provides and misconception that it is a specification competitive to
>> 802.1as (which it is not, it complements 802.1as as much as 1588v2).
>>
>> Marek
>>
>> From: Bill Powell [mailto:bill.powell@xxxxxxxxxxxxxxxxxx]
>> Sent: Tuesday, January 08, 2013 21:40
>> To: Marek Hajduczenia
>> Cc: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
>> Subject: Re: [802.3_EPOC] Synchronization Eval Criteria for EPoC -
>> Presentation for Jan. 8 Eval Criteria Ad Hoc Call
>>
>> Marek,
>> Thanks for the review and comments. I agree, we have not proven yet that we
>> can meet this criteria, especially the time transfer error criteria on slide
>> 17. However, due to industry requirements for MBH, and competing
>> technologies (GPON) that can provide even lower time transfer error
>> performance, I think we need to be aiming at architecting EPoC to try to
>> meet the goals in this presentation. Having a goal in this area will help
>> us when we start comparing potential implementations.
>>
>> Note that on Slide 17 the time transfer error performance is labeled as
>> tentative, which in my mind would depend on physical limitations of what we
>> do in the MAC<->PHY layer for EPoC.
>>
>> I agree that we will need to use a timestamping method for MPCP packets
>> described in 802.3bf. I discussed the differences between 802.3bf and
>> 802.1as (the protocol for MPCP counter synchronization between the EPON OLT
>> and EPON ONU) with Geoff Garner at our last meeting in San Antonio. Geoff
>> mentioned that the timestamping method in 802.1as Clause 13 was essentially
>> similar to the MPCP timestamping criteria in 802.3bf, and the reason that
>> 802.1as did not refer to 802.3bf directly is that 802.3bf was not completed
>> when 802.1as was balloted.
>>
>> So, the intent here is to propose using a timestamping mechanism for MPCP
>> packets over EPoC similar to the method described in both 802.3bf and
>> 802.1as Clause 13. I intentionally left off this level of
>> 802.1as-vs-802.3bf detail in this presentation, as I thought it would not be
>> beneficial to the overall goal of:
>> (1) presenting a system level analysis relative to current MBH and CES
>> timing requirements, and
>> (2) propose specific Eval criteria for EPoC to support these requirements.
>>
>> Regards,
>> Bill
>>
>> -------- Original Message --------
>> Subject:
>> RE: [802.3_EPOC] Synchronization Eval Criteria for EPoC - Presentation for
>> Jan. 8 Eval Criteria Ad Hoc Call
>> Date:
>> Tue, 8 Jan 2013 21:13:46 +0000
>> From:
>> Marek Hajduczenia <marek.hajduczenia@xxxxxx>
>> To:
>> 'Bill Powell' <bill.powell@xxxxxxxxxxxxxxxxxx>,
>> <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
>>
>> Bill,
>>
>> My two cents on that would be simple - a valuable contribution, but adopting
>> such requirements without even knowing if they are achievable, is at least
>> premature. We do not have any working models that would allow to estimate
>> whether such stringent requirements are achievable.
>>
>> Furthermore, despite multiple indications from my side, the support for IEEE
>> Std 802.3bf is being still ignored. Without it, I do not know how you can
>> even think of getting to the level of precision you're suggesting. The delay
>> through each layer in the EPoC PHY needs to be known if we can ever hope to
>> get 1588v2 to the precision level you're showing.
>>
>> Regards
>>
>> Marek
>>
>> -----Original Message-----
>> From: Bill Powell [mailto:bill.powell@xxxxxxxxxxxxxxxxxx]
>> Sent: Tuesday, January 08, 2013 20:30
>> To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
>> Subject: [802.3_EPOC] Synchronization Eval Criteria for EPoC - Presentation
>> for Jan. 8 Eval Criteria Ad Hoc Call
>>
>> Hello All,
>> I've attached a presentation that I plan to present during the Eval Criteria
>> ad hoc call tomorrow (Jan. 9). Some of you may have seen most of this
>> presentation in a different forum, but I'm bringing this into 802.3bn
>> through the Eval criteria Ad Hoc for further discussion, with a recommended
>> performance limit for time and frequency transfer error over the EPoC link
>> on Slide 17 (new slide).
>>
>> If the group thinks that it would be useful to present to the whole 802.3bn
>> group, I can also submit it for presentation for the upcoming Phoenix or a
>> future 802.3bn meeting.
>>
>> Regards,
>> Bill
>>
>> --
>>
>> Bill Powell
>> Alcatel-Lucent
>> Fixed Access Systems Engineering
>> 2301 Sugar Bush Road
>> Raleigh, NC 27612
>> bill.powell@xxxxxxxxxxxxxxxxxx
>> (O) 919-850-6462
>> (Cell) 919-614-3225
>>
>>
>> ________________________________________________________________________
>>
>> To unsubscribe from the STDS-802-3-EPOC list, click the following link:
>> https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
>>
>>
>> ________________________________________
>> <="" p="">
>>
>> ________________________________________________________________________
>>
>> To unsubscribe from the STDS-802-3-EPOC list, click the following link:
>> https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
>>
>> ________________________________________________________________________
>>
>> To unsubscribe from the STDS-802-3-EPOC list, click the following link:
>> https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
>>
>> ________________________________________________________________________
>>
>> To unsubscribe from the STDS-802-3-EPOC list, click the following link:
>> https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
>>
>> ________________________________________________________________________
>>
>> To unsubscribe from the STDS-802-3-EPOC list, click the following link:
>> https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1