Subject: [TICTOC] DSCP for PTP

From: Ron Cohen <[email-masked]>
Date: Sun, 7 Aug 2011 10:59:51 +0300

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

---

From: [email-masked]
Date: Mon, 8 Aug 2011 16:56:47 +0800

Hi，Ron
 
  I agree that classifying PTP event and general messages into separate 
PHBs is  problematic,
  and it is should be to use the same PHB to all PTP messages.
 
  In addition, I think that it should take into consideration the 
encapsulation of PTP message，
  because PTP PHB is related with PTP message formats(e.g. vlan PRI, ip 
Tos, mpls EXP).

Best Regards
Junhui
 
**************************************************
    Junhui Zhang 
    Bearer Network Product Pre-research Dept.
    ZTE Corporation
    No.50 Ruanjian Avenue,Yuhuatai District,
    Nanjing, P.R.China, 210012 
    Telephone    +86-25-88014227
    Mobile Phone +86-13913845289
**************************************************

Ron Cohen <[email-masked]> 
发件人:  [email-masked]
2011-08-07 15:59

收件人
[email-masked]
抄送

主题
[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.

messages, the value of the differentiated service (DS) field in the Type 
of Service (ToS)

Best,
Ron_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 8 Aug 2011 16:10:50 +0300

Hi,

As a reference: 802.1AS defines that the priority of PTP frames in this profile is 6. This priority is not conveyed in the frame, since these messages are untagged.

Tal.

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, August 08, 2011 11:57 AM
To: Ron Cohen
Cc: [email-masked]; [email-masked]
Subject: [TICTOC] 答复: DSCP for PTP

Hi，Ron

  I agree that classifying PTP event and general messages into separate PHBs is  problematic,
  and it is should be to use the same PHB to all PTP messages.

  In addition, I think that it should take into consideration the encapsulation of PTP message，
  because PTP PHB is related with PTP message formats(e.g. vlan PRI, ip Tos, mpls EXP).

Best Regards
Junhui

Ron Cohen <[email-masked]<mailto:[email-masked]>>
发件人:  [email-masked]<mailto:[email-masked]>

2011-08-07 15:59

收件人

[email-masked]<mailto:[email-masked]>

抄送

主题

[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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tictoc

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 8 Aug 2011 10:37:01 -0700

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-masked] [mailto:[email-masked]] On Behalf Of Ron Cohen
Sent: Sunday, August 07, 2011 1:00 AM
To: [email-masked]
Subject: [TICTOC] DSCP for PTP

Hi,

Best,
Ron

---

From: Ron Cohen <[email-masked]>
Date: Mon, 8 Aug 2011 22:41:30 +0300

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-masked]> 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-masked] [mailto:[email-masked]] *On
> Behalf Of *Ron Cohen
> *Sent:* Sunday, August 07, 2011 1:00 AM
> *To:* [email-masked]
> *Subject:* [TICTOC] DSCP for PTP****
>
> ** **
>
> Hi,
>
> messages. As a result vendors have chosen different default values, and some
> vendors also differentiate between the DSCP set on PTP Event messages (Sync,
> Ron****

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 8 Aug 2011 13:03:14 -0700

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-masked]]
Sent: Monday, August 08, 2011 12:41 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]
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-masked]<mailto:[email-masked]>> wrote:
Ron,

Regards,
Shahram

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ron Cohen
Sent: Sunday, August 07, 2011 1:00 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [TICTOC] DSCP for PTP

Hi,

Best,
Ron

---

From: "Roberts, Peter (Peter)" <[email-masked]>
Date: Mon, 8 Aug 2011 15:23:58 -0500

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-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Monday, August 08, 2011 4:03 PM
To: Ron Cohen
Cc: [email-masked]
Subject: Re: [TICTOC] DSCP for PTP

Ron,

Thx
Shahram

Hi Shahram,

Best,
Ron

Regards,
Shahram

Hi,

Best,
Ron

---

From: Ron Cohen <[email-masked]>
Date: Tue, 9 Aug 2011 00:03:17 +0300

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-masked]> 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.****
>
> ** **
>  ------------------------------
>
> Behalf Of *Shahram Davari
> *Sent:* Monday, August 08, 2011 4:03 PM
>
> *To:* Ron Cohen
> *Cc:* [email-masked]
> *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-masked]]
> *Sent:* Monday, August 08, 2011 12:41 PM
> *To:* Shahram Davari
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [TICTOC] DSCP for PTP****
>
> ** **
>
> Hi Shahram,
>
> Ron  ****
> On Mon, Aug 8, 2011 at 8:37 PM, Shahram Davari <[email-masked]>
> wrote:****
>
> Ron,****
>
>  ****
>
>  ****
>  ****
>  ****
>  ****

