[04:01:06] --- andrewdmcgregor@jabber.psg.com has joined
[04:01:21] --- brabson has joined
[04:01:25] --- brabson has left
[04:03:05] --- shep has joined
[04:03:20] --- tsavo_work@jabber.org/Meebo has joined
[04:04:21] --- marshall has joined
[04:04:41] <marshall> acuracy is 50 ppb and 1 to 10 ten microsec accuracy
[04:04:51] <marshall> not addressed by any exisitng IETF WG
[04:04:59] <marshall> so, we proposed Tictoc
[04:05:04] <marshall> what are applications ?
[04:05:13] <marshall> NTP is order 10 msec industries
[04:05:26] <marshall> people that want better performance
[04:05:43] <marshall> frequency from mobile phome
[04:05:49] <marshall> distributed systems
[04:05:54] <marshall> financial
[04:05:56] <marshall> etc
[04:06:07] <marshall> Requirements matrix presented
[04:06:16] --- kenyis has joined
[04:06:23] <marshall> pseudowires - stratum 1 reference needed
[04:06:42] <marshall> 3GPP2 base stations - 50 parts per billion
[04:06:54] <marshall> enterprise residential
[04:07:03] <marshall> and audio video work
[04:07:18] <marshall> Media Access Control Systems need coordinated time
[04:07:30] <marshall> WiMA is the poster child for that
[04:07:41] <marshall> global time of day
[04:07:56] <marshall> packet transit times - need < 1 mec
[04:07:59] <marshall> msec
[04:08:07] <marshall> to 10 microseconds or better
[04:08:28] <marshall> power distribution needs 1 microsecond UTC time
[04:08:36] <marshall> synchrophasers
[04:08:48] <marshall> with guaranteed reliability
[04:08:58] <marshall> these are all infrastructure applications
[04:09:07] <marshall> quality needs are high
[04:09:08] --- kdz has joined
[04:09:17] <marshall> but there is flexibility as to means
[04:09:23] <marshall> higher packet rates
[04:09:29] <marshall> client server pairings
[04:09:31] <marshall> etc
[04:09:43] <marshall> techniques
[04:09:44] <marshall> :
[04:09:53] <marshall> now, largely SDH / SONET
[04:10:01] <marshall> physical transfer
[04:10:15] <marshall> in ITU there is synchronous ethernet
[04:10:25] <marshall> there is a continuous carrier in Ethernet
[04:10:41] <marshall> so the SONET/SDH type physical transfer works
[04:10:52] <marshall> this requires continuous end to end ethernet
[04:11:05] <marshall> dedicated networks - radio is standard
[04:11:23] <marshall> and now packets
[04:11:39] <marshall> note that high quality time means high quality frequency
[04:11:52] <marshall> and high quality freqeuncy can help transfer time
[04:12:17] <marshall> Synchronous Ethernet - use the SDH frequency locking to Ethernet physical carrier
[04:12:26] <marshall> no change to Ethernet itself
[04:12:59] <marshall> NOTE : The packet transfers are NOT synchronized
[04:13:16] <marshall> DOCSIS timing interface is another method
[04:13:39] <marshall> for scheduling of TDMA modem transmissions
[04:13:57] <marshall> this requires 5 nanoseconds over 70 meters
[04:14:11] <marshall> another method is the GPS / GNSS
[04:14:25] <marshall> GLONAS and Galileo
[04:14:45] <marshall> very high accuracy with external antennae
[04:14:49] <marshall> coverage is limited
[04:14:58] <marshall> not absolutely universal
[04:15:04] <marshall> concerns over reliability
[04:15:20] <marshall> 2% per year need to service base stations
[04:15:28] <marshall> and political concerns
[04:15:38] <marshall> Packet Environment
[04:15:47] <marshall> a bad environment for time transfer
[04:15:54] <marshall> delay variation
[04:16:00] <marshall> propagation assymmetry
[04:16:10] <marshall> packet rate limits all interfer
[04:16:25] <marshall> a service provider network is better than the general internet
[04:16:42] <marshall> IEEE 1588 does on the fly correction of packets using middleware
[04:17:16] --- geoff has joined
[04:17:25] <marshall> this requires contiguous end to end support
[04:17:38] <marshall> at high rates, better chance to do these corrections
[04:17:52] <marshall> so, packet rate will be siugnificantly higher than NTP
[04:18:03] <marshall> which is once per 4seconds
[04:18:15] <marshall> new techniques are 15 pps or higher
[04:18:23] <marshall> Other forums for this
[04:18:27] <marshall> NTP WG
[04:18:31] <marshall> PWE3 WG
[04:18:42] <marshall> IEEE 1588
[04:18:55] <marshall> IEEE 1588 A/V Task forum
[04:18:59] <marshall> force
[04:19:05] <marshall> IEEE 802.1AS
[04:19:08] <marshall> ITU
[04:19:16] <marshall> Congestion :
[04:19:26] <marshall> How many packets per second
[04:19:38] <marshall> also, influence of congestion on quality of time transfer
[04:19:48] <marshall> Conclusion :
[04:19:58] <marshall> This is an important problem area
[04:20:05] <marshall> this should be a solveable problem
[04:20:24] <marshall> contention : IETF should form a WG to address these problems
[04:20:58] <marshall> This was Stewart Bryant speaking
[04:21:06] <marshall> Question : Jim ?
[04:21:22] <marshall> What are the needs ?
[04:21:42] <marshall> Chair : Leave the need for the open mic
[04:21:43] --- AWGY has joined
[04:21:51] <marshall> Chair : Presentations are on line
[04:21:59] <marshall> Next is Peter Lothberg
[04:22:18] <marshall> Requirements for Wall Clocks
[04:22:40] <marshall> If yours are better than what I talk about, don't walk away
[04:22:50] --- kdz has left
[04:22:55] <marshall> Wall clock is a means of getting time of day
[04:23:06] <marshall> target is better than 1 milliseconds on average
[04:23:10] <marshall> Why ?
[04:23:37] <marshall> Why so large an error ?
[04:23:59] <marshall> Local PCs probably won't have oscillators that support better than this
[04:24:30] <marshall> I would like a physical wall clock on the wall with a radio interface
[04:24:55] <marshall> In NTP, we can transfer time but we don't know where it came from
[04:25:13] <marshall> There are actually a bunch of UTCs from different laboratories
[04:25:27] <marshall> I would like to see the source of the time added to the protocol
[04:25:42] <marshall> where did the server get the time, is it trraceable, etc.
[04:25:50] <marshall> then there is the need fro security
[04:26:07] <marshall> a server that serves a million users can't store state for each user
[04:26:18] <marshall> so, state for security will have to be kept by the client
[04:26:24] <marshall> maybe all, at least most
[04:26:48] <marshall> Now, NTP says I am "Stratum 1" or ...
[04:27:16] <marshall> but that just means that it is connected to a physical clock
[04:27:24] <marshall> another issue is leap seconds
[04:27:35] <marshall> which NTP doesn't really do right
[04:28:01] <marshall> today's NTP requires modulo 2^32 secobds
[04:28:15] <marshall> the protocols should be able to decode this
[04:28:21] <marshall> so nothing has to be typed in
[04:28:48] <marshall> the real problem is thus how does the time protocol talk to the host system
[04:28:58] <marshall> this should be standardized
[04:29:36] <marshall> maybe the formats in the API and on the wire should be decoupled
[04:29:42] <marshall> wire format
[04:29:57] <marshall> and algorithms should be separated
[04:30:15] <marshall> wire format should support picosecond resolution
[04:32:26] <marshall> Joe Touch ISI
[04:32:32] <marshall> why one millisecond ?
[04:32:44] <marshall> if that is based on current OS's
[04:32:48] <marshall> won't that change ?
[04:33:09] <marshall> Peter : Protocol will deal with frequuency, phase and time
[04:33:37] <marshall> wall clock is very few packets and light weight and limited by stability of clock
[04:33:55] <marshall> 1 msec average is way better than what we do today
[04:34:03] <marshall> CHair : Let's cut this off
[04:34:39] <marshall> Peter : I put an arbitrary number that limits for wall clocks
[04:34:48] <marshall> chair : next presentation is also Peter
[04:35:02] <marshall> Peter : I looked at NTP
[04:35:10] <marshall> You can do much better with NTP packets
[04:35:14] <marshall> than we do today
[04:35:30] <marshall> what we can do today is much better
[04:35:44] <marshall> probably don't want to change the format
[04:35:52] <marshall> the installed base is a lot
[04:36:04] <marshall> and I can't come up with a good reason to obsolete it
[04:36:23] <marshall> let's see what we can do with NTP
[04:36:36] <marshall> take type code 7, which is not used
[04:36:48] <marshall> change time stamp to 64+64 bits
[04:37:07] <marshall> with upper 64 bits be the modified julian dates
[04:37:17] <marshall> which will run for as long as the Sun
[04:37:27] <marshall> NTP jumps
[04:37:34] <marshall> need a linear time
[04:37:42] <marshall> so, there is TAI
[04:38:00] <marshall> Galileo is GPS
[04:38:02] <marshall> time
[04:38:09] <marshall> I didn't pay attention to why
[04:38:25] <marshall> anyway, you want a linear time scale
[04:38:32] <marshall> GPS time scale you can't use the format
[04:38:47] <marshall> you need a way of queriering the server
[04:38:56] <marshall> about its characteristics
[04:39:10] <marshall> and if you can do that., you can do that hop by hop
[04:39:40] <marshall> ALSO, ask IEEE 1588 to make there timestamping mechanisms generic
[04:39:50] <marshall> so can be used by anyone who wants to use it
[04:40:00] <marshall> Now, we need to make an API
[04:40:09] <marshall> POSIX doesn't do leap seconds
[04:40:34] <marshall> maybe the API is generic so it can be used by frequency uses
[04:40:42] <marshall> maybe it can be future proofed
[04:40:45] <marshall> but probably not
[04:41:08] <marshall> it is clear that NTP is used by people behind assymetric connections
[04:41:13] <marshall> different speeds
[04:41:31] <marshall> can send different size packets to see how long they
[04:41:40] <marshall> take and how fast each direction is
[04:41:53] <marshall> then, you can look at recording routes in NTP
[04:42:03] <marshall> either modify packets
[04:42:08] <marshall> or add more packets
[04:42:41] <marshall> Chair : Next is Greg
[04:42:57] <marshall> Enhancements to NTP
[04:43:11] <marshall> Greg : I don't think I am going to talk about enhancements to NTP
[04:43:26] <marshall> There is a lot of lack of understanding about
[04:43:31] <marshall> 1588 versus ntp
[04:43:51] <marshall> in a point to point fashion, neither protocol has a significant advantage
[04:44:26] <marshall> We attempted to set a test in the lab to positively show that we could use it for high quality synch transfer
[04:44:35] <marshall> NTP has evolved a lot
[04:45:04] <marshall> NTP operations - looking at 1588, a lot of things there were addressed in NTP
[04:45:09] <marshall> years and years ago
[04:45:43] <marshall> there is a great deal of simularity
[04:45:48] <marshall> enhanced NTP
[04:46:01] <marshall> everything now is all bound up
[04:46:11] --- fparent@jabber.org has joined
[04:46:11] <marshall> NTP WG is trying to codify the existing standards
[04:46:19] <marshall> what new stuff ?
[04:46:24] <marshall> hardware time stamping
[04:46:37] <marshall> generally on the leading edge of a packet
[04:46:41] <marshall> gating methods
[04:46:56] <marshall> using a gating function in rtl
[04:47:11] <marshall> the fpga can do a time sync function
[04:47:18] <marshall> "it's just software"
[04:47:28] <marshall> error feedback mechanisms
[04:47:39] <marshall> the kind of stuff we focus on
[04:47:53] <marshall> we have highly accurate, stable frequency references
[04:47:58] <marshall> so we leveage that
[04:48:13] <marshall> we understand that higher accuracy will require higher packet rates
[04:48:16] <marshall> what stays the same ?
[04:48:21] <marshall> On the wire protocol
[04:48:34] <marshall> NTP has a huge legacy base
[04:48:58] <marshall> we need to carefully analyze the impact on the existing customer base
[04:49:18] <marshall> server time stamp accuray to a nanosecond
[04:49:25] <marshall> 50 to 60 pps packet rate
[04:49:41] <marshall> set up a test environment
[04:49:43] --- kenyis has left
[04:49:51] <marshall> MTIE andTDEV
[04:49:58] <marshall> Maximum Time Interval Error
[04:50:05] <marshall> and Time interval deviation
[04:50:31] <marshall> distribution is stronly modal
[04:50:39] <marshall> need enough packets per seconds
[04:50:46] <marshall> to pick off the fundamental mode
[04:51:04] <marshall> TDEV reflects the huge amount of power coming through the noise floor
[04:51:14] <marshall> they are chosing the minimum offset
[04:51:48] <marshall> the noise floor does drop through the stratum 1 level
[04:51:55] <marshall> NTP does 10 msec
[04:52:09] <marshall> but if you have hardare, engineering, etc., you get better
[04:52:29] <marshall> that's really all we wanted to bring out today
[04:52:39] <marshall> both NTP and 1588 are going to grow
[04:52:56] <marshall> the potential scope is huge
[04:53:01] <marshall> it's a huge issue
[04:53:05] <marshall> there is a lot of groups
[04:53:17] <marshall> and a lot of room to discuss what applications require
[04:53:19] <marshall> in this space
[04:53:34] <marshall> in NTP there is a big push to codify where we are today
[04:53:41] <marshall> Quesrtions
[04:54:11] --- brabson has joined
[04:54:13] <marshall> Joe Touch : NTP is susceptible to the variability in the delivery of messages
[04:54:23] <marshall> which seems to be increasing in the Internet
[04:54:29] <marshall> how much of this is worse now
[04:55:05] <marshall> Greg : These are problems for anty time transfer
[04:55:16] <marshall> these properties haven't changed much
[04:55:34] <marshall> you need nimble time filters
[04:55:45] <marshall> this problem scales up and down very well
[04:56:10] <marshall> Chair : Not discussing properties of NTP
[04:56:23] <marshall> Ron Cohen will now talk about 1588
[04:56:27] <marshall> Ron :
[04:56:37] <marshall> I am going to discuss 1588
[04:56:42] <marshall> PTP v1 and v2
[04:56:50] <marshall> transparent clocks
[04:56:56] <marshall> and how it fits tictoc
[04:57:06] <marshall> PTP v1 released in 2002
[04:57:17] <marshall> pushed by test and measurements
[04:57:37] <marshall> lot of deployments in power distribution industry as well
[04:57:44] <marshall> v2 was approved in 2005
[04:57:56] <marshall> gained from experience
[04:58:08] <marshall> many products have 1588 built into them
[04:58:14] <marshall> information on web site
[04:58:18] <marshall> objectives :
[04:58:21] <marshall> nanosecond accuracy
[04:58:27] <marshall> for local systems
[04:58:32] <marshall> self organizing
[04:58:45] <marshall> important that minumal resources were requreid
[04:59:11] <marshall> ptp has 3 parts
[04:59:14] <marshall> timing protocol
[04:59:22] <marshall> delay between master and slace
[04:59:24] <marshall> slave
[04:59:31] <marshall> or in version 2 pair link
[04:59:52] <marshall> self organization of the synchronization hierarchy
[05:00:02] <marshall> ptp assures that there is only 1 master clock
[05:00:29] <marshall> boundary clocks get time from master and act as masters to slave below
[05:00:38] <marshall> master sends sync messages
[05:00:57] <marshall> master can send sync messages with time t1
[05:01:08] <marshall> if it is not available
[05:01:32] <marshall> one idea here is that you need to
[05:01:43] <marshall> time stamp every queing delay possible
[05:02:15] <marshall> this is described as 1 step and 2 step clocks
[05:02:30] <marshall> 1 step - accurate time stamp in sync message
[05:03:09] <marshall> 2 step sends it in a flollowup measurement which is better for security
[05:03:27] <marshall> PTPv2 allows for subpicosecond time stamp accuracy (!)
[05:03:39] <marshall> here is the format of the time stamp
[05:03:46] <marshall> [see presentation]
[05:04:35] <marshall> end to end transparent clocks
[05:04:43] <marshall> e2e tc's
[05:05:06] <marshall> cancels the residence time and the upstream link propagation delay
[05:05:25] <marshall> for calculating the delay, an additional set of optional messages was added
[05:05:56] <marshall> here we see a packet switched network with transparent clocks
[05:06:18] <marshall> messages are received without queuing delay
[05:06:35] <marshall> it doesn't mean that you have to use transparent clocks
[05:06:58] <marshall> topology does not affect the slave performance
[05:07:18] <marshall> topology CHANGE does not affect the slave performance
[05:07:28] <marshall> comparison between switches
[05:07:42] <marshall> boundary clocks are synchronized
[05:07:54] <marshall> end to end transparent clocks are syntonized
[05:08:05] <marshall> each solution has its own merits
[05:08:51] <marshall> ptp was designed for multiple industries
[05:09:05] <marshall> additional extensions where therefore allowed for
[05:09:10] <marshall> in TLV or flag formats
[05:09:17] <marshall> and introduction of a profiule
[05:09:24] <marshall> there is a way to extend p2p
[05:10:04] <marshall> sub nanosecond accuracy has been demonstrated
[05:10:24] <marshall> telephone grade performance over real networks has demonstrated
[05:10:31] <marshall> it is robust to master failures
[05:11:23] <marshall> correction field is scaled nanoseconds
[05:11:33] <marshall> can use either 2 step or 1 step clock designs
[05:11:39] <marshall> and it is slave friendly
[05:11:46] <marshall> the time stamp does not roll over
[05:12:16] <marshall> Chair : For our purposes P2P and 1588 are the same thing
[05:12:30] <marshall> Next is Karen Odonoghue
[05:12:35] <marshall> Karen :
[05:13:14] <marshall> Basic Metric for scalability
[05:13:28] <marshall> what are the things that impact scalability
[05:13:44] <marshall> number of clients supported is on the broad
[05:13:46] <marshall> Internet
[05:13:55] <marshall> another is the number of servers
[05:14:05] <marshall> master/slace
[05:14:09] <marshall> master/slave
[05:14:19] <marshall> master initiates exchange of messages
[05:14:28] <marshall> client / server
[05:14:43] <marshall> in NTP the client initiates exchange of messages
[05:14:52] <marshall> in 1588 the master initates
[05:15:09] <marshall> there is clock aware and non clock aware network elements
[05:15:27] <marshall> another scalability is number of networks traversed
[05:15:38] <marshall> another is the scale of the network
[05:15:51] <marshall> 802.1AV is a home network with a maximum of 7 hops
[05:16:08] <marshall> last scalability issue is available bandwidth
[05:16:54] <marshall> a question : If the WG is limited to infrastruicture networks, how are the requirements clarified ?
[05:17:05] <marshall> impacts on scalability :
[05:17:16] <marshall> 1588 : master maintains state
[05:17:23] <marshall> NTP : Clients maintain state
[05:17:44] <marshall> in 1588, desire was to have very simple slaves
[05:17:52] <marshall> in NTP, not concerned about that so much
[05:18:37] <marshall> 1588 was designed as a multicast protocol
[05:18:50] <marshall> this should maybe be tailored to unicast for a broader scale
[05:19:00] <marshall> ntp has many modes of operations
[05:19:22] <marshall> while 1588 p2p has lots of different types of devices
[05:19:44] <marshall> algorithm complexity : ntp has a lot of complexity for edge cases
[05:20:00] <marshall> 3 solutions
[05:20:10] <marshall> 1588, ntp 802.1AV
[05:20:20] <marshall> all address parts of problems
[05:20:26] <marshall> none are going away soon
[05:20:42] <marshall> these could thus maybe be leveraged
[05:21:00] <marshall> there needs to be a detailed technical analysis of the 2 proposals
[05:21:07] <marshall> Chair : Questions ?
[05:21:22] <marshall> Chair : there is CTP
[05:21:30] <marshall> classless time protocol
[05:21:38] <marshall> it optimizes error
[05:21:47] <marshall> over the entire network
[05:21:53] <marshall> next is Peter
[05:22:05] <marshall> on Security
[05:22:07] <marshall> Peter :
[05:22:35] <marshall> OK, traditional time transfer
[05:23:02] <marshall> need to add a way to sign and identify clocks
[05:23:16] <marshall> it may be just charactertistics of the box
[05:23:29] <marshall> or of the government agency that is ditributing the time
[05:23:38] <marshall> official time
[05:23:49] <marshall> organizations may need internal time
[05:24:04] <marshall> a common time but maybe or maybe not utc
[05:24:19] <marshall> may want to add where the server is
[05:24:45] <marshall> then could also ask about daylight savings time
[05:25:02] <marshall> another WG is extending DHCP to include daylight saving time rules
[05:25:12] <marshall> today, to get time from NIST
[05:25:23] <marshall> first - DNS lookup
[05:25:27] <marshall> to IP address
[05:25:46] <marshall> how do I know a send to that is actually going to NIST
[05:25:56] <marshall> man in the middle attacks
[05:26:25] <marshall> So, an outcome of this
[05:26:41] <marshall> there are organizations running servers
[05:27:00] <marshall> another document might be a BCP for time dissemenation
[05:27:41] <marshall> Chair : Related work in other SDO's
[05:27:53] <marshall> we have shown that there is a problem that can be soved
[05:27:54] <marshall> solved
[05:28:00] <marshall> is anyone else solving it
[05:28:19] <marshall> Silvana Rodrigues :
[05:28:21] <shep> What is "SDO"?
[05:28:26] <marshall> ITU-T
[05:28:50] <marshall> Standards Defining organization [I think]
[05:28:58] <marshall> IETF is an SDO
[05:29:04] <marshall> so it ITU, etc.
[05:29:19] <shep> tnx
[05:29:21] <marshall> ITU-T Study ZGroup 15, Working Part 3, Question 13
[05:29:34] <marshall> Synchronization experts group
[05:29:39] <marshall> G.8261
[05:29:52] <marshall> Rapporteur is
[05:30:04] <marshall> Jean-Loup Ferrant of Alcatel
[05:30:13] <marshall> G.8261
[05:30:20] <marshall> published in May 2006
[05:30:35] <marshall> specifies minimum requires for jitter and wander
[05:30:48] <marshall> ITU-T G.pacmod
[05:30:55] <marshall> includes SSM
[05:31:05] <marshall> Syncrhonization of Messaging
[05:31:24] <marshall> G.paclock is also under development
[05:31:38] <marshall> minimum requirements for clocks
[05:31:55] <marshall> synchronous ethernet is also packet of G.paclock
[05:32:35] <marshall> in 2005 PAR was launched
[05:32:46] <marshall> Project Authoprization Request
[05:32:59] <marshall> P.1588 meets twice per week by conference calls
[05:33:41] <marshall> version 2 should be available by July 2007
[05:33:46] <marshall> what are profiles ?
[05:34:10] <marshall> set of required and prohibited options for a particular industry or problem
[05:34:24] <marshall> can be developed by any external body
[05:34:54] <marshall> 802.1AS (NOTE - INCORRECTLY DESCRIBED AS 802.1AV BEFORE)
[05:35:00] <marshall> 1 microsecond
[05:35:07] <marshall> PAR approved last year
[05:35:33] <marshall> Another is ATIS-OPTXS
[05:35:58] <marshall> formerly T1X1.3
[05:36:08] <marshall> Question :
[05:36:14] <marshall> What are the IPR issues ?
[05:36:27] <marshall> A : At 1588 there are some IPR issues
[05:36:39] <marshall> they license for a very low fee
[05:36:55] <marshall> for version 2 CISCO and Rcokwell have IPR statements
[05:37:12] <marshall> for ITU work there is no IPR I know of
[05:37:18] <marshall> Chair : A patent exists
[05:37:28] <marshall> for synchronous Ethernet
[05:37:39] <marshall> Question : For NTP
[05:37:48] <marshall> Chair : Everything is open
[05:38:10] <marshall> Chair :
[05:38:15] <marshall> Now the proposal charter
[05:38:23] <marshall> Kurtis Lindqvist
[05:39:06] <marshall> Here is the proposed charter
[05:39:13] <marshall> [see web site]
[05:39:22] <marshall> The problem statement
[05:39:37] <marshall> describes the class of beneficiaries
[05:40:00] <marshall> we have to agree that there is a problem to be solved
[05:40:09] <marshall> and a means of solving it
[05:40:21] <marshall> and then Mark, the AD, goes off to decide
[05:41:08] <marshall> Mark pointed out that we need a threat analysis
[05:41:18] <marshall> for security requirements
[05:41:26] <marshall> Any comments ?
[05:41:41] <marshall> [I will relay jabber comments !]]
[05:41:45] <marshall> Al Morton :
[05:42:16] <marshall> We want to modify the 3rd paragraph about the current version of NTP
[05:42:30] <marshall> Karens new slide about the tradeoffs
[05:43:08] <marshall> Chair : We now say, commonly available versions of NTP
[05:43:18] <marshall> Pekka : The charter seems too open ended to me
[05:44:07] <marshall> You might get into a 50 pages requirements document
[05:44:11] --- fparent@jabber.org has left
[05:44:15] <marshall> get consensus on critical issues
[05:44:48] <marshall> Mark T (the AD) : if we can decide now, I would prefer that
[05:45:02] --- sam-xzq has joined
[05:45:13] <marshall> Peter Lothberg : The first sentance looks like marketing
[05:45:31] <marshall> it is IP packet over an IP packet
[05:45:45] <marshall> Chair : It is important to allow PSN networks
[05:46:09] <marshall> Peter : How do you create a end point identifier
[05:46:36] <marshall> Tim Shepherd
[05:46:40] <marshall> :
[05:46:57] <marshall> It would be nice to focus on the most important requirements
[05:47:48] <marshall> what I hear as the most fundamental requirement is the ability to simultaneously transfer from multiple sources
[05:48:08] <marshall> for roughly 1/2 a century we have had different definitions
[05:48:18] <marshall> the rotations of the Earth
[05:48:22] <marshall> the atomic clocks
[05:48:56] <marshall> [Editorial comment : this is nonsense]
[05:50:42] <marshall> Joe Touch :
[05:50:53] <marshall> We have jumped 3 orders of magnitude into a problem
[05:51:08] <marshall> first question is
[05:51:14] <marshall> should this be a working group
[05:51:40] <marshall> this is a good place to standardize solutions
[05:51:53] <marshall> but a bad place to standardize solutions
[05:52:43] <marshall> Chair : So, we should let each organization do it's thing and come back in 2 years and fight it out here ?
[05:52:44] <shep> Explain why you say "this is nonsense".
[05:53:53] <shep> It's not nonsense at all if you are serious about nanosecond synchronization.
[05:53:54] <marshall> Because the rotation of the Earth is not time and there are very clear IAU standards that specify what IAT means, what UTC means and what UT1 is used for. Google on IERS standards
[05:54:25] <marshall> I have done nanosecond synchronization and also
[05:54:31] <marshall> micro second UT1
[05:54:37] <marshall> and they are not the same at all
[05:54:50] <marshall> now, back to the program
[05:56:01] <marshall> Kurtis : When it comes to the requirements
[05:56:02] <shep> Ah, you wish to exclude from such protocols considering rotational position of the earth within the definition of time.
[05:56:17] <marshall> it IS excluded from the definition of time
[05:56:21] <marshall> since 1968
[05:56:41] <shep> But that is the traditional definition of time.
[05:57:23] <marshall> It is not accurate enough for modern physics
[05:57:37] <marshall> by about 6 or 8 orders of magnitude
[05:57:41] <shep> Sure.
[05:57:59] <andrewdmcgregor@jabber.psg.com> Only 6 or 8? More like 20...
[05:58:35] <marshall> depends on the time scale
[05:58:55] <andrewdmcgregor@jabber.psg.com> Still, it is an important service to provide correct translation from linear time into UTC, even on a movign platform.
[05:59:06] <marshall> on 1 -10 years, it's good to order 10^-7
[05:59:15] <marshall> and time scales are good to 10^14
[05:59:27] <marshall> no better than 10^-16
[05:59:40] <marshall> any case, back to the program
[05:59:47] <andrewdmcgregor@jabber.psg.com> Yep, but I worked on a physics experiment that had frequency resolution at 10^-29
[05:59:48] <marshall> Mark (the AD)
[06:00:08] <marshall> Security is a really tough issue
[06:00:36] <marshall> there is a great deal of consensus to keep the generality of the Internet
[06:00:39] <marshall> present in your mind
[06:01:22] <marshall> One of the things that ? reminded me of in the 3WPE charter is that it is not just IP in IP but IP in MPLS
[06:01:39] <marshall> Question : Are we going to invent a new protocol ?
[06:01:57] <marshall> Chair : We have standards track solution drafts as a goal
[06:02:10] <marshall> we are not going to decide this here
[06:02:12] <marshall> specifically
[06:02:28] <marshall> Question : The last sentence in the charter
[06:02:35] <marshall> coordinate with other SDOs
[06:02:46] <marshall> we should not just coordinate but work together
[06:03:10] <marshall> Kurtis : There is a formal relationship now
[06:03:21] <marshall> there is a well defined process if more is needed
[06:03:35] <marshall> this is up to the IAB (speaking as an IAB member)
[06:03:49] <marshall> this is not something you put in the charter
[06:03:59] <marshall> so this is deliberately vague
[06:04:17] <marshall> Chair : There is a large spectrum of potential cooperation
[06:04:29] <marshall> MEGACO had the same document come out in 2 places
[06:04:37] <marshall> PWE3 just
[06:04:41] <marshall> had liasons
[06:05:16] <marshall> Question : We should prioritize between the requirements on timing
[06:05:35] <marshall> one example, is being able to provide telecom grade synchronization
[06:05:43] <marshall> is the most important thing
[06:05:48] <marshall> in my mind
[06:05:55] <marshall> there were many other problems
[06:06:04] <marshall> we should select one to solve first
[06:06:11] <marshall> Kurtis :
[06:06:24] <marshall> I am not sure that some of these requirements are that different
[06:06:45] <marshall> we are trying to limit the solution space by listening to 2 hours
[06:06:49] <marshall> of presentations
[06:06:57] <marshall> I am not sure that that is fair
[06:07:01] <marshall> or practical
[06:07:09] <marshall> I think that there is a lot more work to be done
[06:07:19] <marshall> Joe Touch : Dramatically change the charter
[06:07:30] <marshall> What are the requirements for
[06:07:43] <marshall> what those issue are
[06:07:52] <marshall> [what issues ?]
[06:08:09] <marshall> Sounds like an IRTF problem not a IETF problem
[06:08:36] <marshall> I saw no information today or before today to say that we know what the problem is we are trying to solve
[06:09:00] <marshall> Sharon : Given NTP I would like to see something about transisition strategies in the charter
[06:09:30] <marshall> Question : The charter needs to be focused so you can go in a particular direction
[06:09:44] <marshall> you need to integrate the solution with IETF transport protocol
[06:10:26] <marshall> if it is not focused you will not get a solution
[06:10:55] <marshall> Question : There is a need for a general solution, which could maybe be done by NTP
[06:11:17] <marshall> We can certainly do much, much better than we are doing today.
[06:11:33] <marshall> The piece we do not capture is the need to modularize this
[06:11:47] <marshall> all the work in the past has been highly stove piped
[06:12:02] <marshall> and, that makes it hard to move to other problem spaces
[06:12:04] <marshall> Greg :
[06:12:26] <marshall> Regardless of the name of the group, there are a number of issues associated with IP timing
[06:12:39] <marshall> in general. There are number of fractured
[06:12:48] <marshall> solution spaces
[06:13:10] <marshall> the creation of a modular NGN NTP will allow us to create a framework for solving
[06:13:21] <marshall> a number of different problems in the future
[06:13:46] <marshall> for system engineering purposes and astronomical purposes - by
[06:14:02] <marshall> creating a modular environment we can address this
[06:14:05] <marshall> Kurtis :
[06:14:17] <marshall> A few people said that the primary customer would be telecoms
[06:14:31] <marshall> I don't think that that is necessarily true
[06:14:37] <marshall> the banking industry
[06:14:40] <marshall> air traffic control
[06:14:44] <marshall> military
[06:14:49] <marshall> all would benefit
[06:14:54] --- brabson has left: Replaced by new connection
[06:15:08] <marshall> we have an overwieght of telecom particpants
[06:15:10] <marshall> that said
[06:15:26] <marshall> whether this is IRTF or IETF
[06:15:43] <marshall> I think that this is an IETF
[06:15:49] <marshall> we are in an engineering space
[06:16:00] <marshall> this should be modular
[06:16:11] <marshall> so we can do changes in the future
[06:16:28] <marshall> Question : One thing mentioned is network management
[06:16:57] <marshall> not mentioned
[06:17:30] --- josoinin has joined
[06:17:33] <marshall> Question : I would like to find out whether the existing protocols can
[06:17:44] <marshall> fulfill the requriements
[06:17:55] <marshall> we need an evaluation of protocols
[06:18:13] <marshall> Chair : I think that the statement about NTP was an editing problem
[06:18:40] <marshall> what remains, if we look at the problem statement are there solutions ?
[06:19:12] <marshall> and I think that there are 10 groups today who have solutions or who are working on solutions
[06:19:21] <marshall> and if we put them in this room
[06:19:30] <marshall> you would have a solution
[06:19:55] <marshall> Joe Touch : If what you are talking about is true then this is not in the IETF space
[06:20:07] <shep> what did person away from the mic say?
[06:20:13] <marshall> Greg : As the person who put the NTP spec together, I don't
[06:20:23] <marshall> think that NTP can address these problems
[06:20:57] <marshall> Joe Touch : I am still not convinced that these problems should be done here
[06:21:36] <marshall> Question : The results for NTP today are for frequency transfer not time transfer. There was stuff added to 1588 that may be needed for time
[06:22:04] <marshall> Peter : Of all of the requirements
[06:22:14] <marshall> I see today
[06:22:49] <marshall> I don't see anything that we can't do with solutions we have today
[06:23:14] <marshall> Kurtis : We should add a threats analysis document
[06:23:24] <marshall> floor - and Karen's tradeoff list
[06:23:31] <marshall> Mark (the AD) :
[06:23:34] <marshall> Comments
[06:23:39] <marshall> threat analysis
[06:23:42] <marshall> management
[06:23:46] <marshall> interoperability
[06:24:09] <marshall> Karen's overview of tradeoffs of PtP NTP
[06:24:17] <marshall> I heard modularization
[06:24:28] <marshall> I heard discssion of charter needing focus
[06:24:45] <marshall> modularization effort might lead to focus
[06:25:42] <marshall> Can I get some hands on the modularization effort
[06:25:46] <marshall> [hands raised]
[06:25:59] <marshall> I am not sure that that needs a working group
[06:26:22] <marshall> so, if I can get that effort...
[06:26:36] <marshall> we don't need another BOF
[06:26:47] <marshall> Am I on the mark ?
[06:27:00] <marshall> Joe Touch : What is the problem we are trying to solve ?
[06:27:22] <marshall> So, I can't tell you if you have covered the parameters we need to
[06:27:35] <marshall> Chair : Have you read the problem statement ?
[06:27:43] <marshall> Joe : Yes.
[06:27:54] <marshall> But I don't that there is agreement on this.\
[06:28:26] <marshall> Stuart : There is a book
[06:28:37] <marshall> that says that you need high frequency time
[06:28:46] <marshall> but, do we need it on the Internet
[06:29:14] <marshall> Mark (AD) : I disagree that we need to create a list of normative statements on the problem [?]
[06:29:23] <marshall> I get the feeling that there is a problem that
[06:29:32] <marshall> NTP v4 is not solving
[06:29:44] <marshall> and there is other work in other SDOs
[06:30:05] <marshall> So this is engineering
[06:30:49] --- AWGY has left
[06:31:48] <marshall> Stuart : Is there a general interest ?
[06:32:25] <marshall> Mark : The classical question to ask is :how many people believe that this charter is sufficient to form a working group with the changes mentioned above"
[06:32:27] <marshall> ?
[06:32:54] <marshall> With a first objective of modularization as I discussed ?
[06:33:02] <marshall> Yes ?
[06:33:04] <marshall> No ?
[06:33:15] <marshall> Not enough information ?
[06:33:29] <marshall> [No No's but some not enough's]
[06:34:33] <marshall> Mark : How many people are willing to work on this ?
[06:35:42] --- shep has left
[06:35:54] --- josoinin has left
[06:35:55] --- sam-xzq has left
[06:37:02] <tsavo_work@jabber.org/Meebo> I missed the final conclusion, there seemed to be some people in favor of wg?
[06:37:34] <andrewdmcgregor@jabber.psg.com> Yes, many
[06:37:53] --- andrewdmcgregor@jabber.psg.com has left
[06:38:07] <tsavo_work@jabber.org/Meebo> thanks
[06:40:41] --- marshall has left
[06:42:01] --- tsavo_work@jabber.org/Meebo has left
[06:43:05] --- geoff has left