Hacker News Reader

Comment by ixf | Hacker News Reader

You really can't do PTP over the internet, at least not meaningfully. Anyone who needs PTP is going to have their own grandmasters, reference sources, etc - and then a distribution network.

Most telecoms applications use an ePRTC source which tends to be implemented as a GPS/GLONASS/Galileo redundant frequency source, plus a local rubidium source or cesium reference. High-end telecoms applications use a hydrogen maser.

You can't stuff that over an unmanaged network and get the performance you need. Hardware needs to support it hop-to-hop.

View on HN

Yeah I agree, but ptpv2 does support unicast and you can set offsets. It would be very challenging, but not impossible sans the very high res stuff where you need oscillators on the switches and routers, as you alluded to. It wouldn't get down to the sub-10 nanosecond sync you get with a proper stratum 1 timesource (such as the rubidium decay ones), but you could get faster than the guaranteed 1 second of accuracy which is what I believe ntp used to guarantee from a protocol level.

That was my point. Also if you're inside one of Cloudflare's many POPs, this could, in theory, be provided.

PTP over Internet doesn't make much sense. PTP requires hardware support in all network devices on the path between the (grand)master and slave. Without this support it will generally perform worse than NTP. Of course, it depends also on the implementation.

PTP does support unicast messaging, but it is not meant to be used as a public service. There are two major problems: It's not stateless and it has a huge traffic amplification, which could be easily exploited for DoS attacks.

Yeah this is the most sensible reason against it. NTP is also responsible for some of the biggest traffic amplification DDoS events.

Yes, but NTP as a time service (client/server mode) is safe. A request has a single response and their lengths are symmetric (that's actually a requirement for accurate synchronization). The problem with amplification is in the optional monitoring/control modes of the protocol (modes 6 and 7 as used by the ntpq and ntpdc utilities respectively), which should be disabled on public servers. Unfortunately, there are still some old misconfigured servers causing problems for a lot of people.

In PTP the problem is in the synchronization protocol itself. A master in the unicast mode is basically a programmable packet generator. It sends sync/announce messages at a rate and duration specified by its slaves, and the address can be spoofed.

Reply on news.ycombinator.com