cmd/tailcat, internal/perf: add iperf-like perf command and service - #131
Merged
Merged
Conversation
Add "tailcat perf <tc-addr>" and a matching "perf" service for "tailcat serve" to measure what a tunnel can carry: TCP or UDP throughput in either or both directions, with one or more parallel streams, for a duration or a byte count. UDP tests report loss, reordering, and RFC 3550 jitter from a sequence number and send timestamp in each datagram. All tests report round-trip latency measured over the test's control connection while the data streams are running, which is the number that matters when a full pipe makes everything else sluggish. The protocol lives in internal/perf. The client opens a JSON-lines control connection to TCP port 5201 on the server's tailcat address, data flows on separate TCP connections or UDP flows to the same port, and each side reports what it sent and received so the client prints both views of every direction. The server runs one test at a time and bounds stream count and duration. The service plugs into the existing OnTCP and OnUDP hooks with the packet filter narrowed to that port, and logs one line per completed test. A throughput test through a shared DERP relay mostly measures the relay's rate limit while crowding out everyone else on it, so the client waits for a direct path first (up to --timeout, like ping --until-direct) and refuses to run relayed. --via-derp allows a relayed test through a relay the user runs, but never through one under ipn.dev or tailscale.com. Client.DERPRegion is added to the library so the CLI can see which relay is in use. Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add "tailcat perf " and a matching "perf" service for
"tailcat serve" to measure what a tunnel can carry: TCP or UDP
throughput in either or both directions, with one or more parallel
streams, for a duration or a byte count. UDP tests report loss,
reordering, and RFC 3550 jitter from a sequence number and send
timestamp in each datagram. All tests report round-trip latency
measured over the test's control connection while the data streams
are running, which is the number that matters when a full pipe makes
everything else sluggish.
The protocol lives in internal/perf. The client opens a JSON-lines
control connection to TCP port 5201 on the server's tailcat address,
data flows on separate TCP connections or UDP flows to the same port,
and each side reports what it sent and received so the client prints
both views of every direction. The server runs one test at a time
and bounds stream count and duration. The service plugs into the
existing OnTCP and OnUDP hooks with the packet filter narrowed to
that port, and logs one line per completed test.
A throughput test through a shared DERP relay mostly measures the
relay's rate limit while crowding out everyone else on it, so the
client waits for a direct path first (up to --timeout, like
ping --until-direct) and refuses to run relayed. --via-derp allows a
relayed test through a relay the user runs, but never through one
under ipn.dev or tailscale.com. Client.DERPRegion is added to the
library so the CLI can see which relay is in use.