[email protected] said: > Some of this was discussed elsewhere. There are two cases to look at:
> 1) Client sends a packet and the server doesn't receive it ... > Open issue is how many retries should there be before it gives up? Does crypto complicate that decision? > 2) The client sends the packet and the server receives it and responds but > the client doesn't get the response. If the client now resends the request, > what should the server do? Resend? Ignore? Does it need to remember what it > last sent? This is a much harder case to resolve. I agree. That needs to be part of evaluating any proposal that involves multiple packets. -------- Perhaps the setup exchange should not be piggybacked on top of NTP packets. If it uses a separate port or TCP it would be easier to put the setup work in a separate process. TCP avoids the lost packet problem. (Or at least simplifies it.) It might avoid the problems with certificate chains overflowing a packet. -- These are my opinions. I hate spam. _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
