The problem with speedtests

Imagine this scenario. Outside your house, the most awesome super highway has been built.  It has a speed limit of 120 Mile Per Hour.  You calculate at those speeds you can get to and from work 20 minutes earlier. Life is good.  Monday morning comes, you hop in your Nissan GT-R, put on some new leather driving gloves, and crank up some good driving music.  Your pull onto the dedicated on-ramp from your house and are quickly cruising at 120 Miles an hour. You make it into work before most anyone else. Life is good.  

Near the end of the week, you notice more and more of your neighbours and co-workers using this new highway.  Things are still fast, but you can’t get up to speed to work like you could earlier in the week.  As you ponder why you notice you are coming up on the off-ramp to your work.  Traffic is backed up. Everyone is trying to get to the same place.  As you are waiting in the line to get off the super highway, you notice folks passing you by going on down the road at high rates of speed.  You surmise your off-ramp must be congested because it is getting used more now.

Speedtest servers work the same way. A speedtest server is a destination on the information super-highway. Man, there is an oldie term.  To understand how speedtest servers work we need a quick understanding of how the Internet works.   The internet is basically a bunch of virtual cities connected together.  Your local ISP delivers a signal to you via Wireless, Fiber, or some sort of media. When it leaves your house it travels to the ISP’s equipment and is aggregated with your neighbours and sent over faster lines to larger cities. It’s just like a road system. You may get access via a gravel road, which turns into a 2 lane blacktop, which then may turn into a 4 lane highway, and finally a super-highway.  The roads you take depend on where you are going. Your ISP may not have much control over how the traffic flows once it leaves their network.

Bottlenecks can happen anywhere. Anything from fiber optic cuts, oversold capacity, routing issues, and plain old unexpected usage. Why are these important? All of these can affect your speedtest results and can be totally out of control of your ISP and you.  They can also be totally your ISP’s fault. They can also be your fault, just like your car can be.  An underpowered router can be struggling to keep up with your connection. Much like a moped on the above super-highway can’t keep up with a 650 horsepower car to fully utilize the road, your router might not be able to keep up either.  Other things can cause issues such as computer viruses, and low performing components.

Just about any network can become a speedtest.net node or a node with some of the other speedtest sites.  These networks have to meet minimum requirements, but there is no indicator of how utilized these speedtest servers are.  A network could put up one and it’s 100 percent utilized when you go running a speedtest. This doesn’t mean your ISP is slow, just the off-ramp to that speedtest server is slow.

The final thing we want to talk about is the utilization of your internet pipe from your ISP.  This is something most don’t take into consideration.  Let’s go back to our on-ramp analogy.  Your ISP is selling you a connection to the information super-highway.   Say they are selling you a 10 megabyte download connection.  If you have a device in your house streaming an HD Netflix stream, which is typically 5 megs or so, that means you only have 5 megs available for a speedtest while that HD stream is happening. Speedtest only test your current available capacity.  Many folks think a speedtest somehow stops all the traffic on your network, runs the test, and starts the traffic. It doesn’t work that way. A speedtest tests the available capacity at that point in time.  The same is true for any point between you and the speedtest server.  Remember our earlier analogy about slowing down when you got to work because there were so many people trying to get there.  They exceeded the capacity of that destination.  However, that does not mean your connection is necessarily slow because people were zooming past you on their way to less congested destinations.

This is why speedtest results should be taken with a grain of salt. They are a useful tool, but not an absolute. A speedtest server is just a destination.  That destination can have bottlenecks, but others don’t.  Even after this long article, there are many other factors which can affect Internet speed. Things we didn’t touch on like Peering, the technology used, speed limits, and other things can also affect your internet speed to destinations.

Some Random Visio diagram

Below, We have some visio diagrams we have done for customers.

This first design is a customer mesh into a couple of different data centers. We are referring to this as a switch-centric design. This has been talked about in the forums and switch-centric seems like as good as any.

This next design is a netonix switch and a Baicells deployment.

Design for a customer

MTIN is growing again

Over the years MTIN has gone from being a computer repair shop to a dial-up ISP, to a Wireless ISP, and many things in-between.  Each time technology and market conditions change we adapt to change with it.  Our next metamorphosis is needed so we can grow into more aspects of the xISP world In order to accomplish this we are splitting into divisions of what we do.

