Re: [TERNLI] Forwarding corrupt packets

[Gorry Fairhurst <[e-mail]>]

A) On which link layers support this?

Not all link-layers necessarily check all the bytes within a link framer 
when calculating the frame integrity check (e.g. CRC-16 or CRC-32).

A classic example of this is the ISO HDLC frame format, that has long 
included a frame-type called UIH, which assigns the CRC to cover a 
pre-agreed minimum number of bytes (perhaps pre-configured, perhaps 
negotiated using the XID method). Frames with invalid CRCs are 
discarded, frames with good CRCs are forwarded without judgement on the 
remaining content. This could be used by a UDP-Lite aware (L4 snooping) 
link driver to select to choose UIH format in favour of UI frames, when 
this is compatible with the UDP-Lite coverage value.

HDLC Voice links have used this format, and something similar is 
supported in some of 3GPP specs. BUT DO NOTE, to support this and get 
strong benefits you have to make the correct PHY decisions, which 
impacts coding, modulation, synchronisation, etc. - It's not just a 
matter of ignoring the CRC and hoping for the best.

If you don't use a CRC at all, you increase the chance of mis-delivery 
to others (and the possibility of getting mangled packets). This is 
particularly bad for IPv6 nodes. The IPv4 checksum is too weak to really 
give you much confidence under these cases either;-).

---

B) On whether this extra signalling is useful?

What I don't understand is the "essence" of the message that you need to 
generate to utilise this, since you seem to suggest in this thread using 
explicit signalling to set L2 state, rather than per-packet choices.

 > "From transport end point to network"
- I think we already have this as a transport option.
- not sure I am convinced we need the signal.
- I don't understand this signal... it seems to bind a specific TSpec 
(IPsrc,IPdst, Transport, srcport,dstport)to a L2 identity... How do you 
differentiate when a new app replaces the previous one with different 
semantics?

 > From network to transport end point:"Corruption Forwarding supported 
(CF)"
- Why do we need to know this at the transport layer?
- If your end systems (and any L4 middleboxes!) support UDP-Lite and/or 
DCCP with partial coverage it is FINE to use this irrespective of 
whether the links do anyrthing special. you don't gain, but you don't 
loose either.

- Can you clarify how the extra signalling helps?


Michael Welzl wrote:

> On Fri, 2006-09-01 at 16:06, Joe Touch wrote:
> 
>>Michael Welzl wrote:
>>
>>>Hi all,
>>>
>>>Here's an idea for a potentially useful message that
>>>could be exchanged between end systems and the inner
>>>network:
>>>
>>>>From transport end point to network:
>>>"Corruption Acceptable (CA)" (meaning that it would be
>>>preferrable to forward packets that are corrupt rather
>>>than drop them)
>>>
>>>>From network to transport end point: "Corruption
>>>Forwarding supported (CF)"
>>>
>>>Purpose: help the end system decide whether to use
>>>UDP-Lite, or partial checksums in DCCP, or the
>>>Data Checksum option in DCCP.
>>
>>Why does the _network_ need to know about these? The network doesn't
>>check (or shouldn't check) transport checksums.
>>
>>The only reason the network would think a packet is corrupt:
>>
>>1) bad net checksum (e.g., IPv4)
> 
> 
> I agree that, if this checksum is known to be corrupt, the
> packet should be dropped.
> 
> 
> 
>>2) bad link checksum
> 
> 
> which normally covers everything, e.g. in 802.11 nets AFAIK.
> So that's the one that I'm concerned about.
> 
> 
> 
>>In both cases, the destination address is not trusted anymore, so you're
>>potentially sending the corrupt packet to the wrong _place_. If you
>>can't send it the right place, then why are you sending it?
> 
> 
> i remember you saying some time ago that sending it to the
> wrong destination isn't a big problem for the network, and
> therefore the lack of a checksum in ipv6 isn't a big issue.
> 
> chances are that it would reach the right place, so where's
> the problem?
> 
> 
> 
>>This isn't a new issue; it's one of the reasons for the partial checksum
>>in lite/DCCP - but also why it should be only over the _data_ portion.
> 
> 
> This is at least the only portion the end node is concerned
> with, so yep - the precise message from the sender would have
> to be "corrupt data portion is okay" (no matter how exactly
> the element in the network would handle this message - e.g. by
> looking at the data portion, which I consider ugly design,
> or by always forwarding corrupt data when at least the IP
> checksum is ok, which I'd prefer).
> 
> 
> 
>>In those conditions, you might end up with one e2e-pair causing a
>>separate endpoint to throttle-back thinking its packets are corrupted.
>>That cross-contamination seems like a sufficient reason not to do this.
> 
> 
> I don't get this - could you go into more details?
> 
> 
> 
>>IMO, partial transport checksums are useful only where the header
>>checksum is still valid; otherwise, there's no point in interpreting the
>>header at all.
> 
> 
> As I say above, that's an implementation detail in my opinion.
> We can make recommendations in either direction - right now,
> I'm just suggesting this explicit message between the transport
> endpoints and the network.
> 
> Cheers,
> Michael
> 
> 
>