Wouldn't the appropriate place to add the tunable for Stretch ACKs be as a route attribute similar to RTAX_ADVMSS? Then system administrators who are aware of the local network topology, netfilters, etc, could use an "ip route" or whatever command to enable it on the route entry for the local IPoIB subnet.
On a more general note, I find the idea that a current dst entry doesn't actually reflect the interface (even a logical interface) and nexthop that will be used to deliver a packet a little disturbing. It would seem to me that any filter that is going to re-route a packet to a different address or a different interface should be a logical device (with its own IP address) or logical interface, respectively. Otherwise what is going on is completely invisible to the transport protocol, as well as users of tools like traceroute.
In other words, if a netfilter rule needs to actually re-reroute / transform packets, it shouldn't be a netfilter rule at all. It should be a logical device accepting and delivering packets on one or more interfaces. A case where this is important is localhost optimization. Both OpenSolaris and FreeBSD eliminate SCTP CRC32c checksum processing on localhost connections. That cannot be done if netfilter can redirect packets in a way completely invisible to the transport layer.
If transforming operations were required to be performed by a logical device, the fact that a packet is routed or transformed in an unusual manner would be easily detectable. 127.0.0.1 could be reserved for the true localhost interface, and various other packet transformers could use other 127.0.0.0/8 addresses.
A side benefit would be that various byzantine NAT transformations could be moved into userspace, where they belong. Is H323 or FTP NAT so performance critical that it needs to be done in kernel?
Comments? - Mark B. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
