Re: [RFC] VHT fields

On Tue, 2012-06-12 at 15:05 +0000, Alwin Beukers wrote:

> http://www.radiotap.org/suggested-fields/GROUP_ID

(I just deleted that)

> http://www.radiotap.org/suggested-fields/SU_VHT
> http://www.radiotap.org/suggested-fields/MU_VHT
> http://www.radiotap.org/suggested-fields/PARTIAL_AID

So one thing that strikes me is that this is not extensible at all any
more now inside the VHT fields, all the known flags are already used up.
I don't know if there's anything else in VHT that could possibly be of
relevance in the future though? Also, how stable is the VHT amendment? I
haven't followed it closely.

With the SU_VHT field being 5 bytes and the PARTIAL_AID requiring 2 byte
alignment, having them follow each other wastes a byte. I'm not worried
about that at all, but I wonder if splitting this into three fields is
really worth it? Given the many dependencies on SU/MU in all fields, it
almost seems that making them all one (slightly bigger) VHT field would
be easier to use?

If we wanted to go there, we could even use a union:

require 2 byte alignment of the VHT field, and then have
u8 known
u8 flags
u8 bw
u8 mcs
u8 gid
union {
	struct {
		u8 pad
		u16 partial_aid
	} su
	struct {
		u8 user1, user2, user3
	} mu
}



Also, looking at the fields in more detail, does it really make sense to
have the bits packed so tightly? NSTS and bandwidth for example, do they
really belong into the same field?

Also I think the coding/NSTS for the first and three other users should
be more regular? It seems then it wouldn't be possible to squeeze it all
into one byte per user, but ... does that really matter so much? This
isn't a huge amount of data.

Ok wait, I don't even see now how to distinguish between SU and MU
frames, except by the presence of the other fields? That's a bit
awkward, don't you think?

I think overall I'd probably just use a bit more space and make the
format more regular instead of packing MU/SU fields like MCS in with
common fields like NSS.


How about this:

u8 known         - maybe split this up further, or are there technical
                   reasons that e.g. if the coding is known the LDPC
                   extra symbol must also be known?
u8 flags         - add a MU/SU flag (and hope that all receivers know
                   this, or add a known flag?)
u8 bw            - only the bandwidth, not NSTS
u8 nss           - or maybe this could be packed with the bandwidth
u16 P_AID        - partial AID, valid only if SU
u8 NSTS[4]       - NSTS for up to 4 users
u8 mcs_coding[4] - MCS/coding/coding_known(?) for up to 4 users


Overall, this is just 6 bytes longer than your previous encoding (or
maybe 7 or 8 if flags/known now need to be extended), but I think it's
much more regular?

johannes