Topology for consistent datarate per node

60 views
Skip to first unread message

lind...@gmail.com

unread,
Apr 13, 2018, 9:06:15 AM4/13/18
to ns-3-users

I am trying to connect docker containers via taps to NS-3 nodes, and give a guaranteed available data rate for each machine. But after many hours of trying to figure out the correct topology, I give up. It seems like such a basic functionality, that I'm thinking I'm missing something.

Example of my goal:
I would like to create a setup where NS-3 acts as if it was a switch with a Gigabit/s backplane and ten 100 Megabit/s ports available. In such a scenario, any host connected over the switch would be guaranteed 100 Mbps of bandwidth, independently of how much the other nodes uses.

Problem:
The topology I have had some hope for is the tap-bridge tap-csma-virtual-machine.cc.
The basic topology of tap-csma-virtual-machine seems really close to what I want. It populates a set of nodes with tapBridge devices, and connects those devices in turn to a csma channel. And in principle, the csma channel do deliver the data rate I set it to (for example 100M). But it's shared between nodes, so if I have 2 nodes sending at the same time, they don't get 100M each. And it's worse than if it was just cut in half – it's unevenly distributed, which is a deal breaker for my use case. And it is of course even worse if I add more nodes.

I've also tried a modified version of the openflow-switch, trying to add nodes with tap-bridges to it. But that got me really awful performance, something like 3 Mbps at most.

Surely there must be some easy way to connect ten machines over a NS-3 network with a guarantee on the available data rate?

pdbarnes

unread,
Apr 14, 2018, 1:15:10 AM4/14/18
to ns-3-users
What about connecting each container to a single node, by PointToPoint links for example. That would represent a single switch with extremely high backplane bandwidth.

Note that you may still not achieve 100 Mbps for each container: if several containers all send to one, that link will become the bottleneck.

Peter

lind...@gmail.com

unread,
Apr 16, 2018, 4:32:45 AM4/16/18
to ns-3-users
Are you sure that should work? Have you tried it? I read elsewhere that PointToPoint devices do not support bridging (I.E. are not compatible with TapBridges)...

pdbarnes

unread,
Apr 16, 2018, 1:17:07 PM4/16/18
to ns-3-users
Just do a star:  P2P between the "switch" and leaves, and TapBridge from each leaf to a container.
Peter

lind...@gmail.com

unread,
Apr 17, 2018, 4:42:49 AM4/17/18
to ns-3-users
Do you have an example? I can not get it to work. I have tried installing PointToPointDevices on the nodes much like in the first.cc tutorial example, but then I have no idea how to install the tap bridges on the nodes. In tap-csma-virtual-machine they use tapBridge.Install (nodes.Get (i), devices.Get (i)) in a loop for each node i. But that only works because devices is a csma NetDeviceContainer. I can not get it to work with PointToPoint...

pdbarnes

unread,
Apr 18, 2018, 9:21:08 AM4/18/18
to ns-3-users
I’m suggesting you do this:

Container Container
| |
CSMA CSMA
| |
leaf node leaf node
| |
—— P2P —— switch —— P2P ——

The containers will be attached via tap bridge to CSMA devices, which will forward to P2P (these could also be CSMA if you want). Strictly speaking the leaf nodes are acting as gateways.

Peter
Reply all
Reply to author
Forward
0 new messages