EXT_TIME: a new HE for timing information in LCT

-----------------------------------------------------------------------
Modifications to draft-ietf-rmt-bb-lct-revised-01.txt for a new EXT_TIME
			header extension
-----------------------------------------------------------------------


I - General goals (updated to take into account Mark's comment)
---------------------------------------------------------------


Goals
-----

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.

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).

The new HE, called EXT_TIME is used to carry
timing information of various types/semantics, defined below.

We are proposing a general HE for LCT and NORM, not something
specific to LCT.
==> The same (or similar) text could be added in the NORM
specification.


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, but nobody seems to use SCT/ERT...


Notes
-----

NOTE_1: unit in case of ERT:
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 here also. High 32 bits are in
seconds; if one wants better resolution, then specifying an ERT-Low
flag/field could be possible in the future, but today we see no
benefit in doing it.



===============================================================================


II - Modifications to draft-ietf-rmt-bb-lct-revised-01.txt
----------------------------------------------------------


3.

COMMENT: Updated text to take into account the fact that timing information
COMMENT: is now provided through a HE. Added a sentence for SLC.
COMMENT: Modifications start with a "|".


   The LCT header provides a number of fields that are useful for
   conveying in-band session information to receivers.  One of the
   required fields is the Transmission Session ID (TSI), which allows
   the receiver of a session to uniquely identify received packets as
   part of the session.  Another required field is the Congestion
   Control Information (CCI), which allows the receiver to perform the
   required congestion control on the packets received within the
   session.  Other LCT fields provide optional but often very useful
   additional information for the session.  For example, the Transport
   Object Identifier (TOI) identifies which object the packet contains
   data for.  As other examples, flags for indicating the close of the
|  session and the close of sending packets for an object. Header
|  extensions can carry additional fields that for example can be used
|  for packet authentication or to convey various kinds of timing
|  information: the Sender Current Time (SCT) conveys
|  the time when the packet was sent from the sender to the receiver,
|  the Expected Residual Time (ERT) conveys the amount of time the
|  session will be continued for, and Session Last Change conveys
|  the time when objects have been added, modified or removed from
|  the session.


4.2


COMMENT: Updated text to take into account the fact that timing information
COMMENT: is now provided through a HE.
COMMENT: Modifications start with a "|".

      There are several features ALC provides to support the push model.
      For example, the sender can optionally include an Expected
|     Residual Time (ERT) in the packet header extension that indicates the
      expected remaining time of packet transmission for either the
      single object carried in the session or for the object identified
      by the Transmission Object Identifier (TOI) if there are multiple
      objects carried in the session.  This can be used by receivers to
      determine if there is enough time remaining in the session to
      successfully receive enough additional packets to recover the
      object.  If for example there is not enough time, then the push
      application may have receivers report back to the sender to extend
      the transmission of packets for the object for enough time to
      allow the receivers to obtain enough packets to reconstruct the
      object.  The sender could then include an ERT based on the
      extended object transmission time in each subsequent packet header
      for the object.  As other examples, the LCT header optionally can
      contain a Close Session flag that indicates when the sender is
      about to end sending packet to the session and a Close Object flag
      that indicates when the sender is about to end sending packets to
      the session for the object identified by the Transmission Object
      ID.  However, these flags are not a completely reliable mechanism
      and thus the Close Session flag should only be used as a hint of
      when the session is about to close and the Close Object flag
      should only be used as a hint of when transmission of packets for
      the object is about to end.



5.1.  LCT header format

COMMENT: From Figure 1, remove the T and R flags and replace them by two
COMMENT: "Reserved for future use" bits.
COMMENT: New version of figure 1 is:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   V   | C |PSI|S| O |H|Res|A|B|   HDR_LEN     | Codepoint (CP)|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Congestion Control Information (CCI, length = 32*(C+1) bits)  |
       |                          ...                                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Transport Session Identifier (TSI, length = 32*S+16*H bits)  |
       |                          ...                                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Transport Object Identifier (TOI, length = 32*O+16*H bits)  |
       |                          ...                                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Header Extensions (if applicable)              |
       |                          ...                                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Figure 1: Default LCT header format


