Does anybody understand this Linux kernel behavior?
I drop packets with a tool like tc or ethtool on the sending host and the kernel magically replaces them!
I understand that the solution is to drop the packets somewhere else rather than the sending host. However, this is magical and decidedly non-scientific.
Personally, I am content with the magical behavior. I could care less if Linux leprechauns in the kernel are sprinkling fairy dust on the packets and causing them to magically regenerate themselves!
However, when I try to explain to my various bosses that I need another piece of hardware because of the Linux leprechauns, well, ummm, yeah, sounds like penguin poop!
Does anybody know why this happens? Or better yet, where is the code that does this? Is this legacy behavior? Is it an optimization? What is the purpose? Did the old skool kernel koders think that the stack would drop packets by accident?
I guess that could happen if we overflowed a buffer on our own stack, but, wouldn't TCP's congestion control behavior be the correct thing to do? Instead of just replacing my packet without telling anyone?
Hmmmm...
This is an excerpt from the linuxfoundation.org's page on netem:
http://www.linuxfoundation.org/colla...tworking/netem
Caveats
When loss is used locally (not on a bridge or router), the loss is reported to the upper level protocols. This may cause TCP to resend and behave as if there was no loss. When testing protocol reponse to loss it is best to use a netem on a bridge or router.
...Daniel
PS...I hope this is an apropos forum for Linux TCP kernel questions. I thought linux networking was a good one, but, they don't seem to think so.
