Re: Can P2P applications learn to play fair on networks?

[Mikael Abrahamsson <swmike () swm pp se>]

On Fri, 26 Oct 2007, Sean Donelan wrote:

> If Comcast had used Sandvine's other capabilities to inspect and drop 
> particular packets, would that have been more acceptable?

Yes, definately.

> Dropping random packets (i.e. FIFO queue, RED, not good on multiple-flows)
> Dropping particular packets (i.e. AQM, WRED, etc, difficult for multiple 
> flows)
> Dropping DSCP marked packets first (i.e. scavenger class requires voluntary 
> marking)
> Dropping particular protocols (i.e. ACLs, difficult for dynamic protocols)

Dropping a limited ratio of the packets is acceptable at least to me.

> Sending a TCP RST (i.e. most application protocols respond, easy for 
> out-of-band devices)

... but terminating the connection is not. Spoofing packets is not 
something an ISP should do. Ever. Dropping and/or delaying packets, yes, 
spoofing, no.

> Changing IP headers (i.e. ECN bits, not implemented widely, requires inline 
> device)
> Changing TCP headers (i.e. decrease windowsize, requires inline device)
> Changing access speed (i.e. dropping user down to 64Kbps, crushes every 
> application)
> Charging for overuse (i.e. more than X Gbps data transferred per time period, 
> complaints about extra charges)
> Terminate customers using too much capacity (i.e. move the problem to a 
> different provider)

These are all acceptable, where I think the adjust MSS is bordering on 
intrusion in customer traffic. An ISP should be in the market of 
forwarding packets, not changing them.

--
Mikael Abrahamsson    email: swmike () swm pp se