You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.
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.
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.
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.
The text was updated successfully, but these errors were encountered: