[e2e] Reacting to corruption based loss

[David P. Reed]

Cannara writes:

> a typical TCP will be brought to its knees by a few % packet losses that are simply due to hardware errors.

A very good point!   I'll raise you one, Alex:

I really think that *software* corruption should be treated differently than *hardware* corruption.   TCP really gets brought to its knees by software errors, such as buffer overflows, deadlocks, etc.   I mean really, those complete turkeys who designed TCP got congestion wrong, hardware wrong, and software wrong.  Responding to software errors requires a completely different error recovery technique - I suggest a remote router reboot is usually needed.  So we need to characterize the errors so that the link layer can discriminate and do the right thing.

What we need is a whole new protocol that is based on characterizing packet corruption.   Each router is to determine the cause of corruption:

hardware corruption can be detected by software, 

software corruption can be detected by hardware,

and congestion can be inserting an optical fiber into the nasal passages of the network consultant.

It shouldn't be too difficult to obtain six sigma precise characterization of packet corruption in this way.

Of course, financially derived corruption and corruption by power (or absolute power) are possible, but those can be dealt with on an end-to-end basis, as we know that network consultants such as Mr. Cannara are omniscient and incorruptible.

Really, this could become a whole new subdiscipline of communications theory - the general systems theory of corruption and the practice of switch-based corruption-characterization.  Perhaps we could invent devices that sense the sources of corruption by detecting the spin of the photons that come out of the fiber...