COMMENT: Add the associated new text for the "Res" bits, just after the
COMMENT: Half-word flag (H):


Reserved (Res): 2 bits

      These bits are reserved for future use.  In this version of LCT
      these bits MUST be set to zero.


COMMENT: - remove the text that specifies the "Sender Current Time present flag (T)"
COMMENT: - remove the text that specifies the "Expected Residual Time present flag (R)"
COMMENT: - remove the text that specifies the "Sender Current Time (SCT)"
COMMENT:   This specification is moved to new section 5.2.2 EXT_TIME Header Extension.
COMMENT: - remove the text that specifies the "Expected Residual Time (ERT)"
COMMENT:   This specification is moved to new section 5.2.2 EXT_TIME Header Extension.



5.2.  Header-Extension Fields

COMMENT: New subsection title

5.2.1 General considerations

COMMENT:   No change in the beginning of section 5.2, except to add a third
COMMENT:   bullet at the very beginning:

   Header Extensions are used in LCT to accommodate optional header
   fields that are not always used or have variable size.  Examples of
   the use of Header Extensions include:

   o  Extended-size versions of already existing header fields.

   o  Sender and Receiver authentication information.

   o  Transmission of timing information.


COMMENT: Then the text remains the same up to the top of page 23.
COMMENT: From that point on, the new text follows:

   The following LCT Header Extensions are defined by this
   specification:

   EXT_NOP, HET=0 No-Operation extension.  The information present in
                 this extension field MUST be ignored by receivers.

		 COMMENT: no change for EXT_NOP

   EXT_AUTH, HET=1 Packet authentication extension Information used to
                 authenticate the sender of the packet.
                 [...]

		 COMMENT: no change for EXT_AUTH

   EXT_TIME, HET=2 Time extension. 
                 This extension is used to carry several types of timing
                 information. It includes general purpose timing information,
                 namely the SCT, ERT and SLC extensions described
                 in the present document. It can also be used for timing
                 information with narrower applicability (e.g. defined
                 for a single Protocol Instantiation or CDP); in this case
                 it will be described in a separate document.

   All senders and receivers implementing LCT MUST support the EXT_NOP
   Header Extension and MUST recognize EXT_AUTH and EXT_TIME, but MAY NOT
   be able to parse their content.


5.2.2 EXT_TIME Header Extension

This section defines the timing header extensions with general applicability.
The time values carried in this header extension are related to the server's
wall clock. The server MUST maintain consistent relative time during a
session (i.e. insignificant clock drift). For some applications, system
or even global synchronization of server wall clock may be desirable,
such as using the Network Time Protocol (NTP) [RFC1305] to ensure actual time
relative to 00:00 hours GMT, January 1st 1900. Such session-external
synchronization is outside the scope of this document.

