xISPs, especially WISPS, and their web-sites

I wanted to take a few moments and talk about the WISP web-site.  This is an often neglected area of your business. This really should not be the case.  With all the talk of the younger generations not using the web, e-mail, and other things we “old-timers” are used to, the web is still one of the top resources for information. I will go into some things every web-site should have.

1. Contact information including your state.  I see too many websites that mention things like counties and towns but don’t mention the state anywhere on their site.  It’s like you expect all customers to be familiar with who you are.  Remember, your website is also an introduction to potential customers, many of them are finding you through search engines.  These may be folks who have just moved to the area or are contemplating a move to your coverage area.

2. Coverage areas which are just images of circles drawn on a map. While these are helpful for folks who have found the site, search engines can’t pick these up. If you use things like the towercoverage.com integration it helps.  But having a page with city/town names will really help with search engines picking you up.  Things like zip codes and state will also help narrow down search results.

3. SSL.  Google sends websites with SSL/HTTPS to the top of the list. Make sure you have a valid SSL certificate for your domain and all subdomains. If you want to go the extra mile add them to the Google webmaster tools.  Bing has a similiar one.

4. Update your content.  A blog is the easiest way to update your content.  WordPress and others are easy to update and type in.  Company news, new service areas, and news can all go on the blog.  This helps increase search engine ratings.  The more specific your blog posts are the better.

5. Integrations. Integrate your blog with Facebook, Twitter, and even Instagram.  If you use WordPress as your blog you can push out updates to all these platforms from a single place. This saves time and simplifies your communications.

There is so much more you can do, but these are some of the hot button items.

Remote Peering

Martin J. Levy from Cloudflare did a presentation about remote peering possibly being a bad thing. In this presentation, he brings up several valid points.


Some thoughts of my own.

Yes, remote peering is happening.  One thing touched upon is the layer3 vs layer2 traffic.  We at MidWest-IX only allow remote peering at a layer2 level unless it is groups like routeviews.org or other non-customer traffic situations.

Many providers are overselling their backbone and transit links.  This oversubscription means access to content networks in places that do not have an exchange or places that do have the content locally can suffer through no fault of the ISP or the content provider.  We have situations with content folks like Netflix who do not join for-profit IXes at the moment, keeping the content further away from customers.  These customers are reaching Netflix through the same transit connections many other providers are.  The can result in congested ports and poor quality for the customer.  The ISP is left trying to find creative ways to offload that traffic.  An Internet Exchange is ideal for these companies because cross-connect charges within data centers are on the rise.

When we first turned up MidWest-IX, now known as FD-IX, in Indianapolis we used a layer2 connection to Chicago to bring some of the most needed peers down to our members.  This connection allowed us to kick-start our IX.  We had one member, who after peering with their top talkers, actually saw an increase in bandwidth.  The data gained told the member that their upstream providers were having a bottleneck issue. They had suspected this for a while, but this confirmed it. Either the upstream provider had a congested link, or their peering ports were getting full.

As content makes it way closer remote peering becomes less and less of an issue.  There are many rural broadband companies just now getting layer2 transport back to carrier hotels. These links may stretch a hundred miles or more to reach the data center.  The rural broadband provider will probably never get a carrier hotel close to them.  As they grow, they might be able to afford to host caching boxes. The additional cost and pipe size to fill the caches is also a determining factor. The tradeoff of hosting and filling multiple cache boxes outweighs the latency of a layer2 circuit back to a carrier hotel.

I think remote peering is necessary to by-pass full links which give the ISP more control over their bandwidth.  In today’s race to cut corners to improve the bottom line having more control over your own network is a good thing. By doing a layer2 remote peer you might actually cut down on your latency, even if your upstream ISP is peered or has cache boxes.