| What would be your suggestions on making Napster a more network | friendly app? 1. RFC 2001 compliance. Keep it TCP. 2. Although RFC 1349 is supposedly dead and the TOS octet in the RFC 791 scheme is dead too[*], it is at least good politics to set a low TOS value on the bulk transfer traffic. (If not on all traffic). Thus, routers configured to do TOS-based fancy queueing will DTRT and fewer people will accuse Napster of being a resource pig. 3. "If we aren't network friendly, please let us know what will make us more network friendly" is a great attitude to demonstrate. Hopefully this will be appreciated by actual operators (at least the ones who don't pay per-packet/per-byte charges). Sean. [*] RFC 2474/RFC 2475 but don't hold your breath -:) Who implements this could be a NANOG topic. -:) -:)
On Tue, Mar 07, 2000 at 09:45:08AM -0800, smd@clock.org wrote:
| What would be your suggestions on making Napster a more network | friendly app?
1. RFC 2001 compliance. Keep it TCP.
Agreed - I don't know of anything we would want to do that would break that stuff.
2. Although RFC 1349 is supposedly dead and the TOS octet in the RFC 791 scheme is dead too[*], it is at least good politics to set a low TOS value on the bulk transfer traffic. (If not on all traffic). Thus, routers configured to do TOS-based fancy queueing will DTRT and fewer people will accuse Napster of being a resource pig.
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...
3. "If we aren't network friendly, please let us know what will make us more network friendly" is a great attitude to demonstrate. Hopefully this will be appreciated by actual operators (at least the ones who don't pay per-packet/per-byte charges).
Yeah, definately we aren't trying to make peoples' lives/budgets/latencies harder than they need to be. The trick is in figuring out how much headache is the nature of the beast, how much we can help alleviate, and what the realistic compromise is. Of course, I can only make suggestions to management, but I know that everyone here is very aware of the real life issues for the NANOG type community, and also very interested in doing what can reasonably be done.
Sean.
[*] RFC 2474/RFC 2475 but don't hold your breath -:) Who implements this could be a NANOG topic. -:) -:)
-- Michael Ridley <michael@napster.com>
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."
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
Sean wrote:
2. Although RFC 1349 is supposedly dead and the TOS octet in the RFC 791 scheme is dead too[*], it is at least good politics to set a low TOS value on the bulk transfer traffic. (If not on all
Michael wrote: traffic).
Thus, routers configured to do TOS-based fancy queueing will DTRT and fewer people will accuse Napster of being a resource pig.
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...
I think while the technology is not anywhere near perfect (hence the deprecation in most environments of ToS), if you label your traffic as bulk, then at least those who are interested can have the opportunity to prioritise based on ToS. Most will not do this, but you will gain the respect (to whatever degree) of those that do, by acknowledging that you are concerned about the resources of others. Think of it more as a politcial rather than operational acknowledgement. Peter
Any operator trying to control which applications are used on their networks has either never learned, or already forgotten, the lesson of "fsp, NASA, and OZ." Precis: they (developers, users) can modify the application to use spread-spectrum style port numbers that constantly change throughout the life of a session, which makes it effectively impossible to filter using existing technology. Sean Doran has it right: be glad this is bulk TCP (fsp was UDP based), and turn on RED. Erik <fair@clock.org>
Well said Erik However this is what leads many organizations to restrict/remove internet access from whole regions of the company to solve the bandwith utilization issue. So we are back to needing effective ToS/QoS methods to balance the quality of life issues with the bottom line requirements of organizations Keeping it TCP with a well known port is a good first step because then with a custom queue you can route it with a low priority, IF the link is not busy it goes out fast this is how we handle web traffic. Sure it slows down from time to time but it ALWAYS works rather than the 'ACL the Napster servers' approach which is currently in effect. and right now Napster NEVER works. "Erik E. Fair" wrote:
Any operator trying to control which applications are used on their networks has either never learned, or already forgotten, the lesson of "fsp, NASA, and OZ."
Precis: they (developers, users) can modify the application to use spread-spectrum style port numbers that constantly change throughout the life of a session, which makes it effectively impossible to filter using existing technology.
Sean Doran has it right: be glad this is bulk TCP (fsp was UDP based), and turn on RED.
Erik <fair@clock.org>
participants (7)
-
Christian Kuhtz -
Erik E. Fair -
Jeremy Porter -
Michael Ridley -
Peter Galbavy -
Scott McGrath -
smd＠clock.org