There's an old joke. It was said that English automobiles of the 1950's came equipped with a walnut inlayed toolbox containing many hammers. These ranged in size from a small jeweler's hammer up through a heavy, concrete shattering, sledge. It was said that when something in the automobile stopped working that one should begin by pounding on it with the smallest hammer. If that didn't solve the problem then one should move up to the next larger size. And so on, using ever larger hammers, until the sledge, which would reduce the automobile to a heap of shattered parts that could easily be hauled away – because the original problem was obviously insolvable.
Fuzz testing of software is somewhat like that old English automotive technique, but often without the benefit of an orderly sequence.
The question of “how many bits” were sent and received clearly is a matter of interest when measuring data rates or data quantities.
Mobile providers, consumer ISP's, consumers, and regulators talk a lot about their speed and (not so often) about their data caps. But rarely, if ever, are sufficient details provided:
And it is not just a consumer issue: ISPs that exchange data with one another under contractual peering and transit arrangements need common ground when they discuss how much data each party is delivering to the other.