From: <erik.taraldsen@telenor.com>
To: <dave@taht.net>
Cc: <dave.taht@gmail.com>, <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] emulating non-duplex media in linux qdiscs
Date: Tue, 10 Oct 2017 08:38:49 +0000 [thread overview]
Message-ID: <1507624730253.7735@telenor.com> (raw)
In-Reply-To: <87376s6z5z.fsf@nemesis.taht.net>
> wifi is not p2p, all data is broadcast to many potential recievers,
> only one can transmit at one time.
On the radio level that is true for the time being. That may change with 802.11ax, as MU-MIMO is set up to get an multiple sender version. OFDMA I believe.
> Saying that is half duplex, doesn't work for me. In their example of
> "half duplex", (using push to talk), it still means that everybody on
> that channel hears who is talking. "half duplex" to me, given the
> definition of duplex, means more that there is a *p2p* channel (a wire),
> that you can ping pong data across.
Well, as Mikael stated as well, half duplex has been used on shared medium in the ethernet world since it's inception. As you state it does not match 100% with the wikipedia definition, but the tradition is there.
> This conflation of ideas has always bugged me and I've longed to find
> another word that more accurately describes what happens, therefore
> I've been saying "non-duplex".
Given your distaste for the term half duplex, and the coming advances in .11ax which further confuses the issue, there may be a real need for a better term. How about starting with a description of the transmission properties and making a set of terms? Shared medium, single sender, multiple recivers. (current mu-mimo wifi). Shared medium multiple sender, multiple receivers. (OFDMA 802.11ax if they get it working). Shared medium entails coordinated action. Sender/receiver description also encapsulates that there is different behavior in the different direction in the air.
> > Simplex is one way communication like traditional AM radio.
>
> wifi/lte are not very similar similar to AM radio.
Which was my point. :) Simplex seems to be a non applicable term here.
-Erik
next prev parent reply other threads:[~2017-10-10 8:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-09 1:54 Dave Taht
2017-10-09 7:41 ` erik.taraldsen
2017-10-09 16:53 ` Dave Taht
2017-10-09 19:05 ` Andrew Shewmaker
2017-10-10 7:02 ` Mikael Abrahamsson
2017-10-10 8:38 ` erik.taraldsen [this message]
2017-10-10 13:21 ` Michael Richardson
2017-10-09 13:09 ` Y
2017-10-09 20:21 ` Stephen Hemminger
2017-10-09 21:04 ` Michael Richardson
2017-10-10 9:25 ` Luca Muscariello
Reply instructions:
You may reply publicly 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
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1507624730253.7735@telenor.com \
--to=erik.taraldsen@telenor.com \
--cc=bloat@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=dave@taht.net \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox