Subject: [Rmt] FLUTE, ACL and timestamps and wall clocks

From: [email-masked]
Date: Wed, 17 Aug 2005 16:21:38 +0300

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.

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: [email-masked]
Date: Fri, 19 Aug 2005 10:45:01 +0300

>such that (e.g.) RAP time stamped media can be cross-checked 
                  ^^^
RTP not RAP - though rap over RTP might be to someone's taste :) 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>Sent: 17 August, 2005 16:22
>To: [email-masked]
>Subject: [Rmt] 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.
>