Can P2P applications learn to play fair on networks?

Mailman List Mirror (Read Only)
1

>> So your recommendation is that universities, enterprises and ISPs simply
>> stop offering all Internet service because a few particular application
>> protocols are badly behaved?
>
> They should stop to offer flat-rate ones anyway.

Comcast's management has publically stated anyone who doesn't like the
network management controls on its flat rate service can upgrade to
Comcat's business class service.

Problem solved?

Assuming a "business class" service that's reasonably priced and featured?
Absolutely. I'm not sure I've seen that to be the case, however. Last
time I checked with a local cable company for T1-like service, they wanted
something like $800/mo, which was about $300-$400/mo more than several of
the CLEC's. However, that was awhile ago, and it isn't clear that the
service offerings would be the same.

I don't class cable service as being as reliable as a T1, however. We've
witnessed that the cable network fails shortly after any regional power
outage here, and it has somewhat regular burps in the service anyways.

I'll note that I can get unlimited business-class DSL (2M/512k ADSL) for
about $60/mo (24m), and that was explicitly spelled out to be unlimited-
use as part of the RFP.

By way of comparison, our local residential RR service is now 8M/512k for
about $45/mo (as of just a month or two ago).

I think I'd have to conclude that I'd certainly see a premium above and
beyond the cost of a residential plan to be reasonable, but I don't expect
it to be many multiples of the resi service price, given that DSL plans
will promise the bandwidth at just a slightly higher cost.

Or would some P2P folks complain about having to pay more money?

Of course they will.

> Or do general per-user ratelimiting that is protocol/application agnostic.

As I mentioned previously about the issues involving additional in-line
devices and so on in networks, imposing per user network management and
billing is a much more complicated task.

If only a few protocol/applications are causing a problem, why do you need
an overly complex response? Why not target the few things that are
causing problems?

Well, because when you promise someone an Internet connection, they usually
expect it to work. Is it reasonable for Comcast to unilaterally decide that
my P2P filesharing of my family photos and video clips is bad?

>> A better idea might be for the application protocol designers to improve
>> those particular applications.
>
> Good luck with that.

It took a while, but it worked with the UDP audio/video protocol folks who
used to stress networks. Eventually those protocol designers learned to
control their applications and make them play nicely on the network.

:slight_smile:

... JG

2

So what about the other 490 people on the node expecting it to work? Do you tell them sorry, but 10 of your neighbors are using badly behaved applications so everything you are trying to use it for is having problems. Maybe Comcast should just tell the other 490 neighbors the 10 names and addresses of poorly behaved P2P users and let the neighhood
solve the problem.

Is it reasonable for your filesharing of your family photos and video clips to cause problems for all the other users of the network? Is that fair or just greedy?

3

Sean Donelan wrote:

So what about the other 490 people on the node expecting it to work? Do you tell them sorry, but 10 of your neighbors are using badly behaved applications so everything you are trying to use it for is having problems.

Maybe Comcast should fix their broken network architecture if 10 users sending their own data using TCP (or something else with TCP-like congestion control) can break the 490 other people on a node.

Or get on their vendor to fix it, if they can't.

If that means traffic shaping at the CPE or very near the customer, then perhaps that's what it means, but installing a 3rd-party box that sniffs away and then sends forged RSTs in order to live up to its advertised claims is clearly at the "wrong" end of the spectrum of possible solutions.

> Maybe Comcast should just tell the other 490 neighbors the 10
> names and addresses of poorly behaved P2P users and let the neighhood
> solve the problem.

Maybe Comcast's behavior will cause all 500 neighbors to find an ISP that isn't broken. We can only hope.

Is it reasonable for your filesharing of your family photos and video clips to cause problems for all the other users of the network? Is that fair or just greedy?

It isn't fair or greedy, it is a bug that it does so. Greedy would be if you were using a non-congestion-controlled protocol like most naive RTP-based VoIP apps do.

Matthew Kaufman
matthew@eeph.com

4

Joe Greco wrote:

Well, because when you promise someone an Internet connection, they usually
expect it to work. Is it reasonable for Comcast to unilaterally decide that
my P2P filesharing of my family photos and video clips is bad?
  
Comcast is currently providing 1GB of web hosting space per e-mail address associated with each account; one could argue that's a significantly more efficient method of distributing that type of content and it still doesn't cost you anything extra.

