* Re: [Bloat] backbone loss statistics over the past 15 years or so?
@ 2015-06-18 19:32 Hal Murray
2015-06-19 16:28 ` Dave Taht
0 siblings, 1 reply; 5+ messages in thread
From: Hal Murray @ 2015-06-18 19:32 UTC (permalink / raw)
To: bloat; +Cc: Hal Murray
I don't think you can measure backbone loss using ping unless you control both ends and ensure that both last-miles are not contributing to the problem.
I think there are several different areas to investigate. The main one is whether your packet gets handed off between two "backbone" IPSs that are currently squabbling about who is going to pay whom how much. The obvious example is Netflix vs Comcast.
I don't have any numbers, but I think over the past 5 or 10 years, all the major ISPs have set things up so that all their internal links are overprovisioned. You might notice packet loss when a link goes down and the traffic patterns get rearranged. (I know you can see changes in transit time using NTP.)
I have an old/slow DLS link. I get close to 0% packet loss if my last mile is not busy and lots of loss when it is overloaded.
--
These are my opinions. I hate spam.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bloat] backbone loss statistics over the past 15 years or so?
2015-06-18 19:32 [Bloat] backbone loss statistics over the past 15 years or so? Hal Murray
@ 2015-06-19 16:28 ` Dave Taht
0 siblings, 0 replies; 5+ messages in thread
From: Dave Taht @ 2015-06-19 16:28 UTC (permalink / raw)
To: Hal Murray; +Cc: bloat
On Thu, Jun 18, 2015 at 12:32 PM, Hal Murray <hmurray@megapathdsl.net> wrote:
>
> I don't think you can measure backbone loss using ping unless you control both ends and ensure that both last-miles are not contributing to the problem.
Well, fractional percentages would be nice to have out of this website.
I have a great title for a paper one day: "Bufferbloat and the Rise of
the Too-Perfect Network".
>
> I think there are several different areas to investigate. The main one is whether your packet gets handed off between two "backbone" IPSs that are currently squabbling about who is going to pay whom how much. The obvious example is Netflix vs Comcast.
The MIT paper was awesome...
But I am thinking that supply (on downlinks) is outstripping demand,
along the first world edge, now... it really is hard to imagine how
much more bandwidth one can consume...
> I don't have any numbers, but I think over the past 5 or 10 years, all the major ISPs have set things up so that all their internal links are overprovisioned. You might notice packet loss when a link goes down and the traffic patterns get rearranged. (I know you can see changes in transit time using NTP.)
>
> I have an old/slow DLS link. I get close to 0% packet loss if my last mile is not busy and lots of loss when it is overloaded.
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
--
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bloat] backbone loss statistics over the past 15 years or so?
2015-06-17 20:34 ` Rick Jones
@ 2015-06-17 22:34 ` Benjamin Cronce
0 siblings, 0 replies; 5+ messages in thread
From: Benjamin Cronce @ 2015-06-17 22:34 UTC (permalink / raw)
To: Rick Jones; +Cc: bloat
[-- Attachment #1: Type: text/plain, Size: 2542 bytes --]
> Now in 2015 I notice that it is at 0% packet loss worldwide. Looks
> > like the big boys found a way to fight any connection speed, and
> > buffer issues that where the cause of what was an ever increasing
> > packet loss issue. My wish is that it would now make it all the way
> > down to the end of the last mile. The issues with packet loss due to
> > buffer bloat that are now at the end of the home and business
> > connections I feel helps lead to the congestion issues we see during
> > the high use periods at night. "
>
> http://www.internettrafficreport.com/faq.htm#measure
>
> > Q: How do you measure "Internet traffic?"
> > A: A test called "ping" is used to measure round-trip travel time
> > along major paths on the Internet. We have several servers in
> > different areas of the globe perform the same ping at the same time.
> > Each test server then compares the current response to past responses
> > from the same test to determine if the response was bad or good on a
> > scale of 0 to 100. The scores from all test servers are averaged
> > together into a single index.
>
> If you drill-down on regions, it will show individual routers. The
> results seem to be particularly binary - a given router will have either
> an index of 100 and a loss percentage of 0, or an index of 0 and a loss
> percentage of 100. Asia seems to have a couple exceptions proving the
rule.
>
> You will probably get a kick out of:
>
> http://www.internettrafficreport.com/faq.htm#packet
Dear lord! Quote: "as long as it is under 5% or so you shouldn't even
notice".
In the long long ago, I've had issues with VoIP having issues with under 1%
loss. Issues as in perceptible differences that were both distracting and
sometimes problematic.
More of the issue is that packetloss is typically associated with
congestion which also means high ping times for most. Even then, 5% loss?!
Until recently, I've had pings running 24/7 against external servers like
Google.com, 8.8.8.8, 8.8.4.4, 4.2.2.2, etc. At some point I let ping run
for a month strait and had 0.0002% loss, two ten-thousandths of a percent,
rounded to nearest. Something like 10 packets out of 2.5mil samples that
were taken every 0.5sec. To my ISP during that same time period I had 0%
loss. At one point I let a ping run against an Amazon AWS server in both
Germany and London. Both showed about 0.01-0.001% loss over nearly a week.
Both are about an 8.5k mile round trip if by a bee-line.
>
> I'm not sure if they are setup to report fractional packet loss
percentages
[-- Attachment #2: Type: text/html, Size: 3310 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bloat] backbone loss statistics over the past 15 years or so?
2015-06-17 19:10 Dave Taht
@ 2015-06-17 20:34 ` Rick Jones
2015-06-17 22:34 ` Benjamin Cronce
0 siblings, 1 reply; 5+ messages in thread
From: Rick Jones @ 2015-06-17 20:34 UTC (permalink / raw)
To: bloat
> Now in 2015 I notice that it is at 0% packet loss worldwide. Looks
> like the big boys found a way to fight any connection speed, and
> buffer issues that where the cause of what was an ever increasing
> packet loss issue. My wish is that it would now make it all the way
> down to the end of the last mile. The issues with packet loss due to
> buffer bloat that are now at the end of the home and business
> connections I feel helps lead to the congestion issues we see during
> the high use periods at night. "
http://www.internettrafficreport.com/faq.htm#measure
> Q: How do you measure "Internet traffic?"
> A: A test called "ping" is used to measure round-trip travel time
> along major paths on the Internet. We have several servers in
> different areas of the globe perform the same ping at the same time.
> Each test server then compares the current response to past responses
> from the same test to determine if the response was bad or good on a
> scale of 0 to 100. The scores from all test servers are averaged
> together into a single index.
If you drill-down on regions, it will show individual routers. The
results seem to be particularly binary - a given router will have either
an index of 100 and a loss percentage of 0, or an index of 0 and a loss
percentage of 100. Asia seems to have a couple exceptions proving the rule.
You will probably get a kick out of:
http://www.internettrafficreport.com/faq.htm#packet
I'm not sure if they are setup to report fractional packet loss percentages
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bloat] backbone loss statistics over the past 15 years or so?
@ 2015-06-17 19:10 Dave Taht
2015-06-17 20:34 ` Rick Jones
0 siblings, 1 reply; 5+ messages in thread
From: Dave Taht @ 2015-06-17 19:10 UTC (permalink / raw)
To: bloat
I am wondering if there is any long term loss statistics across the
internet over a very long interval... for example does
internettrafficreport.com have long term data?
from an anecdote at:
https://vip.asus.com/forum/view.aspx?id=20150608072917905&board_id=11&model=RT-AC68U&page=1&SLanguage=en-us
"When I first started to work on the Internet at a little mom, and pop
ISP when it first opened up in the 1990’s there was and still is a
site called Internet Traffic Report [
http://www.internettrafficreport.com ]. Back then it was showing
anywhere from 4% to 6% packet loss in North America. As the years
rolled on some days it was at or above 10%. If you looked at Asia it
was even worse.
Now in 2015 I notice that it is at 0% packet loss worldwide. Looks
like the big boys found a way to fight any connection speed, and
buffer issues that where the cause of what was an ever increasing
packet loss issue. My wish is that it would now make it all the way
down to the end of the last mile. The issues with packet loss due to
buffer bloat that are now at the end of the home and business
connections I feel helps lead to the congestion issues we see during
the high use periods at night. "
--
Dave Täht
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-06-19 16:28 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-18 19:32 [Bloat] backbone loss statistics over the past 15 years or so? Hal Murray
2015-06-19 16:28 ` Dave Taht
-- strict thread matches above, loose matches on Subject: below --
2015-06-17 19:10 Dave Taht
2015-06-17 20:34 ` Rick Jones
2015-06-17 22:34 ` Benjamin Cronce
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox