Re: Recent NTP pool traffic increase

[Laurent Dumont <admin () coldnorthadmin com>]

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 () 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 () nanog org] On Behalf Of Tim Raphael 
> > > [raphael.timothy () gmail com]
> > > Sent: Tuesday, December 20, 2016 5:34 PM
> > > To: Gary E. Miller
> > > Cc: nanog () 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 () rellim com> wrote:
> > > >
> > > > Yo Valdis.Kletnieks () vt edu!
> > > >
> > > > On Tue, 20 Dec 2016 20:20:48 -0500
> > > > Valdis.Kletnieks () 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 () rellim com  Tel:+1 541 382 8588