[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ULE-01 : last byte(s) precision
Gorry Fairhurst wrote:
- more complexity in the code of the receiver, because it has to
keep a sort of new state for an SNDU which is currently being
in the reass process and whose length is still not known.
The current spec says the sender *MAY* choose to do this, either based
on policy, or some otehr rules. So if the sender wishes to never
fragment the length, this is allowed, that's currently a design choice
for the encapsulation gateway.
Yes but if the packing is optionnal for the sender, its processing by
the receiver is mandatory, because it cannot know wether the sender
is packing-enabled or not, or wether it preforms lenght-split or not.
** well I realize it has no importance, see below
... snip ...
So the issue you speak of is a receiver simplification. I worry about
the breadth of implementation experience here. Is this important
enougth to add a mandatory rule to require the sender to do this? - I'd
like to understand more.
- in case of end of packing, the end-indicator needs an extra
TS-cell to be transmitted.
Not so, the current spec says the receiver MUST discard any TS-Packet
Payload with only one byte remaining, when looking for a new start of SNDU.
OK I missed that point. Indeed the before-the-last paragraph of 5.2.2
need that the sender behave acordingly i.e. :
"If there is either 0 or 1 byte of payload data remaining in the TS
Packet after completion of the Current SNDU, the receiver MUST
discard this remaining TS payload, and wait for the next TS Packet
with the PUSI value set to 1 (the Idle State). "
==> The sender MUST NOT start a SNDU if it cannot put at least 2 bytes.
because if only one byte can be stored, it will be dropped by the
receiver. This more or less the same thing as
> "If the first two bytes of an SNDU can not be put in in TS-cell,
> then, a new TS cell MUST be started."
>> [extract from the following Gorry'smail]
>> I'd agree - some text saying *why* you wish to have the length field
>> all in one packet would be good.
Indeed in that case, the fact that length is not split is no more a
goal, but a consquence fo the rule the sender has to apply, to conform
to the receiver expectation
Cheers.
Alain.
--
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com