[e2e] Reacting to corruption based loss

[Cannara]

Good one Clark!  Indeed FDDI and other fiber rings have dual interfaces &
fibers and anything can happen in any part of the hardware.  The assumptions
about the physical layer that have been made in most TCP discussions simply
evidence lack of understanding of the reality and complexity of underlying
layers.  This lack extends to the length of time the defects last and go
undiscovered, while folks struggle with peformance issues.

It would have been interesting if your tech had disconnected one half of one
interface and made the ring wrap!

Alex

> Clark Gaylord wrote:
> 
> Detlef Bosau wrote:
> 
> > Sam Manthorpe wrote:
> >
> >
> >> > As an example of the latter, a major telecom company, whose services
> >> > many of
> >> > us are using this instant, called a few years back, asking for help
> >> >
> >> >
> >> How many (years?)
> >>
> >>
> > Alex reminded me on a strange situation, I met myself a couple of years
> > ago.
> >
> >
> you did? that is strange.  what did you say?  :-)
> 
> > One day, I met strong TCP/IP problems on a WAN line exhibiting a BER
> > 10^-9, which was more than specified. However, I have thought about the
> >
> >
> Ok, while we're discussing "corruption-based loss" and weirdness, here's
> mine:
> 
> We often talk about bit errors being random.  I put it to you that this may
> not be true.  Perhaps it is the traffic data that are the random element and
> the bit errors are more predictable than we believe.
> 
> A user called us years ago, when our backbone was a FDDI ring, about a
> several megabyte file he could not send to a neighboring building.  He had
> successfully sent it throughout his LAN, and there were other buildings to
> which he could send it, but not to this one.  He was using ftp.  As it turns
> out, the intended destination was counter-clockwise from him on the ring;
> all buildings he had successfully sent it to via the backbone were clockwise
> from him.  We did further testing with the user and found that, in fact,
> there were no buildings to which he could send this file that were
> counter-clockwise on the ring.  Weird.  So, we split the file in half and
> found that one piece would successfully traverse the ring, the other would
> not.  And so we continued via binary search splitting the unsuccessful piece
> until we had a piece of the file with a few hundred bytes that were the
> problem.  Out of the entire several megabyte file, these few hundred bytes
> absolutely could not be convinced to traverse the ring counter-clockwise
> from this building, yet could travel anywhere else just fine.  If we tried
> to send a packet with these data, the FDDI interface would always accumulate
> an error.
> 
> We sent out a field tech with an alcohol swap, and fixed the problem.
> 
> The conjecture is that there was a particular bit pattern that would
> reliably get corrupted by the reflections on this fiber.  Cleaning the fiber
> fixed the problem.
> 
> --ckg