Re: "ule" and last byte

[Dr G Fairhurst <gorry@erg.abdn.ac.uk>]

See my thoughts in-line:

alain.ritoux@6wind.com wrote:
> 
> Precision about the "ule" method wrt the last byte
> 
> The sentence (p11)
> "If the TS packet carrying the final part of SNDU has either
> 0 or 1 byte of unused payload, the encapsulator will start
> transmission of the next SNDU in a new TS packet".
> 
> I think it is to allow enough room for the payload pointer,
> is this correct, or is there any other motivation ?

Yes, you are correct, there are two issues, and I can see three
scenarios:

(i) There is a corner case, where the payload has 1 byte left,
and no PUSI previously set (i.e. where the TS Packet contains
only the end of a SNDU that was started in a previous TS Packet).

In this case, the SNDU may wish to set the PUSI, and this will
incur a 1B payload pointer (to be inserted after the TS Packet 
header) - the value should be the position of the first byte
of the SNDU within the TS Packey payload, however, addition of
the Payload start pointer, has "eaten" the byte to be used, and
the SNDU may not now be started within the current TS Packet.

(ii) An encapsulator that has no more data to send may wish to
signal this.  The normal procedure is to stuff/PAD.  

Suppose the encapsulator has two bytes left, but the PUSI
was not set. So the first byte would be used for the Payload
start, leaving one byte for Payload data. ULE howver defines 
a padding sequence that is 2 bytes  long, with only
one byte spare, this would imply sending one byte at the last
position in a TS Packet and the second as the first byte of
a continuation TS packet. (The remainder of this continuation
packet would then be discarded). This seems complex.

(iii) There is a varient of the above where one byte is left,
and the PUSI was set (and hence a paylaod start pointer was 
already present in the current TS Packet, however the encapsulator
has no more data and wishes to send a 2B "PAD/Idle" value.

The diagrams in:
http://www.erg.abdn.ac.uk/ip-dvb/meetings/IETF-57-Vienna/
(presented in Vienna) may help.

This requires a new rule to say what to do. 

I proposed that we add a rule that says that the receiver
NEVER uses the last two bytes of the TS Packet Payload, if a
SNDU finishes leaving two or less bytes of unused payload. In the
worst case, this ammounts to an extra ~1% overhead, normally
traffic patterns will make it is much less.


> Does this includes the payload pointer ?
> I mean :
>    (MPEG_HDR)(End of SNDU-A)[1 byte left] ==> OK send it now
> but, in the following case
>    (MPEG_HDR)(End of SNDU-A)[2 bytes left]
> it will become, with a SNDU-B
>    (MPEG_HDR)(Payload Pointer)(End of SNDU-A)(start SNDU-B)
>                                              ^^^^^^^^^^^^^^
>                                               Only 1 byte !
> so, was it to be sent at once, or is the second TS cell legal ?
> because in the second case, it would mean that the SNDU length
> is not yet available, until a second TS cell is received, which
> is not really a pleasant thing.
> 

> 1) If having the SNDU length split over 2 cell is a pb, then the
> sentence should more replaced with something like :
> 
> "If there is not enough room in a TS packet to put the first
> 2 bytes of an SNDU (possibly due to the needed payload pointer),
> the encapsulator will start transmission of this SNDU in a new
> TS packet. The remaining bytes, MUST be set ...."
> 

> 2) if such a length split is not a pb, then first sentence is a bit
> hard because, in case of multiple SNDU in a single TS cell, there
> is not the payload pointer pb :
>    (MPEG_HDR)(End of SNDU-A)(SNDU-B)[1 byte left]
> OK keep it, because SDNU-C can start in this TS_cell :
>    (MPEG_HDR)(End of SNDU-A)(SNDU-B)(start SNDU-C)
>                                     ^^^^^^^^^^^^^^^
>                                        1 byte
> hence the sentence could be rephrased into something like
> "If the TS packet carrying the final part of SNDU has either
> 0 or 1 byte of unused payload and the PUSI bit clear, the
> encapsulator will start transmission of the next SNDU in a new
> TS packet".
> so it would relax the condition when PUSI bit is set, i.e.
> there won't be other payload pointer added.
> 
> I would prefer solution 1)
> Your thoughts ?
> 

If we tell the receiver that a SNDU never starts in the last two
bytes of a TS Packet, there is no need for complex logic to set 
the PUSI, and cope with the possibility of a split "length/pad"
sequence over a TS Packet Payload Boundary...

> Regards.
> Alain.
> --
> Alain RITOUX
> Tel +33-1-39-30-92-32
> Fax +33-1-39-30-92-11
> visit our web http://www.6wind.com