I do see a couple of retransmissions early in that query (lost ACKs?) which could be upstream throttling but in any event certainly explains why the connection

I do see a couple of retransmissions early in that query (lost ACKs?) which could be upstream throttling but in any event certainly explains why the connection was slow to get off the ground. Agreed that segment offload is probably kernel-side coalescing. From shunting this into Wireshark, you can see that the sequence number grows fairly linearly (often a good indicator of a rate limiter) starting from 1.508s up until the 1.95s mark, but at a rate closer to 25-30 Mbps (1.5MB in 0.45s). https://i.imgur.com/s2JBrCf.png https://i.imgur.com/s2JBrCf.png edit: this was for iphone-capture.pcap. You see a similarly strong picture of shaping for capture.pcap [0], and indeed that corresponds to the ~320kbps range you've noted. [0] https://i.imgur.com/g9cN95d.png https://i.imgur.com/g9cN95d.png edit edit: of course, under normal situations, your bandwidth will get saturated, and steady-state will look fairly linear. If you're using "classic" congestion control like CUBIC or New Reno, you'll see this interspersed with drops (search for "tcp sawtooth"). Under BBR you'd expect to see drops in bandwidth due to latency spikes (per bufferbloat). Neither of those seem to be in play here.