Regarding A-MPDU status field

Regarding A-MPDU status field

[Rao, Krishna]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

Hi everyone,

I noticed that the A-MPDU status field has been listed under 'Suggested Fields' (http://www.radiotap.org/suggested-fields). I feel having this field will make things easier in some scenarios, especially when carrying out performance related analysis.

I would like to request for this field to be made official.

(In case I am missing any context, do let me know. I did briefly check the mailing list, but something might have slipped by).

Regards,
Krishna Rao,
Sr. Lead Engineer,
Qualcomm Atheros Inc.



[-- Attachment #2: Type: text/html, Size: 2682 bytes --]

Re: Regarding A-MPDU status field

[Johannes Berg]

[please try writing text-only email]

> I noticed that the A-MPDU status field has been listed under
> ‘Suggested Fields’ (http://www.radiotap.org/suggested-fields). I feel
> having this field will make things easier in some scenarios,
> especially when carrying out performance related analysis.

Indeed.

> I would like to request for this field to be made official. 

I had worked on this for a while, but never followed through on the
process of formally adopting it.

Having a driver that supports this field would also be required so we
can judge its implementation, and so far I haven't had a chance to add
support to any driver. If you can do that for any of the QCA drivers
that would be helpful.

Also, the question about the contents came up at some points -- it might
also be helpful to know the padding length before/after (?) the packet
for example.

johannes

RE: Regarding A-MPDU status field

[Rao, Krishna]

Hi,

>Having a driver that supports this field would also be required so we can judge its implementation,
>and so far I haven't had a chance to add support to any driver. If you can do that for any of the QCA
>drivers that would be helpful.
Once we settle upon the additional content (discussed below), I'll see if I can get someone to try this out on ath9k. Else, I would love to add the support myself during one of the coming weekends when I get spare time.

>Also, the question about the contents came up at some points 
I agree it would be a good idea to discuss additional contents before finalizing the field. I'll present some suggestions to restart the discussion. Requesting feedback from the group.

> -- it might also be helpful to know the padding length before/after (?) the packet for example.
We can add
1) Padding length information
a) value of padding length after the MPDU, and
b) (debatable) total padding length before the subframe for the special case of preceding delimiters with MPDU length zero used to meet minimum MPDU start spacing requirements. All the octets of the preceding 'zero delimiters' together form the pad, as I understand. Note that this information might not be provided by some hardware.
If an MPDU (not 'zero delimiter') is actually present prior to the current subframe for which radiotap info is being displayed, 1b) should be zero for the current subframe. Post MPDU pad length information for the prior MPDU would anyway be available (assuming the containing subframe of the prior MPDU is not corrupted).

Additionally:
2) A bit to indicate if this is the last subframe in the A-MPDU. Though there might be other ways to infer this information, having it as an explicit field would provide convenience. 
3) A bit to indicate if the Delimiter CRC is in error.
4) (Debatable) Delimiter CRC value itself. I don't know if there is any hardware which returns the actual value to software. Anyway, having it as part of the field will allow platforms which do possess the capability, to provide this information. It may come in handy for some users.

For all the above fields, there should be corresponding bits to indicate if the value is valid.

Regds,
Krishna Rao

-----Original Message-----
From: Johannes Berg [mailto:johannes@sipsolutions.net] 
Sent: Wednesday, November 02, 2011 2:12 PM
To: Rao, Krishna
Cc: radiotap@radiotap.org
Subject: Re: Regarding A-MPDU status field

[please try writing text-only email]

> I noticed that the A-MPDU status field has been listed under 
> ‘Suggested Fields’ (http://www.radiotap.org/suggested-fields). I feel 
> having this field will make things easier in some scenarios, 
> especially when carrying out performance related analysis.

Indeed.

> I would like to request for this field to be made official. 

I had worked on this for a while, but never followed through on the process of formally adopting it.

Having a driver that supports this field would also be required so we can judge its implementation, and so far I haven't had a chance to add support to any driver. If you can do that for any of the QCA drivers that would be helpful.

Also, the question about the contents came up at some points -- it might also be helpful to know the padding length before/after (?) the packet for example.

johannes

RE: Regarding A-MPDU status field

[Johannes Berg]

Hi,

> > -- it might also be helpful to know the padding length before/after
> (?) the packet for example.
> We can add
> 1) Padding length information
> a) value of padding length after the MPDU, and
> b) (debatable) total padding length before the subframe for the
> special case of preceding delimiters with MPDU length zero used to
> meet minimum MPDU start spacing requirements. All the octets of the
> preceding 'zero delimiters' together form the pad, as I understand.
> Note that this information might not be provided by some hardware.
> If an MPDU (not 'zero delimiter') is actually present prior to the
> current subframe for which radiotap info is being displayed, 1b)
> should be zero for the current subframe. Post MPDU pad length
> information for the prior MPDU would anyway be available (assuming the
> containing subframe of the prior MPDU is not corrupted).

