FLUTE, ACL and timestamps and wall clocks

As everyone knows, we have an optional 32-bit "Sender Current Time" to
use with ALC and LCT. It's expressed in milliseconds since the start of
the session - i.e. the sender chooses when to set it to zero and no
packet gets labelled with a negative value. There is a wraparound at
49.71 days which we assume implementers understand they have to deal
with. This time is totally in-band for a session and has no baring on
any other clock (other than the length of a second being equal) without
additional specification.

For example, one might specify that the sender must set the SCT=0 at the
advertised session start time (e.g. from an SDP start time), and that
the sender must be able to synchronise itself with a common clock (i.e.
so that the abstract entity which set the time in the advert/SDP is
synchronised with this), and one might say that a +/-1 second tolerance
is allowed (or something reasonable for the deployment in question).
These are the kind of sensible sets a mobile broadcast system might
implement.

However, another alternative is to provide a time stamp relative to
absolute (wallclock) time <and then make all the same requirements about
synchronising servers and other abstract entities>.

So the point is: What about an optional NTP wall clock time stamp header
extension? Not only does this give a common reference against (e.g.)
SDP, it also does for media payout - such that (e.g.) RAP time stamped
media can be cross-checked with FLUTE-media and the client can do
"something great" (like play out, caching and storage) in a synchronised
way.

I'm thinking about an I-D on such an extension header so I want
arguments as to why this is a bad idea (as I don't see any yet) and
maybe why a 32-bit millisecond SCT was more interesting than a middle or
most significant 32-of-64 bit NTP timestamp.


Cheers, Rod.