Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!brutus.cs.uiuc.edu!zweig
From: zweig@brutus.cs.uiuc.edu (Johnny Zweig)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Error Control and ATM (was: TCP Fletcher Checksum Option)
Message-ID: <1989Dec14.041614.18913@brutus.cs.uiuc.edu>
Date: 14 Dec 89 04:16:14 GMT
References: <6830@shlump.nac.dec.com> <8912132300.AA16068@ucbvax.Berkeley.EDU>
Sender: news@brutus.cs.uiuc.edu
Reply-To: zweig@cs.uiuc.edu
Organization: U of Illinois, CS Dept., Systems Research Group
Lines: 22

ddeutsch@BBN.COM (Debbie Deutsch) writes:

>We are planning to look at this problem here at BBN, as part of a
>research project.
    ....
>After all, the applications vary widely in their sensitivity to errors.
>
>Of course, one of the central issues here is just what kind of errors
>will be experienced, and what pattern they will follow.  Until we know
>that, it will be hard to determine the best way to deal with errors.
>
>Debbie

Which is precisely why I advocated that there be some standard mechanism
to augment the corrective/detective features of the checksum being used on
a TCP connection when I started this Fletcher-checksum string.  We can't
look into a crystal ball and see all the things that people are ever going
to want to do.  I think it would be better for the transport protocol to
roll with the punches than to have it be inflexible, forcing users to
reinvent the wheel (say by using UDP to send adequately-checksummed packets).

-Johnny Checksum