So what I wanted here was to be able to reconstruct what happened on the
air as precisely as possible. I don't think the length of the padding is
actually needed -- it can be calculated after the fact since it is
always 0-3 bytes up to a multiple of 4. The number of zero delimiters
would be more interesting.

I'm not sure how to deal with the corruption case.

> Additionally:
> 2) A bit to indicate if this is the last subframe in the A-MPDU.
> Though there might be other ways to infer this information, having it
> as an explicit field would provide convenience. 

That seems useful, although I'm not even sure how you would even know
that it is the last one?

> 3) A bit to indicate if the Delimiter CRC is in error.

That's useful, but in that case are you even decoding the MPDU and
passing it up? Also what if a zero delimiter has a bad CRC? Or what if
it just got corrupted and you have to recover parsing? I'm not sure we
can cover all these cases.

> 4) (Debatable) Delimiter CRC value itself. I don't know if there is
> any hardware which returns the actual value to software. Anyway,
> having it as part of the field will allow platforms which do possess
> the capability, to provide this information. It may come in handy for
> some users.

That seems a bit of a stretch, but it's only 8 bits so I wouldn't mind
adding it.

johannes

Re: Regarding A-MPDU status field

[David Young]

On Wed, Nov 09, 2011 at 03:02:46PM +0100, Johannes Berg wrote:
> Hi,
> 
> > > -- it might also be helpful to know the padding length before/after
> > (?) the packet for example.
> > We can add
> > 1) Padding length information
> > a) value of padding length after the MPDU, and
> > b) (debatable) total padding length before the subframe for the
> > special case of preceding delimiters with MPDU length zero used to
> > meet minimum MPDU start spacing requirements. All the octets of the
> > preceding 'zero delimiters' together form the pad, as I understand.
> > Note that this information might not be provided by some hardware.
> > If an MPDU (not 'zero delimiter') is actually present prior to the
> > current subframe for which radiotap info is being displayed, 1b)
> > should be zero for the current subframe. Post MPDU pad length
> > information for the prior MPDU would anyway be available (assuming the
> > containing subframe of the prior MPDU is not corrupted).
> 
> So what I wanted here was to be able to reconstruct what happened on the
> air as precisely as possible. I don't think the length of the padding is
> actually needed -- it can be calculated after the fact since it is
> always 0-3 bytes up to a multiple of 4. The number of zero delimiters
> would be more interesting.
> 
> I'm not sure how to deal with the corruption case.
> 
> > Additionally:
> > 2) A bit to indicate if this is the last subframe in the A-MPDU.
> > Though there might be other ways to infer this information, having it
> > as an explicit field would provide convenience. 
> 
> That seems useful, although I'm not even sure how you would even know
> that it is the last one?
> 
> > 3) A bit to indicate if the Delimiter CRC is in error.
> 
> That's useful, but in that case are you even decoding the MPDU and
> passing it up? Also what if a zero delimiter has a bad CRC? Or what if
> it just got corrupted and you have to recover parsing? I'm not sure we
> can cover all these cases.
> 
> > 4) (Debatable) Delimiter CRC value itself. I don't know if there is
> > any hardware which returns the actual value to software. Anyway,
> > having it as part of the field will allow platforms which do possess
> > the capability, to provide this information. It may come in handy for
> > some users.
> 
> That seems a bit of a stretch, but it's only 8 bits so I wouldn't mind
> adding it.

I think that in the interest of, as you say, "reconstruct[ing] what
happened on the air as precisely as possible", which is a goal that I
strongly agree with, it is important to pass that information up.

On the other hand, if the information is only hypothetically
available....

Dave

-- 
David Young
dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org    Urbana, IL    (217) 721-9981

RE: Regarding A-MPDU status field

[Rao, Krishna]

Hi,

>I don't think the length of the padding is
>actually needed -- it can be calculated after the fact since it is
>always 0-3 bytes up to a multiple of 4.
The objective behind suggesting its inclusion was 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). In the absence of an explicitly viewable field, the possibility might not occur to some users.
However, in case the design philosophy behind radiotap is to store only non-deducible information, I agree we should stick to that. May be Wireshark dissector code can independently calculate and display this info instead? (Am yet to get familiar with the code internals, especially with regard to how filtering is impacted by this).

>The number of zero delimiters
>would be more interesting.
I agree. Also (as implicit in your reply) instead of providing the number of bytes, it can simply be the number of delimiters.
But the second part of the discussion below for point 3) 'Delimiter CRC' opens up a new question as to whether we should have this subfield at all.

