North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Napster and others...
- From: Jeremy Porter
- Date: Wed Mar 08 02:36:03 2000
What is being missed here, and what firstname.lastname@example.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
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.email@example.com>, "Christian Kuhtz" w
>> 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.
>Christian Kuhtz, Sr. Network Architect Architecture, BellSouth.net
><firstname.lastname@example.org> -wk, <email@example.com> -hm Atlanta, GA
> "Speaking for myself only."
Director Network Operations/Network Engineering, Wayport, Inc.
1609 Shoal Creek Blvd Suite 301