[11:08:52] Danny joins the room [11:50:13] Stewart Bryant joins the room [11:57:15] sventers_3 joins the room [11:59:35] kodonog joins the room [12:01:23] psavola joins the room [12:06:19] brabson joins the room [12:06:31] report from Paris interim [12:06:47] Jyrki.Soini joins the room [12:08:24] john.zhao joins the room [12:09:15] I assume you can hear this ok [12:10:27] sventers_3 leaves the room: Replaced by new connection [12:14:29] sventers_3 joins the room [12:17:44] lllmartini joins the room [12:20:37] adam.wertheimer.telcordia joins the room [12:20:50] Peny joins the room [12:32:37] Ilya Varlashkin joins the room [12:34:02] In NTP4 the algorithms in the client takes care of loop prevention, multiple clocks, etc. [12:34:54] IPSec is most likely not possible [12:35:32] Danny - do you want these comments verbalized for those not on jabber ? [12:36:14] sure [12:40:00] satoru.matsushima joins the room [12:40:13] we need to define the terms in the matrix [12:41:27] agree - and we need help doing that - please help [12:44:17] You cannot really looks at protocols without deciding on the required elements [12:47:15] patcain joins the room [12:49:32] can you hear sylvana? [12:49:42] no [12:49:47] now? [12:50:28] yes [12:50:32] ks [12:50:34] tks [12:53:03] it would be useful to order the priority of requirements since not everything can be done at the same time [13:01:05] Danny- I agree with you. We have too many applications here [13:03:06] each app has it's own set of priorities, do you mean an order or priorities for each app, or a choice as to which app we support best? [13:05:32] Basically, We at least need to set the priorities for each app. [13:09:06] but you also need overall priorities of what needs to be implemented first (meaning some apps are less important than others) [13:14:12] Well, I think we should at least has a minimum base-line requirements, which are important for all the applications, if possible :) [13:16:03] correct [13:18:01] I agree as well. It would be great if you could suggest this to the mailing list with a candidate minimum set. [13:18:19] If one app needs 1uS over a good packet path and another needs 1mS over a poor path, what would the merged requirements look like? [13:19:00] good question. Do you have an answer? [13:19:20] Well, IMHO IETF defines protocols. The timing performance highly replys on the algorithm and hardware. [13:20:01] but it does drive the required data in the packets [13:20:14] and the packet rates [13:21:02] Yeah. The protocol must cover the requirements from different applications/algorithms, that's what is called *base-line* [13:21:21] VH joins the room [13:21:23] this has been one of the headaches of the NTPv4 draft since it did not separate the on-wire requirements from the algorithms [13:23:04] VH leaves the room [13:23:46] 1.5 us is hard to achieve under any circumstances [13:24:01] at least in today's hardware [13:24:23] How about the "base-line+options". Since we are defining some timing protocol, there surely should have some common features [13:25:01] It depends. basically I agree that 1.5us is difficult for open internet. [13:27:51] xNP needs to be able to operate over a wide envelope of conditions. Perhaps the way baseline is a set of points in that space. (I'm not sure the points can be ordered by priority by the group.) [13:28:01] sorry, xTP [13:29:08] you can have different options in each packet as long as you define those options properly so that they can interoperate in the same networks. [13:29:27] Danny, I agree. [13:29:30] 1.5us is necessary for some apps. [13:30:19] I'm not sure we need different packets, just different rates and less algorithm constraints. [13:30:53] I don't pretend to understand wireless and backhaul networks [13:31:24] but we should be able to distill their requirements to a point that all can understand. [13:33:33] generally we know that packet rate does not always give you better results [13:33:38] kurtis@jabber.psg.com joins the room [13:34:17] mitsuru.kanda joins the room [13:34:51] mitsuru.kanda leaves the room [13:34:54] satoru.matsushima leaves the room [13:35:40] satoru.matsushima joins the room [13:37:27] right, but for a given accuracy requirement, if the packet path gives 10% good measurements, and the local oscillator stability says you can wait 100 seconds between good measurements, then you need 10 seconds per packet. Faster might not help, but slower will sure hurt. [13:39:14] Sventers, Agree. We can define the protocol to convey the information related to that. Then, let the timing applications to decide it by using this protocol [13:39:34] timescale can be TAI, UTC, UTC(GPS), UTC(k) or arbitrary [13:39:49] for a sensor network the timescale would be arbitrary [13:39:56] actually no. NTP has shown that once things are stable the discipline code needs less information and it backs off getting updated timing. Additional data can make the discipline loop less stable [13:42:02] patcain leaves the room: Computer went to sleep [13:42:10] for frequency, the timescale can be UTC, UTC(GPS) or UTC(k) or arbitrary depending on where the frequency is derived from [13:43:47] Ilya Varlashkin leaves the room [13:43:50] satoru.matsushima leaves the room [13:44:13] satoru.matsushima joins the room [13:48:23] Between measurements packets, the stability of NTP depends on the stability of the local reference oscillator. If you need 1uS accuracy and the osc is only stable enough to hold 1us for 100 sec, then it seems like you need new, good measurement at least every 100 sec to recalibrate the local osc freq and phase. (Granted, for the typical oscillators and accuracies NTP has historically dealt with, faster hasn't helped,) [13:50:17] Peny leaves the room: Replaced by new connection [13:50:20] satoru.matsushima leaves the room [13:51:01] brabson leaves the room [13:54:14] Stewart Bryant leaves the room [13:54:15] john.zhao leaves the room: Computer went to sleep [13:54:37] kurtis@jabber.psg.com leaves the room [13:54:45] sventers_3 leaves the room [13:55:06] adam.wertheimer.telcordia leaves the room [13:57:50] Jyrki.Soini leaves the room [14:01:58] lllmartini leaves the room: Replaced by new connection [14:01:58] lllmartini joins the room [14:06:03] psavola leaves the room [14:31:22] kodonog leaves the room [14:34:38] Jyrki.Soini joins the room [14:34:52] Jyrki.Soini leaves the room [14:37:51] lllmartini leaves the room [14:43:01] patcain joins the room [14:43:16] patcain leaves the room [14:51:34] Danny leaves the room: Replaced by new connection [14:51:35] Danny joins the room [15:16:08] Danny leaves the room: Replaced by new connection [15:16:09] Danny joins the room [15:28:15] Danny leaves the room: Replaced by new connection [15:28:15] Danny joins the room [15:31:28] Danny leaves the room: Replaced by new connection [15:31:28] Danny joins the room [15:39:58] lllmartini joins the room [15:52:06] lllmartini leaves the room [16:04:16] lllmartini joins the room [16:45:23] lllmartini leaves the room [17:05:01] Danny leaves the room: Replaced by new connection [17:05:03] Danny joins the room [18:01:29] Danny leaves the room [18:18:06] Danny joins the room [18:54:16] Danny leaves the room: Replaced by new connection [18:54:16] Danny joins the room [19:40:39] Danny leaves the room [20:08:48] Danny joins the room [20:08:48] sventers leaves the room [21:58:32] Danny leaves the room