Recent NTP pool traffic increase
ktims at stargate.ca
Wed Dec 21 02:41:37 UTC 2016
Better for whom? I'm sure all mobile operating systems provide some
access to time, with a least 'seconds' resolution. If an app deems this
time source untrustworthy for some reason, I don't think the reasonable
response is to make independent time requests from a volunteer-operated
pool for public servers designed for host synchronization. Particularly
on mobile, the compartmentalization of applications means that this
'better' time will only be accessible to one application, and many
applications may have this 'better time' requirement. These developers
should be lobbying Apple and Google for better time, if they need it,
not making many millions of calls to the NTP pool. To make things worse,
I'm fairly sure that Apple's 'no background tasks' policy means that an
application can't *maintain* its sense of time, so it would not surprise
me if it fires off NTP requests every time it is focused, further
compounding the burden.
Time is already available, and having every application query for its
own time against a public resource doesn't seem very friendly. It
certainly doesn't scale. If they are unsuccessful lobbying the OS, why
not trust the time provided by the API calls they are surely doing to
their own servers? Most HTTP responses include a timestamp; surely this
is good enough for expiring Snaps. Or at least operate their own NTP
I'm sure that Snap had no malicious intent and commend them for their
quick and appropriate response once the issue was identified, but I
don't think this behaviour is very defensible. I for one was not harmed
by the ~10x increase in load and traffic on my NTP pool node, but the
100x increase if a handful of similar apps decided they 'need' more
accurate time than the OS provides would be cause for concern, and I
suspect a great many pool nodes would simply disappear, compounding the
problem. Please make use of these and similar services as they are
designed to be used, and as efficiently as possible, especially if you
are responsible for millions of users / machines.
In a similar vein, I've always been curious what the ratio Google sees
of ICMP echo vs. DNS traffic to 188.8.131.52 is...
On 2016-12-20 18:16, Tim Raphael wrote:
> Also they’re across Android and iOS and getting parity of operations across those two OSs isn’t easy.
> Better to just embed what they need inside the app if it is specialised enough.
> - Tim
>> On 21 Dec. 2016, at 10:13 am, Emille Blanc <emille at abccommunications.com> wrote:
>> Perhaps the host OS' to which snapchat caters, don't all have a devent ntp subststem available?
>> I have vague recollections of some other software (I'm sure we all know which) implemented it's own malloc layer for every system it ran on, for less trivial reasons. ;)
>> From: NANOG [nanog-bounces at nanog.org] On Behalf Of Tim Raphael [raphael.timothy at gmail.com]
>> Sent: Tuesday, December 20, 2016 5:34 PM
>> To: Gary E. Miller
>> Cc: nanog at nanog.org
>> Subject: Re: Recent NTP pool traffic increase
>> This was my thought actually, Apple does offer some time services as part of the OS but it’s becoming common with larger / more popular apps to provide some of these services internally.
>> Look at the FB app for example, there are a lot of “system” things they do themselves due to the ability to control specifics. Users don’t want to have to install a second “specialised app” for this either.
>> With regard to an ephemeral chat app requiring time sync, I can think of quite a few use cases and mechanisms in the app that might require time services.
>> - Tim
>>> On 21 Dec. 2016, at 9:26 am, Gary E. Miller <gem at rellim.com> wrote:
>>> Yo Valdis.Kletnieks at vt.edu!
>>> On Tue, 20 Dec 2016 20:20:48 -0500
>>> Valdis.Kletnieks at vt.edu wrote:
>>>> On Tue, 20 Dec 2016 18:11:11 -0500, Peter Beckman said:
>>>>> Mostly out of curiosity, what was the reason for the change in the
>>>>> Snapchat code, and what plans does Snap have for whatever reason
>>>>> the NTP change was put in place?
>>>> From other comments in the thread, it sounds like the app was simply
>>>> linked against a broken version of a library....
>>> But why is a chat app doing NTP at all? it should rely on the OS, or
>>> a specialized app, to keep local time accurate.
>>> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>>> gem at rellim.com Tel:+1 541 382 8588
More information about the NANOG