RE: Regarding A-MPDU status field

Hi,

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

Timing deduction can still be made with u16 in a VHT scenario. For the u16 reference number to rollover in say 1 second, A-MPDUs would have to be received at an average rate of (1000000/65536)=15.25 microseconds. This average rate would have to be sustained over the period of the entire second. Even with VHT, this may not happen in practical situations given Interframe Spacing requirements (albeit reduced), contention, and intervening non-AMPDU traffic. If for argument’s sake we take a theoretical _sustained_ rate of one A-MPDU every 2 microseconds (which as per my current understanding, cannot occur anyway), we still have a rollover spacing of >131 ms which is large. It is much above the max time spacing between MPDUs in the same A-MPDU for even 11n.

But I now feel u32 will be preferable given that a) the VHT amendments are still in draft b) there is always the possibility of other amendments in the future c) we would like a common simple criterion to be applied by the sniffer application which can work irrespective of current/future PHY parameters and for all theoretical possibilities.

>If I understand correctly, this would be generated by the driver 

That is correct. 

>> 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:
a) If none of the subframes returned by the driver are marked as 0-subframes, the sniffer app has two ways of interpreting this, leading to confusion: 
    i) No 0-subframe padding was actually used over the air (valid since tMMSS as defined in the standard can be zero).
    ii) Padding may or may not have been used over the air, but the driver is not capable of indicating this, so it is unknown.
Providing the same output to the end user for i) and ii) could be misleading.
To allow the sniffer app to come to the right conclusion, we need a way of helping it reliably differentiate between i) and ii)

b) Sniffer capture files can be filtered and saved into smaller files. The differentiating information discussed in a) should survive this. 

c) Conversely, sniffer capture files can be combined (e.g., for multi-channel roaming performance analysis). Different sniffer drivers/hardware could have been used for each channel. The differentiating information discussed in a) should not get mixed up in such situations.

d) The files, whether original or abridged, can be sent to other users not having access to the original setup used for the capture.

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.

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

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.

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

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

>The note about 0-length subframes seems pointless since they otherwise don't exist?

See discussions for bits 2 and 3 above.

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

I agree. That will promote uniformity. It might increase the work for the driver writer, depending on design, but that should be ok.

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

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

For the sake of uniformity, I think it would be good to display it.
Besides, it would be beneficial for users trying to learn how things work on the air, from observation. 
May be we can keep it Optional like ‘4’ below, for starters.  It is independent of the Radiotap field definition anyway.

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

Regds,
Krishna