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

[Reinaldo Penno <[e-mail]>]

Thanks for the comments Robb. I will go over them and get back to you
possibly in time for a new revision of the document.


On 10/28/08 4:46 PM, "Robb Topolski" <[e-mail]> 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.  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
> 
> 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
> 
> 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!
> 
> 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.
> 
> 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
> 
> 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.
> 
> 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."  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.
> 
> 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.
> 
> 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, 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.
> 
> 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.
> 
> 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 ([e-mail])
> Hillsboro, Oregon USA
> http://www.funchords.com/

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