Re: [Bloat] wireless software retry with ECN?

[Jonathan Morton <chromatix99@gmail.com>]

On 15 Jun, 2011, at 9:43 pm, Dave Taht wrote:

> When you have to retry sending a packet in swretry at a wireless
> driver (mac802.11?) level, marking it as 'congested' seems to make sense.
> 
> If you are going to make heroic efforts to deliver packets in the
> first place, you might as well tell the receiver of your heroism.

This actually makes sense, because one of the major causes of a packet retry is noise - and other wifi networks sharing the same airspace (or indeed other APs for the same network in the same large room) look a lot like noise to the receiver.

OTOH, a single retry might not be enough to justify this - it could be due to burst noise or short-term fading (ie. the user walked behind a pillar).  But then again, a single ECN marked packet shouldn't have a large effect on the TCP.

On the gripping hand, due to the definition of ECN, this would require that hardware does not retry (or, alternately, only retries once) any packets that are not ECN enabled.  This is because the ECN RFC says that routers must drop packets which would otherwise have been marked if they are not ECN enabled (and thus cannot be marked).

Reducing TTL on each retransmission *sounds* like a good idea too, but might require more detailed analysis.  How many retransmits are typically attempted by current hardware?  Do we really want to reduce the number of retries based on how far away in the internet they came from?  Do we really want to reduce the ability of heroically-transmitted packets to reach their ultimate destination abroad?  This isn't really what TTL is designed for.

 - Jonathan