[RFC] per-sta reassembly buffers

[RFC] per-sta reassembly buffers

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

Hey,

I was looking through the defragmentation code and noticed that we only
allow four fragmented frames to be in flight at the same time. It seems
that in a somewhat contended QoS network where fragmentation is enabled
this is far from enough since as far as I can tell from the standard
each source STA may be sending fragmented frames in the various access
categories (think starting in background and then preempting by best
effort etc.)

We could easily increase this by using per-sta reassembly buffers at no
CPU cost [1] but that has the obvious disadvantage of having much higher
worst-case memory usage. Thoughts?

johannes

[1] the reassembly code can even be made faster then: instead of looking
through all four reassembly buffers whether they match we already know
that the source MAC matches, and by default we can hash into the four
slots by the lowest two bits of the sequence number and only if no match
continue to look in the other slots, this shouldn't really ever happen
as far as I can tell.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [RFC] per-sta reassembly buffers

[Jouni Malinen]

On Wed, Sep 05, 2007 at 12:28:22PM +0200, Johannes Berg wrote:

> I was looking through the defragmentation code and noticed that we only
> allow four fragmented frames to be in flight at the same time. It seems
> that in a somewhat contended QoS network where fragmentation is enabled
> this is far from enough since as far as I can tell from the standard
> each source STA may be sending fragmented frames in the various access
> categories (think starting in background and then preempting by best
> effort etc.)

I would have expected STAs to transmit only one MSDU at a time to any
given destination STA. This was the way it was done before QoS and I did
not find any clear point in QoS changes that would have changed the
behavior. The changes in the duplicate detection are, though, implicitly
pointing out that there may actually be separate fragmentation for each
TID.

> We could easily increase this by using per-sta reassembly buffers at no
> CPU cost [1] but that has the obvious disadvantage of having much higher
> worst-case memory usage. Thoughts?

The main reason for the original design was in being conservative with
memory use. After all, this was used for embedded devices with very
limited memory capabilities and the AP was actually allowing up to 2007
STAs to be associated. If each associated STA were to use fragmentation
and if there were large number of lost (un-ACK'ed) frames, the total
memory buffers needed for the frames could go quite high.

Since fragments are commonly sent out in a burst that includes the full
MSDU, the number of pending fragments from unfinished MSDUs is often
quite a bit smaller than the worst case.

Anyway, I would be fine with changing this as long as there is a way of
enforcing the total number of buffered frames to be below a reasonable
(and preferably configurable) limit.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [RFC] per-sta reassembly buffers

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]

On Wed, 2007-09-05 at 19:06 -0700, Jouni Malinen wrote:

> I would have expected STAs to transmit only one MSDU at a time to any
> given destination STA.

Yeah, me too, but I came to challenge that expectation recently :)

> This was the way it was done before QoS and I did
> not find any clear point in QoS changes that would have changed the
> behavior. The changes in the duplicate detection are, though, implicitly
> pointing out that there may actually be separate fragmentation for each
> TID.

Right. Not very specific. Maybe something for 802.11ma, if it hadn't
been dissolved ;)

> The main reason for the original design was in being conservative with
> memory use. After all, this was used for embedded devices with very
> limited memory capabilities and the AP was actually allowing up to 2007
> STAs to be associated. If each associated STA were to use fragmentation
> and if there were large number of lost (un-ACK'ed) frames, the total
> memory buffers needed for the frames could go quite high.

Yes, I understand, hence my question.

> Since fragments are commonly sent out in a burst that includes the full
> MSDU, the number of pending fragments from unfinished MSDUs is often
> quite a bit smaller than the worst case.

Obviously. Since we're talking about a single station having a
fragmented frame outstanding in each access category, this would mean
that others stations would have to contend very much in the voice
category to even allow this situation to happen. Not very likely.

> Anyway, I would be fine with changing this as long as there is a way of
> enforcing the total number of buffered frames to be below a reasonable
> (and preferably configurable) limit.

Good plan actually, implementing it would probably require having the
skbs on two lists: one per station to lookup and one global list to age
them. Shouldn't be hard to implement at all, I'll look into it.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]