Discussion:
emulating non-duplex media in linux qdiscs
(too old to reply)
Dave Taht
2017-10-09 01:54:12 UTC
Permalink
Raw Message
I have been hacking away at netem for a while now in the hope that
eventually - with a great deal more hacking - it could be used to more
accurately emulate shared media like wifi and lte.

(Some people try to describe these as simplex (which is not true
because you can have multiple destinations), and they certainly are
not duplex, so I tend to say non-duplex and still hope some better
word emerges)

So... one sticking point for me has been wanting to emulate the fact
that on shared media, that you cannot transmit and receive at the same
time; that these are "coupled" events, and what I'd like to be able to
express might be something like:

tc qdisc add dev eth0 root netem rate 100mbit coupled some_identifier
... some tc mirred magic for ifb here ...
tc qdisc add dev ifb0 root netem rate 10mbit coupled the_same_identifier

"some_identifier" would be a mutex of some sort, and I confess to
not having much grip on the kernel outside of the net/sched directory.

What facility would be best to try and leverage? It would be created
(globally) on first use, ref-counted (thus destroyed when it goes to
zero), atomically updated... posix shared memory seems too heavyweight
to use....

--

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
e***@telenor.com
2017-10-09 07:41:52 UTC
Permalink
Raw Message
Half duplex is the term you are looking for
https://en.wikipedia.org/wiki/Duplex_(telecommunications)

Simplex is one way communication like traditional AM radio.

Within emulation I'm not sure how to set this up with qdiscs, but you can often set the network interface to half duplex with ethtool. Not sure if this solves your task though.

-Erik

________________________________________
Fra: Bloat <bloat-***@lists.bufferbloat.net> på vegne av Dave Taht <***@gmail.com>
Sendt: 9. oktober 2017 03:54
Til: bloat
Emne: [Bloat] emulating non-duplex media in linux qdiscs

I have been hacking away at netem for a while now in the hope that
eventually - with a great deal more hacking - it could be used to more
accurately emulate shared media like wifi and lte.

(Some people try to describe these as simplex (which is not true
because you can have multiple destinations), and they certainly are
not duplex, so I tend to say non-duplex and still hope some better
word emerges)

So... one sticking point for me has been wanting to emulate the fact
that on shared media, that you cannot transmit and receive at the same
time; that these are "coupled" events, and what I'd like to be able to
express might be something like:

tc qdisc add dev eth0 root netem rate 100mbit coupled some_identifier
... some tc mirred magic for ifb here ...
tc qdisc add dev ifb0 root netem rate 10mbit coupled the_same_identifier

"some_identifier" would be a mutex of some sort, and I confess to
not having much grip on the kernel outside of the net/sched directory.

What facility would be best to try and leverage? It would be created
(globally) on first use, ref-counted (thus destroyed when it goes to
zero), atomically updated... posix shared memory seems too heavyweight
to use....

--

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
_______________________________________________
Bloat mailing list
***@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
Dave Taht
2017-10-09 16:53:12 UTC
Permalink
Raw Message
<***@telenor.com> writes:

> Half duplex is the term you are looking for
> https://en.wikipedia.org/wiki/Duplex_(telecommunications)

"A duplex communication system is a point-to-point system composed
of two connected parties or devices that can communicate with one
another in both directions."

wifi is not p2p, all data is broadcast to many potential recievers,
only one can transmit at one time.

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.

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

>
> Simplex is one way communication like traditional AM radio.

wifi/lte are not very similar similar to AM radio.

>
> Within emulation I'm not sure how to set this up with qdiscs, but you can often set the network interface to half duplex with ethtool. Not sure if this solves your task though.

Nope.
Andrew Shewmaker
2017-10-09 19:05:03 UTC
Permalink
Raw Message
On Mon, Oct 9, 2017 at 10:53 AM, Dave Taht <***@taht.net> wrote:
>
> <***@telenor.com> writes:
>
> > Half duplex is the term you are looking for
> > https://en.wikipedia.org/wiki/Duplex_(telecommunications)
>
> "A duplex communication system is a point-to-point system composed
> of two connected parties or devices that can communicate with one
> another in both directions."
>
> wifi is not p2p, all data is broadcast to many potential recievers,
> only one can transmit at one time.
>
> 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.
>
> 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".

