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

Hello Robb,

Thanks for the comments. Inline..

On 10/28/08 4:46 PM, "Robb Topolski" <robb@funchords.com> wrote:

> With GREAT respect to Reinaldo, who did the infinitely harder job of
> creating a document than it takes to critique one -- and please
> understand that my critique is on the document and the process, not on
> the persons...
> 
> I feel like we're back to square one.
> 
> From the first paragraph, the paper draws attention to P2P that is
> undeserved. It attributes to P2P clients behaviors and motives that
> are generally untrue and makes conclusions that do not logically
> follow even if they were. The very motivation for using P2P over other
> methods isn't especially good.
> 
> Users frequently favor transfers over P2P networks because they seem
> more efficient and robust than those over client-server.

Do you really think the average user goes by these beliefs? I would think
users (as in the the majority of people that are not power users) do not
care about the technology. The biggest drive of P2P is that the client is
easy to configure (click and forget) and you have access to tons of
extremely appealing content.

And no, I'm not talking about Ubuntu's distribution, which compared the
traffic generated by 'Iron Man' torrent is a drop in the ocean.

If users had access to the same content (and with the same price) in another
technology with ease of configuration they would go for it.

P2P is that
> it doesn't require or burden a central server yet remains light enough
> to be a background operation on user machines.  P2P transfers
> generally avoid hammering traffic through a congested route when other
> routes exist.  For some of these reasons, given sufficient
> availability, a P2P transfer often results in faster background
> acquisition of the desired data.
> 
> PEER-TO-PEER QUALITIES VS. CLIENT-SERVER QUALITIES
> ... a lot of the paper assigns to P2P those things that are just as
> true for Client-Server

True. At some point I say that multiple connections are an old issue that
were amplified by P2P. I can make this issue clearer

> 
> PEER-TO-PEER CONSEQUENCES VS. LARGE MULTIMEDIA FILES
> ... a lot of the called-out effects listed here are the effects of the
> type of data being moved, not how it is being moved

Humm...see below

> 
> For example The goal of widely popular client-server protocols is also
> to provide the requested data quickly, yet the paper assigns this
> feature to P2P.  To accomplish this goal, the paper says that P2P
> turns to opening multiple connections.  But the multiple connections
> just aren't used in the way that most people think!  Fire up a client
> and see for yourself!

I have, what you mean by that exactly?

> 
> In Gnutella and Emule, the non-transfering clients don't stay
> connected after requesting a place in queue except for a few
> coordination connections to keep the searches and peer-assisted
> connections working.  BitTorrent clients probably only stay connected
> because it's fewer packets than closing and reopening connections to
> keep the rest of the swarm updated as to newly available pieces and to
> send choke/unchoke interested/uninterested flags.  But in all cases a
> P2P client is only sending significant data (the file transfer) over a
> small handful of connections at any one time.

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?

> 
> The "using more bandwidth" effect has nothing to do with the P2P
> architecture nor the overhead of the P2P network.  It has to do with
> the fact that multimedia files are large files.  If P2P were to
> suddenly be removed as a choice, then their client-server replacements
> would use a large amount of bandwidth on the net and spread that use
> more throughout the day

This part I disagree. You are assuming everything has the same availability
and same constraints. With P2P you can download 10Kbps from 10 people and
get 100kbps. Let's also assume that the download constrain is on the side of
the uploader.

In a pure client to server you would be downloading only 10kbps.

Would you agree?

> 
> Using upload bandwidth is a factor for all file-sharing, regardless of
> architecture.  Most ISPs disallow public HTTP and FTP servers, so it's
> not so much a function that consuming upload bandwidth is a P2P thing
> than it is a file-sharing thing.  It would save upload bandwidth if
> everyone took advantage of central servers for their desired
> downloads, but there are drawbacks there as well concerning the
> battles of costs, disk space quotas, and terrible overloading when
> popular content is released.

I tend to agree, that's why P2P allows more bandwidth to be consumed,
because the constraint is on the uploader.

> 
> P2P applications do not use more download bandwidth than their non-P2P
> counterparts.  P2P clients do not download a lot of duplicate data.
> Again, download bandwidth consumption is the market taste changing to
> larger files.
> 
> PLEASE READ THIS ESPECIALLY
> 
>> The advantages of P2P applications come from the fact that they open
>> multiple TCP connection to different peers. On the other hand, this
>> is also their major drawback.
> 
> There has been no evidence shown that there is a "major drawback."

For whom? Clients, equipment vendors, ISPs? Client probably not, ISPs we
have been seen major problems.

Should I say the drabwback from somebody's point of view?

