From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rao, Krishna" Subject: RE: Regarding A-MPDU status field Date: Sun, 8 Jan 2012 13:43:30 +0000 Message-ID: <21E1C3B49A18BA428D58607D5EEA5398C20149@nasanexd02b.na.qualcomm.com> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> ,<1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> ,<1321259214.4472.16.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BC8C00@nasanexd02b.na.qualcomm.com> <1321867620.3999.7.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C1F289@nasanexd02b.na.qualcomm.com>,<1325673736.3339.27.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1325673736.3339.27.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> Content-Language: en-US Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: Johannes Berg Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org Hi,=0A= =0A= >> 1) (New) Driver generated A-MPDU reference number (u16). All subframes = =0A= >> belonging to the same A-MPDU will have the same reference number (but = =0A= >> see rollover condition discussed shortly). This reference number =0A= >> allows the driver to reliably convey to sniffer application which =0A= >> subframes it found under the same A-MPDU, independent of driver data =0A= >> path characteristics, zero MPDU length subframes, mix of traffic on =0A= >> the air, and various error conditions. The reference number is common = =0A= >> across all traffic and not maintained separately for separate DA-SA =0A= >> pairs or any such tuples.=0A= >> Rollover is easily handled by sniffer application using timestamp =0A= >> locality. Subframes with the same reference number which don't =0A= >> actually belong to the same A-MPDU (owing to rollover) will have =0A= >> timestamps several seconds apart.=0A= >I like this. Maybe we should extend it to u32 though? Space probably isn't= at a premium,=0A= >and VHT might make the timing deduction harder in the future?=0A= =0A= If space isn=92t at a premium, I agree we should make it u32. There might b= e some embedded system sniffers where this space still matters, since it is= multiplied by # of packets =96 but see discussion a paragraph later.=0A= =0A= 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 rece= ived at an average rate of (1000000/65536)=3D15.25 microseconds. This avera= ge rate would have to be sustained over the period of the entire second. Ev= en with VHT, this may not happen in practical situations given Interframe S= pacing requirements (albeit reduced), contention, and intervening non-AMPDU= traffic. If for argument=92s sake we take a theoretical _sustained_ rate o= f one A-MPDU every 2 microseconds (which as per my current understanding, c= annot occur anyway), we still have a rollover spacing of >131 ms which is l= arge. It is much above the max time spacing between MPDUs in the same A-MPD= U for even 11n.=0A= =0A= 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 th= e future c) we would like a common simple criterion to be applied by the sn= iffer application which can work irrespective of current/future PHY paramet= ers and for all theoretical possibilities.=0A= =0A= >If I understand correctly, this would be generated by the driver =0A= =0A= That is correct. =0A= =0A= >> 2) (New) A bit to indicate if the driver is capable of returning =0A= >> information about individual zero MPDU length subframes.=0A= >Is that required/useful? It doesn't seem like per-frame information, and= =0A= >global things are hard to deduct out of per-frame information?=0A= =0A= The thought process behind adding that is as follows:=0A= a) If none of the subframes returned by the driver are marked as 0-subframe= s, the sniffer app has two ways of interpreting this, leading to confusion:= =0A= i) No 0-subframe padding was actually used over the air (valid since tM= MSS as defined in the standard can be zero).=0A= 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.=0A= Providing the same output to the end user for i) and ii) could be misleadin= g.=0A= To allow the sniffer app to come to the right conclusion, we need a way of = helping it reliably differentiate between i) and ii)=0A= =0A= b) Sniffer capture files can be filtered and saved into smaller files. The = differentiating information discussed in a) should survive this. =0A= =0A= c) Conversely, sniffer capture files can be combined (e.g., for multi-chann= el 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.=0A= =0A= d) The files, whether original or abridged, can be sent to other users not = having access to the original setup used for the capture.=0A= =0A= An explicit indication of the driver=92s capability to return info on 0-sub= frames was proposed as a means to solve problem a). Including it in every= frame was suggested as a means to solve b-d.=0A= =0A= But there may be better solutions. Requesting comments/alternatives from th= e group.=0A= =0A= Note:=0A= Some additional wireshark suggestions will be required (subject to comments= from the group regarding the above):=0A= - Bit 2 should be processed by wireshark for every single frame.=0A= - Due to c), =91Driver generated A-MPDU reference number=92 should be cons= idered separate for every channel.=0A= If the end user combines two different sniffer captures taken on the same c= hannel having overlapping absolute times, IMHO that is an end-user mistake.= =0A= =0A= >> 3) (New) A bit to indicate if the current subframe is a zero MPDU =0A= >> length subframe. Valid if bit =912=92 above is set.=0A= >This seems good, but the if the driver isn't capable this bit would=0A= >always be 0 obviously, so I'm not sure I see the need for '2'.=0A= =0A= See explanation above regarding why bit =912=92 might be required.=0A= Besides, if we retain bit 2, the sniffer app can first examine it, and if i= t is zero, it can skip two things at once:=0A= - examination of bit 3 here and=0A= - any additional 0-subframe related code while processing the Index field b= elow (depending on sniffer app design).=0A= =0A= >> 4) (Updated) Index field: Zero-based index of the subframe, within the = =0A= >> A-MPDU (u16). This is applicable to zero MPDU length subframes as =0A= >> well, if bit =912=92 above is set.=0A= >I guess a u16 will be sufficient even for VHT, right?=0A= =0A= Yes (there was one piece of information I couldn=92t manage to find in the = draft I have when verifying this, but it should be ok).=0A= =0A= For reasons similar to a) and b) under the discussion for =911) Driver gene= rated A-MPDU reference number=92, I propose making this a u32.=0A= =0A= >The note about 0-length subframes seems pointless since they otherwise don= 't exist?=0A= =0A= See discussions for bits 2 and 3 above.=0A= =0A= >> (To accommodate the case where a driver/hardware combination may be =0A= >> capable of providing total zero MPDU based padding length before a =0A= >> given subframe, but not info on individual zero MPDU subframes =0A= >> themselves, should we add one more field which directly gives the =0A= >> total padding length? Bit 2 will be zero in this case. Discussion 1 =0A= >> under ' Wireshark Implementation Suggestions' will get modified).=0A= >Not sure -- it could generate one (or more?) padding frame(s) in that case= , no?=0A= =0A= I agree. That will promote uniformity. It might increase the work for the d= river writer, depending on design, but that should be ok.=0A= =0A= >> Wireshark Implementation Suggestions:=0A= >> =0A= >> 1) If bit 2 is set by driver: Total value of zero MPDU length padding = =0A= >> before a given non-zero length MPDU containing subframe should be =0A= >> calculated by Wireshark. If the Delimiter CRC is in error for any of =0A= >> the zero-length MPDU subframes involved, then the padding value should = =0A= >> be set to invalid (Question: Can we set this to something like =0A= >> =91indeterminate=92 to differentiate it from the case where bit 2 is 0, = =0A= >> described below?)=0A= >"indeterminate" would be not adding the field to the parse tree at all=0A= =0A= 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 ex= pression, or if one uses tshark to try and extract the value of the field, = what would be the outcome?=0A= (Sorry, I should be digging this from the Wireshark documentation or source= s. But I am a bit short on time, so thought of asking).=0A= =0A= >> 3) If Delimiter CRC is not in error, the driver will not copy the CRC = =0A= >> value from hardware. Wireshark should calculate the value itself.=0A= >Or simply not display it I guess.=0A= =0A= For the sake of uniformity, I think it would be good to display it.=0A= Besides, it would be beneficial for users trying to learn how things work o= n the air, from observation. =0A= May be we can keep it Optional like =914=92 below, for starters. It is ind= ependent of the Radiotap field definition anyway.=0A= =0A= >> 4) (Optional) Value of subframe padding length after the MPDU could be = =0A= >> calculated and displayed by Wireshark. Though this can be easily =0A= >> calculated from MPDU length, it is good to help users easily observe =0A= >> and filter on this value without having to resort to any post =0A= >> processing scripts. If the value is readily observable, it might help = =0A= >> for example, a mobile app developer with only cursory knowledge of =0A= >> 802.11n to chance upon and inquire into the reason for the padding.=0A= >> For real-time apps operating in noisy RF environments, adjusting the =0A= >> payload bytes to minimize subframe padding may form one of many little = =0A= >> optimizations to extract better performance (depending on traffic =0A= >> characteristics).=0A= >What would it calculate, based on the data provided?=0A= =0A= I didn=92t get which app you are referring to =96 Wireshark or the real-ti= me app?=0A= I was suggesting in my example that the developer of the real-time app woul= d gain knowledge about the padding behavior when experimenting with Wiresha= rk 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 wo= uld be, and then adjusts the # of app payload bytes (fed into the socket) t= o minimize the subframe-end padding wastage. This would be one among a seri= es of little optimizations (and it wouldn=92t work all the time).=0A= This is just an illustration.=0A= Again, it is independent of the Radiotap field definition.=0A= =0A= Regds,=0A= Krishna=0A=