Recent NTP pool traffic increase

Wed Dec 21 03:27:18 UTC 2016

I do think that the point of the Pool network is to be used by both 
consumers and vendors. And as mentioned before, there is a process if 
you are a vendor and want to use the pool within a commercial product. I 
have 3 NTP servers running and I don't really care who is using it.

That said, setting up your own infrastructure is also worth considering 
if it's a business critical feature. I assume that a Snapchat app that 
fails to have accurate time or correct itself could be abused.

To be honest, the fact that NTP is still something managed by volunteers 
and not a regulated entity (a bit like DNS) is mind boggling.

On 12/20/2016 09:41 PM, Keenan Tims wrote:
> 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
>