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

[Steve <[e-mail]>]

Just my two cents.

On Tue, Oct 28, 2008 at 7: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.

imho, I agree that the paper exaggerates a bit on some of the peer to
peer stuff.  That's easy enough to fix in a later revision, though.

> 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.

Unfortunately, they create many, many more congested routes by doing so.

> For some of these reasons, given sufficient
> availability, a P2P transfer often results in faster background
> acquisition of the desired data.

Less distance to travel + more options to better adjust to network
topology = win.

> 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

Could you explain this a little further?  I can see how p2p would keep
connections open / in use for longer than the "average", "traditional"
client server app.  I guess I see "client/server" as defined by
transactions and "p2p" as defined by time.  A file being transferred
over a p2p link neither has a beginning nor an end; the transfer
starts when you switch the client on, and stops when you tell the
client to stop seeding the file.

> 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!

Multiple connections to a server rate-limited by the overwhelming
number of clients connected to it means that these multiple
connections might not consume your entire link, as opposed to p2p
stuff which, in all likelihood, will.

> 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

I would argue that even for small files this would be the case.  Say,
for example, Windows Update started using something like BT to
distribute patches; you'd have a LOT of small files being transferred
fairly often, which would likely still kill available bandwidth.
Actually, it might even hose a connection worse than many large media
files, since you have a larger overhead / useful data ratio because of
the smaller packet payload sizes.

> 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.

I'd argue that this isn't necessarily true.  p2p applications *do* use
more download bandwidth than their traditional client/server
counterparts, but not because they can create any more bandwidth in a
single connection.  Instead, p2p dramatically increases the average
bandwidth usage of all the links on a network, which means downloads
aren't rate-limited by a single, overloaded server anymore.  Instead,
downloads are min(client download speed, sum of clients' upload speeds
to the client).

> 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.

In my mind, more routes = more chances to find a better path = better
speeds on average; also, multi-connection stuff does better imho at
getting around servers who set up IP-based rate control.

The drawback, I would guess, would be the additional overhead 10
connections would introduce as opposed to 2.

> 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 is only true if the bottleneck later in the internet has a
greater amount of available bandwidth than the user's modem does.
Also, I'd argue that congestion control means that 10 connections
would own 2 connections when you're fighting for control of an
already-congested link (i.e. if your sister is downloading ubuntu ISOs
via BT while you're downloading gentoo ISOs via HTTP).

> 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.

3 uploading connections via bittorrent using full link rate generally
wins over 3 upload connections to FTP servers using full link rate,
when I've tried  ("Why's my download so slow?!  Oh. . . I'm still
seeding that ISO. . .").

> 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.

Why?

> 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.

So we implement the new congestion control stuff on that too :D

> 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.
>

I agree that p2p doesn't necessarily work *exactly* as described by
the paper, but I'd argue that p2p does actually consume more bandwidth
than client/server applications designed to do the same thing.  Thus,
the problem statement is valid.

>
> Respectfully,
>
> Robb Topolski
>

*shrug* In any case, back to lurking on the list.

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