Hi Lachlan,
First: I missed the whole page slicing with its extra element and the
capability when I read through it earlier. But then of course we can
simply decide not to implement that on either side, i.e. client doesn't
support it, and AP just doesn't take advantage of it (and thus is
limited to fewer STAs even if some of them implement page slicing.)
(So we have dot11PageSlicingImplemented = false and
dot11PageSlicingActivated = false as well.)
> > Which ... seems questionable? At least in terms of message it's not
> > actually _invalid_ if it's out of this range, in theory S1G allows up to
> > 8191.
>
> Yes, from a client side it is. See comments below.
Maybe I'm confused, but what do you mean by invalid from the client
side"? I've been looking now and didn't find any restrictions on the AID
for STAs that e.g. don't implement page slicing, though of course an AP
might want to e.g. reserve lower AIDs for them and always use higher
AIDs for STAs with page slicing even if lower AIDs are free.
> > Also the parsing for S1G only parses a subset of the valid formats,
> > notably the format that mac80211 can generate. That seems questionable,
> > unless you expect there never to be another implementation (or the
> > mac80211 one to never be extended) and you can basically make up your
> > own standard?
> >
> > And even if you _do_ get an AID that's <1600 there's still no guarantee
> > that the encoding will be in the bitmap format, if only two stations
> > have traffic the AP might well decide to use the "Single AID" mode?
> >
> > So I'm overall a bit confused how all this is meant to work - even if
> > only partially - because AID<1600 is no guarantee that you can parse the
> > bitmap, so turning off powersave only for AID>=1600 will not really be
> > sufficient?
>
> This is something we discussed internally, and in retrospect mac80211
> should be able to parse all types, even though it may only encode a
> single type. So actually my reasoning for this is not very good as it
> was essentially "nobody uses the other encoding modes" but in the future
> who knows if that will remain true...
Yeah OK, that's fair, I'm really not going to push you too hard push
into "must implement the spec faithfully" territory, and you know better
than me what might be deployed or not matter, and lifetime of systems
being built now possibly factors into it etc.
Mostly I'm asking because I didn't really understand what it was trying
to do, so even clarifying that only part of it is implemented might be
reasonable.
> After verifying with the standard and based on your feedback here is
> what I propose:
>
> For a first implementation, we still won't support page slicing - but
> this is fine as it is an advertised capability.
Right.
> A new bitmap
> should be added for S1G (as mentioned, probably a union of some sort
> with the existing bitmap) that allows us to use the _actual_ S1G AID
> count, this ensures correct interoperability into the future and is
> safe due to page slicing being a discrete capabilitity.
OK I don't even follow here ... I feel confused between the AP side and
non-AP STA side now.
If you talk about a union, do you literally mean in a struct or
something? I'm not sure that really matters for either side? The AP side
has the ps->tim bitmap, but that could even remain as is, even if it
limits the # of STAs to 2008 right now. That's not a big deal, it just
limits the AIDs to that, but that's an implementation choice. It just
won't be able to have more STAs connected, but that's OK?
(In principle, we don't even really _need_ the ps->tim bitmap as a
bitmap, we could iterate the stations instead or something, but that's
more expensive and so the ps->tim bitmap is an optimisation, at least I
see it that way.)
Obviously the AP side then for S1G can't just put the partial virtual
bitmap from the ps->tim bitmap into the frame, but that's ultimately
just a question of bit twiddling while building the frame too. So not
sure where a union is needed for the AP side :)
For the client side, similarly, all it has to do is be able to walk
through the element (elements, if later implementing page slicing), and
be able to identify whether or not its own bit is set, so it never
really needs a holistic view of the bitmap.
> So as per figure 9-214, we can still use a page slice number of 31 which
> states that the entire page indicated by the page index is encoded in
> the PVB, but given we now have a correctly sized AID bitmap we would
> correctly determine the page index. On the AP side, we would encode
> using block bitmap but correctly indicate the page index. On the STA
> side, we'd properly decode the PVB with the ability to decode all possible
> formats. So this would consist of block bitmap, single AID, OLB and ADE
> alongside their equivalent inverts.
Yeah, that seems right.
(And kunit tests for this parsing would probably be a good idea :) )
> One concern I have is that without page slicing, we are limited to a TIM
> of size 255. A single page represents 2048 AIDs (page index = 2 bits),
> using block bitmap encoding we can overflow given worst case scenario.
> Now the easy answer is to probably encode until we hit the maximum
> length, allow STAs to clear their bit after the beacon and repeat.
> Though maybe this isn't the nicest? Not sure. Obviously this is an
> extreme case and would (hopefully) never happen in the real wordl but
> still needs to be considered. Internally, we default to block bitmap
> encoding and this isn't modified dynamically, same goes for most
> (if not all) vendor implementations - but as mentioned the client needs
> the ability to decode these other formats.
If I'm reading the spec correctly, then the worst case for only encoding
with block bitmaps would be having a large number of scattered AIDs
indicate presence, which would require
- DTIM count [1 octet]
- DTIM period [1 octet]
- Bitmap Control [1 octet]
- B0 (depends on traffic)
- B1-B5: 31 (special page slice)
- B6-B7: 0b00 (page index 0)
- followed by a number B of blocks, numbered b=0..B-1, each:
- Block Control [1 octet]
- encoding mode: block bitmap
- inverse: 0
- block offset: b * 64
- Block Bitmap: 0xFF [1 octet, assuming worst case]
- subblocks [8 octets]
so out of 255 octets, 3 are overhead, leaving 252 = 25*10+2 for up to 25
blocks, for up to 64*25=1600 AIDs? I think? Which matches your 1600, so
whew, maybe I did this right ;-)
