Bug #309

Description

A crazy idea that I’ve been nursing for a while has been that the core reason why we do all the retries and acknowledgements in the wireless layer to avoid packet loss is because tcp + wireless over the LFN - 30+ms latencies - works really badly. HOWEVER:

I theorize that local connections (e.g. inside the home) have sufficiently low RTTS for tcp to compensate well for the actual wireless packet loss that is occurring.
(and not only that, deal with congestion much better). Furthermore if fair queuing is applied on streams to stations, the bursty packet loss that is typical of wireless would be minimized.

Now, since we can’t depend on the RTT measurement due to bufferbloat, inspecting TTL (for ipv6, that’s hopcount) at the Access Point, and turning off mac layer acknowledgements when appropriate may actually work. Nobody mucks very much with hopcount. For a TTL of greater than 61 (for ipv4) and a hopcount of greater than 251 (possibly incorrect, have to check the default for ipv6), the connection is pretty much guaranteed to be very local.

with acks turned off a good wireless connection would actually run faster in the general case, and recover quicker. On a bad connection, this would provide feedback
much sooner than the heroic measures being taken to get the packets through.

mildly deeper packet inspection (only turning off mac layer acks for tcp streams) might work better. OR, applying the don’t ack this frame idea algorithmically,
like red, might work as well.

This idea was inspired by seeing patches go by that make turning off mac layer acks a property of the queue for 802.11e. This would make it a property of the packet…

(and this idea only applies to access points. Turning off mac acks at the station layer, mmm… can’t do that based on hopcount.)

Now, everybody sing… with appropriate irony… ‘Every packet’s sacred…’