RadioTap Archive on lore.kernel.org
 help / color / Atom feed
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org
Subject: Re: HE (11ax) extensions
Date: Tue, 27 Jun 2017 15:41:58 +0200
Message-ID: <1498570918.13489.1.camel@sipsolutions.net> (raw)
In-Reply-To: <1488266885.2388.0.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>

On Tue, 2017-02-28 at 08:28 +0100, Johannes Berg wrote:
> On Wed, 2017-02-22 at 12:54 +0100, Johannes Berg wrote:
> > > 
> > 
> > Anyway, that proposal missed a number of things and didn't really
> > make any sense, here's a new one:
> > 
> > http://www.radiotap.org/fields/HE
> > http://www.radiotap.org/fields/HE-MU-common
> > http://www.radiotap.org/fields/HE-MU-user
> 
> FWIW, I've not pursued this further for now since the spec is still a
> moving target. I'm told HE-SIG-B is fairly stable, but HE-SIG-A is
> still a heavily contended topic (at least some parts of it)

In the meantime, I've come to the conclusion that it's a stupid idea to
encode the data like in HE-SIG-A, for multiple reasons:

1) the encoding heavily depends on the PPDU type (SU, ER SU, MU, TB),
and there's practically nothing common between them - this means
decoding has lots of special cases

2) the encoding is really really tight on bits, doing tricks like
DCM=STBC=1 to indicate a 5th possibility for the 2-bit LTF+GI field,
this also makes it awkward to decode again in tools like wireshark

3) TB PPDUs don't even contain the necessary rate data, it's given by
the trigger frame, so one would have to correlate that during encoding.
For pure sniffer mode, that may be necessary, but for some "monitor
while operating" modes, the real rate etc. would be available

(and there are probably more reasons)

I'm going on sabbatical soon, but I'll revisit this in September or
later to come up with a better proposal.

johannes

  parent reply index

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-13 13:23 Johannes Berg
     [not found] ` <1486992211.19813.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-02-13 19:33   ` Simon Barber
     [not found]     ` <D96F5F50-5B44-487C-8FF8-36A793960B7D-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
2017-02-13 19:39       ` Johannes Berg
     [not found]         ` <1487014748.19813.5.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-02-13 19:42           ` Simon Barber
     [not found]             ` <0FB8C34C-910C-404F-97BA-18BB7F8949C4-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
2017-02-13 19:49               ` Johannes Berg
     [not found]                 ` <1487015370.19813.7.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-02-13 20:08                   ` Simon Barber
     [not found]                     ` <4443A151-EFD0-44A4-A892-C40218EE0291-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
2017-02-13 20:14                       ` Johannes Berg
2017-02-15  8:58               ` Johannes Berg
2017-02-15  9:08               ` Guy Harris
2017-02-13 19:40       ` Johannes Berg
2017-02-15  9:05       ` Johannes Berg
2017-02-15 12:48   ` Johannes Berg
     [not found]     ` <1487162908.31885.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-02-22 11:54       ` Johannes Berg
     [not found]         ` <1487764486.2215.5.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-02-28  7:28           ` Johannes Berg
     [not found]             ` <1488266885.2388.0.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-06-27 13:41               ` Johannes Berg [this message]
2017-09-08  8:35   ` Johannes Berg
     [not found]     ` <1504859711.6177.12.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-10-25 11:54       ` Johannes Berg
     [not found]         ` <1508932475.2421.34.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-10-25 12:17           ` Arend Van Spriel
     [not found]             ` <CAF7Mx6qFmbyDex8VOV9sxbMXofQVk9dpzBQNK0S57GCTfbw_PA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-10-25 12:18               ` Johannes Berg

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1498570918.13489.1.camel@sipsolutions.net \
    --to=johannes-cdvu00un1vgdhxzaddlk8q@public.gmane.org \
    --cc=radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

RadioTap Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/radiotap/0 radiotap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 radiotap radiotap/ https://lore.kernel.org/radiotap \
		radiotap@radiotap.org
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.netbsd.radiotap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git