Re: [tana] FW: New Version Notification for draft-penno-tana-app-practices-recommendation-00

[Reinaldo Penno <[e-mail]>]

Robb,

I had to trim down the email since I'm getting lost on your responses.
Inline...


On 10/29/08 9:27 PM, "Robb Topolski" <[e-mail]> wrote:

> On Wed, Oct 29, 2008 at 3:00 PM, Reinaldo Penno <[e-mail]> wrote:

>>> Users frequently favor transfers over P2P networks because they seem
>>> more efficient and robust than those over client-server.
>> 
 file.
> 
> But this effort isn't about these infringing factors.  If that was the
> target, then we should also look at the client-server practices of
> HTTP direct-download sites and NNTP hosters. Sure, they're there, but
> what's the point?
> 

You said people prefer P2P because they see it as a better technical
advantage. That seemed an important point you were trying to drive, but I
disagree, that's all. I think content (and its availability) plays an
important part and will continue to play for the near future.

Yes, I've seen all the statistics talking about how legal content will
dominate in N [put your preferred number here] years, that is cheap, etc.
But the statistics from piratebay/mininova in one month from the top 100
torrents is dwarfs all other forms of legal video on demand or download.

Mininova last time I checked had 5M (millions) downloads per day and the
number of downloads grows exponentially from 2005-2008 (and continues to
grow).

> 

>> I have, what you mean by that exactly?
> 
> I mean, exactly, that many are told by authoritative sources that P2P
> clients fire up hundreds or thousands of connections.  At best, the
> leading voices fail to mention that most of these connections are idle
> but in the worst examples, they even assert that all of these
> connections actively uploading.  And finally, they reach the
> conclusion that this behavior is intended and designed to skirt the
> effectiveness of congestion control.
> 
> One of these voices you mentioned by name.

I can certainly clarify the behavior of the client in the paper if that's
what your getting to.

> 
> 
>> 
>> Correct. And I point that in this case what matters is not bandwidth but:
>> 
>> * State tables in firewall NATs
>> * TCPCB in case of certain devices.
>> 
>> Do you think this is not clear?
> 
> It's almost an entire change of gears.  Attacking that problem seems
> out of place.  It's really not the problem anyone sought to solve who
> came to the P2PI workshop and as a co-project to the scavenger class
> thing it's really a strange coupling.

Robb, you are mixing the goals of the different documents in the WG charter.
This document is about documenting practices and making recommendations. It
is not about driving solutions.

> 
> 

> 
> But on the other hand, I'm not going to download duplicate data,
> either, so by the end of the download -- whether it took an hour or a
> day, I've still taken nnnn megabytes.   All of that was to point out
> that this wasn't a P2P factor, it was a large-file factor.  The paper
> focused on P2P as a problem because of its bandwidth use.  My argument
> is that P2P doesn't create significantly higher bandwidth use (save a
> statistically tiny amount of overhead).
> 

Sure, you will not duplicate data, but amount of data you consume is
different than bandwidth consumption. They are different units because of
time scale as you point out. With P2P you are going to consume more
bandwidth within a certain time scale.

And you will continue to consume more bandwidth since there are tons of
content available. I guess this needs clarification.


> 
> Maybe this is the crux of a misunderstanding -- If you believe that
> P2P does something fundamentally that skirts the bandwidth usage or
> speed limit imposed by the ISP at the modem, then tell me why or how
> you believe that because it may be the fundamental misunderstanding
> between us.  The facts are that these are just network sockets to the
> software.  There's nothing under the hood going on here.  The upload
> bandwidth consumed would be the same whether the file-sharer was
> sharing using client-server or peer-to-peer.

Robb, think about P2P as a technology + content + availability. Do not be so
hang up on sockets. I agree with you that underneath is all sockets, but If
this was the issue, none of us would be here.

Anyway, I do not believe it perform this magic. But it is a enabling
technology that combined with the amount of content available drives
*average* bandwidth consumption up.

> 
> We have to be able to say why Peer-to-peer as an architecture uses
> more bandwidth than Client-server as a technology would to do the same
> tasks, otherwise we'll be focused on the wrong problem due to an
> assertion that just isn't true.

Sure.

> 
> 
>> 
>>> 
> 
> Please note the weaker emphasis to objection.  I'm not very against
> going down this path somewhere and somehow.  It's a real problem, it's
> just a really different problem than congestion and seems orthogonal
> to the intents and purposes of this group.  :-)
> If you want a lot more comment on it, my observations are that it's
> usually the UDP traffic involved in some distributed database that
> pops the lid on the NAT tables.  Turn these off, clear out the table,
> change the port, and the user usually doesn't need to limit the TCP
> connections any further than normal.

Thanks. The idea is not to solve this issue but document and make
recommendations (if any).

> 
> 

_______________________________________________
tana mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tana