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

Also: Let's make the ERT in seconds, or else are we going to make it
bits 22-53 (of 0-63) of an NTP to make it "almost milliseconds"? (hint:
rhetorical question:)

Cheers, Rod.

PS Just 'cos Imed and me have the same MS exchange "(Nokia-NRC/Tampere)"
stamp on our emails does mean our comments need aggregating into a joint
Rod/Imed persona - we disagree too :) 


>-----Original Message-----
>From: Walsh Rod (Nokia-NRC/Tampere) 
>Sent: 13 December, 2005 16:27
>To: 'ext Vincent Roca'; Rmt@ietf. org; Mark Watson
>Cc: Paila Toni (Nokia-M/Espoo); Bouazizi Imed (Nokia-NRC/Tampere)
>Subject: RE: New HE for timing information, including SCT/ERT
>
>Hi All
>
>The proposal assumes no one has the requirement to signal more 
>than a single timestamp in a single packet.
>
>If you have this requirement, speak up or be left in need.
>
>Cheers, Rod.
>
>
>>-----Original Message-----
>>From: ext Vincent Roca [mailto:[email protected]]
>>Sent: 12 December, 2005 10:56
>>To: Rmt@ietf. org; Mark Watson
>>Cc: Paila Toni (Nokia-M/Espoo); Walsh Rod 
>(Nokia-NRC/Tampere); Bouazizi 
>>Imed (Nokia-NRC/Tampere); 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)
>>