Recent NTP pool traffic increase

Keenan Tims 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 
infrastructure.

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 8.8.8.8 is...

Keenan


On 2016-12-20 18:16, Tim Raphael wrote:
> Exactly,
>
> 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.
>>>
>>> RGDS
>>> GARY
>>> ---------------------------------------------------------------------------
>>> 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 mailing list