Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
JC Dill
jcdill.lists at gmail.com
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. :-)
More information about the NANOG
mailing list