>I'm not sure how to deal with the corruption case.
See discussion below for point 3) 'Delimiter CRC'

>> 2) A bit to indicate if this is the last subframe in the A-MPDU.
>> Though there might be other ways to infer this information, having it
>> as an explicit field would provide convenience.
>That seems useful, although I'm not even sure how you would even know
>that it is the last one?
It is possible for hardware to detect this and provide this information to the driver (am making a generic technical statement without referring to specific products here). For products not having this capability, this subfield can be marked as invalid (if the driver has no other way to infer the information).

>> 3) A bit to indicate if the Delimiter CRC is in error.
>That's useful, but in that case are you even decoding the MPDU and
>passing it up?
In case the delimiter CRC for a subframe containing an MPDU is corrupted, is it an option to record and display only the radiotap header without the (suspect) MPDU following it? This will at least let the user know a subframe corruption has happened. Except the 'Delimiter CRC error' bit, all other A-MPDU status field contents can be set as invalid.
If this option is not available, may be we should just drop 3 (and by extension, 4 'Delimiter CRC Value') to avoid ambiguity.

>Also what if a zero delimiter has a bad CRC? Or what if
>it just got corrupted and you have to recover parsing? I'm not sure we
>can cover all these cases.
Assuming the option discussed above is available:
Perhaps we should limit the scope of all A-MPDU status field information as being applicable only to subframes actually containing MPDUs. Even 1b, 'Number of zero delimiters before current subframe' would be with reference to a given 'non-zero' MPDU bearing subframe. 
If we accept the above limitation, then a zero delimiter having a bad CRC doesn't matter for subfield 3) 'Delimiter CRC error'. We will never be providing this information for any zero delimiter. However, there is an open question about what happens once hardware recovers parsing after a corrupted zero delimiter and and successfully gets a non-zero MPDU bearing subframe. Generally speaking, I feel there is scope for ambiguity/variances about how differing products can react and return information used for constructing 1b. In case this is a concern, we could drop 1b as well. 

Regards,
Krishna

RE: Regarding A-MPDU status field

[Johannes Berg]

Hi,

> >I don't think the length of the padding is
> >actually needed -- it can be calculated after the fact since it is
> >always 0-3 bytes up to a multiple of 4.

> The objective behind suggesting its inclusion was 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). In the absence of an explicitly viewable field, the
> possibility might not occur to some users.
> However, in case the design philosophy behind radiotap is to store
> only non-deducible information, I agree we should stick to that. May
> be Wireshark dissector code can independently calculate and display
> this info instead? (Am yet to get familiar with the code internals,
> especially with regard to how filtering is impacted by this).

I can't really say if that's the design philosophy (some things make me
think it's not, like the strange channel type field), but it'd certainly
be trivial to show it in wireshark either way so personally I think we
should leave it out.

> >The number of zero delimiters
> >would be more interesting.
> I agree. Also (as implicit in your reply) instead of providing the
> number of bytes, it can simply be the number of delimiters.
> But the second part of the discussion below for point 3) 'Delimiter
> CRC' opens up a new question as to whether we should have this
> subfield at all.

Well, ok, so I don't really care about bytes vs. delimiters, I didn't
put it that way to mean I'd prefer the number of delimiters.

> >> 2) A bit to indicate if this is the last subframe in the A-MPDU.
> >> Though there might be other ways to infer this information, having
> it
> >> as an explicit field would provide convenience.
> >That seems useful, although I'm not even sure how you would even know
> >that it is the last one?
> It is possible for hardware to detect this and provide this
> information to the driver (am making a generic technical statement
> without referring to specific products here). For products not having
> this capability, this subfield can be marked as invalid (if the driver
> has no other way to infer the information).

Ok, that sounds good. Let's just include it then, it's only a bit after
all.

> >> 3) A bit to indicate if the Delimiter CRC is in error.
> >That's useful, but in that case are you even decoding the MPDU and
> >passing it up?
> In case the delimiter CRC for a subframe containing an MPDU is
> corrupted, is it an option to record and display only the radiotap
> header without the (suspect) MPDU following it? This will at least let
> the user know a subframe corruption has happened. Except the
> 'Delimiter CRC error' bit, all other A-MPDU status field contents can
> be set as invalid.
> If this option is not available, may be we should just drop 3 (and by
> extension, 4 'Delimiter CRC Value') to avoid ambiguity.

I think we can do that. Or display it but mark it as bad in some way if
this happens (maybe also set the bad FCS bit if that isn't independently
calculated anyway?)

