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

["Robb Topolski" <[e-mail]>]

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