Re: "ule" and last byte

[alain.ritoux@6wind.com]

Cmoments inside

Dr G Fairhurst wrote:
> 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.

I don't see it as a pb, for my understanding that such a padding
was only needed if a next SNDU could start in the following bytes.
but in this case, the rule about having 1 byte or less available
already forbids the sender to start a new SNDU.

> (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.
This is already covered by the fact that there is only one byte
left, and so a new TS cell MUST be used, and the reciever using the
same rule won't expect a new SNDU

> The diagrams in:
> http://www.erg.abdn.ac.uk/ip-dvb/meetings/IETF-57-Vienna/
> (presented in Vienna) may help.
Ooops, I hought they were teh commented parts of the ULE
drafts and didn"t read them carefully :-(

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

Maybe it is not necessary to forbid usage of the last 2 bytes, but
only to the last byte hence can be restricted to :

"The receiver NEVER uses the last byte of a TS Packet Payload if
 a SNDU finishes leaving one or less byte of unused payload."

so it is possible to start a new SNDU with exaclty the SNDU
length, is saves one byte, .... I feel I'm starting to get
greedy about bytes ;-)

Whatever, the sending rule should also be changed, because the
current one only speak about the bytes left after putting and SNDU,
and doens't explicitly see the payload_pointer pb. So it is better to
speak about how many bytes of the next SNDU can be stored :

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

This in my opinion should solve everything,
 - always enough place for padding with end-indicator
 - no length split (not really cool to manage)
 - no corner case in sight ;-)

but maybe the avoidance of the last 2 bytes helps avoiding another pb
I haven't seen ?

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