> >Also what if a zero delimiter has a bad CRC? Or what if
> >it just got corrupted and you have to recover parsing? I'm not sure
> >we can cover all these cases.
> Assuming the option discussed above is available:
> Perhaps we should limit the scope of all A-MPDU status field
> information as being applicable only to subframes actually containing
> MPDUs. Even 1b, 'Number of zero delimiters before current subframe'
> would be with reference to a given 'non-zero' MPDU bearing subframe. 
> If we accept the above limitation, then a zero delimiter having a bad
> CRC doesn't matter for subfield 3) 'Delimiter CRC error'. We will
> never be providing this information for any zero delimiter. However,
> there is an open question about what happens once hardware recovers
> parsing after a corrupted zero delimiter and and successfully gets a
> non-zero MPDU bearing subframe. Generally speaking, I feel there is
> scope for ambiguity/variances about how differing products can react
> and return information used for constructing 1b. In case this is a
> concern, we could drop 1b as well. 

Given that hardware might even implement different strategies for
recovering (iirc the spec only has an informational description of an
algorithm), I think that's fair. It'd be nicer to have perfectly
comparable values, but I wouldn't leave things out just because of that.

Technically we could also report each zero delimiter as a separate
zero-length frame I guess.

johannes

RE: Regarding A-MPDU status field

[Rao, Krishna]

Hi,

I apologize for the delay in responding. Was held up with some other work.

>>>I don't think the length of the padding is
>>>actually needed -- it can be calculated after the fact since it is
>>>always 0-3 bytes up to a multiple of 4.
>
>> The objective behind suggesting its inclusion was to help users easily
>> observe and filter on this value without having to resort to any post
>> processing scripts.
[cut]
>> However, in case the design philosophy behind radiotap is to store
>> only non-deducible information, I agree we should stick to that. May
>> be Wireshark dissector code can independently calculate and display
>> this info instead? (Am yet to get familiar with the code internals,
>> especially with regard to how filtering is impacted by this).
>
>I can't really say if that's the design philosophy (some things make me
>think it's not, like the strange channel type field), but it'd certainly
>be trivial to show it in wireshark either way so personally I think we
>should leave it out.
I agree we can leave it out of the A-MPDU status field itself then.

>>>> 3) A bit to indicate if the Delimiter CRC is in error.
>>>That's useful, but in that case are you even decoding the MPDU and
>>>passing it up?
>> In case the delimiter CRC for a subframe containing an MPDU is
>> corrupted, is it an option to record and display only the radiotap
>> header without the (suspect) MPDU following it? This will at least let
>> the user know a subframe corruption has happened. Except the
>> 'Delimiter CRC error' bit, all other A-MPDU status field contents can
>> be set as invalid.
>> If this option is not available, may be we should just drop 3 (and by
>> extension, 4 'Delimiter CRC Value') to avoid ambiguity.
>
>I think we can do that. Or display it but mark it as bad in some way if
>this happens
Ok. For hardware that does return the suspect MPDU, we can display it - I suggest not as an MPDU, but as a bunch of un-dissected bytes (the reason for this suggestion, along with alternatives, will be discussed shortly). For hardware that doesn't return the suspect MPDU (or is capable, but doesn't under some circumstances), we should have the flexibility to display only the Radiotap header.

>(maybe also set the bad FCS bit if that isn't independently
>calculated anyway?)
Since the Delimiter CRC only covers the Reserved bits and MPDU length field of the subframe (and not the MPDU itself), we wouldn't be sure if the MPDU FCS is really bad on the basis of just the Delimiter CRC being bad. For that matter, we wouldn't even be sure if what we think is the MPDU FCS is actually so (depending on hardware implementations and parse recovery failures). This is the reason I suggested displaying the MPDU as a bunch of un-dissected bytes. 
Alternatively, the wireshark implementation can carry out an attempted heuristic dissection, with Wireshark documentation updated to warn that this can go quite awry.

>>>Also what if a zero delimiter has a bad CRC? Or what if
>>>it just got corrupted and you have to recover parsing? I'm not sure
>>>we can cover all these cases.
>> Assuming the option discussed above is available:
>> Perhaps we should limit the scope of all A-MPDU status field
>> information as being applicable only to subframes actually containing
>> MPDUs. Even 1b, 'Number of zero delimiters before current subframe'
>> would be with reference to a given 'non-zero' MPDU bearing subframe. 
>> If we accept the above limitation, then a zero delimiter having a bad
>> CRC doesn't matter for subfield 3) 'Delimiter CRC error'. We will
>> never be providing this information for any zero delimiter. However,
>> there is an open question about what happens once hardware recovers
>> parsing after a corrupted zero delimiter and and successfully gets a
>> non-zero MPDU bearing subframe. Generally speaking, I feel there is
>> scope for ambiguity/variances about how differing products can react
>> and return information used for constructing 1b. In case this is a
>> concern, we could drop 1b as well. 
>
>Given that hardware might even implement different strategies for
>recovering (iirc the spec only has an informational description of an
>algorithm), I think that's fair. It'd be nicer to have perfectly
>comparable values, but I wouldn't leave things out just because of that.

