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
@steely-glint was wondering on Twitter how well network testing tools such as Synthetic Network simulate real-world network characteristics such as buffering that real congested networks do.
Seems like a great opportunity to compare notes: what do we do, and what do networks do? What could we do to be more like networks?
Right now we have these building blocks:
RateLimiter: forwards packets up to a bps limit, and drops all packets exceeding the limit (no buffering!). It uses a token bucket algorithm and replenishes tokes every 100us.
Loss: drops a fraction of all incoming packets at random and forwards the rest (no buffering!)
Latency: buffers packets for X ms before forwarding. (Never drops or reorders packets!)
Jitter: like Latency but buffers packets for a random duration up to X ms. Can be configured to reorder packets. (Never drops packets!)
At the moment they are combined as our QoS path for each direction of each flow like so:
@steely-glint had some specific use-cases in mind that I think would be interesting to think about how to model in SyntheticNetwork:
I am trying to mimic 2 common domestic situations.
where a user moves from room to room forcing WiFi to change modulation modes.
where a second family member starts streaming Netflix and halves the available bandwidth.
I worry about the delay. I suspect that changing the modulation also changes the time to transmit a packet, so the delay would change too.
Buffer preserved in both cases ?
We might be able to model 1) already by scripting RateLimiter and Latency in concert. However we don’t have an explicit way to talk about buffers, It might make sense to decouple simulation of buffering and delay, and make the buffer sizes scriptable as well. Imagine this:
We could differentiate between wifi latency and geographic network latency, and we could change RateLimiter and Latency to read from Buffers as permitted/needed. If the Buffer size would be scriptable we could possibly simulate arbitrary network configurations?
As for 2) we might want to add contenders to a flow. For example:
The Join building block we already have. LoadGen could be interesting to write. It should probably simulate real traffic with pauses/intervals etc, and probably we should make sure that we don’t actually send the generated packets out in the end! ;-)
Anyways that’s the braindump / food for thought. Looking forward to hear what others think! :-)
The text was updated successfully, but these errors were encountered:
@steely-glint was wondering on Twitter how well network testing tools such as Synthetic Network simulate real-world network characteristics such as buffering that real congested networks do.
Seems like a great opportunity to compare notes: what do we do, and what do networks do? What could we do to be more like networks?
Right now we have these building blocks:
Latency
but buffers packets for a random duration up to X ms. Can be configured to reorder packets. (Never drops packets!)At the moment they are combined as our QoS path for each direction of each flow like so:
@steely-glint had some specific use-cases in mind that I think would be interesting to think about how to model in SyntheticNetwork:
We might be able to model 1) already by scripting
RateLimiter
andLatency
in concert. However we don’t have an explicit way to talk about buffers, It might make sense to decouple simulation of buffering and delay, and make the buffer sizes scriptable as well. Imagine this:We could differentiate between wifi latency and geographic network latency, and we could change RateLimiter and Latency to read from Buffers as permitted/needed. If the Buffer size would be scriptable we could possibly simulate arbitrary network configurations?
As for 2) we might want to add contenders to a flow. For example:
The
Join
building block we already have.LoadGen
could be interesting to write. It should probably simulate real traffic with pauses/intervals etc, and probably we should make sure that we don’t actually send the generated packets out in the end! ;-)Anyways that’s the braindump / food for thought. Looking forward to hear what others think! :-)
The text was updated successfully, but these errors were encountered: