Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?

Sun Sep 19 14:54:14 UTC 2010

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.  :-)