>Technically we could also report each zero delimiter as a separate
>zero-length frame I guess.
I like this idea. It sounds better than having subfield 1b. We can more uniformly handle bad delimiter CRC events.

Regards,
Krishna 

RE: Regarding A-MPDU status field

[Johannes Berg]

Hi,

> >>>> 3) A bit to indicate if the Delimiter CRC is in error.
> >>>That's useful, but in that case are you even decoding the MPDU and
> >>>passing it up?
> >> In case the delimiter CRC for a subframe containing an MPDU is
> >> corrupted, is it an option to record and display only the radiotap
> >> header without the (suspect) MPDU following it? This will at least let
> >> the user know a subframe corruption has happened. Except the
> >> 'Delimiter CRC error' bit, all other A-MPDU status field contents can
> >> be set as invalid.
> >> If this option is not available, may be we should just drop 3 (and by
> >> extension, 4 'Delimiter CRC Value') to avoid ambiguity.
> >
> >I think we can do that. Or display it but mark it as bad in some way if
> >this happens

> Ok. For hardware that does return the suspect MPDU, we can display it
> - I suggest not as an MPDU, but as a bunch of un-dissected bytes (the
> reason for this suggestion, along with alternatives, will be discussed
> shortly). For hardware that doesn't return the suspect MPDU (or is
> capable, but doesn't under some circumstances), we should have the
> flexibility to display only the Radiotap header.
> 
> >(maybe also set the bad FCS bit if that isn't independently
> >calculated anyway?)
> Since the Delimiter CRC only covers the Reserved bits and MPDU length
> field of the subframe (and not the MPDU itself), we wouldn't be sure
> if the MPDU FCS is really bad on the basis of just the Delimiter CRC
> being bad. For that matter, we wouldn't even be sure if what we think
> is the MPDU FCS is actually so (depending on hardware implementations
> and parse recovery failures). This is the reason I suggested
> displaying the MPDU as a bunch of un-dissected bytes. 

Right, that makes sense.

> Alternatively, the wireshark implementation can carry out an attempted
> heuristic dissection, with Wireshark documentation updated to warn
> that this can go quite awry.

That might be easier to implement, but ultimately it's up to the
wireshark implementation. Could even be configurable :-)

> >>>Also what if a zero delimiter has a bad CRC? Or what if
> >>>it just got corrupted and you have to recover parsing? I'm not sure
> >>>we can cover all these cases.
> >> Assuming the option discussed above is available:
> >> Perhaps we should limit the scope of all A-MPDU status field
> >> information as being applicable only to subframes actually containing
> >> MPDUs. Even 1b, 'Number of zero delimiters before current subframe'
> >> would be with reference to a given 'non-zero' MPDU bearing subframe. 
> >> If we accept the above limitation, then a zero delimiter having a bad
> >> CRC doesn't matter for subfield 3) 'Delimiter CRC error'. We will
> >> never be providing this information for any zero delimiter. However,
> >> there is an open question about what happens once hardware recovers
> >> parsing after a corrupted zero delimiter and and successfully gets a
> >> non-zero MPDU bearing subframe. Generally speaking, I feel there is
> >> scope for ambiguity/variances about how differing products can react
> >> and return information used for constructing 1b. In case this is a
> >> concern, we could drop 1b as well. 
> >
> >Given that hardware might even implement different strategies for
> >recovering (iirc the spec only has an informational description of an
> >algorithm), I think that's fair. It'd be nicer to have perfectly
> >comparable values, but I wouldn't leave things out just because of that.
> 
> >Technically we could also report each zero delimiter as a separate
> >zero-length frame I guess.

> I like this idea. It sounds better than having subfield 1b. We can
> more uniformly handle bad delimiter CRC events.

:)

Did you keep track and want to write up a new proposal?

johannes

RE: Regarding A-MPDU status field

[Rao, Krishna]

Hi,

>>> 4) (Debatable) Delimiter CRC value itself. I don't know if there is
>>> any hardware which returns the actual value to software. Anyway,
>>> having it as part of the field will allow platforms which do possess
>>> the capability, to provide this information. It may come in handy for
>>> some users.
>> 
>> That seems a bit of a stretch, but it's only 8 bits so I wouldn't mind
>> adding it.
>
>I think that in the interest of, as you say, "reconstruct[ing] what
>happened on the air as precisely as possible", which is a goal that I
>strongly agree with, it is important to pass that information up.
>
>On the other hand, if the information is only hypothetically
>available....
Since there is always a possibility that some existing or future hardware might have this capability, having this subfield in the specification might prove useful down the line. Inviting comments on this.

