How much packet loss is too much? I know for example, telnet/ssh is very sensitive to packet loss, and I can tell every time there's even 1% packet loss when I'm doing stuff in ssh/telnet window. But what about http protocol? When you're just visiting a site on a server that has say, 10% packet loss, is it very noticable? At what threshold does it become noticable to a casual surfer visiting a site?

Aslo, if co-location provider has 99.99% uptime guarantee, could the packet loss be considered a downtime? Say, for example, if there was a 10% packet loss for 90 minutes, isn't it equal to 90x0.10 = 9 minutes of straight downtime?

i've never seen packet loss count in a uptime gurantee

It all depends on where the packet loss is occuring. If the loss is at your bandwidth provider, there is not much your colo provider can do. Have you asked your colo provider about it, who are they? Do you have a trace route that you can post?

Well, here's the reason why I ask. I was trying to decide if I should co-locate with eFreeServers. So I left "ping /t efreeservers.com" running for about half an hour during different times of day. And it turns out they lose packets. About 1% at night and up to 5% during the day at peak hours. Then I thought, maybe it was my connection. So I went to Exodus traceroute -- http://www.exodus.net/network/traceroute.html -- and tried both West and East. If you try maximum amount of probes (10) you will see what I'm talking about -- it's always only 80% of packets reaching the destination. The speed and ping times seem to be great, there are no complaints about them in the forums, so I'm trying to decide if the packet loss is something to really worry about?

The main thing to remember about them is that they only use Level 3 as a provider with no BGP redundant routing. Level 3 is all you get!

Packet loss shouldn't really be ocurring in normal operations. The main times you get packet loss is when you either a) are having backbone problems b) are overusing your connection, be it a physical line or the local network (ie. putting 50 servers that are using a total of 11mbps on a 10mbps capped line).

Personally I don't mind to be connected to Level3 only as my home DSL provider buys bandwidth from Level3 and I've been running several sites off that line for the last year and a half and they have excellent uptime.

Aslo, the packet loss doesn't seem to be from connection overuse. Otherwise wouldn't the webpage itself load very slowly? And the ping times would be very high too. I've seen what happenes when a DSL line gets saturated. :)

It is interesting you should mention this. My website was having some significant packet loss earlier today. During pings the percent loss ranged from 7% to 22% for a few hours. I thought the slowdown was very significant. It made web browsing quite sluggish, much more than the 7 to 22% slowdown you might expect. I suspect that when a packet is lost, the network waits for a short time to receive it. This makes a small packet loss add up to big delays.

You said you noticed an 20% packet loss. I would first do a traceroute to find out where the packet loss is occurring. If it is happenning very close to your server, then it is likely to affect most of your viewers. I would stay away from any host that has this kind of packet loss in its facilities.

Packet loss is best avoided by proper capacity planning. Most Internet Providers oversubscribe their bandwidth (i.e. they might sell 90Mbps of connectivity using 1 45Mbps DS3). While at times the actual utilization might be under the physical bandwidth capacity, at other times the actual utilization will be far in excess. When this occurs, packet loss occurs.



Since a lot of bandwidth is being provisioned in the carrier hotels these days via ethernet as opposed to traditional TDM circuits, we no longer have to be at the constraints of rigid steps in our capacity planning and service subscription (i.e. DS1 = 1.544 Mbps, DS3 = 45 Mbps, OC3 = 155Mbps). We can now grow into our desired "physical" capacity in 8 bit increments through Quality of Service at the provisioned edge of the network.



It is important to go with a hosting provider that can guarantee that both your physical port and your network space is segregated from any other customers. If a hosting company is simply purchasing L2 service from a nother provider and not doing any L3 QoS of their own, all of their customer traffic will be in the same pool, each attributing their usage haphazardly together until the subscribed bandwidth of the hosting company is surpassed causing packet loss will occur.



It is also important to make sure that upstream facilities to the Internet backbones are underutilized (at least under 50 percent ultilization). BGP peering is important as well. Although providers cannot guarantee the packet loss experienced beyond their Autonomous System, when they see that this packet loss is occuring on an backbone, they can take appropriate measures to manipulate packets into traversing over non-latent backbones through AS hop prepends and localpref attributes. I will actually be implementing a system in my Dallas, TX colo that will do this automatically.



Other reasons for packet loss include bad connectors on the ends of cables, bad interface cards on routers or switches, over utilized router and switch backplanes, excessive router hops from source to destination, and assymetric routing loops that occur when packets leave via one backbone and return on another (i.e. Assymmetric BGP peering).



Providers can gurantee packet loss in SLA's. My company does. We define a down situation by not only excessive packet loss but also loss of connectivity. If an excessive amount of packet loss occurs within my autonomous system for a specified amount of time, we view the connection to the customer as down and will provide credit for the down period. The packet loss has to be reported when it is happening. I believe that Exodus does this as well. If a customer is exceeding his subscribed amount of bandwidth, thus causing packet loss, I can only inform them of the overutilization problem and can't be liable for the packet loss in that situation.



In my opinion no greater that 2 percent packet loss is acceptable end to end. But as you say, it depends on the application.