Router with IP 152.179.50.62 continues to suffer serious packet loss during peak hours

[Thunker1]

That IP is registered to Verizon as a business class router.  I have reported this problem well over a month ago.

Did some research and this is a known issue.  Here are just a few of the dozens of posts about it.

http://businessforums.verizon.net/t5/FiOS-Internet/google-youtube-slow-over-fios-definitely-verizon-...

http://www.google.com/support/forum/p/youtube/thread?tid=7049aa07dcbf8f9d&hl=en&start=40

http://www.dslreports.com/forum/r25529076-Northeast-Gmail-Google-Slow-in-Washington-DC-area

I find it hard to believe that Verizon has let such a serious problem continue as it has for such an extended period of time.  

I would like to know if Verizon plans to address the issue and an approximate timeframe for a fix?

I find it to be an unaccetable level of service that will be cause for cancel of all services including phone and tv as well as internet at the next contract renewal if not resolved by then.  I'm even starting to have second thoughts about keeping your stock in my portfolio as such poor customer treatment can't bode well for future financial performance.

Thanks,

Nick

[smith6612]

The google-gw.customer.alter.net hops (they have several IPs, basically wherever they peer with Google's network) have been problematic ever since YouTube transferred ownership to YouTube, and for that matter, YouTube enabling higher quality videos of longer length and enabling larger file sizes. Since then, there's periods where the Google sites are simply unbearably slow, despite how simplistic many of their sites are in nature. It is unacceptable, considering it is Verizon routers at fault according to Trace Routes, for this problem to be sticking around for this long. I don't know if it is an issue with Google and Verizon's Peering Agreement, but it should be sorted out soon. Before, many of the issues I've had with Google's network were growing pains that tended to clear up within a week (way back when they first enabled YouTube HD, for example; not enough capacity which was shortly solved). Now it's been alter.net/MCI/Verizon Business hops causing the issues.

Of course, if Traceroute packets are programmed to be set to lowest priority by the router, that's one thing, but loss and/or latency should not carry over to the Google network. I suppose we need an official reading from Verizon.

[Thunker1]

Thanks fpr the response and verification Smith6612. I too would like an official comment. I intend to continue posting on this topic until I do get a response. I'm really suprised a company like Verizon appears to either ignore this issue or think it is acceptable. They certainly have the resources to addess it if they chose to do so.

Here is a sample packet loss reading on this Router today at 06-12-2011 at 7:10 PM.

Pinging 152.179.50.62 with 32 bytes of data:

Reply from 152.179.50.62: bytes=32 time=51ms TTL=58
Reply from 152.179.50.62: bytes=32 time=47ms TTL=58
Reply from 152.179.50.62: bytes=32 time=53ms TTL=58
Reply from 152.179.50.62: bytes=32 time=56ms TTL=58
Reply from 152.179.50.62: bytes=32 time=57ms TTL=58
Reply from 152.179.50.62: bytes=32 time=56ms TTL=58
Reply from 152.179.50.62: bytes=32 time=57ms TTL=58
Request timed out.
Reply from 152.179.50.62: bytes=32 time=52ms TTL=58
Reply from 152.179.50.62: bytes=32 time=50ms TTL=58
Reply from 152.179.50.62: bytes=32 time=54ms TTL=58
Reply from 152.179.50.62: bytes=32 time=45ms TTL=58
Reply from 152.179.50.62: bytes=32 time=49ms TTL=58
Request timed out.
Reply from 152.179.50.62: bytes=32 time=51ms TTL=58
Reply from 152.179.50.62: bytes=32 time=50ms TTL=58
Request timed out.
Reply from 152.179.50.62: bytes=32 time=47ms TTL=58
Request timed out.
Reply from 152.179.50.62: bytes=32 time=80ms TTL=58
Reply from 152.179.50.62: bytes=32 time=46ms TTL=58
Reply from 152.179.50.62: bytes=32 time=68ms TTL=58
Request timed out.
Reply from 152.179.50.62: bytes=32 time=52ms TTL=58
Reply from 152.179.50.62: bytes=32 time=42ms TTL=58
Reply from 152.179.50.62: bytes=32 time=53ms TTL=58
Reply from 152.179.50.62: bytes=32 time=48ms TTL=58
Reply from 152.179.50.62: bytes=32 time=47ms TTL=58
Reply from 152.179.50.62: bytes=32 time=50ms TTL=58
Request timed out.
Reply from 152.179.50.62: bytes=32 time=49ms TTL=58
Request timed out.


Ping statistics for 152.179.50.62:
    Packets: Sent = 32, Received = 25, Lost = 7 (21% loss),
Approximate round trip times in milli-seconds:
    Minimum = 42ms, Maximum = 80ms, Average = 52ms

[Thunker1]

Here is another for Friday, June 17 2011 11:10PM EST.

Pinging 152.179.50.106 with 32 bytes of data:


Reply from 152.179.50.106: bytes=32 time=44ms TTL=58
Reply from 152.179.50.106: bytes=32 time=48ms TTL=58
Reply from 152.179.50.106: bytes=32 time=68ms TTL=58
Request timed out.
Reply from 152.179.50.106: bytes=32 time=45ms TTL=58
Reply from 152.179.50.106: bytes=32 time=47ms TTL=58
Reply from 152.179.50.106: bytes=32 time=47ms TTL=58
Reply from 152.179.50.106: bytes=32 time=47ms TTL=58
Request timed out.
Reply from 152.179.50.106: bytes=32 time=45ms TTL=58
Request timed out.
Reply from 152.179.50.106: bytes=32 time=46ms TTL=58
Reply from 152.179.50.106: bytes=32 time=45ms TTL=58
Reply from 152.179.50.106: bytes=32 time=45ms TTL=58
Reply from 152.179.50.106: bytes=32 time=47ms TTL=58
Reply from 152.179.50.106: bytes=32 time=50ms TTL=58
Reply from 152.179.50.106: bytes=32 time=47ms TTL=58
Request timed out.
Request timed out.
Reply from 152.179.50.106: bytes=32 time=46ms TTL=58
Request timed out.
Request timed out.
Reply from 152.179.50.106: bytes=32 time=48ms TTL=58
Reply from 152.179.50.106: bytes=32 time=86ms TTL=58
Reply from 152.179.50.106: bytes=32 time=47ms TTL=58
Reply from 152.179.50.106: bytes=32 time=46ms TTL=58
Reply from 152.179.50.106: bytes=32 time=46ms TTL=58
Reply from 152.179.50.106: bytes=32 time=46ms TTL=58
Reply from 152.179.50.106: bytes=32 time=46ms TTL=58


Ping statistics for 152.179.50.106:
    Packets: Sent = 29, Received = 22, Lost = 7 (24% loss),
Approximate round trip times in milli-seconds:
    Minimum = 44ms, Maximum = 86ms, Average = 49ms
Control-C

[Thunker1]

More fun packet loss on Father's Day from the "network ahead"

Reply from 152.179.50.106: bytes=32 time=42ms TTL=58
Reply from 152.179.50.106: bytes=32 time=47ms TTL=58
Request timed out.
Reply from 152.179.50.106: bytes=32 time=46ms TTL=58
Request timed out.
Request timed out.
Reply from 152.179.50.106: bytes=32 time=46ms TTL=58
Request timed out.
Reply from 152.179.50.106: bytes=32 time=46ms TTL=58
Request timed out.
Reply from 152.179.50.106: bytes=32 time=58ms TTL=58
Reply from 152.179.50.106: bytes=32 time=45ms TTL=58
Request timed out.
Reply from 152.179.50.106: bytes=32 time=46ms TTL=58
Request timed out.
Request timed out.
Reply from 152.179.50.106: bytes=32 time=46ms TTL=58
Reply from 152.179.50.106: bytes=32 time=49ms TTL=58
Request timed out.
Reply from 152.179.50.106: bytes=32 time=46ms TTL=58
Request timed out.
Reply from 152.179.50.106: bytes=32 time=49ms TTL=58
Reply from 152.179.50.106: bytes=32 time=46ms TTL=58
Reply from 152.179.50.106: bytes=32 time=46ms TTL=58
Request timed out.
Reply from 152.179.50.106: bytes=32 time=49ms TTL=58
Reply from 152.179.50.106: bytes=32 time=46ms TTL=58
Reply from 152.179.50.106: bytes=32 time=45ms TTL=58
Reply from 152.179.50.106: bytes=32 time=43ms TTL=58
Request timed out.
Reply from 152.179.50.106: bytes=32 time=49ms TTL=58


Ping statistics for 152.179.50.106:
    Packets: Sent = 35, Received = 22, Lost = 13 (37% loss),
Approximate round trip times in milli-seconds:
    Minimum = 42ms, Maximum = 78ms, Average = 48ms
Control-C

[bbeesley2]

The other threads seem to be showing ICMP deprioritzation, not packet loss

pinging only one host makes it pretty tough to see if there is actual loss or just deprioritization which more common

can you provide a traceroute that shows the packet loss as well to confirm?