very broken 802.11 retransmit?

[Brad Karp <bkarp@aciri.org>]

I'm rubbing my eyes in disbelief, but it appears that the current 802.11
MAC code in the CVS repository uses the following to compute the
timeout value for a transmitted 802.11 data packet:

                if((u_int32_t)ETHER_ADDR(mh->dh_da) != MAC_BROADCAST)
                        //timeout = ACKTimeout(netif_->txtime(pktTx_))+5;
                        timeout = ACKTimeout(len) + 10;
                else
                        timeout = TX_Time(pktTx_);

Note the clause taken in the "true" case. This timeout value (i.e., when
a sender decides an 802.11 data packet transmission failed because no ACK
came back) is in *seconds*!!!

Many in the IP community are philosophically opposed to link-level
retransmission. But please, be confident enough to believe it will show itself
harmful *without* rigging ns to cause one 10-second outage for each ACK that
doesn't return! :-) (BTW, it is that bad--the code HOL blocks while awaiting
an ACK for the most recently transmitted packet.)

ACKTimeout() computes the 802.11-compliant value.

I verified that the CMU-distributed code doesn't include this + 10. Who put
it there, and why?

I spent hours poring over *my* routing protocol code, mystified about these
rare but very long outages between nodes that were clearly in range of one
another. Sigh.

-Brad, karp@eecs.harvard.edu