Re: Regarding A-MPDU status field

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
[email protected]    Urbana, IL    (217) 721-9981