RE: Regarding A-MPDU status field

[Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>]

Hi,

> If space isn’t at a premium, I agree we should make it u32. There
> might be some embedded system sniffers where this space still matters,
> since it is multiplied by # of packets – but see discussion a
> paragraph later.

Hm, not sure -- yes, it is multiplied, but it's still dwarfed by the
size of the packets -- this won't help much if your system is disk space
constrained -- in that case you'll need to get the data out of it as
soon as possible anyway.

> >> 2) (New) A bit to indicate if the driver is capable of returning 
> >> information about individual zero MPDU length subframes.
> >Is that required/useful? It doesn't seem like per-frame information,
> and
> >global things are hard to deduct out of per-frame information?
> 
> The thought process behind adding that is as follows:
[...]
> An explicit indication of the driver’s capability to return info on
> 0-subframes  was proposed as a means to solve problem a).  Including
> it in every frame was suggested as a means to solve b-d.

Good points.

> But there may be better solutions. Requesting comments/alternatives
> from the group.

I can't think of anything, and it's just a bit in there anyway.

> Note:
> Some additional wireshark suggestions will be required (subject to
> comments from the group regarding the above):
> - Bit 2 should be processed by wireshark for every single frame.
> - Due to c),  ‘Driver generated A-MPDU reference number’ should be
> considered separate for every channel.
> If the end user combines two different sniffer captures taken on the
> same channel having overlapping absolute times, IMHO that is an
> end-user mistake.

That's an interesting point regarding channels -- I think that should be
a note in the radiotap spec of the field (for implementation purposes)

> >> 3) (New) A bit to indicate if the current subframe is a zero MPDU 
> >> length subframe. Valid if bit ‘2’ above is set.
> >This seems good, but the if the driver isn't capable this bit would
> >always be 0 obviously, so I'm not sure I see the need for '2'.
> 
> See explanation above regarding  why bit ‘2’ might be required.
> Besides, if we retain bit 2, the sniffer app can first examine it, and
> if it is zero, it can skip two things at once:
> - examination of  bit 3 here and
> - any additional 0-subframe related code while processing the Index
> field below (depending on sniffer app design).

Ok.

> >> 4) (Updated) Index field: Zero-based index of the subframe, within
> the 
> >> A-MPDU (u16). This is applicable to zero MPDU length subframes as 
> >> well, if bit ‘2’ above is set.
> >I guess a u16 will be sufficient even for VHT, right?
> 
> Yes (there was one piece of information I couldn’t manage to find in
> the draft I have when verifying this, but it should be ok).
> 
> For reasons similar to a) and b) under the discussion for ‘1) Driver
> generated A-MPDU reference number’,  I propose making this a u32.

Sounds good to me.

> >> Wireshark Implementation Suggestions:
> >> 
> >> 1) If bit 2 is set by driver: Total value of zero MPDU length
> padding 
> >> before a given non-zero length MPDU containing subframe should be 
> >> calculated by Wireshark. If the Delimiter CRC is in error for any
> of 
> >> the zero-length MPDU subframes involved, then the padding value
> should 
> >> be set to invalid (Question: Can we set this to something like 
> >> ‘indeterminate’ to differentiate it from the case where bit 2 is
> 0, 
> >> described below?)
> >"indeterminate" would be not adding the field to the parse tree at
> all
> 
> Am not sure I understood this fully. If the field is not added to the
> parse tree, and one tries to work with the value of this field using a
> filter expression, or if one uses tshark to try and extract the value
> of the field, what would be the outcome?
> (Sorry, I should be digging this from the Wireshark documentation or
> sources. But I am a bit short on time, so thought of asking).

You can't work with the field then. It has no value, and any comparison
will return false. This is why you can do things like just
"radiotap.field" in a filter -- that checks that it exists.


> >> 4) (Optional) Value of subframe padding length after the MPDU could
> be 
> >> calculated and displayed by Wireshark. Though this can be easily 
> >> calculated from MPDU length, it is good to help users easily
> observe 
> >> and filter on this value without having to resort to any post 
> >> processing scripts. If the value is readily observable, it might
> help 
> >> for example, a mobile app developer with only cursory knowledge of 
> >> 802.11n to chance upon and inquire into the reason for the padding.
> >> For real-time apps operating in noisy RF environments, adjusting
> the 
> >> payload bytes to minimize subframe padding may form one of many
> little 
> >> optimizations  to extract better performance (depending on traffic 
> >> characteristics).
> >What would it calculate, based on the data provided?
> 
> I didn’t get which app you are referring to  – Wireshark or the
> real-time app?

Sorry, not sure -- either one? Any application that displays things?

> I was suggesting in my example that the developer of the real-time app
> would gain knowledge about the padding behavior when experimenting
> with Wireshark during a study phase. She could then develop the real
> time app such that it checks the TCP/IP and 802.11 settings to
> estimate what the MPDU size would be, and then adjusts the # of app
> payload bytes (fed into the socket) to minimize the subframe-end
> padding wastage. This would be one among a series of little
> optimizations (and it wouldn’t work all the time).
> This is just an illustration.
> Again, it is independent of the Radiotap field definition.

Right. I had misunderstood you -- you wanted wireshark to display the
padding saying it could easily be calculated, and I thought you were
referring to a calculation wireshark would make, while you were in fact
referring to a calculation the user of wireshark would make. Sorry :)


So let me briefly recap what we talked about, is that accurate?

 A-MPDU radiotap field
-----------------------
bit index: TBD
alignment: 4 bytes (u32)

 * ampdu reference number (u32)
 * ampdu subframe index (u32) [*1]
 * flags (u8?)
   - 0x01: driver reports 0-length subframes
   - 0x02: is 0-length subframe (valid if 0x01 set)
   - 0x04: last subframe known
           (should be set for all subframes if driver knows)
   - 0x08: is last subframe in ampdu (valid if 0x04 set)
           (clear for all but last subframe)
   - 0x10: delimiter CRC error
   - 0x20: delimiter CRC value known
 * delimiter CRC value (u8) (valid if flag 0x20 set)


[*1] you said subframe index would be valid if driver reports 0-length
subframes -- why not a separate bit to indicate this is valid?

johannes