[admin] Re: Can P2P applications learn to play fair on networks? and Re: Comcast blocking p2p uploads
On Mon, 22 Oct 2007, Randy Bush wrote: > actually, it would be really helpful to the masses uf us who are being > liberal with our delete keys if someone would summarize the two threads, > comcast p2p management and 204/4. 240/4 has been summarized before: Look for email with "MLC Note" in subject. However, in future, MLC emails will contain "[admin]" in the subject. Interestingly, the content for the p2p threads boils down to: a) Original post by Sean Donelan: Allegation that p2p software "does not play well" with the rest of the network users - unlike TCP-based protocols which results in more or less fair bandwidth allocation, p2p software will monopolize upstream or downstream bandwidth unfairly, resulting in attempts by network operators to control such traffic. Followup by Steve Bellovin noting that if p2p software (like bt) uses tcp-based protocols, due to use of multiple tcp streams, fairness is achieved *between* BT clients, while being unfair to the rest of the network. No relevant discussion of this subject has commenced, which is troubling, as it is, without doubt, very important for network operations. b) Discussion started by Adrian Chadd whether p2p software is aware of network topology or congestion - without apparent answer, which leads me to guess that the answer is "no". c) Offtopic whining about filtering liability, MSO pricing, fairness, equality, end-user complaints about MSOs, filesharing of family photos, disk space provided by MSOs for web hosting. Note: if you find yourself to have posted something that was tossed into the category c) - please reconsider your posting habits. As usual, I apologise if I skipped over your post in this summary. -alex
Re: [admin] Re: Can P2P applications learn to play fair on networks? and Re: Comcast blocking p2p uploads
actually, it would be really helpful to the masses uf us who are being liberal with our delete keys if someone would summarize the two threads, comcast p2p management and 204/4. randy
[admin] Re: Can P2P applications learn to play fair on networks? and Re: Comcast blocking p2p uploads
[note that this post also relates to the thread Re: Comcast blocking p2p uploads] While both discussions started out as operational, most of the mail traffic is things that are not very much related to technology or operations. To clarify, things like these are on-topic: * Whether p2p protocols are "well-behaved", and how can we help making them behave. * Filtering "non-behaving" applications, whether these are worms or p2p applications. * Helping p2p authors write protocols that are topology- and congestion-aware These are on-topic, but all arguments for and against have already been made. Unless you have something new and insightful to say, please avoid continuing conversations about these subjects: * ISPs should[n't] have enough capacity to accomodate any application, no matter how well or badly behaved * ISPs should[n't] charge per byte * ISPs should[n't] have bandwidth caps * Legality of blocking and filtering These are clearly off-topic: * End-user comments about their particular MSO/ISP, pricing, etc. * Morality of blocking and filtering As a guideline, if you can expect a presentation at nanog conference about something, it belongs on the list. If you can't, it doesn't. It is a clear distinction. In addition, keep in mind that this is the "network operators" mailing list, *not* the end-user mailing list. Marty Hannigan (MLC member) already made a post on the "Comcast blocking p2p uploads" asking to stick to the operational content (vs, politics and morality of blocking p2p application), but people still continue to make non-technical comments. Accordingly, to increase signal/noise (as applied to network operations) MLC (that's us, the team who moderate this mailing list) won't hesitate to warn posters who ignore the limits set by AUP and guidance set up by MLC. If you want to discuss this moderation request, please do so on nanog-futures. -alex [mlc chair]