Re: [Ntp] [tsvwg] [Tsv-art] Tsvart early review of draft-ietf-ntp-alternative-port-02

[Miroslav Lichvar <[e-mail]>]

On Wed, Dec 08, 2021 at 08:14:57AM +0100, Eliot Lear wrote:
> Just to follow this up, my point is that the version bit doesn't matter if
> the packets aren't getting to endpoints.  At that point we need to start
> thinking about what is best for the Internet, and there may well be a
> tradeoff here.  But it really depends on what the operational data looks
> like, in so much as we can get at it.

Cloudflare is probably the largest provider of NTP+NTS. It would be
interesting if they could show how is distributed the length of
NTP+NTS requests received on their servers. IIRC they mentioned this
in one of the NTP WG meetings. As NTS clients are encouraged to not
reuse NTS cookies, they should ask for more cookies if there is a
packet loss, and this should be clearly visible in the distribution of
the request length.

I have some data that show that the filtering exists by measuring
losses at different NTP message lengths. I tested about 2600 public
servers from the pool.ntp.org project spread around the world. Only
servers that respond to packets containing an unknown extension field
were tested. This is a one-way test as the response is always short.
This was done from machines in 3 different countries on different
continents. 10 requests were sent to each server for each message
length. The following table shows from how many of the servers at
least 5 responses were received.

 Len   US     CZ     SG   
  48  98.3%  97.7%  98.6%
 148  98.2%  96.7%  98.2%
 248  90.1%  88.3%  85.0%
 348  90.5%  88.1%  84.7%
 448  89.7%  86.9%  84.1%
 548  96.2%  92.8%  95.5%

The dip between 200 and 500 matches the measurements posted by Steven
Sommars that I linked to earlier. A typical NTP+NTS message length
starts at about 230 bytes. So, depending on your location you could
expect >50% of NTP+NTS requests to about 10% of the public servers to
be lost due their length. After three packets lost in a row, the
request length increases to about 550, where the chances of getting a
response is better again. A response to every fourth request. That
is a common pattern I see on some clients.

-- 
Miroslav Lichvar