Lots of information to parse through here.

Have you correlated your results with other embanet users? This is often a good way to isolate (and/or eliminate) components from the problem. If multiple users have similar experiences - even from different geographic areas (with different providers), then you can focus on just the common elements as problems. Alternately, if others do *not* have the problem, you can focus on just the differences.

It looks a lot like bandwidth saturation on their end. The challenge about saying "it's bandwidth saturation on the part of embanet" is that the further you get away from your own network, the more opportunities you have for return routes to impact your data - and you can't see the return route in PingPlotter or any other trace route tool - at least not without having an agent on the remote end of things. Sometimes your provider (the one at hop 2) might have multiple peers and the outbound one works great but the return one (which you can't see) doesn't work nearly as well. This might *look* like an embanet problem (and it very well could be), but in the end it turns out to be an issue with peering closer to home.

The fact that there is a correlation between the close-to-home latency and the final-destination packet loss is a pretty strong indication that your issue starts closer to home rather than at the final destination.

This isn't really much help to you, except to tell you other things you might look for, and to tell you that there may be other things in play here that you can't see.

Your situation is not entirely simple (obviously!), and the quantity of data you've collected and long summaries may be making it more difficult for you to get action. I think the sheer mass and sprawling case you're trying to make might be working against you in some ways.

Based on the data I see here, I can't yet rule out your own provider as a significant contributor to your problem.

I would do the following (not knowing what exactly you've tried and done over the last few months):

* Gather data from other users of the final destination to see if they are experiencing the same.
* Gather data about your provider (DSL Reports, for example) to see if there are any complaints about your provider.
* Start isolating things that you can easily control. If things aren't working well on your home PC / network, take your laptop to a nearby coffee shop and see if it's a problem from there too - or maybe from a friend's house.
* Focus more on the effects of the problem (the inability to connect / use) rather than quite as much disparate data. This depends *a lot* on the provider you're working with, but it's hard to sort through all the data if it's not what they normally deal with.

The amount of packet loss you're seeing is pretty huge for it to be a problem with a pretty widely deployed and used cloud-based application like you're dealing with (I think). It's certainly possible that it's a problem at the far end, but you've really got to work under the assumption it's very close to you first.

Sorry if I've not been much help here.

- Pete