Re: [Ntp] New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)

[Fernando Gont <[e-mail]>]

Hello, Miroslav,

On 29/5/19 03:47, Miroslav Lichvar wrote:
> On Tue, May 28, 2019 at 10:56:39PM -0400, Fernando Gont wrote:
>>> http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2019-May/096536.html
>>>
>>> Different NTP source ports yield varying quality results.
>>
>> So... this would be an argument for "randomize the source port on a
>> per-session basis, but not on a per-request basis", right?
> 
> I think it's actually an argument for randomizing the port on each
> request. If there are multiple paths to the server and the selection
> depends on the port number, the client needs to be changing its port
> to make sure some of its requests take the shortest path. The clock
> filter will drop measurements that took a longer path (assuming the
> increase in delay is significant when compared to jitter and clock
> dispersion).
> 
> If you had two clients in your network and they were synchronized to
> the same server, there could be a significant offset between their
> clocks if they used a fixed port. If they randomized their ports with
> each request, the offset should be smaller and not change randomly
> when the clients are restarted, etc.

Agreed. My question is: should one aim at the individual measurements to
be dropped, or at the server to be un-preferred over other (possibly
better) ones? -- I realize that in some scenarios this might happen with
all servers, in which case the former option (have individual
measurements dropped) might be a better option.

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492