Re: d80211: current TKIP hwcrypto implementation seems to be broken

["Jouni Malinen" <jkm@devicescape.com>]

On Tue, Feb 13, 2007 at 03:08:03AM +0200, Tomas Winkler wrote:

> There are real cases when this happens. Try to two different AC for
> example  VoIP and have FTP in parallel.  Packets for low priority AC
> can be stalled encrypted and scheduled in a AP TX queue while high
> priority packets are already sent with the new key.
> Maybe the new key can be computed on demand but it's good thing to
> preserve the old key for while.

I don't know the particular hardware design well enough to comment on
this, but d80211 software implementation keeps a separate RX P1K for
each AC (actually, each TID). In other words, this kind of issue does
not show up there. If the hardware implementation is limited to only one
P1K for RX, there may be some benefit on storing old keys in some cases,
but I'm not sure how that would work if the key has to be configured
before the frame is actually received.

In other words, in this case, the next frame after an FTP packet could
well be from voice and not background and reconfiguring the old P1K
value could have caused more latency on the higher priority frame at
this point.. In other word, if there is only one RX P1K, the benefits
for throughput may be requiring compromise on latency for higher
priority traffic and that may or may not be acceptable.

-- 
Jouni Malinen                                            PGP id EFC895FA