Mountain View, California-based Google's chief evangelist Dr. Vint Cerf, co-inventor of the TCP/IP protocol that  underlies the Internet, has suggested Internet Service Providers use transmission rate caps to manage increasing network traffic rather than systems that impose volume caps and over-usage fees, according to a message Cerf posted Monday to the official Google public policy blog. Looking Ahead From FCC Ruling On Comcast Following last week's ruling by the United States Federal Communications Commission that broadband provider Comcast cannot block its subscribers from using the file-sharing methods that run such peer-to-peer (P2P) programs as BitTorrent, which Dr. Cerf said "should help ensure that today's broadband networks remain open platforms to the Internet," the Internet pioneer has asked how broadband network providers can best manage the ever-increasing flow of online information. Broadband providers which don't successfully manage their networks face outages and service delays brought on by Internet traffic congestion, Dr. Cerf wrote in the Monday Google blog entry, in which he contended that the most pressing question today "is not whether they need to be managed, but rather how." Dr. Cerf suggested a volume capping method that could be implemented using minimum data rate service level agreements, or SLAs, and not a consumption-based billing method such as the one that Time Warner has been trying out in at least one market in Texas. Internet Pioneer Suggests Transmission Rate Caps "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," Dr. Cerf wrote. Internet traffic methods that charge users fees "by the byte after a certain amount of data has been transmitted during a given period," Dr. Cerf dismisses as "volume cap" plans. "I do not find [such plans] to be a very useful practice," he added. Instead Dr. Cerf favors plans focused on identifying those pieces of Internet data, called packets, that don't require the fastest movement between one computer server to another, so that data needing the greatest speed can be given priority, although he stressed that this selection process should be handled at the protocol level and not by broadband providers. "Internet traffic should be managed with an eye towards applications and protocols," Dr. Cerf wrote. "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," he added. Meetings Held With Comcast Network Engineers If broadband providers were allowed to choose which applications received the fastest latency, they could find themselves "in the business of picking winners and losers in the market under the rubric of network management," Dr. Cerf warned. Dr. Cerf also contended that systems used to manage bandwidth congestion should only be put in use when needed, "at times of actual congestion" and not kept operating continuously. As an example of how even the fastest broadband services need to plan for network congestion, Dr. Cerf made mention of Verizon's fiber optic-based network, FiOS. "Even FiOS, Verizon's speedy fiber-based broadband service, divides up the available wavelengths to carry video and data applications," Dr. Cerf noted. Google hired Dr. Cerf after he left his position as chairman of the Internet Corporation for Assigned Names and Numbers (ICANN) last October, and over the past several months he has met with network engineers at Comcast to discuss Internet traffic congestion and management. "I've been pleased so far with the tone and substance of these conversations," Dr. Cerf said of his meetings with Comcast, and praised their "protocol-agnostic approach to network management," as "a step in the right direction." Harkening back to the early days of Internet access, which was often billed using either metered pricing or hourly fees, Dr. Cerf warned that volume caps could stifle growth of the Web and "end up creating the wrong incentives for consumers to scale back their use of Internet applications over broadband networks." Today's Web link could take a person to either a simple text-based message or to a bandwidth-straining high definition streaming television broadcast, making it difficult for consumers to predict the bandwidth they use -- a problem Dr. Cerf sees as inherent in volume-capping approaches to bandwidth management. Google Internet Evangelist Vinton Cerf Seeks Protocol-Agnostic Net Management "One problem with charging for total bytes transferred (in either direction) is that users will have no reasonable way to estimate their monthly costs," Dr. Cerf wrote. "Clicking on a link can take you to an  unexpected streaming site or a major file transfer," he added. Dr. Cerf praised a Comcast system undergoing tests throughout the summer in three U.S. markets using three different technology suppliers including Sandvine Inc and Camiant Inc., all of which "will focus on the bandwidth consumption activity of individual customers who are contributing to congestion on Comcast's network," according to Comcast's network management policy Web page. The tests use techniques which measure "only aggregate bandwidth consumption, not the protocol or content being used by customers," according to Comcast. These so-called protocol-agnostic approaches have received the support of the largest nonpartisan media reform organization in the United States, Washington, D.C.-based Free Press, which has called them "legal and appropriate." Dr. Cerf's suggestions come as some broadband providers are going forward with plans to test usage-based fee schedules, including Bell Canada and Time Warmer. The Electronic Freedom Foundation recently released a program aimed at testing ISPs for potential bandwidth throttling, called Switzerland. Related Links:
| 
