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
Possible bwtester enhancements, extracted from discussion in #209:
Improve parameter parsing to allow to properly specify zero duration tests (currently, can only specify zero bandwidth). At the same time, support for fractional seconds should be added by using time.Duration types throughout.
Infinite test duration; at the moment we can only pick <= MaxDuration (now 5 minutes)
Fine tune reporting: report inter packet delays over certain threshold.
Instant reporting. Configure reporting every N seconds.
Allow to specify pattern for packets to easily identify them in packet traces etc. More generally, do not require each packet to be full of AES counter mode PRG data. This is overkill (and not "secure" anyway as the key is transmitted in plaintext). Suggested structure for a test data packet:
session identifier (not strictly necessary, but might be helpful)
packet index
user chosen pattern
a fixed, repeated byte value (e.g. 0xca) to detect truncation
Possibly, including a timestamp could also be useful to correlate send with receive times.
Require round trip confirmation before starting test -- it's a bit too easy for a client to spoof its source address and so abuse the bwtestserver to blast at a different host. Maybe even better / simpler would be to just use quic for the control channel.
The text was updated successfully, but these errors were encountered:
Burster and cbrtester, while useful at the time for debugging specific
issues with the routers, are somewhat redundant with the functionality
of the bwtester applications.
Moving forward, the idea to integrate the useful bits of these two tools
into the bwtester instead; see #210.
Burster and cbrtester, while useful at the time for debugging specific
issues with the routers, are somewhat redundant with the functionality
of the bwtester applications.
Moving forward, the idea to integrate the useful bits of these two tools
into the bwtester instead; see #210.
Burster and cbrtester, while useful at the time for debugging specific
issues with the routers, are somewhat redundant with the functionality
of the bwtester applications.
Moving forward, the idea to integrate the useful bits of these two tools
into the bwtester instead; see #210.
Possible bwtester enhancements, extracted from discussion in #209:
Improve parameter parsing to allow to properly specify zero duration tests (currently, can only specify zero bandwidth). At the same time, support for fractional seconds should be added by using
time.Duration
types throughout.Infinite test duration; at the moment we can only pick <= MaxDuration (now 5 minutes)
Fine tune reporting: report inter packet delays over certain threshold.
Instant reporting. Configure reporting every N seconds.
Allow to specify pattern for packets to easily identify them in packet traces etc. More generally, do not require each packet to be full of AES counter mode PRG data. This is overkill (and not "secure" anyway as the key is transmitted in plaintext). Suggested structure for a test data packet:
0xca
) to detect truncationPossibly, including a timestamp could also be useful to correlate send with receive times.
Require round trip confirmation before starting test -- it's a bit too easy for a client to spoof its source address and so abuse the bwtestserver to blast at a different host. Maybe even better / simpler would be to just use quic for the control channel.
The text was updated successfully, but these errors were encountered: