Subject: Re: Correcting LINK (Advice for Internet Subnetwork Designers)

From: Phil Karn <[email-masked]>
Date: Wed, 28 Feb 2001 12:49:58 -0800

There is still a subtle error in the specification of the 
   packet error rate in the wireless example, point 2,3 :
	
   p = 1 - ([1 - BER]^[MSS * 8]) - Not quite so.
   
  MSS should be MSS+(IP HEADER including IPSEC If used)
     +(Cumulative link overhead in bytes)

I've made it even simpler. I reworded this section to replace
all references to "MSS*8" with "PACKET_SIZE". This is defined to
be the total packet size (user data plus all headers) in bits (not bytes).

Phil

---

From: Phil Karn <[email-masked]>
Date: Wed, 28 Feb 2001 14:13:47 -0800

I suggest it may be useful to add a sentence here to say 
  that link layer error checking is normally provided only 
  within the transmit and receive processing.  Errors may be introduced
  by subnetworks while processing a packet pending transmission 
  or already received via a link. These errors are not discovered by 
  a link CRC check, and may not be detected by TCP/UDP checksums. 
  Errors of this sort do occur, and need to be minimised! 

Here's my new text:

Most subnetworks implement error detection just above the physical
layer.  For this reason, nearly every error caught by the Internet
checksum is the result of a subnetwork hardware or software failure,
not a transmission error.  Such errors are rare, but they do
occur. [SP2000] This lowers the motivation to overcome the performance
and especially the backward compatibility problems of a new, stronger
Internet checksum.

The [SP2000] cite is to this reference you gave:

  See also J. Stone & Craig Partridge in SIGCOMM 2000, 
    p309-321 (ACM CCR 30(4)). 

--Phil

---

From: Phil Karn <[email-masked]>
Date: Wed, 28 Feb 2001 16:54:58 -0800

Gorry,

After reading the Stone & Partridge paper you cited, I've
substantially rewritten the section on subnetwork error detection. How
do you like this new text? --Phil

The TCP, UDP and IPv4 protocols all use the same simple 16-bit 1's
complement checksum algorithm to detect corrupted packets. The IP
checksum protects only the IP header, while the TCP and UDP checksums
protect both the TCP/UDP header and any user data.

IP version 6 (IPv6) does away with the IP header checksum and relies
on end-to-end checking to detect IP header errors.

These checksums are not very strong from a coding theory standpoint.
But they are easy to compute in software, and various proposals to
replace them with stronger checksums have failed. Yet a study [SP2000]
has shown that the Internet corrupts one in 1,100 to 32,000 packets,
and it is up to the end-to-end Internet checksum to detect these
errors.

Most packet corruption appears to be caused by bugs and errors in host
and router hardware and software. So even if every subnetwork
implemented strong error detection, the end-to-end use of TCP and UDP
checksums would still be necessary.

Most subnetworks implement error detection just above the physical
layer. Packets corrupted in transmission are detected and discarded
before delivery to the IP layer.  A 16-bit cyclic redundancy check
(CRC) is usually the minimum, and this is known to be considerably
stronger than the 16-bit standard Internet checksum. The
Point-to-Point Protocol [RFC1662] requires support of a 16-bit CRC,
with a 32-bit CRC as an option. (Note that PPP is often used in
conjunction with a dialup modem, which provides its own error
control). Other subnetworks, including 802.3/Ethernet, AAL5/ATM, FDDI,
Token Ring and PPP over SONET/SDH all use a 32-bit CRC that is
considerably stronger.  In addition, many subnetworks (notably dialup
modems, mobile radio and satellite channels) also incorporate forward
error correction, often in hardware.

Any new subnetwork designed to carry IP should therefore provide error
detection at least as strong as the 32-bit CRC specified in [ISO3309].

While this will achieve a very low undetected packet error rate, it
will not (and need not) achieve a very low packet loss rate as the
Internet protocols are better suited to dealing with lost packets than
with corrupted packets.

Designers of complex subnetworks consisting of internal links and
packet switches should consider implementing error detection on an
edge-to-edge basis, i.e., at the interface to IP, either in addition
to or instead of error detection at the interface to each physical
link. This has the significant advantage of protecting against errors
introduced anywhere in the subnetwork, not just its transmission
links.

This is straightforward if the interface presented to IP by the
subnetwork already includes error detection, as with PPP or
Ethernet. If the subnetwork carries the PPP or Ethernet CRC without
change through the subnetwork, it will automatically provide the
desired edge-to-edge error detection.

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 Feb 2001 18:44:25 -0800

> on end-to-end checking to detect IP header errors.

E2E checks don't detect some IP header errors; some fields
change hop-by-hop.

I'd also add that it relies on both end-to-end checks _and_
IPSEC - i.e., if you really care about the header, or if you
don't have an e2e transport-layer checksum that you trust, 
you should IPSEC it.

> detection at least as strong as the 32-bit CRC specified in [ISO3309].

If this is true, then the above (why IPv6 does away with IP checksum) 
should include the reliance on link checksums to flag hop errors,
thus catching predominant causes of errors (according to your argument).

> desired edge-to-edge error detection.

PPP can catch and regenerate these checksums on individual hops,
just as ethernet can. I.e., how do you know when the link layer changes?

If you really want edge-to-edge checksums in IPv6, why not recommend
the use of IPSEC? even with null keys the hash provides some error
detection. (albeit slowly :-)

Joe