The EXT_TIME Header Extension uses the format depicted in Figure 3.

    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 = 2   |    HEL >= 1   |         Use (bit field)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       first time value                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...            (other time values (optional)                  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: EXT_TIME Header Extension format


The "Use" bit field indicates the semantic of the following 32 bit time value(s).
It is divided into two parts:
 o 8 bits are reserved for general purpose timing information. These
   information are applicable to any protocol which makes use of LCT.
 o 8 bits are reserved for PI specific timing information. These
   information are out of the scope of this document.
The format of the "Use" bit field is depicted in Figure 4.

                     2                                       3
     6   7   8   9   0   1   2   3   4   5   6   7   8   9   0   1
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |SCT|SCT|ERT|SLC|   reserved    |          PI-specific          |
   |Hi |Low|   |   |    by LCT     |              use              |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Figure 4: "Use" bit field format (close-up of Figure 3)


The fields for the general purpose EXT_TIME timing information are:

Sender Current Time (SCT): SCT High flag, SCT Low flag, corresponding time
value (one or two 32 bit words)

	This timing information represents the current time at the sender
	at the time this packet was transmitted.

	When the SCT-High flag is set, the associated 32 bit time value
	provides an unsigned integer representing the time in seconds of
	the sender's wall clock. 
	In the particular case where NTP is used, these 32 bits provide
	an unsigned integer representing the time in seconds relative to
	00:00 hours GMT, January 1st 1900, (i.e. the most significant 32
        bits of a full 64 bit NTP time value). In that case, handling of
	wraparound of the 32 bit time is outside the scope of NTP and LCT.

	When the SCT-Low flag is set, the associated 32 bit time value
	provides an unsigned integer representing a multiple of 1/2^^32
	of a second, in order to allow sub-second precision.
	When the SCT-Low flag is set, the SCT-High flag MUST be set too.
	In the particular case where NTP is used, these 32 bits provide
	the 32 least significant bits of a 64 bit NTP timestamp.


Expected Residual Time (ERT): ERT flag, corresponding 32 bit time value

	This timing information represents the sender expected residual
	transmission time for the current session or for the transmission
	of the current object. If the packet containing the ERT timing
	information also contains the TOI field, then ERT
	refers to the object corresponding to the TOI field, otherwise it
	refers to the session.

	When the ERT flag is set, it it expressed as a number of
	seconds. The 32 bits provide an unsigned integer representing
	this number of seconds.


Session Last Changed (SLC): SLC flag, corresponding 32 bit time value

	The Session Last Changed time value is the server wall clock time,
	in seconds, at which the last change to session data occurred.
	That is, it expresses the time at which the last (most recent)
	Transport Object addition, modification or removal was made for
	the delivery session. In the case of modifications and additions it
	indicates that new data will be transported which was not transported
	prior to this time. In the case of removals, SLC indicates that some
	prior data will no longer be transported.

	When the SLC flag is set, the associated 32 bit time value provides
	an unsigned integer representing a time in second.
	In the particular case where NTP is used, these 32 bits provide
	an unsigned integer representing the time in seconds relative to
	00:00 hours GMT, January 1st 1900, (i.e. the most significant 32
        bits of a full 64 bit NTP time value). In that case, handling of
	wraparound of the 32 bit time is outside the scope of NTP and LCT.

	In some cases, it can be appropriate that a packet containing a
	EXT_TIME Header Extension with an SLC information also contain a
	SCT-High information.


Reserved by LCT (4 bits):
	In this version of LCT, these bits MUST be set to zero.


PI-specific use (8 bits): 
	These bits are out of the scope of this document.
	The bits that are not specified by the PI built on top of LCT
	SHOULD be set to zero.


Several "time value" fields can be present in a given EXT_TIME Header
Extension, as specified in the "Use-field". When several "time value"
fields are present, they MUST appear in the order specified by the
associated flag position in the "Use-field": first SCT-High (if present),
then SCT-Low (if present), then ERT (if present), then SLC (if present).

The total EXT_TIME length is carried in the HEL, since this Header
Extension is of variable length. It also enables clients to skip this
Header Extension altogether if not supported (but recognized).



8. Security Considerations


The rudimentary time synchronization feature made possible by
the SCT mechanism, or the ERT signaling feature can both be
subject to attacks. Indeed an attacker can easily de-synchronize clients,
sending erroneous SCT information, or mount a DoS attack by informing
all clients that the session (resp. a particular object) is about to
be closed. It is therefore RECOMMENDED that measures be taken to
prevent receivers from accepting incorrect packets, e.g. by using a
source authentication and content integrity mechanism.



9.2.  LCT Header Extension Type registration

   This document registers three values in the namespace "ietf:rmt:lct:
   headerExtensionTypes:variableLength" as follows:

                 +-------+----------+--------------------+
                 | Value | Name     | Reference          |
                 +-------+----------+--------------------+
                 | 0     | EXT_NOP  | This specification |
                 |       |          |                    |
                 | 1     | EXT_AUTH | This specification |
                 |       |          |                    |
                 | 2     | EXT_TIME | This specification |
                 +-------+----------+--------------------+