Regards,
Krishna

Re: Regarding A-MPDU status field

[David Young]

On Tue, Nov 22, 2011 at 02:27:17PM +0000, Rao, Krishna wrote:
> Hi,
> 
> >>> 4) (Debatable) Delimiter CRC value itself. I don't know if there is
> >>> any hardware which returns the actual value to software. Anyway,
> >>> having it as part of the field will allow platforms which do possess
> >>> the capability, to provide this information. It may come in handy for
> >>> some users.
> >> 
> >> That seems a bit of a stretch, but it's only 8 bits so I wouldn't mind
> >> adding it.
> >
> >I think that in the interest of, as you say, "reconstruct[ing] what
> >happened on the air as precisely as possible", which is a goal that I
> >strongly agree with, it is important to pass that information up.
> >
> >On the other hand, if the information is only hypothetically
> >available....
> Since there is always a possibility that some existing or future
> hardware might have this capability, having this subfield in the
> specification might prove useful down the line. Inviting comments on
> this.

Still thinking along the lines of "reconstruct ... as precisely", let me
throw this idea out there: the A-MPDU field can help us to reconstruct a
whole A-MPDU by telling us the range of byte indices where the subframe
may have begun in the aggregate, [start0, start1].  If the driver
doesn't know, then the interval is [0, length of A-MPDU].  If the driver
knows precisely, then [x, x], otherwise [x, y] where x != y.

Dave

-- 
David Young
dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org    Urbana, IL    (217) 721-9981

RE: Regarding A-MPDU status field

[Rao, Krishna]

Hi,

>Did you keep track and want to write up a new proposal?
Sure. I’ll send in a revised proposal. However, I realized that 4 ‘Delimiter CRC value itself’ is still an open item. I just sent out a separate email to David and the rest of the group to discuss this.

Regards,
Krishna

RE: Regarding A-MPDU status field

[Rao, Krishna]

Hi,

>>>>> 4) (Debatable) Delimiter CRC value itself. I don't know if there is
>>>>> any hardware which returns the actual value to software. Anyway,
>>>>> having it as part of the field will allow platforms which do possess
>>>>> the capability, to provide this information. It may come in handy for
>>>>> some users.
>>>> 
>>>> That seems a bit of a stretch, but it's only 8 bits so I wouldn't mind
>>>> adding it.
>>>
>>>I think that in the interest of, as you say, "reconstruct[ing] what
>>>happened on the air as precisely as possible", which is a goal that I
>>>strongly agree with, it is important to pass that information up.
>>>
>>>On the other hand, if the information is only hypothetically
>>>available....
>> Since there is always a possibility that some existing or future
>> hardware might have this capability, having this subfield in the
>> specification might prove useful down the line. Inviting comments on
>> this.
>
>Still thinking along the lines of "reconstruct ... as precisely", let me
>throw this idea out there: the A-MPDU field can help us to reconstruct a
>whole A-MPDU by telling us the range of byte indices where the subframe
>may have begun in the aggregate, [start0, start1].
I feel the originally suggested subfield, 'zero-based index of this MPDU within the a-MPDU', in combination with the (shortened list of) new subfields being discussed should help achieve the equivalent. The Wireshark implementation should be able to estimate these indices based on information returned in the individual A-MPDU fields for 'non-zero' and 'zero' subframes.

>If the driver
>doesn't know, then the interval is [0, length of A-MPDU].  If the driver
>knows precisely, then [x, x], otherwise [x, y] where x != y.
Along the same line of trying to reconstruct things as precisely as possible, we should be able to reconstruct what went wrong:
If the driver doesn't know (info towards) the indices precisely, then the reason would mostly be corruption of Delimiter CRC protecting MPDU length info in subframe. I feel the Radiotap standard should afford the driver the opportunity to convey what went wrong on the air, depending on hardware capabilities (Delimiter CRC is bad, what the bad CRC value itself is, and any suspect bytes found by hardware where the MPDU should have been).

Regards,
Krishna

RE: Regarding A-MPDU status field

[Rao, Krishna]

Hi,

> Did you keep track and want to write up a new proposal?

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.

Guiding principle: We attempt to arrive at a field definition which allows drivers/hardware capable of providing advanced information to do so, in the interest of being able to reconstruct whatever happened on the air as precisely as possible. This advanced information covers both success and failure conditions. This could aid in enhanced analysis. Driver/hardware combinations with lesser capability may skip some of the sub-fields - Wireshark will work with whatever is available and provide correspondingly reduced information. 

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.
2) (New) A bit to indicate if the driver is capable of returning information about individual zero MPDU length subframes.
3) (New) A bit to indicate if the current subframe is a zero MPDU length subframe. Valid if bit ‘2’ above is set.
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.
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.
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.

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

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?)
If bit 2 is 0, then Wireshark should set the padding value to invalid.

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.

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

