[e2e] Reacting to corruption based loss

Cannara cannara at attglobal.net
Thu Jun 30 15:35:21 PDT 2005


Well, maintaining a serious attitude, guess what David?  

1) Indeed "hardware corruption can be detected by software", which is what
MIBs report to us via net mgmnt systems, and all metro distribution systems
employ.  Of course, IP was never designed to gather & use lower-level info
like that because it's designers thought the network began with their software
interfaces to IMPs stuck onto their various time-sharing machines. Otherwise,
we might even have had a reasonable addressing scheme from day 2.

2) Indeed link hardware does much more than many TCP/IP folks realize, but
"those complete turkeys who designed TCP got congestion wrong, hardware wrong,
and software wrong" is rather harsh, don't you think?  I mean all they did was
assume every loss was due to congestion.  Now, how bad is that?  :]  And, why
want TCP to muddle in hardware, if it's got a cogent network layer beneath it
to give "best-effort" service (whatever that means)?  You're just so
demanding. 

3) Your wish: "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" has already been satisfied by uSoft.  Their recent upgrades to
Win2000 & XP servers includes software that requires reboots in order for ICMP
Redirects to be handled correctly after a day or so of running.  And, the
experiment of pulling the Enet cable from a Windows PC for a few seconds has
an intriguing effect on its user's apps -- if held out about 5-10 secs, the
hardware driver tells the Windows protocol mgr the network is disconnected and
uSoft, always wanting to plug security holes, assumes a tap is being inserted,
so forces IP to change its address to Loopback.  Thus, all packets coming back
to the PC, containing important financial or anti-terror info, are ignored.  A
denial of service attack generated by a machine's own OS, how clever of
uSoft!  Glad I got paid a good rate last month for helping find these two.  :]

These and many other real examples show how the main flaw in the Internet is
no control & management of installed software.  We can all laugh at uSoft's
OS-for-Dummies tricks over the years, but decades have paassed with no
sensible release control for minor things, like TCP/IP stacks.  Linux is far
better managed than the middle-level protocols the Internet depends on.

Alex

"David P. Reed" wrote:
> 
> 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...



More information about the end2end-interest mailing list