[27671] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Napster and others...

daemon@ATHENA.MIT.EDU (smd@clock.org)
Tue Mar 7 10:53:30 2000

From: smd@clock.org
To: nanog@merit.edu, s_mcgrath@bexair.com
Message-Id: <20000307154657Z945-3570+8@cesium.clock.org>
Date:	Tue, 7 Mar 2000 07:46:53 -0800
Errors-To: owner-nanog-outgoing@merit.edu



| When you have limited bandwidth you need to ensure that it is used for
| what it is purchased for (email access to network based resources etc) 

Napster traffic is principally bulk TCP transfers.  Bulk TCP 
transfers are good for your network -- much better than lots 
of short TCP transfers (web "mice") because they are highly 
sensitive to network congestion.

Moreover, where chronic congestion is a problem (i.e., your access
line is full and dropping packets for long periods of time),
bulk transfers back off much more quickly with a very gentle
RED control law than do web mice or short SMTP sessions etc.

So, having one's supplier apply RED on your access line, and
you applying RED towards the supplier, is a cheap, simple, and
bandwidth-effective way of making sure that Napster traffic
can consume the entire line, but not in any way worsen the
performance of short TCP sessions and the like, which are
not as congestion-sensitive.   

I deliberately do not address intellectual property issues,
nor issues of "I don't want my access line to be 100% used,
even if the napster traffic behaves in a UNIX nice +20 fashion,
because I pay for number of bytes moved per month".

	Sean.


home help back first fref pref prev next nref lref last post