Regards,
Krishna

RE: Regarding A-MPDU status field

[Johannes Berg]

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

RE: Regarding A-MPDU status field

[Rao, Krishna]

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

RE: Regarding A-MPDU status field

[Johannes Berg]

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

RE: Regarding A-MPDU status field

[Rao, Krishna]

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.
I agree. In any case, we need the extra bytes for 'future-proofing'.

>> 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?
You summarized correctly below about the calculations in the illustration I presented. 

>> 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?
Thanks for summarizing the field definitions. 

> A-MPDU radiotap field
>-----------------------
>bit index: TBD
>alignment: 4 bytes (u32)
>
> * ampdu reference number (u32)
We need to add a note about the reference number being different for every channel.

> * 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?
The subframe index would always be valid. It would provide the position of the current subframe, in within the A-MPDU (irrespective of whether the subframe is zero or non-zero MPDU length). The index value itself is zero-based (i.e., it starts from 0 and increments onwards).

a) If 0x01 is set, then the index for the current subframe takes into account previous zero MPDU length subframes (because these previous zero subframes have been reported individually and the index incremented for each of them).
b) If 0x01 is clear, then the index for the current subframe does not account for previous zero MPDU length subframes that might have been transmitted over the air.

Thus if two different drivers are observing the same traffic:
The driver that sets 0x01 will report a larger index value for a given non-zero subframe, than the driver that clears 0x01 (if zero padding occurs before that subframe). 

If 0x01 is set, then the sniffer app can calculate zero padding by processing index information and MPDU length field values across subframes.

Everything else looks good.

Regds,
Krishna.

RE: Regarding A-MPDU status field

[Johannes Berg]

Hi,

> > A-MPDU radiotap field
> >-----------------------
> >bit index: TBD
> >alignment: 4 bytes (u32)
> >
> > * ampdu reference number (u32)

> We need to add a note about the reference number being different for every channel.

Right, sorry, missed that.

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

> The subframe index would always be valid. 

Ok, I misunderstood this then.

> It would provide the position of the current subframe, in within the
> A-MPDU (irrespective of whether the subframe is zero or non-zero MPDU
> length). The index value itself is zero-based (i.e., it starts from 0
> and increments onwards).
> 
> a) If 0x01 is set, then the index for the current subframe takes into
> account previous zero MPDU length subframes (because these previous
> zero subframes have been reported individually and the index
> incremented for each of them).
> b) If 0x01 is clear, then the index for the current subframe does not
> account for previous zero MPDU length subframes that might have been
> transmitted over the air.
> 
> Thus if two different drivers are observing the same traffic:
> The driver that sets 0x01 will report a larger index value for a given
> non-zero subframe, than the driver that clears 0x01 (if zero padding
> occurs before that subframe). 
> 
> If 0x01 is set, then the sniffer app can calculate zero padding by
> processing index information and MPDU length field values across
> subframes.


Ok, but I think that then we still need to resolve a small ambiguity
here. Imagine this:

   [mpdu][pad][pad][mpdu][pad][mpdu]
a) 0     1    2    3     4    5
b) 0               1          2

Right?

But now imagine a device misses a frame due to decode problem or so ...
then which one would you want:
1) subframe index skips that one
2) subframe index just increases

Say
   [mpdu][pad][pad][----][pad][mpdu]
1) 0     1    2    (3)   4    5
2) 0     1    2          3    4

but then the driver would have to guess at the padding? Not sure. In any
case, we need to nail this down, because in the case 2) the driver can
number the subframes (but it's less useful), and in the case 1) the
device has to provide it (and not all do -- so we need a separate valid
bit). In the case 1), even the application (wireshark) could provide the
subframe index?

johannes

RE: Regarding A-MPDU status field

[Rao, Krishna]

Hi,

>> It would provide the position of the current subframe, in within the 
>> A-MPDU (irrespective of whether the subframe is zero or non-zero MPDU 
>> length). The index value itself is zero-based (i.e., it starts from 0 
>> and increments onwards).
>> 
>> a) If 0x01 is set, then the index for the current subframe takes into 
>> account previous zero MPDU length subframes (because these previous 
>> zero subframes have been reported individually and the index 
>> incremented for each of them).
>> b) If 0x01 is clear, then the index for the current subframe does not 
>> account for previous zero MPDU length subframes that might have been 
>> transmitted over the air.
>> 
>> Thus if two different drivers are observing the same traffic:
>> The driver that sets 0x01 will report a larger index value for a given 
>> non-zero subframe, than the driver that clears 0x01 (if zero padding 
>> occurs before that subframe).
>> 
>> If 0x01 is set, then the sniffer app can calculate zero padding by 
>> processing index information and MPDU length field values across 
>> subframes.
>Ok, but I think that then we still need to resolve a small ambiguity here. Imagine this:
>
>   [mpdu][pad][pad][mpdu][pad][mpdu]
>a) 0     1    2    3     4    5
>b) 0               1          2
>
>Right?
Correct.