Isn't wi-fi adequately described as a combination of frequency and time
domain multiplexing? In my mind, "multiplex" would be better than "
non-duplex", since using the latter could reasonably be interpreted as
"anything not duplex".




--
Andrew Shewmaker
Mikael Abrahamsson
2017-10-10 07:02:41 UTC
Permalink
Raw Message
On Mon, 9 Oct 2017, Dave Taht wrote:

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

A 10base-T hub connected to a 10base-2 or 10base-5 segment, all in the
same broadcast domain, is considered to be "half duplex" in ethernet port
configuration term.

So it doesn't have to be p2p. And I do think this mimics a shared radio as
well (because a coax wire with multiple nodes on it seems very similar to
a radio channel over the air).

Now, radio has the difference that two stations might not hear each other,
and that's of course a problem in CSMA/CD terms.

Back to your netem problem. What you need is to force all packets through
the same queue, right? So I tried to dream up a complicated scheme with 4
bridges and some kind of "forced forwarding", but I don't think it'd pan
out.

So the best way is probably to have a shaper that feeds
transmit-tokens/does scheduling into two different shapers (rx/tx on the
same interface). So whatever scheduling they are fed in order to tell them
the rate they're allowed to transmit, they get it from the same source.
That way they have to compete for the same resources.

This will not perfectly mimic the exponential backoff of CSMA/CD, but it
might be good enough for what you need? Also, I just realised I have no
idea how wifi is scheduled. Is it even close to CSMA/CD?

--
Mikael Abrahamsson email: ***@swm.pp.se
e***@telenor.com
2017-10-10 08:38:49 UTC
Permalink
Raw Message
> 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
Michael Richardson
2017-10-10 13:21:19 UTC
Permalink
Raw Message
<***@telenor.com> wrote:
>> 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.

The ethernet interface on the device is half-duplex, because it can only do tx
or rx to/from the coax cable. There is in essence a half-duplex connection
there. (And with thickernet, there was actually a p2p AUI cable...)

But, the coax cable is *not* half-duplex, because it has more than two
senders to multiplex, so it can't be "half" duplex.
And it's the coax that we actually want to similate, not the AUI cable.

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

semi-multiplex

--
Michael Richardson <mcr+***@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
Y
2017-10-09 13:09:55 UTC
Permalink
Raw Message
Interesting :)

On 2017年10月09日 10:54, Dave Taht wrote:
> I have been hacking away at netem for a while now in the hope that
> eventually - with a great deal more hacking - it could be used to more
> accurately emulate shared media like wifi and lte.
>
> (Some people try to describe these as simplex (which is not true
> because you can have multiple destinations), and they certainly are
> not duplex, so I tend to say non-duplex and still hope some better
> word emerges)
>
> So... one sticking point for me has been wanting to emulate the fact
> that on shared media, that you cannot transmit and receive at the same
> time; that these are "coupled" events, and what I'd like to be able to
> express might be something like:
>
> tc qdisc add dev eth0 root netem rate 100mbit coupled some_identifier
> ... some tc mirred magic for ifb here ...
> tc qdisc add dev ifb0 root netem rate 10mbit coupled the_same_identifier
>
> "some_identifier" would be a mutex of some sort, and I confess to
> not having much grip on the kernel outside of the net/sched directory.
>
> What facility would be best to try and leverage? It would be created
> (globally) on first use, ref-counted (thus destroyed when it goes to
> zero), atomically updated... posix shared memory seems too heavyweight
> to use....
>
Stephen Hemminger
2017-10-09 20:21:51 UTC
Permalink
Raw Message
On Sun, Oct 8, 2017 at 6:54 PM, Dave Taht <***@gmail.com> wrote:

