That's the problem though... this is more an issue on your ISP's side or their partners and not SE's--as clearly evidenced in your trace. If your latency stays in check you can actually manage in spite of a good bit of packet loss--especially if your entire route stays around 100 or less (under 1/8 a second). Now, if you consistently break the 300ms mark and are having 1/3 second or more lag, then you will surely feel the crunch when losses start creeping up.
A 4% loss at Ormuco's side is nearly negligible if you have decent latency--like if your latency is staying under 100 for the bulk of your route, which it clearly is not. I played for a while with 7% measured losses when my latencies were only going just over 100 at one hop---the rest of the route was staying under 80ms, even at SE's end. Things still ran pretty smooth in spite of the packet loss.
Again.. the bulk of the problems are rooted in segments managed by either your ISP or their partners. They are the ones with the responsibility and the means to remedy the situation--not SE. The ISP's need to be analyzing the traffic to see what is going on and adjust the routes/policies to rebalance the flow. The only connection to SE on this matter is they have recently become a high volume endpoint that has caught the ISP's unaware. This kind of thing happens anytime there is a major shift in the flow that results in overloading the routes. Barring it being a major chokedown at the endpoint itself, the ISP's have to take action to reign in the congestion. SE is NOT responsible for problems with your internet service because, well, they aren't the Internet Service Provider.... that falls to your ISP and their partners to address.
Not saying SE and/or Ormuco shouldn't look into the intermittent losses we've been seeing in their last 3 hops when it is within the scope of SE's service and/or network, but the bigger problems exist before you even get to them. If Ormuco and SE had a near perfect 30ms, no packet loss service at the end--you would still be suffering long delays and packet loss along your path with nearly 1/4 packets lost at level3, compounded by latency spikes up to 1/3 a second or more at various points along your way to Montreal. This can cause out of order transmission (calling for a high retransmit rate) or otherwise trigger slow-start, and your rubberbanding issue would still persist.
Since the vast majority of the instability issues reside on our ISP's and their partners segments, they are the ones that really need to be pressured into addressing the issue. SE is not their customer... so they basically can just as well ignore them if they want. We however are the ISP's paying customers, and they do need to listen to us.