---

From: [email-masked]
Date: Tue, 9 Aug 2011 11:30:57 +0800

Shahram,

  There are many factors   introduce  PDV noise which has a significant 
impact on the synchronization performance , 
  except  the priority of PTP messages. 
 
  I think  the PDV metrics should be considered in PTP LSP 
Setup,Protection and Redundancy . 
  That is,  except for TC-capability and the priority of PTP messages, the 
capability of reserving bandwidth should be considered 
  in PTP LSP Setup, because some of the network nodes don’t support the 
capability of reserving bandwidth due to the complexity 
  of implementation and the cost of HW.

  In addition,it is possible that a more efficient path for the PTP 
becomes available, for example, the deployment 
  of new 1588-aware LSRs, and so on. In order to improve the 
synchronization performance, the head-end re-route the
  PTP onto the new path.
 
  Since an occasional connection failure is insignificant to the 
synchronization performance. However, the PDV noise
  by the packet timing signal as it traverses the network from the 1588 
Master to the 1588 Slave is critical to the
  synchronization performance.So, it is reasonable to recover the 
synchronization application based on the PDV 
  metrics.
 
  I would like to hear any suggestions from you and everybody.  Thanks.

  Best Regards
  Junhui

"Shahram Davari" <[email-masked]> 
发件人:  [email-masked]
2011-08-09 01:37

收件人
"Ron Cohen" <[email-masked]>, "[email-masked]" <[email-masked]>
抄送

主题
Re: [TICTOC] DSCP for PTP

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-masked] [mailto:[email-masked]] On Behalf 
Of Ron Cohen
Sent: Sunday, August 07, 2011 1:00 AM
To: [email-masked]
Subject: [TICTOC] DSCP for PTP
 
Hi,

Best,

---

From: "Kevin Gross" <[email-masked]>
Date: Mon, 15 Aug 2011 21:47:04 -0600

I'm new to TICTOC. I've worked on the AVB standards and am working on other
high-performance media networking systems and standards that would benefit
from improvements in clock distribution. I know a lot about Ethernet and IP
but I'm not an MPLS expert. Here's my contribution on the topic of QoS:

RFC 4596 specifically recommends using EF for NTP messaging. EF is also
routinely used for VoIP payloads. Although it would seem to fit nicely here,
Ideally we'd want 1588 to take precedence over both of these. Unfortunately
and by design, there's no standard service level higher than EF. Network
administrators are free to define custom service levels above EF and if
there's any chance of a warm reception for such a recommendation, I think it
should be made.

As allowed by the other DiffServ RFCs and implementation by vendors, there's
no magic to the DSCP numbers. Best practice is for edge network devices to
ignore incoming DSCP values and re-mark traffic based on characteristics
such as protocol identifier, destination address and port number. 

The DCSP numbers used within a network are, in the end, enterprise specific.
In this context you can appreciate that a 1588 QoS recommendation can be
descriptive and loose and may not need to conform strictly to RFC 4596
recommendations.

1588 prioritization under AVB is a largely irrelevant benchmark as no PTP
packets are ever bridged so there are never any queuing delays for QoS to
address.

Kevin Gross

AVA Networks

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Shahram Davari
Sent: Monday, August 08, 2011 11:37 AM
To: Ron Cohen; [email-masked]
Subject: Re: [TICTOC] DSCP for PTP

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-masked] [mailto:[email-masked]] On Behalf Of
Ron Cohen
Sent: Sunday, August 07, 2011 1:00 AM
To: [email-masked]
Subject: [TICTOC] DSCP for PTP

Hi,

Best,
Ron

---

From: "Kevin Gross" <[email-masked]>
Date: Mon, 15 Aug 2011 16:50:33 -0600

RFC 4596 specifically recommends using EF for NTP messaging. EF is also
routinely used for VoIP payloads. Ideally we'd want 1588 to take precedence
over both of these but there's no standard service level higher than EF.
Network administrators are free to define custom service levels above EF and
if there's any chance of a warm reception for such a recommendation, I think
it should be made.

As allowed by the other DiffServ RFCs and implementation by many vendors,
there's no magic to the DSCP numbers. Best practice is for edge network
devices to ignore incoming DSCP values and re-mark traffic based on
characteristics such as protocol identifier, destination address and port
number. 

The DCSP numbers used internally are then enterprise specific. In this
context you can appreciate that a 1588 QoS recommendation can be descriptive
and may not need to conform strictly to RFC 4596 recommendations.

1588 prioritization under AVB is largely irrelevant as no PTP packets are
ever bridged so there are never any queuing delays for QoS to address.

Kevin Gross

AVA Networks

Ron,

 

Regards,

Shahram

Hi,

Best,
Ron