What is being missed here, and what smb@clock.org said, was that Napster uses bulk TCP, bulk TCP adapts to available bandwidth, furthmore if the QOS bits are set on the application, the router at the end site where the napster client is running, can classify the packets, since TCP doesn't care where the packets get dropped, it doesn't matter which way the stream is running in bulk. RED or WRED allows the end site router to also ensure fairness among hosts as well. Its really simple. Turning the bits on in Windows might be more difficult. What the other service providers do with respect to TOS doesn't matter here, you can even strip the tos bits at the router after weighting them. Some people might even say that the whole filtering of specific applications is complete red herring by both parties, as the control freaks want to classify "bad" trafffic, and the people with the application that generates this "bad" traffic wants to ensure it gets through. As with CuCeme, real audio, etc, the applications that do this lose. There doesn't seem to be much of a market effect on the control freaks, so those seem to perpetuate themselves. The key issue with IP tos bits is it allows the packets to be filtered by the site that cares to turn on processing of those bits, and puts the burden back on them taken it of the application provider. In message <NDBBIHGIMLHECOLBHAACKEDFCEAA.ck@arch.bellsouth.net>, "Christian Kuhtz" w rites:
I believe there was some discussion about doing that, actually, although I don't know where it went (as I just do system admin stuff, not development stuff). I'll have to inquire as I haven't heard anything about it recently. Of course, the real impact would be pretty limited since I don't know that most peoples' routers really look to that header for QoS. Nevertheless...
Err, excuse me.. if a service provider reclassifies the traffic inside their cloud and rewrite the IP ToS precedence, your wonderful marking gets messed up. It is highly unlikely that the original ToS of each packet will be restored once it leaves the provider's cloud... keep it TCP, keep it predictable and you got a KISS pattern to match.
Cheers, Chris
-- Christian Kuhtz, Sr. Network Architect Architecture, BellSouth.net <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Atlanta, GA "Speaking for myself only."
--- jerry@fc.net Director Network Operations/Network Engineering, Wayport, Inc. 512-481-1542x522 www.wayport.net 1609 Shoal Creek Blvd Suite 301