RE: Regarding A-MPDU status field

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

Hi Rao,

> Here is the new proposal based on earlier discussions. This is not yet
> in standard Radiotap field definition format. This is because there
> are some subfields which have not been discussed before (or have been
> updated), and the group may have comments on these. Comments on
> previously settled subfields too are welcome.

Cool, thanks.

> 1) (New) Driver generated A-MPDU reference number (u16). All subframes
> belonging to the same A-MPDU will have the same reference number (but
> see rollover condition discussed shortly). This reference number
> allows the driver to reliably convey to sniffer application which
> subframes it found under the same A-MPDU, independent of driver data
> path characteristics, zero MPDU length subframes, mix of traffic on
> the air, and various error conditions. The reference number is common
> across all traffic and not maintained separately for separate DA-SA
> pairs or any such tuples.
> Rollover is easily handled by sniffer application using timestamp
> locality. Subframes with the same reference number which don't
> actually belong to the same A-MPDU (owing to rollover) will have
> timestamps several seconds apart.

I like this. Maybe we should extend it to u32 though? Space probably
isn't at a premium, and VHT might make the timing deduction harder in
the future?

If I understand correctly, this would be generated by the driver anyway
(and I see easily how I could generate it in our drivers)

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

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

> 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?
The note about 0-length subframes seems pointless since they otherwise
don't exist?

> 5) A bit to indicate if ‘6’ below is valid.
> 6) A bit to indicate if this is the last subframe in the A-MPDU. This
> does not apply to zero MPDU length subframes.

Right, they can't be last.

> 7) (Updated) A bit to indicate if the Delimiter CRC is in error. This
> is applicable to zero MPDU length subframes as well, if bit ‘2’ above
> is set. If the driver/hardware doesn’t pass upwards subframes for
> which Delimiter CRC is in error, then this bit should be cleared (i.e.
> 0) all the time - only successfully parsed subframes will be passed to
> the sniffer application (note that here, successfully parsed does not
> necessarily mean that the 802.11 FCS too will be valid – the two are
> different).
> We don’t provide a means to indicate if this bit is ‘invalid’. If a
> driver doesn’t know whether what it is passing upwards has been
> successfully parsed or not, IMHO there could be serious implementation
> mistakes at some level.
> 8) A bit to indicate if ‘9’ below is valid.
> 9) Delimiter CRC value itself (8 bits). Applicable only if the
> Delimiter CRC is in error, i.e. bit 7 is set.

Makes sense.

> (To accommodate the case where a driver/hardware combination may be
> capable of providing total zero MPDU based padding length before a
> given subframe, but not info on individual zero MPDU subframes
> themselves, should we add one more field which directly gives the
> total padding length? Bit 2 will be zero in this case. Discussion 1
> under ' Wireshark Implementation Suggestions' will get modified). 

Not sure -- it could generate one (or more?) padding frame(s) in that
case, no?

> 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

> 2) If Delimiter CRC is in error, then the hardware may or may not
> return the suspect MPDU bytes.
>     a) If h/w does not return MPDU bytes, then Wireshark can display
> just the Radiotap header without the MPDU contents
>     b) If h/w does return the suspect MPDU bytes, Wireshark may carry
> out one of the following based on configuration settings:
>         i) Display the suspect MPDU as a bunch of un-dissected bytes.
>         ii) Attempt a heuristic dissection of the MPDU bytes. But note
> that this can go quite wrong due to uncertainty about validity of MPDU
> boundaries.
>  
> 3) If Delimiter CRC is not in error, the driver will not copy the CRC
> value from hardware. Wireshark should calculate the value itself.

Or simply not display it I guess.

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

johannes