Re: ULE-01 : last byte(s) precision

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

My comments in-line too.

Mahesh Sooriyabandara wrote:

> ..snip
>
>  
>
> > > (iii) No split Length field if {0,1,2} bytes when PUSI set and {0,1,2,3)
> > >
> > > bytes when PUSI was not originally set. That would mean skipping if
> > > there is <4B remaining!
> > >      
> > No, I think it is one byte less.
> >    
>
> Yes, ofcourse it should be one less, my mistake
>  
Agreed, this would require >=3B of space remaining in a TS Packet payload.

> > I think splitting length and/or end-indicator is a bad idea
> > because the receiver must in such case, when there is nor more
> > SNDU, the receive a next TS cell to discover that there was nothing
> > more !
> >    
>
> I also think it may not be worth to add extra complexity to receiver code for
>
> (1 or 2)/184 gain.
>
> But what exactly is the real penalty if we choose to allow splitting of
> length
> field and/or end indicator?
>
>  
Does someone wish to offer text to describe this trade-off?

> > the way to work that seems good to me is :
> >   PP set, 0,1 bytes left        --> new TS-cell
> >   PP set,  >= 2 bytes left      --> pack in this TS-cell
> >   PP not set, 0,1,2 bytes left  --> new TS-cell
> >   PP not set, >=3 bytes left    --> pack in this TS-cell
> >    
>
> Agree
>
> ..snip
>
>  
>
> > Here is a text that I think would remove all ambiguity, and that
> > needs not detail the sub-case is PP alreay set or not ...
> >
> > "If the first two bytes of an SNDU can not be put in in TS-cell,
> > then, a new TS cell MUST be started."
> >    
> This looks good to me. 
Seems to match the argument above.

> However, may be it is useful to explicitly state the
> reason for this two bytes decision (details of the PP set or not set case).
I'd agree - some text saying *why* you wish to have the length field all 
in one packet would be good.

> - Mahesh
>
>  
Gorry Fairhurst