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

Create trace-driven simulation #30

Open
dosirrah opened this issue Nov 5, 2024 · 1 comment
Open

Create trace-driven simulation #30

dosirrah opened this issue Nov 5, 2024 · 1 comment

Comments

@dosirrah
Copy link

dosirrah commented Nov 5, 2024

Tracd driven simulation means that the simulator takes a log of actual traffic and "plays" it into the simulator at the simulation times corresponding to the real times each packet would've been generated in the real network.

Simultaneously we should generate random short codes at random intervals. We could randomly distribute lambda arrival rate of beacon attempts. Interarrivals should obey a Poisson process such that each imitator beacon takes place a random time after the first one starts. With a Poisson process, the interarrival times are IID. NOTE: the timer for the next one to start should be an exponentially distributed amount of time after the prior one started (not after the prior one completed). If we started the timer for the next to start only after the prior completes then there would never be cases where than one beacon is transmitting at the same time. The system should allow for overlapping beacons.

If $T$ is the average inter-arrival time then $\lambda = 1 / T$ is the arrival rate. The arrival rate should configurable so that we control how frequently beacons interfere with each other.

@dosirrah
Copy link
Author

dosirrah commented Nov 5, 2024

See https://github.com/mlsquared/fling/blob/main/analysis/frame_length_mod.ipynb
However, check it out to your local system and run jupyter notebooks. GitHub doesn't display all of the embedded images.

With packet length encoding, longer packets are more expensive. We achieve optimal bandwidth in bits per second with packets varying between M and M + 256 where M in the upper-edge of the distribution mode for short packets > 116 bytes. Given that WiFi pads frames up to a multiple of 16 bytes, we can only use packet lengths at a granularity of 16 or greater bytes. If 116 bytes means 0, 116 + 16 = 1, 116 + 32 = 2, and so on.

According to the analysis in frame_length_mod.ipynb:

  • Number of different lengths at maximum efficiency: 10
  • Max efficiency in side channel bits / bits transmitted is 0.002208728786494257
  • Most efficient maximum frame length is 260.0 bytes
  • Most efficient average frame length is 188.0 bytes
  • Bits communicated in a single frame at most efficient length is 3.321928094887362

If we use 10 levels then the maximum length is 116 + 10*16 =276 bytes.

Using 10 levels each packet does not communicate an integral number of bits. However, it does communicate one decimal number per packet if we have no additional encoding overhead.

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

No branches or pull requests

1 participant