Hi Peter, You are right that randomization should take care of this effect, at least theoretically. However I looked carefully at IEEE1588-2008 and the standard does not require randomization of Sync messages, rather it requires randomization of Delay_Req messages (which makes sense when working in multicast). ITU-T G.8265.1 doesn't add any randomization requirement. Hence randomization of Sync messages is a good option to implement, but not a standard one. Note also that wide-enough randomization (e.g. uniform distribution half-interval wide) may not be that easy to implement in masters that support multiple (sometimes hundreds) of slaves.
Best, Ron On Mon, Aug 8, 2011 at 11:23 PM, Roberts, Peter (Peter) < [email protected]> wrote: > Ron,**** > > The interference effects of the plesiochronous traffic can be mitigated by > randomizing the generation of the 1588 packets. Since the actual > transmission time is recorded in the timestamp, there is no requirement for > exact periodicity to the 1588 packet generation (just the 30% accuracy > requirement of the standard *7.7.2.1*).**** > > ** ** > > I agree with your statement on there being a difference between an > environment with full on path support (every node a port based Timestamping > capable TC or BC) and an environment where this full support is not > available. But I think there will be enough of the second class of > deployments to warrant a recommendation on forwarding class.**** > > ** ** > > Peter R.**** > > ** ** > ------------------------------ > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Shahram Davari > *Sent:* Monday, August 08, 2011 4:03 PM > > *To:* Ron Cohen > *Cc:* [email protected] > *Subject:* Re: [TICTOC] DSCP for PTP > **** > > ** ** > > Ron,**** > > ** ** > > I have to look at this issue that you are raising. Do you have any > reference for this effect? **** > > ** ** > > In I theory one could have 2x EF PHB, with different DSCP code points, > where one has higher priority than the other one.**** > > ** ** > > Thx > Shahram**** > > ** ** > > *From:* Ron Cohen [mailto:[email protected]] > *Sent:* Monday, August 08, 2011 12:41 PM > *To:* Shahram Davari > *Cc:* [email protected]; [email protected] > *Subject:* Re: [TICTOC] DSCP for PTP**** > > ** ** > > Hi Shahram, > > One possible drawback for using EF for PTP is that EF is also used by some > video/voice and similar plesio-synchronous applications. The danger is that > the noise introduced by such application might be harder to filter than > 'normal' packet based traffic. Therefore, it might be better to use another > PHB, with even higher forwarding priority if possible, or maybe simply a > different PHB altogether. It would be great if someone did a study on this > and can share the results with us. > > We should also differentiate between the PTP-aware (TC/BC) or PTP-unaware > cases. In principle a TC doesn't need to send PTP messages with high > forwarding priority as it compensates for the residence time anyhow. > > Best, > Ron **** > > On Mon, Aug 8, 2011 at 8:37 PM, Shahram Davari <[email protected]> > wrote:**** > > Ron,**** > > **** > > I agree with you that all PTP messages must configured with highest > priority (a.k.a EF PHB) and EF should be the default. In fact I would also > think it is best to use L-LSP with EF PHB for 15880MPLS. If this is > acceptable by the group then we could add this to the 1588oMPLS draft.**** > > **** > > **** > > Regards,**** > > Shahram**** > > **** > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Ron Cohen > *Sent:* Sunday, August 07, 2011 1:00 AM > *To:* [email protected] > *Subject:* [TICTOC] DSCP for PTP**** > > **** > > Hi, > > Current standards do not recommend which DSCP values to set on PTP > messages. As a result vendors have chosen different default values, and some > vendors also differentiate between the DSCP set on PTP Event messages (Sync, > Delay_Req, etc.) and PTP General messages (Announce, Follow_Up, Delay_Resp). > I think TICTOC can help clarify the recommended DSCP usage, along the > guidelines of RFC4595, 'Configuration Guidelines for DiffServ Service > Classes'. > > In my opinion classifying PTP event and general messages into separate PHBs > is problematic as discard of Follow_Up would render its associated Sync > message useless. Forwarding of Sync messages in a higher priority queue > compared to Follow_Up may lead to Sync message getting ahead of the previous > Follow_Up message which again causes the slave to discard the previous Sync > message. Hence the first order recommendation in my opinion should be to use > the same PHB (and DSCP marking) to all PTP messages. > > Choosing one of the existing PHBs as the recommended one for PTP is > somewhat harder. EF is a reasonable choice in my opinion, as per RFC4595 > 'The intent of Expedited Forwarding PHB [RFC3246] is to provide a building > block for low-loss, low-delay, and low-jitter services.' TICTOC could in > principle recommend defining a new PHB tailored for PTP and similar > services, but I guess this would be a longer process. > > I would appreciate if others will share their insight on the recommended > usage and whether this issue should or should not be addressed by TICTOC. > > Here is the relevant text from IEEE1588-2008 Annex D: "For PTP event > messages, the value of the differentiated service (DS) field in the Type of > Service (ToS) > field should be set to the highest traffic class selector codepoint > available." The PTP Telecom profile for frequency distribution, ITU-T > G.8265.1, doesn't specify or recommend DSCP settings. > > Best, > Ron**** > > ** ** >
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
