Subject: Re: IP checksum

From: Joe Touch <[email-masked]>
Date: Wed, 18 Aug 1999 17:29:22 -0700 (PDT)

> From: Jonathan Stone <[email-masked]>
> 
> Has anyone considered two distinct checksums at each level?  That
> might not be as flexible for demuxing above UDP (application-level
> demuxing); aside from that it seems more useful.

It assumes the error is in the body.
Earlier discussions focused on the IP checksum,
which is just the header. If the header is bad, 
you can't tell that layer what to do about it.

> In message <[email-masked]>,
> Joe Touch writes:
> 
> >(PS - this doesn't count the use of FEC or stronger error recovery
> >mechanisms, but they need to be in the link level, to recover the
> >IP header, UDP demux, etc. You can't layer strong on weak on strong.)
> 
> Because once the underlying `weak' layer fails, you can't find your
> way up to the higher `strong' (or error-tolerant) layer, right? 

Given a weak-layer error, you can't trust any info inside that
layer - even the offset or packet type. Interpreting the rest of the
packet, and using interior strong FEC to fix it, is a leap of faith.

> I think the Larzon and Degermark I-D can layer strong on top of weak, by
> doing the (weak) checksum only over that prefix of a packet necessary
> to demux to the strong (or error-tolerant) application layer. 

If the weak fails, then you still cannot get at the strong layer.
The benefit of LD is that it reduces the probability that the weak
layer is affected, by reducing the length of the packet over
which it holds.

> If headers are, say, 1/3rd of a packet, and error bursts are uniformly
> distributed amongst all bits of a packet, then UDP-Lite will still
> fail to deliver 1/3rd of all packets which incur errors. Is that
> right?

Somewhat less than 1/3 (i.e., any packet where any part
of the error burst affects any part of the header. if the burst is
as long as the header, this could be 2/3, e.g.)

But basically, yes.

Joe

---

From: Jonathan Stone <[email-masked]>
Date: Wed, 18 Aug 1999 18:27:52 -0700

>you can't tell that layer what to do about it.

Sure. I think we all agree on that.

>packet, and using interior strong FEC to fix it, is a leap of faith.

Again, sure. My `what-if' was based on partitioning the `weak' layer
into two (or more) pieces and checksumming them independently. Turns
out VMTP did that, and checksummed each 512-byte chunk of a packet
individually, too, i think.  That's partly why I mentioned VMTP
several messages back, but either  it's too obscure, or I wasn't
clear enough.

[...]
>layer is affected, by reducing the length of the packet over

Right, sure.  But I was suggesting two independent checksums, one for
the header and a separate checksum for the payload, as opposed to no
checksum at all for the payload.  In either case, if the checksum
which covering the demux info is bad, the packet must be dropped.  The
difference is that if you *do* use a separate checksum over the body,
you have the option to verify that checksum and proceed appropriately:
as Chrisitan Huitema's point about encrypted or compressed traffic,
for example.

Either way, doing one link-level checksum over the entire frame
renders this moot.

Where I'm coming from is: given a choice between (a) two link-level
checksums, one over a `header' prefix and a second over the remaining
`payload',  or (b) having no link-level checksum over the payload 
portion whatsoever,  and the same for UDP, I'd take (a) over (b) any day.
Even if it's used for no more than counting the checksum failures on
error-tolerant UDP payloads, or detecting broken NICs.
Is that clearer?

>as long as the header, this could be 2/3, e.g.)

Sure. I was over-simplying conservatively (in favour of LD), to get some
insight.  Thate 1/3rd is  just a rough guess at telephony speech-sample
size (the 32 and 64 bytes that led to ATM's 48), so there's little point
to a more accurate estimate (which requires estimating burst length).

Still doesnt seem like a compelling reason to replace UDP though:
link-level FEC over lossy links seems like a better bet.

What do the PILC folk think?

---

From: Mikael Degermark <[email-masked]>
Date: Thu, 19 Aug 1999 09:19:26 +0200

>> to demux to the strong (or error-tolerant) application layer.

No, absolutely not. For UDP Lite to make sense for error-prone links, 
at least the packet prefix covered by the UDP Lite checksum must be
covered by a strong checksum at lower layers. 

>layer is affected, by reducing the length of the packet over

Yup.

>as long as the header, this could be 2/3, e.g.)

Correct, but the numbers are very different. 

Micke Degermark

http://www.cdt.luth.se/~micke

---

From: Jonathan Stone <[email-masked]>
Date: Thu, 19 Aug 1999 01:34:41 -0700

In message <[email-masked]>,
>covered by a strong checksum at lower layers. 

Yes, that's what I said (note strong *or* error tolerant), only with
the emphasis the other way.

Yup.

>Correct, but the numbers are very different. 

Re-estimating with the frame size you specified, it comes out around
4/19 or 4/34. (increase by a factor of 2 if you discard checksums
over the wireless link; but that will *really* make enemies).

I think the only way you can get significantly different numbers is if
errors hit the middle and rear of packets more than they hit the
front.  Which suggests you should fix the link-layer to avoid that, or
readjust the FEC to take account of it.

And none of this explains why anyone would use IP on such a
persisently lossy network in the first place. If the post-FEC los rate
is so big it makes TCP non-viable, why bother?  Acknoweedge that this
network is too lossy for TCP, or modem, or fax traffic, and bridge the
lossy-net traffic to the Internet where necessary.