BitStream

BitStream moves real bytes between two machines over a WebRTC data channel (SCTP over DTLS over UDP). The traffic genuinely traverses the network path under test — there is no relay or proxy in the middle when both ends are on the same subnet.

What is measured

• Throughput — application-layer goodput, measured at the receiver.
• Latency — round-trip time of small probes over the control channel, plus the ICE connectivity-check RTT reported by the browser.
• Jitter — RFC 3550 smoothed mean deviation of transit time. Because it works on the variation in transit time, it is valid without any clock synchronisation between the two machines.
• Packet loss / reordering / duplication — from per-packet sequence numbers, in unreliable mode only.

What is deliberately not here

Browsers have no access to raw sockets. Rather than fake these, BitStream leaves them out:

• Traceroute — needs ICMP and TTL control. Not possible, and not approximable.
• ICMP ping — the latency figures here are application-level round trips, which include a small amount of browser scheduling overhead. Treat them as an upper bound.
• Port selection — the browser chooses ephemeral UDP ports for ICE.
• QoS / DSCP marking — not exposed for data channels in a portable way.
• True MTU discovery — the size control below sets the application message size, not the IP MTU. Messages larger than the path MTU are fragmented by SCTP.

Reading the throughput number honestly

A browser data channel costs CPU: SCTP framing, DTLS encryption, and JavaScript overhead all sit between you and the wire. On fast links the browser, not the network, is often the limit. BitStream watches for this and labels any result where the sender could not fill the requested rate as sender-limited. A sender-limited result is a floor on the path's capacity, not a measurement of it.