Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integration with traffic control #23

Open
je-clark opened this issue Sep 14, 2021 · 2 comments
Open

Integration with traffic control #23

je-clark opened this issue Sep 14, 2021 · 2 comments
Labels
enhancement New feature or request

Comments

@je-clark
Copy link

What a cool project!

The immediate use case I see for this is quick virtual network labs for education and application testing (e.g. how does the pcap differ when it's network delay vs server delay), so integration with tc would be fantastic to introduce delay and loss into the network path.

I would be happy to help build that, but don't have any time immediately available. So I thought I would at least log an enhancement request.

@garywill garywill added the enhancement New feature or request label Sep 16, 2021
@garywill
Copy link
Owner

Hi there ! thank you for feedback!

I did a little google about tc. It is new to me. There're several terms that I haven't fully understand yet.
Anyway, I believe users would be glad to see a feature to limit clients' net speed.

introduce delay and loss into the network path

I think delay means net speed limiting. That's a feature wanted by many users. Looking forward to that !

Loss is a feature only for like labs, I think. Is it necessary for this script to integrate loss? I think it would be better to keep the loss feature in a seperated script.

Open for discussion, still.

@je-clark
Copy link
Author

tc really has 4 main features:

  1. Introduce delay - This causes the router to hold on to the packet for a set amount of time before forwarding it, artificially increasing the round trip time and allowing you to test high latency connections.
  2. Introduce packet loss - The router will randomly drop packets by whatever probability you set. Likewise, it helps test protocol/application recovery on a bad network link.
  3. Restrict overall speed - Just like an ISP will sell a 100Mbps plan that runs on a 1Gbps fiber link, this enables setting an arbitrary bandwidth that is lower than the configured physical or virtual link.
  4. Change the queueing algorithm - This is the truly funky advanced network engineering stuff. It basically tell the kernel which algorithm to use to organize incoming packets, which has a big effect on which packets get dropped when there are too many coming in at once.

Features 1 and 2 are generally going to be lab-only features. 3 and 4 could be used on a real life link, but 4 is complex enough that it's also fair to say that anyone needing to mess with that can go ahead and do that directly with tc.

Since these end up being pretty involved configs, maybe it would be a good idea to have an optional config file this script could point to. And then that's something that helps people like researchers make their work even more repeatable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants