[e2e] Open the floodgate

[Cannara]

Michael,

On IP checksums, yes router firmware and hardware often do lots more than just
look up addresses and assign packets to outbound queues.  In fact, the depth
of analysis has increased because of hardware (network processors)
availability and security concerns.  So, many different
forwarding/priority/drop decisions can be made within router/bridge firmware
that one might never have guessed a few years ago.

Alex

Michael Welzl wrote:
> 
> >     >> we all have known for some time that i) TCP can't currently
> >     >> distinguish between error loss and congestion loss, and ii) slowing
> >     >> down for an error loss is a mistake.
> >
> >     > So why don't we have separate header/payload checksums in TCP yet
> via a
> >     > header option, as we now have in DCCP?
> >
> > The problem is that many routers (and low-level device drivers) simply
> > discard packets which fail the link-level checksum, so many (most?) of
> those
> > error packets will simply never get to the host.
> 
> I thought that routers should only examine IP headers?
> But maybe I'm being naive here ...
> 
> as for low-level device drivers - well, if you mean the link-level equipment
> itself, there is a list at
> http://www.icsi.berkeley.edu/~gurtov/corruption.html
> 
> We did some tests with 802.11 equipment, it's true that there seems to
> be no chance to get erroneous data from this type of link layer. GPRS,
> as an example, is different in this aspect, I've been told, and it's also on
> this page.
> 
> I remember that "we don't need it, link layers won't give it to you anyway"
> was one of the main reasons against UDP Lite. And, to me, one of the
> most important reasons in favor of UDP Lite (which is now in the RFC
> Editor Queue) was that the goal is to motivate link layer designers to
> do so.
> 
> It's actually a chicken-egg type of problem:
> Either we motivate link layer designers to hand over corrupt data
> (without getting much immediate benefit), or they do it (without getting
> much immediate benefit) and thereby motivate us to design protocols
> that can use such data.
> 
> It's not so useless after all.
> 
> Cheers,
> Michael