If
> you reduce the number of uploading flows from 10 @ 10% of the user's
> upload allocation to 2 @ 50% of the user's upload allocation, you have
> solved nothing and you have somewhat reduced the uploading node's
> beneficial ability to find uncongested paths.
> 
> The whole "multiflows means that congestion signals are less
> effective" argument forgets that these users are behind a
> flow-uncontrolled modem which, no matter what, is going to keep speeds
> from growing beyond a certain relatively tiny point and will
> constantly be trimming the sails of its own heavier flows to allow its
> smaller ones to grow in a never-ending struggle to reach equilibrium
> locally.  This means that any fractional benefit from multiple streams
> across X point in the Internet is quite temporary, as the knocked-down
> TCP stream from a particular host that is growing again is going to
> soon cause the others from that host to get knocked down as they
> eventually try for equilibrium at a subscribers first bottleneck --
> their own modem.

Do you have references to this claim? I would like to if possible cite such
studies on the next revision.

> 
> This long-repeated complaint that P2P is gaining some kind of benefit
> here is completely unsupported.  When the Comcast affair started,
> their base subscription was 6 Mbps/384 Kbps.  Comcast felt that its
> upload was being strained so it used Sandvine to attack P2P in the
> upload direction.  Sure, like anything else P2P apps can be
> misconfigured to open hundreds of connections, but most won't reach
> 100 on one download and doing so would require either massive
> misconfiguration or a very large upload pipe.  On my Comcast account,
> I could run 1-2 simultaneous torrents with ~50-70 connections each and
> 3 or so upload slots (actively uploading connection) each.  That's not
> 100s of connections in simultaneously use for the purpose of cheating
> congestion control.

Agree. But it depends on the number of torrents you share and if you are a
seeder (or a seed box) or not.

> 
> The problem with "making use of multiple TCP connections" as some kind
> of congestion-causing problem is that neither BitTorrent, Gnutella, or
> ED2K -- the more popular P2P protocols -- ever perform uploads over
> more than a small handful of TCP connections!  Most BitTorrent clients
> do open dozens of connections, but they only upload over 3-4 per
> transfer (on the 6/384 connection -- more as the pipes grow).  Both
> ED2K and Gnutella use queuing systems that allow only 3-4 uploads.
> 
> (secondly and much more minor) -- When did middleboxes become a
> consideration?  As far as end-host communications that cross some
> private gateway, sure.  But with respect to network operators,
> middlebox considerations ought to be off the table.  There is nothing
> in the role of access or transit provider that requires one,

I think this does not reflect reality. Firewall and NATs are widespread
today in ISPs.  Firewalls are needed for security, securing the ISPs
infrastructure, their customers, and vice-versa.

NAT are needed due to IP address depletion. I suggest you look at BEHAVE and
check the discussion on v4v6 coexistence and see the many types of NATs
today that exist in the network. We could argue what should happen in a
perfect world vs. what actually is deployed.

 and most
> of the middleboxes we've seen have been attempts to do something
> outside of their scope.
> 
> IN CONCLUSION
> 
> My objection is the poor engineering practice and heavy expenditure of
> effort in solving a problem statement with no evidence of the size or
> confirmation of the correctness of the problem.  We're focused on a
> pre-selected solution that has nothing in common with the declared
> problem.  The problem described is incorrect as P2P apps can be
> observed and don't behave as described.  Plus the touted advantage
> would not last more than a second or two before the local modem forces
> all of the "advantaged" streams back.
> 
> If we're going to focus on flows and flow fairness, we're just wasting
> everyone's time. Go ahead, it's yours to waste -- I really don't care
> from a P2P technology perspective because -- just thinking through it
> -- it's gain is not realized by the multiple flows!  These apps will
> work equally well by opening and closing the socket between sends.

This document is not about solving the flow fairness problem. People have
quite different views on this. See Briscoe's papers on this.

It is about documenting practices, effects and (if possible)
recommendations.

> 
> A scavenger class for whomever and whatever wants to willfully use it
> is an interesting thing.  Why not?  Let's do it.  It seems like an
> inexpensive and useful background class for delay-tolerant traffic
> that could advantage everyone across multiple areas. Win-win-win.
>

Sure.

> But the paper offered is a problem-solving paper.  It should be on a
> solid basis.  P2P apps don't behave as described in that paper.
> 
> 
> 
> Respectfully,
> 
> Robb Topolski
> 
> 
> 
> --
> Robb Topolski (robb@funchords.com)
> Hillsboro, Oregon USA
> http://www.funchords.com/

_______________________________________________
tana mailing list
tana@ietf.org
https://www.ietf.org/mailman/listinfo/tana