[ippm] Re: OWAMP protocol

[stanislav shalunov <[e-mail]>]

Roland,

Your message seems to be mostly about the OWAMP protocol itself rather
than the particular implementation.  I have added [e-mail] (IETF
IP Performance Metrics working group), the IETF WG responsible for the
protocol, draft-ietf-ippm-owdp-17.txt (now in ``publication
requested'' state) to the CC list.

Roland Karch <[e-mail]> writes:

> We have slightly more detailed information about the timesource
> involved in the tests.  Besides the estimated error and the
> timesource (stratum 1?) we also stored the type of the sender's
> timestamps (us vs. ns) and some integrity checks (e.g. packet size).

The protocol needs to be applicable to a wide range of scenarios.
Some system-dependent information about the time source, would,
therefore, be lost in any case.  (Can't include everything for every
possible system.)  I believe that what the protocol has now strikes a
reasonable balance: most implementations should be able to come up
with the information, and it describes most of the important stuff
about the time source.  Note that NTP is not the only possible time
source for OWAMP implementations.

> On second thought, I think it's possible that we just dispose of the
> additional data and make do with just the clock info the protocol
> provides. I have one problem with your choice of format for the
> timestaps though: We'll run into problems in about 30 years from
> now. But that's maybe something that the NTP folks should fix. ;-)

The NTP folks seem to have already done so, or so David Mills says.
The arithmetic with timestamps 30 years from now would need to be a
little funny (add epoch duration if negative), but this is the same
Z/nZ arithmetic that's used in, say, TCP sequence numbers wraparound.
Since the epoch is large enough, there's no need to worry about doing
the right modulo just yet, but that can always be done.

> Excellent, that's (almost) how I would describe a part of our packet
> grouping problem. One thing I'd avoid is to have 0 waiting time between
> test packets. I've seen some interesting effects, just because the
> sender actually queued packets faster than it could send them out on our
> system.

In the protocol specification, this is left up to the user.  The user
can specify zero time between packets (e.g., for packet train
measurements).  If that works poorly, the user is free to specify some
other time.

> That's an interesting way to solve these problems. As I mentioned once,
> we try to avoid collisions of packets completely by either negotiating
> or centrally assigning a global schedule for the measurement slots. I
> can see a way to use OWAMP-control for the latter, centralized case. How
> to efficiently negotiate a test without that entity still poses a
> problem for me.

Periodic streams have long been known (since RIP times) to tend to
synchronize over time.  The OWAMP specification lets you send both
Poisson and periodic streams (and arbitrary other ones), but this
should be taken into consideration.

> Do you think it would be possible within the protocol to _efficiently_
> negotiate a common starting time when both ends have sets of timeslices
> available, but which may differ in most cases? In my opinion a simple
> ACK/NACK type of negotiation could introduce a lot of round-trips for
> that scenario.

The Internet is global.  Having a central authority negotiate sending
times for every test packet doesn't seem feasible.

> I think we'll handle our case of permanent measurements as a special
> case of this. Maybe by specifying a special value of 2^32-1 as the
> number of packets? The implementation should then be able to take care
> of it like I want to see it.

You could also do a sequence of measurement sessions, with the time
between measurement sessions distributed identically to the time
between packets within a test session.


-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

Sex is the mathematics urge sublimated.                 -- M. C. Reed.

_______________________________________________
ippm mailing list
[e-mail] 
https://www1.ietf.org/mailman/listinfo/ippm