Subject: [Ntp] Antw: Re: Antw: Re: Comments on draft-mlichvar-ntp-correction-field

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 28 Mar 2018 08:20:43 +0200

>>> Hal Murray <[email-masked]> schrieb am 28.03.2018 um 06:11 in
Nachricht <[email-masked]>:

> [email-masked] said:
>> Hal, do you have any expectation that youâ€™ll ever be able to get a DSL
>> router that will implement this capability? 
> 
> Seems unlikely.  I think the major vendors would start by "fixing" 
> bufferbloat, then declare victory and ignore any NTP issues.

What my router can do is assigning priority to specified traffic
(port/protocol). So higher priority traffic will be sent first or get more
bandwidth. As we all know, there's no end-to-end bandwidth negotiation in
Internet, and probably where will never be a general one...

> 
> Note that the hardware on DSL links in not symmetrical.  There is some 
> competition for the modem/router box at the customer end.  Wifi is often 
> included.  At least with some ISPs, you have a choice.  I expect there is 
> some open source work in that area, but I don't know any details.
> 
> I think the box at the other end is called a DSLAM.  I doubt if the customer

> 
> gets any choice.
> 
> I've seen comments about working on bufferbloat by interjecting an 
> ethernet-ethernet box between DSL modem and LAN.  The idea is to do rate 
> limiting on that box at slightly below the DSL link speed so there is no 
> queueing at the DSL uplink and the downlink queue is under your control.  It

> 
> would be easy to add code in that environment to update NTP packets.
> 
> I could easily magine research/hacker experiments that might get deployed 
> outside the initial designer's lab.  Consider drones using Wifi, cell 
> phones, 
> or low tech ISM radio links.  Somebody might get interested in NTP 
> corrections.
> 
> In any case, I think we should have enough bits for a few seconds or few 10s

> 
> of seconds, rather than just 10s of ms.  You can do that by allocating lots

> of bits, or use something like a floating point format.  You could move the

> floating point part to the EF type - one type for fast links and another for

> slow links with the time slot scaled differently.  That doesn't scale to 
> many 
> bits of exponent, but it works for 1.
> 
> 
> 
> 
> -- 
> These are my opinions.  I hate spam.

---

From: Hal Murray <[email-masked]>
Date: Tue, 27 Mar 2018 23:47:13 -0700

[email-masked] said:
> What my router can do is assigning priority to specified traffic (port/
> protocol). So higher priority traffic will be sent first or get more
> bandwidth.

If I did the math right, a 1500 byte packet at 384 K bits/sec and 48/53 ATM 
tax takes 34 ms.

Another data point.

I think that's best-case worst-case.  Worst in that it assumes the NTP packet 
arrives just after a 1500 byte packet starts getting sent.  Best in that it 
assumes that the NTP packet will be sent before any other packets in the 
queue.