Re: Comment on LCT draft

There is less ambiguity than one might think with this (perhaps no ambiguity).  If you read the section about the TOI you will see that the TOI field MUST be used in all packets if more than one object is to be transmitted in the session, i.e., the TOI field is either present in all the packets of a session or is never present.  Given this, the ERT within a session is essentially always the end of the transmission of the current object:

(1) If there is more than one object in the session the TOI MUST be in all packets and thus the ERT is the end time of transmission of each object.
(2) if there is only one object in the session
    (a) if the TOI is used for the object then the ERT is the end time of transmission of that object.
    (b) if the TOI is not used then the ERT is the end time of transmission of the session, which presumably is the end time of transmission of that object.

It seems that  the only ambiguity is if there is one object in the session and some of the packets for that object carry the TOI and others don't (this does not seem disallowed by the MUST, despite the "i.e. ..." statement which says it is not allowed).  In this case, it still seems that the ERT will always refer to the end time of the transmission of that object/session (they should be the same).  But, perhaps this could be clarified by including language that says that for a particular object the TOI must be in all packets pertaining to that object or the TOI must not be in all packets pertaining to that object (this seems like a good restriction for other reasons as well, i.e., it is the natural way to do this and to do something different in the case of transmission of one object seems pretty nonsensical, and the "i.e. ... " statement says this is true as well, even if it doesn't logically follow from the MUST).

Perhaps even easier is to just change the definition of ERT to say that it is the end transmission of the object, since practically this is what it is defined to be right now, although in a convoluted way.

So, a concrete suggestion:

Change: The
         TOI field MUST be used in all packets if more than one object
         is to be transmitted in a session, i.e. the TOI field is either
         present in all the packets of a session or is never present.

To: The
         TOI field MUST be used in all packets in a session or none of the packets in a session.
         The TOI field MUST be used in all packets in a session if more than one object
         is to be transmitted in a session.

Change:  Expected Residual Time (ERT): 0 or 32 bits

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

To: Expected Residual Time (ERT): 0 or 32 bits

         This field represents the sender expected residual transmission
         time for the transmission of the current object, measured in units of 1ms.

Mike


On 4/9/09 11:31 AM, "Watson, Mark" <[email protected]> wrote:

All,

I received the following comment in the IESG Last Call for LCT:

"Section 5.2.2 specifies an overloading of the ERT flag and ERT field:

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

This overloading seems to be potentially dangerous; it prematurely
excludes the possibility to specify a session ERT value whenever
a session carries multiple objects and hence needs to make use of
TOI in every packet.
Wouldn't it be a more clean solution to spent another bit and
optional field, to achieve a clean separation of both Object ERT
and Session ERT ?"

This seems reasonable to me, except that I would not change the semantics of the existing bit (for backwards compatibility reasons), but rather add an additional "Expected Session Residual Time" field. However I was not involved in any of the original discussions on the EXT_TIME header, so I would like to know if there are any comments on this from those that were (or indeed anyone else).

...Mark

_______________________________________________
Rmt mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rmt