Re: FCC NPRM ban on Paid Peering harms new innovators

[David Farber <dave () farber net>]

Begin forwarded message:

From: Brett Glass <brett () lariat net>
Date: November 12, 2009 1:37:53 PM EST
To: dave () farber net, "ip" <ip () v2 listbox com>
Subject: Re: [IP] FCC NPRM ban on Paid Peering harms new innovators

David Reed writes:

> Or if this is not the case, maybe, just maybe, all the handwaving about the "Internet" being "indirect and slow" and 
> there being "direct and fast connections" available that create wondrous competition and entry opportunities for us 
> small startups to compete with the big Googles is bushwah.

As an ISP, I can tell you with certainty that my customers complain whenever the traceroute to a site that they 
frequent -- or their workplace -- or their VoIP provider -- shows more hops than they would like. And it doesn't help 
that the strange peering arrangements among various backbone providers, over which I have absolutely no control, can 
cause packets to take strange routes. For example, my packets bound for the Los Angeles Times newspaper site take only 
4 hops to get to a major backbone provider's hub in Los Angeles... but then, due to peering issues, bounce to Denver, 
then San Jose, and then back to LA once more.

Despite the fact that I, as a rural ISP, face anticompetitive pricing for the "middle mile" (and, hence, don't have the 
ability to rent pipes to meet up with lots of networks), the complaints are not unjustified. Every hop adds not only 
latency but jitter. And poorly designed applications, such as Windows Remote Desktop and media players that don't 
buffer, are very fussy about this.

Due to the basic pacing algorithms of TCP, the application provider who can place the actual server at the local or 
regional hub of the user's ISP -- or can "virtually" put it there by renting a direct pipe or prioritized service -- 
gets noticeably better results. This is especially true when Web pages are highly interactive (like Google maps) or 
have robust input autocompletion (like Amazon). Google can place a server at an ISP's hub or a run its own fiber to 
every major peering point; a startup can't. So, it's important to be able to purchase prioritized packet delivery to 
allow a level playing field.

--Brett Glass




-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com