Re: [DNA] persistent TCP connection under 802.11 outage

[Bernard Aboba <aboba@internaut.com>]

> Sorry if this question has been asked before. I am trying to keep a TCP
> connection persistent (e.g. SSH, FTP) over a 802.11 AP even after the
> wireless link experiences temporary outage.

Please be specific about the manner in which the "outage" is generated.
Did you pull the plug on the AP, or is the AP shedding load in an orderly
way (e.g. by Disassociating its associated stations)?

>
> Currently the scenario goes like this:
> 1) 802.11 NIC detects loss of link;
> 2) OS tears down the interface and clears all the exisiting TCP states;

I do not believe that 2) is appropriate behavior: Transport protocols
should not tear down state on receipt of a "link down" indication.

Research by MIT LCS and others has shown that WLAN links need not
necessarily be in the "up" (low packet loss) or "down" (100% packet
loss) state -- they can be intermediate states where a large fraction
of packets are lost or where connectivity is intermittent.  This is
particularly true for 802.11 adhoc operation in mesh networks.

Even in an indoor Infrastructure WLAN network where the classic
"up"/"down" model usually holds, it is possible for a STA to wander out of
range and then come back.  Where no explicit packet exchange
(e.g. Disassociate, Deauthenticate, etc.) has occurred, the "link down"
determination is typically made in an implementation specific way, based
on RSSI, packet loss, etc.

Implementations vary widely;  some will send a "link down" in only a
few seconds, others will take much longer.  The details are highly
dependent on the rate negotiation algorithm, which is not part
of the 802.11 standard.

In general, tearing down transport state on receipt of a "link down" makes
transport protocols more brittle than they need to be.  It can be argued
that this is true even given an explicit packet exchange -- a given AP
might be shutting down for maintenance and the STA might scan and
associate with another nearby AP soon after.  In this case, what good
did it do to tear down transport state?

> Does anyone know how to solve (or approach) this problem under both
> Windows XP and Linux? If the NIC's device driver can shield the link
> outage from the upper layer, this problem should go away, correct?

Shielding the outage is certainly one way to approach the problem, but a
better way is to fix the transport code so that it doesn't respond to
"link down" events.

I'm in the process of editing a document on the subject.  Comments
welcome:
http://www.drizzle.com/~aboba/IAB/draft-iab-link-indications-00.txt