2009/4/23 Jouni Malinen <j@xxxxx>: > On Thu, Apr 23, 2009 at 07:35:55PM +0200, Gábor Stefanik wrote: >> Handling of multicast/NO_ACK packets by mac80211 rate scaling is a >> mess. Basically, the rule of thumb is that any packet with >> IEEE80211_TX_CTL_NO_ACK (including multicasts and broadcasts, which >> always have this flag set) should be sent at lowest rate (unless >> overridden by radiotap - this is not covered in this patchset), with >> no retries. > > While this may be the case with the current rate control > implementations, this is not a good assumption to make. > Multicast/broadcast frames could (and often really should) be > transmitted at higher rate, i.e., the rate control algorithm could > figure out that all associated STAs should be able to receive frames at > a higher basic rate. > > As far as unicast no-ACK frames are concerned, those could (and again, > should) be sent at higher rate, too, if the receiving STA can be assumed > to be able to receive the frame with "large enough" probability. > >> So, the right thing to do in any rate scaling algorithm: >> * Check for IEEE80211_TX_CTL_NO_ACK. No need to check >> is_multicast_ether_addr, as multicasts always have NO_ACK set. >> * If it is set, select the lowest available rate (unless overridden >> by radiotap), with a retry count of 0 (total try count of 1). > > I would not agree with these as general rules for all rate control > algorithms. > > -- > Jouni Malinen PGP id EFC895FA > Yes, I agree what you write - but the point of the patchset is to make sure that (1) all NO_ACK frames get correct treatment, not just multicasts and (2) NO_ACK/multicast frames aren't requested to be retried (which is obviously wrong, and results in always retrying till the limit is reached). Developing an algorithm to allow NO_ACKs to be transmitted at a higher rate is beyond the scope of this patchset. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