>
>But now imagine a device misses a frame due to decode problem or so ...
>then which one would you want:
>1) subframe index skips that one
>2) subframe index just increases
>
>Say
>   [mpdu][pad][pad][----][pad][mpdu]
>1) 0     1    2    (3)   4    5
>2) 0     1    2          3    4
>
>but then the driver would have to guess at the padding? Not sure. In any case, we need to nail
>this down, because in the case 2) the driver can number the subframes (but it's less useful),
>and in the case 1) the device has to provide it (and not all do -- so we need a separate valid bit).
>In the case 1), even the application (wireshark) could provide the subframe index?

Good you brought this up.

I had basically case 2) in mind. Even the device itself may not always be able to provide the index for subframes totally skipped due to decode problems. It may sometimes be able to pass to the driver subframes with bad delimiter CRC and these would get indexed by the driver (with flag 0x10 set). So the principle is that only whatever subframes the device can pass to the driver, good or bad, get indexed.

But I now feel the application itself can provide the subframe indexing (as in case 2). It can use the subframe reference number and timestamp for this. The burden on the driver would be decreased, and we also save space in the Radiotap header by removing this field.

Regds,
Krishna

RE: Regarding A-MPDU status field

[Johannes Berg]

Hi,

Sorry for the delay in reviewing this.

> >But now imagine a device misses a frame due to decode problem or so ...
> >then which one would you want:
> >1) subframe index skips that one
> >2) subframe index just increases
> >
> >Say
> >   [mpdu][pad][pad][----][pad][mpdu]
> >1) 0     1    2    (3)   4    5
> >2) 0     1    2          3    4
> >
> >but then the driver would have to guess at the padding? Not sure. In any case, we need to nail
> >this down, because in the case 2) the driver can number the subframes (but it's less useful),
> >and in the case 1) the device has to provide it (and not all do -- so we need a separate valid bit).
> >In the case 1), even the application (wireshark) could provide the subframe index?
> 
> Good you brought this up.
> 
> I had basically case 2) in mind. Even the device itself may not always
> be able to provide the index for subframes totally skipped due to
> decode problems. 

Yes, good point.

> It may sometimes be able to pass to the driver subframes with bad
> delimiter CRC and these would get indexed by the driver (with flag
> 0x10 set). So the principle is that only whatever subframes the device
> can pass to the driver, good or bad, get indexed.
> 
> But I now feel the application itself can provide the subframe
> indexing (as in case 2). It can use the subframe reference number and
> timestamp for this. The burden on the driver would be decreased, and
> we also save space in the Radiotap header by removing this field.

Makes sense to me. I guess that means we just remove the ampdu subframe
index from the proposal, so we have this?


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

 * ampdu reference number (u32)
 * flags (u16)
   - 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)
 * u8 (reserved)


(I added the reserved field and changed the flags to u16, it seems
relatively likely that other fields will need u32 alignment so it seems
reasonable to reserve a byte here, maybe for VHT extensions?)

johannes

RE: Regarding A-MPDU status field

[Rao, Krishna]

Hi,

>Makes sense to me. I guess that means we just remove the ampdu subframe index from the proposal, so we have this?
The below looks good. You can also add an implementation note that the sniffer application should order the subframes using the A-MPDU reference number and timestamp.

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

>* ampdu reference number (u32)
I assume you will be adding the note about the reference number being different for every channel...

>* flags (u16)
>  - 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)
> * u8 (reserved)

>(I added the reserved field and changed the flags to u16, it seems relatively likely that other fields will need u32 alignment so it seems reasonable to reserve a byte here, maybe for VHT extensions?)
Makes sense.

Regds,
Krishna

RE: Regarding A-MPDU status field

[Johannes Berg]

Hi all,

I've updated the wiki page for this, please see there:

http://radiotap.org/suggested-fields/A-MPDU%20status 

Is everybody happy with the format etc.? Then we can start working on
some patches.

johannes

Re: Regarding A-MPDU status field

[Johannes Berg]

Anyone have a wireshark patch for this
(http://www.radiotap.org/suggested-fields/A-MPDU%20status) yet? I'm
working on Linux kernel support right now.

johannes