Miroslav Lichvar writes: > On Tue, Mar 29, 2016 at 10:36:55PM +0000, Harlan Stenn wrote: > > For a multitasking server, it could well be that one "thread" does the > > ordinary NTP handling while another does the NTS work. The first thread > > might say "I'm willing to wait N milliseconds before I reply to this > > request", and if the NTS processing gets done in time then the > > client_assoc info is ready in that response. If not, a "plain" response > > goes back, the client sends a plain NTP packet as its next query, and > > the server replies with NTP+NTS-client_assoc. > > If the server is not able to respond in time (whatever that means), it > shouldn't respond at all. The client will try again later. Responding > with a plain NTP message would not help as the client would ignore the > reply. Even if it didn't ignore it, the new request would have to be > the same NTS message as before, because the server doesn't have the > previous request. I doubt any server implementation would want to > cache requests and replies.
I disagree, but this may need to become a local policy choice. Are you suggesting the server saves state between the first incoming client request that we can't respond to "fast enough" and then on the next poll the server sees that the client request is identical, so it can immediately respond with the data it has had time to generate? If the answer is "no" then the client will never get an NTS handshake. > > I think it's a Bad Idea to make assumptions and "proactive restrictions" > > about how to do these exchanges. > > What restrictions would you like to lose? The suspension of the NTS > protocol with plain NTP messages you described seems to me like a > major complication in the protocol, which would require the server to > cache the client's requests. As opposed to degrading the server's performance? We're not talking about caching very much information here, or caching it for very long. I think we should define as few restrictions as possible here, and leave it to the implementation to decide what works best. H _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