> I have been hacking away at netem for a while now in the hope that
> eventually - with a great deal more hacking - it could be used to more
> accurately emulate shared media like wifi and lte.
>
> (Some people try to describe these as simplex (which is not true
> because you can have multiple destinations), and they certainly are
> not duplex, so I tend to say non-duplex and still hope some better
> word emerges)
>
> So... one sticking point for me has been wanting to emulate the fact
> that on shared media, that you cannot transmit and receive at the same
> time; that these are "coupled" events, and what I'd like to be able to
> express might be something like:
>
> tc qdisc add dev eth0 root netem rate 100mbit coupled some_identifier
> ... some tc mirred magic for ifb here ...
> tc qdisc add dev ifb0 root netem rate 10mbit coupled the_same_identifier
>
> "some_identifier" would be a mutex of some sort, and I confess to
> not having much grip on the kernel outside of the net/sched directory.
>
> What facility would be best to try and leverage? It would be created
> (globally) on first use, ref-counted (thus destroyed when it goes to
> zero), atomically updated... posix shared memory seems too heavyweight
> to use....
>
> --
>
> Dave TÀht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619
> _______________________________________________
> Bloat mailing list
> ***@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat


Since qdisc only see output packets, maybe a overlay device (like a tunnel
or vlan),
would be closer to what you want.
Michael Richardson
2017-10-09 21:04:38 UTC
Permalink
Raw Message
Dave Taht <***@gmail.com> wrote:
> (Some people try to describe these as simplex (which is not true
> because you can have multiple destinations), and they certainly are
> not duplex, so I tend to say non-duplex and still hope some better
> word emerges)

semi-multiplex?

> So... one sticking point for me has been wanting to emulate the fact
> that on shared media, that you cannot transmit and receive at the same
> time; that these are "coupled" events, and what I'd like to be able to
> express might be something like:

> tc qdisc add dev eth0 root netem rate 100mbit coupled some_identifier
> ... some tc mirred magic for ifb here ...
> tc qdisc add dev ifb0 root netem rate 10mbit coupled the_same_identifier

> "some_identifier" would be a mutex of some sort, and I confess to
> not having much grip on the kernel outside of the net/sched directory.

> What facility would be best to try and leverage? It would be created
> (globally) on first use, ref-counted (thus destroyed when it goes to
> zero), atomically updated... posix shared memory seems too heavyweight
> to use....

I suspect (being equally ignorant of kernel stuff in the last decade) that
anytime you create a mutex that needs to be consistent across CPUs, that you
have to put it on a seperate page so that it can be flushed appropriately, so
I suspect that the overhead is already there.

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
Luca Muscariello
2017-10-10 09:25:20 UTC
Permalink
Raw Message
Dave,

If the objective is to run experiments with some emulated wifi I could
suggest
a workaround that we are using. It is not based on qdisc only.

It is based on ns3 emulation and linux bridges.

https://git.fd.io/cicn/tree/emu-radio/README.md?h=vicn/master

The radio emulation piece includes 802.11n and LTE.
For wifi you get the contention behaviour you're looking for and listen
before talk etc.
You also get the TX or RX behaviour. There is also the propagation models
from ns3 (fast/slow fading, etc. etc.).

The radio piece is a single Linux process so depending on the scaling
you're looking for this tool
might or might not be useful.

In the repo, there is some documentation, but if you plan to use this stuff
and need help let me know.
There is also a ML, in case it helps.

Luca




On Mon, Oct 9, 2017 at 3:54 AM, Dave Taht <***@gmail.com> wrote:

> I have been hacking away at netem for a while now in the hope that
> eventually - with a great deal more hacking - it could be used to more
> accurately emulate shared media like wifi and lte.
>
> (Some people try to describe these as simplex (which is not true
> because you can have multiple destinations), and they certainly are
> not duplex, so I tend to say non-duplex and still hope some better
> word emerges)
>
> So... one sticking point for me has been wanting to emulate the fact
> that on shared media, that you cannot transmit and receive at the same
> time; that these are "coupled" events, and what I'd like to be able to
> express might be something like:
>
> tc qdisc add dev eth0 root netem rate 100mbit coupled some_identifier
> ... some tc mirred magic for ifb here ...
> tc qdisc add dev ifb0 root netem rate 10mbit coupled the_same_identifier
>
> "some_identifier" would be a mutex of some sort, and I confess to
> not having much grip on the kernel outside of the net/sched directory.
>
> What facility would be best to try and leverage? It would be created
> (globally) on first use, ref-counted (thus destroyed when it goes to
> zero), atomically updated... posix shared memory seems too heavyweight
> to use....
>
> --
>
> Dave TÀht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619
> _______________________________________________
> Bloat mailing list
> ***@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
Loading...