Subject: Final issues to be resolved priot to ULE rev -03: CRC mismatch

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 23 Nov 2004 09:17:01 +0000

Bernhard, ipdvb WG,

There were two issues that were addressed at the IETF-61 meeting - one was
the bit of text we had trouble agreeing on, the second was the IANA
considerations section.

I shall post both separately (the first isssue and proposed new text is 
provided below, together with the rationale).

Please give this prompt attention, it would be good to receive email 
supporting this text or requesting clarification. When these are complete the 
authors will be ready to submit the final edits to make rev -03 of ULE.

Gorry
(as ULE Co-Author)

---

CRC MISMATCH ISSUE - Section 7.2

There was discussion at the IETF-61 about whether the Receiver SHOULD/MUST/MAY
discard the remaining TS Packet payload (if any) following a CRC mismatch
and return to the Idle State.

This is a common point of dispute in IETF WGs - the usual philosophy being
"liberal in what you accept and conservative in what you send". Whatever is 
decided by this WG, it is best that this is documented (as agreed in the 
IETF-61 meeting). Please bear in mind that, IETF protocols should not mandate 
implementation methods.

To summarise the discussion:

MUST discard and enter idle state - seems very strong when the impact is not
to forward bad data, but to result in unnecessary processing - the consensus
seemed to be that any processing/design issues could possibly be overcome in
the future, and we shouldn't constrain the spec because of this.

SHOULD discard and enter idle state - is my new suggestion, i.e.
Implementors are advised to take this approach, unless they understand the
implications and decide there is a good reason to do otherwise.

MAY discard and enter idle state - was also proposed, suggesting that it is
entirely valid for an implementor to discard the reassembly buffer at this
stage (and by implication this is a good idea, unless the implementor is
wiser).

I propose some text below:

------------ Proposed text for ULE rev 03 ------------

7.2 Processing of a Received SNDU

When in the Reassembly State, the Receiver reads a 2 byte SNDU Length Field
from the TS Packet payload. If the value is less than or equal to 4, or
equal to 0xFFFF, the Receiver discards the Current SNDU and the remaining TS
Packet payload and returns to the Idle State. Receipt of an invalid Length
Field is an error event and SHOULD be recorded as an SNDU length error.

If the Length of the Current SNDU is greater than 4, the Receiver accepts
bytes from the TS Packet payload to the Current SNDU buffer until either
Length bytes in total are received, or the end of the TS Packet is reached.
When Current SNDU length equals the value of the Length Field, the Receiver
MUST calculate and verify the CRC value (section 4.6). SNDUs that contain an
invalid CRC value MUST be discarded. Mismatch of the CRC is an error event
and SHOULD be recorded as a CRC error. The under-lying physical-layer
processing (e.g. forward error correction coding) often results in patterns
of errors, rather than since bit errors, so the Receiver needs to be robust
to arbitrary patterns of corruption to the TS Packet and payload, including
potential corruption of the PUSI, PP, and SNDU Length fields (see also
7.2.1). Therefore, a Receiver SHOULD discard the remaining TS Packet payload
(if any) following a CRC mismatch and return to the Idle State.

...

7.2.1 Reassembly Payload Pointer Checking

...

---------------

---

From: Bernhard Collini-Nocker <[email-masked]>
Date: Tue, 23 Nov 2004 14:29:20 +0100

Dear Gorry,

I support the text proposing "SHOULD".

Regards,
Bernhard

Gorry Fairhurst wrote:
> supporting this text or requesting clarification. When these are 
> complete the authors will be ready to submit the final edits to make rev 
> -03 of ULE.
> 
> Gorry
> (as ULE Co-Author)
> 
> ---
> 
> "liberal in what you accept and conservative in what you send". Whatever 
> is decided by this WG, it is best that this is documented (as agreed in 
> the IETF-61 meeting). Please bear in mind that, IETF protocols should 
> not mandate implementation methods.
>