Subject: [Rmt] Comment on LCT draft

From: "Watson, Mark" <[email-masked]>
Date: Thu, 9 Apr 2009 11:31:30 -0700

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

---

From: "Luby, Michael" <[email-masked]>
Date: Fri, 10 Apr 2009 10:21:14 -0700

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-masked]> wrote:

All,

...Mark

---

From: "Watson, Mark" <[email-masked]>
Date: Fri, 10 Apr 2009 10:29:03 -0700

Mike,

I agree with your proposals.

The original comment argued for the possibility to specify an expected end time for the session when more than one object is present, which is not currently possible (with or without the changes below). Is such a capability useful ?

...Mark

On 4/10/09 10:21 AM, "Luby, Michael" <[email-masked]> wrote:

Change: The

To: The

Mike

All,

...Mark

---

From: "Luby, Michael" <[email-masked]>
Date: Fri, 10 Apr 2009 10:44:27 -0700

Mark,
I think the original comment was more focused on the ambiguity/overloading of the ERT rather than on arguing that there should be the possibility to specify an expected end time for the session.  I would argue that if someone really wanted this capability then they would have already lobbied for it within the RMT, and it is a bit late to make these kinds of changes now without a good reason, and likely to cause additional work with no clear gain unless someone really sees a reason for doing this.  That said, if people think that it is a good idea to be able to signal the expected end of the session in-band then we could go forward with the work to specify this (there are some reserved bits in the LCT header that could be used to signal this).  I think actually we might have had a way to signal the end of session time in an earlier draft but we took it out (but I might be wrong on this).
Mike

On 4/10/09 10:29 AM, "Watson, Mark" <[email-masked]> wrote:

Mike,

...Mark

Change: The

To: The

Mike

All,

...Mark

---

From: "Watson, Mark" <[email-masked]>
Date: Fri, 10 Apr 2009 10:48:28 -0700

Mike,

Ok, so my proposed disposition of this comment is to say that we will clarify the ERT to always be the end time of the current object and that the possibility to separately specify the end time of the current session is not believed to be useful, but could anyway be added in another document if needed (with an LCT header extension).

Any other comments ?

...Mark

On 4/10/09 10:44 AM, "Luby, Michael" <[email-masked]> wrote:

Mark,

Mike,

...Mark

Change: The

To: The

Mike

All,

...Mark