RE: New HE for timing information, including SCT/ERT

Vincent & co.

The proposal to remove SCT and replace with something like this seems a
good one to me.

I have a small comment, which is that the way you have reserved bits for
future 64-bit times does not make much sense to me - you might as well
say that additional bytes in the header after the entries that the
receiver recognizes are ignored - it would have the same effect.

Also, if I introduce in future a 64-bit version of the SCT, but I want
to remain backwards compatible with my existing receivers, then I need
to send both 64-bit and 32-bit versions - which seems wasteful.

Instead, we could specify that every flag in the 32 bit 'use' field
indicates the presence of absence of a 32-bit field and then define:

Bit-0: SCT (High) flag - high 32 bits of SCT (seconds)
Bit-1: SCT (Low) flag - low 32 bits of SCT (fraction of seconds)
Etc.

Support of the low order portions of the 64 bit fields would of course
be optional for receivers.

Because every field is 32 bits then the receiver can easily parse out
the fields it wants without having to understand what the others are
(and in particular can parse out the 32 bit versions of fields whether
the sender has sent 32 or 64 bits).

...Mark



-----Original Message-----
From: Vincent Roca [mailto:[email protected]] 
Sent: Monday, December 12, 2005 12:56 AM
To: Rmt@ietf. org; Mark Watson
Cc: Toni.paila; [email protected]; [email protected]; Vincent
Roca
Subject: New HE for timing information, including SCT/ERT

Dear All, dear Mark,

After an internal discussion on the SCT/ERT topic and on the
draft-jansky-alc-timestamp-extension-00.txt proposal, we came
to the following conclusions. As usual, comments are welcome.
Best Regards,

   Toni, Rod, Imed, Vincent

---------

1- we are proposing to remove the SCT and ERT fields from the
LCT header and to create a new Header Extension dedicated to
timing aspects.

2- since the SCT/ERT field are removed, the associated T and
R one bit flags are also removed from the LCT header. These
two bits can now either be "reserved for future use" or be
added to the "PSI" bits (for a total of 4 PSI bits then).
((Toni is in favor of 4 PSI bits))

3- the new HE is used to carry timing information of various
types/semantics, defined below.

4- we are proposing a general HE, not something specific to
FLUTE, even if some use-cases are more related to the FLUTE
CDP. In particular, this extension can also be used with NORM,
when the associated use-case makes sense.
((TO DO: ask the opinion of the NORM authors))

5- the LCT HE uses the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   HET = 65    |    HEL >= 2   |         Use (bit field)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       first time value                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...            (other time values (optional)                  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.1- the "Use-field" of the LCT HE indicates the semantic of
the following time value(s)
0x00 = Unspecified
0x01 = SCT-flag (32 bit time value)
0x02 = ERT-flag (32 bit time value)
0x04 = SDF-flag (32 bit time value)
	(corresponds to the "Session Last Change" proposal
	of draft-jansky-alc-timestamp-extension-00.txt)
0x08 = reserved flag, set to 0
0x10 = reserved flag, set to 0
0x20 = reserved flag, set to 0
0x40 = reserved flag, set to 0
0x80 = reserved flag, set to 0
0x0100 = reserved flag, set to 0
....
0x8000 = reserved flag, set to 0

5.2- in case of SCT and SDF, the time value transported in the
HE are the 32 most significant bits of a 64 bit NTP timestamp
(number of seconds since January 1900).

5.3- in case of ERT, the time value transported in the HE is
the number of (TBD: seconds or milliseconds, see NOTE_3 below)
till the end of session.

5.4- several time "time value" fields can be present in a given
HE, depending on the "Use-field". When several "time value" fields
are present, they must appear in the order specified by the
associated bit value:
SCT (if present) - ERT (if present) - SDF (if present) - etc.

5.5- current time values are 32 bit long, but future values
might be 64 bit long, e.g. to carry a full 64 bit NTP timestamp.
"Use field" 0x01 to 0x80 are reserved for 32 bit time values,
while "Use field" 0x0100 to 0x8000 are reserved for 64 bit time
values.
The motivation for this split is to enable clients to skip
"time values" corresponding to Use cases they don't support
while being able to process supported time values (if any).

5.6- the total HE length is carried in the HEL, since the current
HE is of variable length. It also enables clients to skip this
HE altogether if not supported.


6- in case of FLUTE, the FDT Expiry time and the SCT/"Session
last change" MUST refer to the same clock at the sender.

7- using NTP time means that the sender and clients are
synchronized, at least loosely (loosely can be sufficient since
time is often in unit of seconds).
(NB: Note that this is also an assumption we have with the TESLA
authentication scheme...)


---------------

NOTE_1: on the use of the current SCT field in the LCT header
(Toni) I've been asking around and my feeling is that nobody really
needs SCT.
(Toni) At least OMA BCAST, DVB IPDC, 3GPP MBMS and 3GPP2 BCMCS.
(Toni) Regarding these groups, my opinion is that we can safely remove
SCT.


NOTE_2: motivations for having a separate HE dedicated to timing
+ it simplifies the LCT header, removing unused fields from the
"fast header processing path"
+ it adds two more "PSI or reserved" bits (need to choose which
one is the best solution).
+ it logically groups all timing stuff in the same framework
+ it eases the addition of new functionalities to ALC/FLUTE/NORM/
But:
- it's not backward compatible at all! Is it really a problem
(see NOTE_1)?


NOTE_3: unit in case of ERT (Rod/Imed):
Current spec says it's in milliseconds, but is that really
appropriate? With a 32 bit field, in milliseconds, we wrap at 49.71
days.
Changing ms to second mean we wrap at 49710 days = 136.1 years.
The proposal is to go for NTP style - 32 bits is in seconds; if you
want better resolution use 64 bits where the most significant 32 bits
are seconds and the least are a multiple of 1/2^^32 of a second.
This can be done by specifying a new Use value (e.g. 0x0100=ERT_64BITS)