[ntpwg] draft minutes from Vancouver NTP WG meeting

[Danny Mayer]

Shane Kerr wrote:
> Danny,
> 
>> Personally, I don't care what the WG is called, though TICTOC is still a
>> BOF rather than a WG. There are different issues being addressed in the
>> two groups and if that means two subgroups under an umbrella group,
>> that's fine. The current TICTOC seems to be concerned about IEEE1588v2
>> and support for it. I'm sure there's more than that but it didn't come
>> through very well. From NTP's point of your that's something several
>> levels below the one that NTP operates on and therefore by it's very
>> nature will have a more restricted applicability. I suspect that NTP
>> would probably implement 1588 as a refclock.
>>
>> Outside of IEEE1588v2 what does TICTOC want to get done? The same
>> question about NTPv4, autokey and MIB needs to be asked of the NTP WG. I
>> do know of one authentication proposal that has been raised but it needs
>> to be drafted.
> 
> I was at the TICTOC BoF, and some of the ideas were interesting to me (as a
> non-time guy):
> 

Unfortunately, I couldn't be there but I was listening on the audio
relay. I did have to go to a staff meeting during the latter part of the
meeting and was amazed the the meeting was still going on when I
returned an hour later!

> - Using different paths for time than for other network activity (since we care
>   about jitter not delay):
> 

Well we do care about delay if it's asymmetric since the calculations
can make no other assumptions that might be valid. Remote servers are
likely to have asymmetric delays since the return packet can get routed
any way. Local on-LAN delays are most likely to be symmetric. The
biggest problem is measuring the asymmetry.

> - Recording the delays introduced by routers and switches in the path a packet
>   takes from one point in the network to the other to give more accurate time.
> 

The problem that I see with this is that it ignores the propogation time
of the medium, be it fiber, copper, wireless or something else. Each of
these medium will have different propogation times. In addition you will
have older routers and switches in the path that won't recognize that
they have to add their own delay and just forward the packet. Consider
the Interplanetory Internet for example. Sending a packet from a
spacecraft orbiting Mars to a station on Earth, for example, has very
long delays AND asymmetry since the  returned packet will be returned
from a different location on Earth than when it arrived AND the position
of the spacecraft will have changed. I realise that this is an extreme
example (well today it is, tomorrow it will be commonplace) but it gives
you an idea of what we have to struggle with.

> I would say that TICTOC did *not* seem to be concerned only with IEEE 1588,
> although one message I came away with was that IEEE 1588 comes out of a more
> experimental direction than most IEEE standards that the IETF deals with, and so
> is very open to working with other groups on making it more useful.
> 
> If you didn't see them, slides are available at:
> 

I followed them during the meeting so I have seen them.
> http://www3.ietf.org/proceedings/07dec/slides/tictoc-0/
> http://www3.ietf.org/proceedings/07dec/slides/tictoc-1/
> http://www3.ietf.org/proceedings/07dec/slides/tictoc-2/
> http://www3.ietf.org/proceedings/07dec/slides/tictoc-3/
> http://www3.ietf.org/proceedings/07dec/slides/tictoc-4/
> 
> My basic sense of the room was that people are interested in doing time-related
> work, but don't know where to do that at the IETF, hence TICTOC.
> 

We'd be happy to work with them. I just need to understand their problem
space.

Danny

> --
> Shane
>