The use case you describe isn't the problem though, it's the gluttonous "kid in the candy store" reaction that people tend to have when they're presented with all of the content available via P2P networks. This type of behavior has been around forever, be it in people tagging up thousands of Usenet articles, or setting themselves up on several DCC queues on IRC. Certainly innovations like newsreaders capable of using NZB files have made retrieval of content easier on Usenet, but nothing has lowered the barrier to content access more than P2P software. It's to the point now where people will download anything and everything via P2P whether they want it or not. For the AP article they were attempting to seed the Project Gutenburg version of the King James Bible -- a work that is readily available with a 3 second Google search and a clicked hyperlink straight to the eBook. Even with that being the case, the folks doing the testing still saw connection attempts against against their machine to retrieve the content. Must of this is due to a disturbing trend in users subscribing to RSS feeds for new torrent content, with clients automatically joining in the distribution of any new content presented to the tracker regardless of what it is. Again, flat-rate pricing does little to discourage this type of behavior.

-Eric

5

Matthew Kaufman wrote:

Maybe Comcast should fix their broken network architecture if 10 users sending their own data using TCP (or something else with TCP-like congestion control) can break the 490 other people on a node.

That's somewhat like saying you should fix your debt problem by acquiring more money. Clearly there are things that need to be improved in broadband networks as a whole, but the path to that solution isn't nearly as simple as you make it sound.

Or get on their vendor to fix it, if they can't.

They have. Enter DOCSIS 3.0. The problem is that the benefits of DOCSIS 3.0 will only come after they've allocated more frequency space, upgraded their CMTS hardware, upgraded their HFC node hardware where necessary, and replaced subscriber modems with DOCSIS 3.0 capable versions. On an optimistic timeline that's at least 18-24 months before things are going to be better; the problem is things are broken _today_.

If that means traffic shaping at the CPE or very near the customer, then perhaps that's what it means, but installing a 3rd-party box that sniffs away and then sends forged RSTs in order to live up to its advertised claims is clearly at the "wrong" end of the spectrum of possible solutions.

On a philosophical level I would agree with you, but we also live in a world of compromise. Sure, Comcast could drop their upstream sync rate to 64kbps, but why should they punish everyone on the node for the actions of a few? From the perspective of practical network engineering, as long as impact can be contained to just seeding activities from P2P applications I don't think injected resets are as evil as people make them out to be. You don't see people getting up in arms about spoofed TCP ACKs that satellite internet providers use to overcome high latency effects on TCP transfer rates. In both cases the ISP is generating traffic on your behalf, the only difference is the outcome. In Comcast's case I believe for their solutions the net effect is the same; by limiting the number of seeding connections they are essentially rate limiting P2P traffic. It just happens that reset inject is by far the easiest option to implement.

Maybe Comcast's behavior will cause all 500 neighbors to find an ISP that isn't broken. We can only hope.

Broken is a relative term. If Comcast's behavior causes their heavy P2P users to find another ISP then those who remain will not have broken service. For $40/mo you can't expect the service to be all things to all people, and given the shared nature of the service I find little moral disagreement with a utilitarian approach to network management.

-Eric

6

Could someone who knows DOCSIS 3.0 (perhaps these are general DOCSIS questions) enlighten me (and others?) by responding to a few things I have been thinking about.

Let's say cable provider is worried about aggregate upstream capacity for each HFC node that might have a few hundred users. Do the modems support schemes such as "everybody is guaranteed 128 kilobit/s, if there is anything to spare, people can use it but it's marked differently in IP PRECEDENCE and treated accordingly to the HFC node", and then carry it into the IP aggregation layer, where packets could also be treated differently depending on IP PREC.

This is in my mind a much better scheme (guarantee subscribers a certain percentage of their total upstream capacity, mark their packets differently if they burst above this), as this is general and not protocol specific. It could of course also differentiate on packet sizes and a lot of other factors. Bad part is that it gives the user an incentive to "hack" their CPE to allow them to send higher speed with high priority traffic, thus hurting their neighbors.

7

With PCMM (PacketCable Multimedia,
http://www.cedmagazine.com/out-of-the-lab-into-the-wild.aspx) support it's
possible to dynamically adjust service flows, as has been done with
Comcast's "Powerboost". There also appears to be support for flow
prioritization.

Regards,

Frank

8

Yes, as a part of the DOCSIS specification (waiting for D3.0 not required);
however, implementations vary on the CMTS end of the equation though.
Having this capability ubiquitously on the CMTS equipment simplifies the
problem space greatly (plus removes that hacked CPE risk).

-ron