The first is j2sw.com. This part of the business will be focused on personalised WISP services and support.  These will be custom tailored to a limited number of clients.  Projects such as the “Start a WISP” book and upcoming WISP publications will be run under j2sw.com. Other projects that benefit the ISP community will run from j2sw.com. Having j2sw Consulting as a separate arm allows for better personal attention to key customers.

The second division of the business is MTIN.NET.  This arm will be focused on business to business services such as data center co-location, network connectivity, tower services, and related type services. MTIN is becoming a project management company. We will leverage our vast partnerships to leverage the strength of many to accomplish your medium to large projects.   MTIN will be an umbrella company to bring in the right people for the right projects.

Look for changes to the websites and contact information coming over the next month or so. Justin will be involved with each entity on a very regular basis, but having extra folks can allow for time to be dedicated to ever-expanding projects without sacrificing service to the client.

Some FAQs
Why the change?
For a couple of reasons. The first is to leverage Justin being known in the xISP community.  having a face to the consulting side. This allows for better personal service as well as a trusted name in the WISP community. Secondly, is to allow a better division of resources based on projects and individual needs.

Is MTIN going away?
No, MTIN will move into a project management type of company.  We have access to a large network of contractors, partners, service providers, and other groups we have built since 1998. MTIN can bring in needed resources for projects under one contact point. This allows for projects to not depend on just one person.

Will contact info change?
In the upcoming months, we will be publishing updated contact info. The old information will not go away, but things will get routed to the proper folks better.

For now check out http://j2sw.com and like jswconsulting on facebook.

Use tarpit vs drop for scripts blocking attackers

There are many scripts out there, especially on Mikrotik, which list drop as the action for denying bad guy traffic.  While this isn’t wrong, you could put the tarpit action to better use for actions which are dropping attacking type of traffic.

So what is Tarpit?
Tarpit is fairly simple. When connections come in and are “tarpitted” they don’t go back out. The connection is accepted, but when data transfer begins to happen, the TCP window size is set to zero.  This means no data can be transferred during the session.  The session is held open, and requests from the sender (aka attacker) to close the session are ignored. They must wait for the connection to timeout.

So what’s the downside?
TCP is not really designed to hold onto a connection.  It can be additional overhead on a taxed system.  Most modern firewalls can handle tarpitting without an issue. However, if you get thousands of connections it can overwhelm a system or a particular protocol.

How can I use it?
If you have scripts, such as the SSH drop off the Mikrotik wiki, simply change the action to “tarpit” instead of “drop”.

Open Letter to the FCC about CBRS

An open letter regarding:

GN Docket No. 12-354
RM-11788
RM-11789

I am writing on behalf of my Company MTIN.NET LLC in regard to the proposed changes to the CBRS band. We are primarily a consulting company for Wireless Internet Providers (WISPs). One of the biggest changes our customers face is the availability of spectrum to operate in.  These are companies who primarily are investing their own money into providing access in their own communities.  They help to support local businesses by giving them a choice in high-speed broadband access. Sometimes, these WISPs are the only option.

Please take into consideration how any changes will affect these Entrepreneurs and their mission to bring broadband into underserved areas of the country.   Without WISPs, many homes and businesses would not have high-speed access that works with Voice, or streaming services.  Satellite is unable to deliver low-latency connections to users.

The ability of a WISP to have access to more spectrum not only allows them to provider more speeds and better service, but it has other benefits as well. WISPs have usually been started to fill a broadband need in an area.  Having access to high-speed access allows schools to offer greater learning tools, allows businesses to generate new revenue streams as well as saving money.  Please don’t leave the companies who are investing their own money, not shareholder’s money, out in the cold.

We are opposed to both petitions by CTIA and T-mobile. Please consider the comments from the WISP community before making any decisions. It is estimated WISPs service over 3 Million subscribers across the country.  Give them tools they need to thrive.

Server SSH Attempts

For those of you who are curious where many of your cyber attacks appear to come from the following is a sample of just some of the locations the MTIN servers have blocked for malicious attempts.

#1 CN/China/
#2 KR/Korea, Republic of
#3 CZ/Czech Republic

Russian IPs are # 7 and US (mainly AWS IPs) are #8