[e2e] Open the floodgate

[Michael Welzl]

> > Still, my question remains: why don't we have these separate
> > checksums as a TCP option? It strikes me as a rather simple
> > method for links where erroneous data are actually handed
> > over, and I believe that it's about time we transferred these
> > things from the world of research into the IETF.
> 
> When you have erroneous packets (for whatever reaso other than
> congestion), who will inform about that? Maybe the addresses themselves
> are erroneous. Besides, some packets just get completely junked ...
> Special headers will not solve the problem.

This is a misunderstanding, and I guess it's because I didn't
give enough details - sorry!

So:

The idea is to have a second checksum that lets you distinguish
between an error that occured in the header and an error that
occured in the payload (e.g., a checksum that covers only the
header as opposed to the original TCP checksum that covers
header+payload). If the header is broken, I agree that there
is nothing you can do. However, if you know for sure that the
error was in the payload and all the header information is intact,
I don't quite see the point of doing standard TCP backoff as
if it was a congestion event.

Exactly this mechanism was introduced to DCCP by the name
of a Data Checksum option.

Cheers,
Michael