I'm currently studying the TCP layer, one of the main references is the 1981 Internet Engineering Task Force's RFC. One of the paper it cites is a paper published by the Internet Electric and Electronic Engineers in 1974.

In the 1974 paper, one of the considerations for the design of the protocol seems to be the attribution of charges, accounting of packet costs, billing:

To allow networks under different ownership to interconnect, some accounting will undoubtedly be needed for traffic that passes across the interface. In its simplest terms, this involves an accounting of packets handled by each net for which charges are passed from net to net until the buck finally stops at the user or his representative.

Later, this rationale is expanded and curious details about the expected billing

We assume, for simplicity, that each network initially charges a fixed rate per packet transmitted, regardless of distance, and if one network can handle a larger packet size than another, it charges a proportionally larger price per packet. We also assume that a subsequent increase in any network’s packet size does not result in additional cost per packet to its users...

The assumption of simplicity is that charges don't depend on distance travelled, which is surprisingly true nowadays. But the charge per packet is taken as a natural assumption, and the implications of it are further discussed in the paper.

There are 2 oddities here.

  • Charges are measured in packets instead of bits: Nowadays, almost all ISP contracts are stipulated in terms of bits, not packages. Was there ever a time were charges were calculated by the amount of packets sent or received?

  • Charges are measured in data usage not bandwidth : This is the most important difference since, nowadays, most consumer's traffic is billed by the bandwidth, although some large scale hosting providers might internally account per data usage, and mobile providers may charge by data usage. I mention this difference because the original article speaks of stopping the buck at the user representative, which implies that the user is charged per data usage, not bandwidth.

  • electronics.stackexchange.com/help/on-topic : If your question generally covers ... a communication scheme ... then you're in the right place to ask a question! Additionally the paper in question was published by an association called Internet Electric and Electronic Engineers
    – Tomas Zubiri
    Commented Mar 6, 2020 at 22:23
  • It’s a good question, but it should be migrated to a network SE. The bits-vs-bandwidth-vs-packets question is more of a business model discussion - infrastructure and running costs, rent-seeking, etc.
    – hacktastical
    Commented Mar 6, 2020 at 22:32
  • The network SE marked it as offtopic because it's 'historical trivia'. Regarding the business model, these are intricately connected with architecture. Consider modern cloud providers complex billing schemes.
    – Tomas Zubiri
    Commented Mar 6, 2020 at 22:43
  • 2
    Winikpedia says that X.25 billing was typically per 64-byte segment, i.e., a unit larger than an octet and usually smaller than a packet. X.25 could be used under TCP so 'internet' charges were per-segment. But that still does not address the specific question about TCP-level charging.
    – dave
    Commented Mar 6, 2020 at 23:38
  • 1
    There were possibly other protocols besides IP using fixed-length packets that, for various technical reasons, found it appropriate to charge by the packet. E.g., ATM (though in that case it would have been the 48-byte "cells"). Anyway, stuff more from the telecom world rather than the computing world. Anybody know anything about that?
    – davidbak
    Commented Mar 7, 2020 at 1:01

2 Answers 2


While I suspect that per-packet billing for the Internet was rare, per-packet billing for internetworks (particularly private ones) was quite common in the 1980s and early 1990s.

Most of these were long-haul X.25 services offered by companies such as Telenet and Tymnet in the United States and DATAPAC in Canada. Note that your connection to the local Point of Presence (POP) of the long-haul provider was often a dedicated line, but that was typically just a short intra-city link and nowhere near as expensive as a cross-country (or worse yet, international) dedicated line.

Once you had a link to a packet network's POP, there was generally no issue running multiple connections to different remote endpoints on it. So it might well be reasonable for someone already using such a connection for another purpose (such as the one I describe below) to request the provider set up a link to an Internet connectivity provider and use that for Internet access. Depending on how much traffic you have, this might be a cheaper way to connect to the ISP than adding another dedicated line if you needed an always-on connection (e.g., to receive mail via SMTP). But it's a matter of opinion whether or not you would see this as "per-packet charges for Internet access," since those charges are not from the ISP itself but due to the way you chose to connect to the ISP.

Back in the early '90s I was a network administrator at a company in Vancouver that had a remote site in Chile, and we had a local X.25 connection to DATAPAC that, through various other networks, eventually terminated in Santiago. This wasn't any more speedy than a pair of high-speed modems, but we needed an always-up connection and, since we didn't anticipate having a lot of traffic on the link, this was calculated to be considerably cheaper than a a dedicated leased line or a "permanent" long distance phone call.

Sadly for us, we didn't realize that our Novell servers, using the IPX protocol, would exchange route information and service advertising messages with the remote servers several times per minute. This is of course fine on local area networks and dedicated links, since the total volume of data for these is not particularly high, but on X.25 this incurred a charge for each packet. When the first monthly invoice arrived we were rather shocked to see that we had sent and received a few dozen times as many packets as we had calculated for our traffic, and of course the bill was much larger than expected. (We quickly figured out how to reconfigure our systems to stop exchanging these packets, or at least send them much less frequently.)

  • Interesting that these services were billed per packed at the business client level (although not particularly surprising). I used DATAPAC as an end-user in the early 90's to connect to Compuserve due to them not having a local number in my small city and the $20/hour charge for DATAPAC was significantly cheaper than calling long-distance. Mind you, it was billed through Compuserve, so perhaps they were getting billed by the packet and just charging me for it hourly based on some average they expected customers to realistically use.
    – mnem
    Commented Mar 7, 2020 at 7:36
  • 3
    @mnem Keep in mind that what Compuserve was buying there was actually two services: the packet transport over DATAPAC's network and the local connectivity. DATAPAC had to purchase modem banks and rent telephone lines and POP space for the equipment so that you could dial in, which easily amortized out to a few dollars an hour just for that. Consumes almost certainly wouldn't be happy with getting a full breakdown of the charges for that kind of thing; it would feel like nickle-and-diming.
    – cjs
    Commented Mar 7, 2020 at 8:01
  • 1
    That's a fair point too. Way easier just to average it out and price it as a flat hourly surcharge. At a max supported speed of 9,600bps (and an hourly rate for Compuserve as well) its not like there was a lot of wiggle room for a single user to really rack up an unusually high packet cost to Compuserve.
    – mnem
    Commented Mar 7, 2020 at 9:18
  • 1
    Yes, per packet billing for X.25 networks was a thing, and if you ran IP over X.25 you ended up paying those charges for your internet traffic. Commented Mar 8, 2020 at 4:22
  • 1
    I used to work on billing for Telecom Gold and we used to have a complex billing structures like this Commented Mar 14, 2020 at 1:23

It's important to keep in mind that there are vastly different business models when it comes to networking. We can categorise them as peering (between providers) and endpoint (non network user).

Between providers, it's all about the amount of data transferred, as this is in direct relation to resources used. Toward endpoint users, it's about finding an accounting (business) model that fits the user expectation as well as the need to cover cost and generate profit.

One important point in the above citation is:

[...] if one network can handle a larger packet size than another, it charges a proportionally larger price per packet [...]

This simply means charging by data amount exchanged. With a fixed packet size, packet counting is the same as data counting. Incorporating packet size as a price element does extend this for different packet configuration - and turns packet counting into data counting.

And that has (almost) always been the case between peers (providers). Which makes sense for continuous connections. Providers always tried to level connections usage to reduce payments.

End user accounting is a complete different topic. Here, various models have been used:

  • charging by time connected (dial up)
  • flat rate per month
  • charge by data transmitted

All three have additionally been available with different pricing for different speeds.

Bottom line: Many accounting models have been used, and packet counting was among them.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .