>> "standard"?  If so, how come over half the world's business can be done with
>> a protocol that is "less than standard"?  Couldn't standard protocols embrace
>> the same efficiencies attained by these commercial products?  (Question:  My>> understanding is that internal checksums are often avoided in these
>> protocols.  If so, why can't they just be removed from the "standard"?

>These "optimizations" all make the assumption that the packets are
>adequately protected by the datalink checksum (e.g. Ethernet FCS).
>This is more or less ok when you are dealing with a single datalink
>(which could be bridged/repeatered) because the datalink FCS is, in
>effect, an end-to-end checksum on the packet.  However, once you get
>to a routed network, the datalink FCS is no longer end-to-end. In
>each router, the datalink checksum is checked on reception and a new
>one generated on transmission (this is needed because the packet
>changes (TTL gets decremented, maybe the packet gets fragmented), or
>because you are changing media (going from Ethernet to a WAN)).  So,
>if an "optimized" packet goes through a router, there will be places
>where the packet is not protected by an end-to-end checksum. So, the
>TCP/UDP checksum is used to provide end-to-end protection.

>Once you have an internetwork layer (such as IP), you can not assume
>that the packets will never go through a router.

>Finally, checksum calculations do not seem to be as big, bad, and
>ugly as one would think. For instance, in TCP, the biggest
>performance hit seems to be poor timeout/retransmission algorithms.

Also, checksum calculation performance delays can be cut more then half
by recoding things like division operations and matching machine word lengths
and cache to efficient data store and recall.

Therefore, with the proper attention given to this area of performance, one
can reduce the amount of unwanted delays from these calculations.



Mike P DiGioia (MPD)
ThinkTek Consulting

mpd@world.std.com
/mpd