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

Hello Mark,

Good point (once again ;-)
Yes, it seems to make sense to have two 32 bit fields, and let receivers 
choose to
either process the two 32 bit parts or only one of them. The only little 
problem is that
if a future timing info has to be 64 bit long, then two "Use" flags will 
have to be defined
instead of one. With the 16 bit "Use" field, then "only" 8 64 bit 
options can be defined.
Is this sufficient? Today the answer is clearly yes (5 possibilities 
left if SCT/ERT/SDF
are finally 64 bit long). So I'm in favor of this change.
Cheers,

   Vincent

Mark Watson wrote:

>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)
>
>_______________________________________________
>Rmt mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmt
>
>
>  
>