[e2e] Open the floodgate

[Cannara]

Mark, sorry, but the point I was trying to make was not that TCP should tell
us that physical errors are occurring, but that if TCP is to be given
congestion-management responsibility (as it was in the '80s), then it must
also be given information to allow it to distinguish non-congestive loss.  In
other words TCP lacks input that prevents false positives that lead to
backoff.

Now, to implement that, say ECN-like, the network layer needs to provide info
to the ends, thus allowing end-end transfers to remain reliable and fast under
this kind of failing.  Then too, the info to the user could, in fact pop out
on screen, but from the network layer at his/her station (as well as to its
TCP).  That's an extension additional to helping TCP, but I was not even
broaching that at this point.

Alex

Mark Allman wrote:
> 
> > Now the above is not uncommon in the real world.  Is it "hard" to
> > figure out how packets can be transported efficiently under errored
> > rather than congested conditions?  We certainly know that several
> > hundred $50/hr employess slowed by 30% is a hard problem to their
> > employer, because it's very expensive.  But, for some reason, giving
> > TCP a fighting chance to distinguish causes of loss has been very
> > "uninteresting" for many years
> 
> You told this very nice, realistic little story and then took a very odd
> turn at the end, it seems to me.  At the end we find out that something
> is corrupting 1% of the packets.  And, rather than blaming that thing
> and the fact that network troubleshooting is damn hard you turn it
> around on TCP's inability to figure out the reason for loss.  That seems
> strange.
> 
> I.e., you have a working system and this company is getting $50/hour out
> of their people.  And, then some piece of junk equipment at the phone
> company goes flakey and suddenly that is the transport protocol /
> congestion control scheme's fault?  There are things to bemoan here, but
> they are not TCP (and, that does not mean TCP is perfect -- it could
> certainly stand some improvement, but come on ...).
> 
> Troubleshooting networks is one of the biggest pains we have, IMO.  We
> should think about it and figure out how to do better.
> 
> allman
> 
> --
> Mark Allman -- ICIR -- http://www.icir.org/mallman/
>