This has been a problem since Ethernet
Reminds me of back in the 80s. We Brits used networking responsibly and designed traffic controls, those pesky Utah people just blasted out regardless. When pointed out that they were not behaving approriately, the answer was "we must be doing it right as we have the major market share so you are wrong".
They no longer have the market share! Unfortunately the arrival of the web and rapid take up resurrected the all but dead TCP/IP to become the main network transport, hence the rise of Cisco.
As for the analysis - you can get packet loss and drop on a point to point, recovery depends on the transport protocol, I spent many hours communicating how networks work to 3Com people. I haven't been involved in such a way for quite a few years now, so the new people are obviously not quite there yet.
The problems are similar to the ones facing us with the advent of remote bridges, then switches, then remote switches. The worst offender on slow routes used to be Microsoft causing broadcast storms at the drop of a hat, which meant slow lines were flooded with meaningless packets whilst real, important data was dropped as buffers overflowed. Long discussions resolved the problem but yet again the personnel have probably changed. Cisco are fairly good at what they do but were not too hot at innovation so the fact that they are spearheading is probably not a good thing.
The answer to it all is in the transport protocol, if there is a limited buffer count that holds until acknowledged, problem solved as everyone important shuts up while the contention dies down. If the "lost" traffic is important then it should be using a better protocol.