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.

I agree, it's a tight fit. I can't comment on the stability of the VHT amendment,
but it would be good to have some room left anyway. We might even want 
to add some info for 802.11ad at some point in the future, as it's also VHT.

> 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.

These are all valid points. If using a bit more space is not an issue,
combining these three fields would simplify things significantly.
 
> 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

I have put a new proposal at http://www.radiotap.org/suggested-fields/VHT
which is basically the format you are proposing but with a few tweaks.

As there is a fixed relation between NSS and NSTS, we can get by with only
having four per-user NSS values in the field and drop NSTS[4], which saves
one byte. The per-user MCS and NSS values are combined as they go
naturally together.

There is no explicit difference between MU and SU frames, all the info
is available in the VHT field. If required, one can still determine MU or SU 
from the group ID and hide information that is not applicable.
 
> 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?

The combined field is now 12 bytes and has some room to spare. I think
it's a nice improvement over the previous proposal, would you agree?

Alwin
 
> johannes
>