Re: [Ntp] WGLC: draft-ietf-ntp-interleaved-modes

[Harlan Stenn <[e-mail]>]

While I am supportive of the goals of this document, I am opposed to its
acceptance as a standards-track document with the document's current
language.

The following are the items I can find immediately.

1: Requiring an interleaved client/server mode places an unacceptable
burden on servers that have a lot of client traffic.  Specifically,
requiring a server to save date is too often Bad/onerous.

2: I would like to see demonstrated testing and test results that show
that for interleaved client/server mode, the specification behaves as
expected in both hostile and "dirty" environments, and does a thorough
job of demonstrating that there are no unintended consequences.  Has the
solid engineering been don?

On the first point I see two ways to advance this document "now".

One is to remove the language around the interleaved client/server mode,
and continue this work in a new document.  Not my favorite idea.  But as
I re-read my points below, it seems much safer at this time.

The other is to change the following and then re-evaluate the results:

The 4th paragraph of 2. begins with:

  A server which supports the interleaved mode needs to save
  pairs of local receive and transmit timestamps.

I recommend the following instead:

  A server which supports interleaved mode for the client needs to save
  pairs of local receive and transmit timestamps.

This is because a server may decide to support interleave mode for a
subset of clients.

The 4th paragraph of 2. ends with:

  The server MAY separate the timestamps by IP addresses, but
  it SHOULD NOT separate them by port numbers, i.e.  clients
  are allowed to change their source port between requests.

Has this been thoroughly tested?  I am specifically concerned about
multiple clients behind a NAT device, where the server will (almost?)
certainly see different port numbers for each client.  How well does
this work when there are multiple interleaved clients using different
ports from the same IP?  Is it sufficient that the server would compare
the incoming origin(?) timestamp to identify which (interleave response)
transmit timestamp should be sent back?  Given that UDP packets may be
lost in transit, how does the protocol behave in this case of a lost
client request?  How long should the server keep an interleaved transmit
timestamp, especially if we are not using the port number to help
identify responses?  This also goes to the case where an interleaved
client "stops" - how long should the server retain the information about
the last transmit timestamp for an "association" that is now gone?
Should the client/server interleaved mode store the client's poll
interval and use that information for this decision?

Paragraph 6 of 2. begins with:

  When the server receives a request from a client, it SHOULD respond
  in the interleaved mode if the following conditions are met:

I think this is too strong, and doesn't clearly allow for the situation
where a server may only offer interleaved client/server mode to a subset
of clients.  I wonder if:

  When the server receives a request from a client and is willing to
  offer an interleaved client/server association, it SHOULD respond
  in the interleaved mode if the following conditions are met:

is sufficiently "better".

To be clear, I'd like this proposal to show exactly how it behaves in
the face of:

- dropped client requests
- multiple clients using different ports from the same IP
- a client association that "just stops"

"Behavior" includes the behavior (including the amount and longevity of
saved state) of the server.

In the case of a NAT proxy in between the clients and the server, it is
possible that two, and possibly more, clients will send packets with the
same transmit timestamp.  As the number of clients behind the NAT proxy
increases, the possibility of identical transmit timestamps also increases.

I am also very concerned about this paragraph in 2.:

  The client SHOULD NOT update its NTP state when an invalid response
  is received to not lose the timestamps which will be needed to
  complete a measurement when the following response in the interleaved
  mode is received.

There are intricate and critical reasons why NTP updates various aspects
of its state depending on how far along packet validation and processing
occurs.  I would want to see a detailed and specific analysis of the
complete effects of the proposed sentence on the protocol machinery.
The primary goal is that the protocol be robust.  The secondary goal is
that interleave mode works.  I am concerned that the identified sentence
above switches these priorities.

As a general question, exactly how much benefit is seen when using
client/server interleaved mode?

As another general "question", how does this proposal operate in the
face of data-minimization?  Should this be stated in the document?

Aside from the above, I'm still recovering from the cold I've had for
over 2 weeks' time and I need to spend more time to study some of the
intricacies of the interleaved client/server mode in particular, and
this proposal in general.
-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!