so it seems like what we need is a bit in the IP header to indicate
that L2 integrity checks are optional
A lot of folks seem to forget that from the point of view of IP L2
includes the busses between memory and the L2 network interface.
There have been more than a few recorded cases where packet errors
were introduced as the packet flowed in or out of memory, unprotected
by link CRCs.
For apps that tolerate lossage (or more precisely, for apps that work
better in the face of some transmission errors than they do if all
packets with transmission errors are dropped), it doesn't matter whether
the errors occur in the memory-to-interface link or somewhere else -
they'll deal with the errors no matter where they occur.
Of course, the apps that can't tolerate lossage won't set the "lossage
is okay" bit, and they'll continue to expect that the packets that do
arrive, arrive intact. For one particular L2 technology X this might
simply mean that packets that don't have that bit set, but do have
errors, are dropped. For another L2 technology Y it might mean that if
that bit is not set then the IP-over-Y spec will require FEC or
link-level retry or both to make sure that those packets have a
reasonable probability of getting there intact.
To my way of thinking we don't need a bit in the IP header, we need a
bit in the heads of implementors to remind them that relying on
link-by-link protection can be dangerous even if the links have strong
CRCs.
Actually, it seems like we need a bit in the heads of people who don't
understand that
- some kinds of links have inherently high error rates,
- some apps are capable of dealing with less-than-perfect data,
- adding FEC and/or link-level retry to get error rates down to the
level we're accustomed to from wire or fiber carries with it a
substantial penalty in bandwidth and/or delay
- we'd like to be able to use those kinds of links with IP,
- we'd like to be able to run those apps over IP, and over those
links, without paying the bandwidth or delay penalty for
apps that don't need it.
- we'd like a stable spec for this so we can carve it in stone,
(er, silicon)
- since it's going to be carved in stone (silicon) we would do well
to get it right.
Yes, this is a change to IP, and to the IP architecture.
But it's not rocket science, and it doesn't have to affect things that
don't use it explicitly.