Call it late night wording on my part. Think connection.

The TCP protocol does not work well with more than a little packet loss.

TCP will actively detect droped packets as part of its congestion control mechanism. Losing the odd packet (I guess something like 1 in 1000 to 1 in 100) is generally not a problem but 22% packet loss will cripple a connection.

The OP, rather than worrying about slow ICMP responses by routers when using traceroute should be much more worried by 22% packet loss when pinging the BBC.

Edited by bsdnazz (Tue 11-Jun-13 12:47:08)

You need to be careful trying to put a percentage on such a small sample. It isn't particularly representative. Your statement was based on 2 packets missing.

It is fairly straightforward to cause at least 1 missing packet manually. All you have to do is hit ctrl-c after a packet has been sent out, but before the answer has been received. On 200ms response times, that would have a 1-in-5 chance, or 20%. On 20ms response times it would be a 1-in-50 chance, or 2%.

And packet loss when pinging an innocent third-party, who might be deliberately choosing to drop packets anyway, isn't the best way to show packet loss over your own link. The BQM does a much better job of informing you about that, because you are in control of both the link and the ping target (your own router).

Stanman's BQM isn't showing any packet loss; I don't see even 1% during the evening peak time. I don't think packet loss is an aspect that ought to worry him

Comparing his graph to the ones published by Plusnet for a group of users, it seems to have been quite a busy night over there. (You'll have to compare soon, as all the graphs are live, and the peaks are gradually disappearing. Robertos - yours looks bad, given that even the minimum latency was raised!)

But you're right that 22% packet loss is likely to be crippling to TCP throughput.

TCP might change the number of packets in flight as part of congestion control, but I've never heard of it actively dropping a packet. Given that its job is to ensure everything is received, that would be plain daft.

Yep - not a great night for graphs, mine included!

http://www.thinkbroadband.com/ping/share/152e8cdd67a...

In reply to a post by WWWombat:

TCP might change the number of packets in flight as part of congestion control, but I've never heard of it actively dropping a packet.

I guess I'm not much better in the morning either! I've edited my post to change 'actively drop' to 'detect dropped'.

Your point about a 9 packet test being too small a sample size is a good one. I usually send 100 packets (ping -c 100 XXX or ping -n 100 XXX depending on OS).

Thanks for the heads-up. It does look rather worse than usual, considering I never do anything to cause even the normal variation at that time of day.