Bill Stewart wrote:
A very common design is that businesses can get diffserv (or the MPLS equivalents) on end-to-end services provided by ISP X, but the peering arrangements with ISP Y don't pass diffserv bits, or pass it but ignore it, or use different sets of bits. It's very frustrating to me as a consumer, because what I'd really like would be for the main bottleneck point (my downstream connection at home) to either respect the diffserv bits set by the senders, or else to give UDP higher priority and TCP lower priority, and put Bittorrent and its ilk in a scavenger class, so VOIP and real-time video work regardless of my web activity and the web gets more priority than BitTorrent.
I can understand you wanting this done on YOUR bottleneck, in the connection between the ISP and you. And you want it done to YOUR specifications. That is entirely reasonable. But would you want the ISP doing it elsewhere in the network, and done to their priorities, not yours? (A "one size fits all" congestion prioritization solution.) Further, would you be happy with an ISP that HAS a bottleneck elsewhere in their network - not just in the last mile to your door? IMHO it's stupid for an ISP to intentionally design for and allow bottlenecks to exist within their network. The bottleneck to the end user is currently unavoidable, and users with bandwidth intensive uses might prefer some prioritization (to their own specifications) on that part of the link. Bottlenecks within the ISP network and between ISPs should be avoidable, and should be avoided. Any ISP that fails to mitigate those bottlenecks will quickly find customers streaming to another ISP that will advertise "no network congestion here, no traffic shaping that slows down traffic that might be important to YOU" etc. jc PS. Bill, if you aren't using Sonic, give their Fusion service a look. It's better than Kadu. :-)