North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Sean Donelan
  • Date: Fri Oct 26 12:33:51 2007

On Fri, 26 Oct 2007, Iljitsch van Beijnum wrote:
And generating packets with false address information is more acceptable? I don't buy it.

When a network is congested, someone is going to be upset about any possible response.

Within the limitations the network operator has, using a TCP RST to
cause applications to back-off network use is an interesting "hack" (in the original sense of the word: quick, elaborate and/or "jerry rigged" solution).

Using a TCP RST is probably more "transparent" than using some other clever active queue management technique to drop particular packets from the network. Comcast's publicity problem seems to be that they used a more "visible" technique instead of a harder to detect technique to respond to network congestion.

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

Please re-read my first post about some of the alternatives, and people
griping about all of them.

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)
Sending an ICMP Source quench (i.e. ignored by many IP stacks)
Sending a TCP RST (i.e. most application protocols respond, easy for out-of-band devices)
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)

and of course

Do nothing (i.e. let the applications grab whatever they can, even if that results in incredibly bad performance for many users)

Add more capacity (i.e. what do you do in the mean time, people want something now)

Raise prices (i.e. discourage additional use)

People are going to gripe no matter what.  One week they are griping about
ISPs not doing anything, the next week they are griping about ISPs doing