As we said a few weeks ago, the Federal Communications Commission's order last Friday in the Comcast-BitTorrent dispute should help ensure that today's broadband networks remain open platforms to the Internet. But more broadly, the recent attention on Comcast -- and on Time Warner's recently launched trial of "consumption-based billing" -- raises the question: what is a reasonable approach for broadband networks to manage their Internet traffic?

Network capacity (bits per second or data rate) is a limiting factor in all communications networks. Users cannot send traffic faster than the amount of network capacity available to them. But when users' aggregate demand exceeds the available capacity of the network, network operators naturally seek to manage the traffic loads. Even FiOS, Verizon's speedy fiber-based broadband service, divides up the available wavelengths to carry video and data applications. Wireless broadband networks have capacity issues based on their own unique technical characteristics. The end result is the potential for traffic congestion, leading to service delays and even outages for consumers.

At least one proposal has surfaced that would charge users by the byte after a certain amount of data has been transmitted during a given period. This is a kind of volume cap, which I do not find to be a very useful practice. Given an arbitrary amount of time, one can transfer arbitrarily large amounts of information. Rather than a volume cap, I suggest the introduction of transmission rate caps, which would allow users to purchase access to the Internet at a given minimum data rate and be free to transfer data at at least up to that rate in any way they wish.

Others have suggested that users should be able to contract for a "floor" capacity and that they might possibly receive more capacity if it is available. One problem with charging for total bytes transferred (in either direction) is that users will have no reasonable way to estimate their monthly costs. Clicking on a link can take you to an unexpected streaming site or a major file transfer.

So the real question for today's broadband networks is not whether they need to be managed, but rather how.

In my view, Internet traffic should be managed with an eye towards applications and protocols. For example, a broadband provider should be able to prioritize packets that call for low latency (the period of time it takes for a packet to travel from Point A to Point B), but such prioritization should be applied across the board to all low latency traffic, not just particular application providers. Broadband carriers should not be in the business of picking winners and losers in the market under the rubric of network management.

Network management also should be narrowly tailored, with bandwidth constraints aimed essentially at times of actual congestion. In the middle of the night, available capacity may be entirely sufficient, and thus moderating users' traffic may be unnecessary. Some have suggested metered pricing -- charging by the megabyte rather than flat fee plans -- as a solution to congestion, and prices could be adjusted at non-peak periods. These kinds of pricing plans, depending on how they are devised or implemented, could end up creating the wrong incentives for consumers to scale back their use of Internet applications over broadband networks.

Over the past few months, I have been talking with engineers at Comcast about some of these network management issues. I've been pleased so far with the tone and substance of these conversations, which have helped me to better understand the underlying motivation and rationale for the network management decisions facing Comcast, and the unique characteristics of cable broadband architecture. And as we said a few weeks ago, their commitment to a protocol-agnostic approach to network management is a step in the right direction.