> > 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.