[Bloat] wireless software retry with ECN?

[Bloat] wireless software retry with ECN?

[Dave Taht]

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.

While retry is normal, even without collisions, especially with aggregation,
some indication of the level of heroism involved would be useful at
the receiver.

A related idea is to use more of the diffserv markings to indicate actually
drop-able packets.

What is it going to take to get to drop (or mark) more packets, of any kind,
under appropriate circumstances, on wireless?

A related thought might be to decrement the hop count on each retry,
and not by one.

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

Re: [Bloat] wireless software retry with ECN?

[Jonathan Morton]

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