[e2e] What should e2e protocols know about lower layers?

[Ted Faber]

On Fri, Oct 12, 2001 at 03:33:03PM -0400, Craig Partridge wrote:
> 
> In message <20011012090021.B28377 at ted.isi.edu>, Ted Faber writes:
> 
> >still wouldn't catch it.  Granted, skipping the checksum on the local
> >link is an additional error source, but I suspect it's less of one than
> >a disk nearing its MTBF.  
> 
> If my memory is right, while doing the data collection for our
> SIGCOMM paper and Jonathan Stone's dissertation, we saw some systems
> corrupt on the order of 1 packet in 100 (bad network adapters, so the
> data was corrupted by the sending host's adapter after the TCP checksum
> was computed but before the CRC was computed).  I think that kind of
> error rates beats most disks nearing the end of their lifetime...

Fair enough.  I know you know more about the error characteristics of
failing disks and the coverage of the IP checksum than I do.

My point is that moving data from an internal site to a server already
introduces a range of error possibilities, some significant, some not.
Singling out local checksum-free transmission of the data from site to
server as a networking error while ignoring the possibility that the
data is subject to other error sources also not covered by a checksum
while sitting on or passing through the server seems unreasonable.
Using the checksum on the transfer would add an error check, not expand
the coverage of the checksum to be end-to-end, internal site->client.
Granted this point isn't terribly profound, but it was late in the
evening.

And to beat the horse one more time, the checksum is a bad choice for an
example of a protocol feature to turn off in local operation anyway.  I
think you've done work (correct me if I'm wrong) that shows that as long
as you've got one copy in the protocol processing path (and most hosts
do), checksum computation can be rolled into the memory copy for free on
modern CPUs - hide it in a delay slot.  In that environment,  the choice
wrt to checksum is cut and dried - use it, it can only help you. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20011012/7ab6600d/attachment.bin