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

From: Reinaldo Penno <[email-masked]>
Date: Mon, 27 Oct 2008 17:55:28 -0700

We submitted a new draft that hopefully helps the discussion on the tradeoff
and practices of TANA 'applications'.

Thanks,

Reinaldo

------ Forwarded Message
From: IETF I-D Submission Tool <[email-masked]>
Date: Mon, 27 Oct 2008 15:02:42 -0700 (PDT)
To: Reinaldo Penno <[email-masked]>
Cc: <[email-masked]>
Subject: New Version Notification for
draft-penno-tana-app-practices-recommendation-00

A new version of I-D, draft-penno-tana-app-practices-recommendation-00.txt
has been successfuly submitted by Reinaldo Penno and posted to the IETF
repository.

Filename:  draft-penno-tana-app-practices-recommendation
Revision:  00
Title:   TANA Practices and Recommendations
Creation_date:  2008-10-27
WG ID:   Independent Submission
Number_of_pages: 8

Abstract:
Applications routinely open multiple TCP connections.  For example,
P2P applications maintain connections to a number of different peers
while web browsers perform concurrent download from the same web
server.  Application designers pursue different goals when doing so:

 P2P apps need to maintain a well-connected mesh in the swarm while
web browsers mainly use multiple connections to parallelize requests
that involve application latency on the web server side.  But this
practice also has impacts to the host and the network as a whole. For
example, an application can obtain a larger fraction of the
bottleneck than if it had used fewer connections. Although capacity
is the most commonly considered bottleneck resource, middlebox state
table entries are also an important resource for an end system
communication.  

This documents clarifies the current practices of application design
and reasons behind them, and discusses the tradeoffs surrounding the
use of many concurrent TCP connections to one destination and/or to
different destinations. Other resource types may exist, and the
guidelines are expected to comprehensively discuss them.

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 Error!
Reference source not found..

The IETF Secretariat.

------ End of Forwarded Message

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

---

From: "Robb Topolski" <[email-masked]>
Date: Tue, 28 Oct 2008 16:46:13 -0700

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 ([email-masked])
Hillsboro, Oregon USA
http://www.funchords.com/
_______________________________________________
tana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tana

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 28 Oct 2008 16:58:12 -0700

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.

---

From: Steve <[email-masked]>
Date: Wed, 29 Oct 2008 13:26:47 -0400

Just my two cents.

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

> routes exist.

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

> For some of these reasons, given sufficient

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

> ... a lot of the paper assigns to P2P those things that are just as

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.

> just aren't used in the way that most people think!  Fire up a client

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.

> would use a large amount of bandwidth on the net and spread that use

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.

> Again, download bandwidth consumption is the market taste changing to

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

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

> eventually try for equilibrium at a subscribers first bottleneck --

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

> 100s of connections in simultaneously use for the purpose of cheating

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

> of the middleboxes we've seen have been attempts to do something

Why?

> all of the "advantaged" streams back.

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

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

> Robb Topolski

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

--Steve

---

From: "Robb Topolski" <[email-masked]>
Date: Wed, 29 Oct 2008 14:20:31 -0700

Thanks for all of your responses, Steve.  I agreed with a lot of them,
but wanted to respond to certain of the others.

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

Everyone uses congested routes, and client-server nor P2P will perform
any better or worse if all the routes (or the single route) are/is
congested. The sin occurs when one continues to use a congested route
when uncongested routes exist.

This sin doesn't occur with BitTorrent for very long and only
fractionally.  With BitTorrent, a long-term transfer peer pair is
created when both sides establish a relatively strong exchange --
uploading and downloading at the highest rates.  There are 2-3 of
these, plus one upload slot is used to move from peer-to-peer (30
seconds at a try) to try to find an even better candidate to replace
the weakest of the established pairings.  Since congestion affects
speed  (obeying normal congestion controls), a congested pairing won't
be paired for very long.  And even during that 30 second trial, the
other 2-3 streams on uncongested paths continue.

This sin doesn't occur with ED2K or Gnutella and only fractionally.
These clients will upload for a set size (usually up to a maximum
time) and if one of its queues is stuck on a very slow link, it will
service the other queues at their own speeds (obeying normal
congestion controls).  The result is a natural one -- its contribution
to the file-sharing network is going to be biased towards the fastest
routes.

And while I've admitted that a sin occurs at all on P2P modes, keep in
mind that their client-server alternatives have no such ability to
shift use to uncongested routes -- it "sins" because it can't make
choices when a route is congested.  Client-server alternatives have no
choice but to pound the congested route until the transfer is
completed or aborted by the user.

> I can see how p2p would keep

A download is a download.  Once you've got the file, you stop
downloading it.  Uploaders tend to run a range. Some will upload to a
certain % of the file, some for a certain amount of time, and some to
keep a particular file perpetually available.  The nature of the first
two are more transactional in nature, and the last example more mimics
the operator of a FTP or web server.

> stuff which, in all likelihood, will.

They're exactly the same.  There is nothing special about these
sockets to the network software (be it a server or a P2P node),
they're presented and managed by the OS and software in the same way.

Residential users do have some additional factors working against
them, and these do make a difference (the lack of flow controls,
overwhelming the local modem) the paper doesn't go into these and
these generally aren't the issues that a scavenger class would
address.

> downloads are min(client download speed, sum of clients' upload speeds

Whether I download Ubuntu 8.10's new release tomorrow over
Client-Server @ 100 KB/s or BitTorrent @ 1 MB/s, I will have used the
same amount of bandwidth.  To further illustrate, the first choice
will take longer, and any impacts that I have on the network will last
longer.  The second will not last as long, but my impacts will be
greater during that time.   But if the first choice is on an already
heavily-saturated route, most of my second choice is likely to avoid
heavily saturated routes.

> connections would introduce as opposed to 2.

These are literally bytes (not KB).  Once established, idle TCP
connections have no cost (although some app developers do send pings
or "NOOP" commands every once in a while as a keep-alive).

> greater amount of available bandwidth than the user's modem does.

That's true in all of the ISP access networks that are the subject of
this effort.

> via BT while you're downloading gentoo ISOs via HTTP).

We have to flip that example to the upload to make use of it.
(Congestion control is a sender response).

We'd  also see that USER and SISTER dynamics would not be good
examples because they transmit at unconstrained rates at the
tightly-constrained upstream modem.  In the ISP case, users are
sending at constrained rates toward a less-constrained upstream
router.  The question at that point is SUBSCRIBER1 to SUBSCRIBERn
fairness.

(We should stop, since the example is invalid to this situation, but
let's go on because it's interesting .  10 uploading connections
would "own" two uploading connections at the first packet drop and
perhaps the next several -- but then the Japanese proverb "the tallest
tree catches the most wind" means that the most prolific sender of
data during the next several occurrences of packet drop is the one
likely to be affected next.  As an end result, we ought to run it
before declaring for sure -- but it cannot be predicted that USER
would have a 500% advantage over SISTER because USER would get 500%
more packet drops than SISTER.  I don't think it would be quite
50%/50% either.)

> when I've tried  ("Why's my download so slow?!  Oh. . . I'm still

Predictably true, because those upload connections have been chosen as
the best candidates from among a list of 35-70 choices.  When you're
uploading to an FTP server, you're using whatever route you've got and
you're stuck with its conditions.

>> of the middleboxes we've seen have been attempts to do something

Because all the data an ISP needs to do its job is in the IP header.
Most of the middleboxes are on the network edges (not the Internet).
Those used on the Internet are doing something that is usually
communication neutral (such as looking for spam and attack patterns,
blocking frequently attacked ports, creating segments within bigger IP
pipes, and other non-controversial things) or communication harmful
("enhancing the experience" and "monetizing every transaction" and
"inserting the ISP into the content value chain").

> the problem statement is valid.

Hopefully, I've persuaded you.  I could agree that P2P users tend to
use the Internet differently than client-server users and, owing to
those different uses, tend to use more bandwidth as a group.  But if
the goal is file sharing, there is no appreciable difference in
bandwidth use that is owing to the different architectures of P2P and
client-server.

I appreciate this chance to hopefully shed some light.

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 29 Oct 2008 15:00:24 -0700

Hello Robb,

Thanks for the comments. Inline..

On 10/28/08 4:46 PM, "Robb Topolski" <[email-masked]> wrote:

> 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
> ... a lot of the paper assigns to P2P those things that are just as

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

> type of data being moved, not how it is being moved

Humm...see below

> just aren't used in the way that most people think!  Fire up a client

I have, what you mean by that exactly?

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

> would use a large amount of bandwidth on the net and spread that use

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?

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

> 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
> eventually try for equilibrium at a subscribers first bottleneck --

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

> 100s of connections in simultaneously use for the purpose of cheating

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

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

> that could advantage everyone across multiple areas. Win-win-win.

Sure.

---

From: "Robb Topolski" <[email-masked]>
Date: Wed, 29 Oct 2008 21:27:00 -0700

> traffic generated by 'Iron Man' torrent is a drop in the ocean.

Easier to use and configure than a web browser that can access the
same content?

Yes, I really think that robustness and speed matter to users.
Although HTTP and FTP can resume a broken download provided both
client and server are equipped to do so, this has been a consistent
feature of common P2P clients.

I think that P2P clients are frustrating to configure.  Do it wrong,
and there is no "click and forget" because everything crawls.  There
are further complications involving locating the content you want
where a complete copy is shared.

The availability or appealing choice of content is and has been a
valid driving point, but it's one that quickly is becoming less of a
factor.   Legal and free (or very inexpensive) choices are abounding
and studios and publishers are becoming more comfortable and
forthcoming with business models that work online.  Sandvine released
its study that predicted that P2P would grow 400% over 5 years (which
is about normal net growth) but within that statistic, legal P2P would
grow at a 10x to infringing or illegal uses.

So we can talk about Iron Man, but what problem are we here to solve?
The Iron Man issue is declining in relevance (and has been for about
two years) but using P2P to reduce the cost and other burdens of
spreading multimedia is going to be a factor for some time to come.

> technology with ease of configuration they would go for it.

I think you're probably right and this factor is eroding at two of the
common drivers of P2P file-sharing fans --

 -- the lack of availability of content online causes people to
"hoard" it when it appears online.  They download it even if they
don't intend to watch or listen to it right away because it's
available now.   This factor is decreasing because now nearly
everything more than 6 months old is available online.

 -- the "free" offer is very compelling against $15 retail price of CD
or DVD content.  This factor is decreasing because the new online
price of $2 - free per track or episode or a low monthly subscription
price is a price people are willing to pay to get a professionally
encoded and unencumbered multimedia 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?

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

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

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

I can't say no, because there is a time factor.  I mentioned this to
Steve in the other message.  See
http://www.ietf.org/mail-archive/web/tana/current/msg00111.html

---endquote---

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

What's driving bandwidth use higher in the fastest way today is the
addition of video into the Internet user's experience.  We can blame
P2P, but we're missing the point that if P2P would go away, people
would still want to create and share this stuff.  Fifteeen years ago,
facing much the same stress, we could have blamed HTTP for the
additional burden of graphics files and throttle all traffic that
wasn't Gopher, but we didn't because the cause wasn't HTTP, the cause
was that people liked using graphics in their presentation of web
information.

> because the constraint is on the uploader.

NO, no no!  P2P doesn't allow more bandwidth to be consumed (except
perhaps as a side-effect of avoiding congested routes and thus gaining
some better throughput).

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.

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.

> have been seen major problems.

And my points, summarized, are that no one has demonstrated that these
drawbacks are due the number of connections or something else special
about P2P connections, or even provided a size or nature of these
drawbacks sufficient for designing a particular solution that will
cover the need.

We've had plenty of assertions, likely good-faith assertions,
highly-respected assertions, but they don't work out when you try
them!  They don't open as many connections, they only actually upload
on a handful of connections at a time, and assignments of nefarious
intentions don't match the personalities involved (let alone the
specs).

P2P has been compared to download accelerators, but I know of no
clients that open multiple connections to the same host.  If the
intention was to skirt congestion control, then why wouldn't P2P
developers follow that well-established example?  Why leave most of
those open connections idle?  The uploader could be transferring on
them and effectively never slow down much when the net drops a packet?
  Why use TCP or OS sockets at all when the developer can use UDP and
roll his own rules?  BECAUSE P2P developers generally seen congestion
control and congestion signals as good things, and it is in their own
best interests to use and respect them.  With limited upload
bandwidth, it just doesn't help the P2P network to hammer packets down
a congested path that is going to drop half of them anyway, it just
makes more sense to slow down on that path and go use another path to
someone else in the meantime.  That's WHAT they do, and that's WHY
they do it.

You asked for studies.  But I asked you first, and since it is you
framing the problem statement, the onus is on you.

> studies on the next revision.

I can probably work up the test case (it's pretty obviously stated
above).  I'm interested in knowing what you think would happen
instead?

> seeder (or a seed box) or not.

The number of torrents you share simultaneously is actually a function
of the configuration, which is set based on the upload and download
speeds.  Any more than that and the surplus is queued until previous
tasks finish.  When I wrote my P2PI paper, I was on a 6/384 connection
which was also generous in the industry.  I think Comcast offers
12M/2M in that class now, so the 2 x (3 or 4 slots) figure probably
changes.

> perfect world vs. what actually is deployed.

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.

> quite different views on this. See Briscoe's papers on this.

After reading the paper, I felt it was very much about asserting a
flow-fairness problem and repeated many incorrect and easily tested
assertions often related to that problem.  I also felt that it listed
other problems such as overall more bandwidth usage to P2P as an
architecture or P2P technologies when the same use would be true if
users were restricted to using only client-server, given the same
tasks and content.

The paper failed to recognize that one factor is that video screens
and video files are growing exponentially in size.  Yes, sharing
copyrighted studio-quality content has been a strong draw, and this
will continue although it is declining as the studios and publishers
are successfully converting users to their own offerings.  But even
"piracy" isn't a P2P-specific problem as 15 years ago the traffic
complaints were that FTP software pirates were dominating the traffic
graphs during most hours and forcing their dial-up modems to run 24/7.
The paper needs to recognize that whatever the technology, users no
longer exclusively want to "pull" or "get" but more and more
frequently they also want to participate and contribute. They are
sharing the stuff that they like, some are personalizing it, and now
some are even producing it!

The last-generation network provisioning of 10:1 download/upload
ratios currently have users topping out their upload pipe for longer
periods of time.   Given the very public and uninhibited way that
today's newer net users view their lives today, how can we not include
that in the factors and practices that are going to drive the network
decisions for tomorrow?

Thanks again, Reinaldo!

Robb

---

From: "Robb Topolski" <[email-masked]>
Date: Wed, 29 Oct 2008 21:42:10 -0700

A quick PS, one that I hope isn't necessary but just in case:

At some point I said something like "...I asked you first" which reads
terribly wrong in several ways.  First, this isn't a personalities
thing and, second, I never asked first.  My point was supposed to be
something to the effect of "I'm not making the assertion, I'm
questioning it." But even more important than that, it's not the
critic or the criticism that counts, it's the paper.  I don't want
lose the fact that Reinaldo is taking on significant and respectable
work as an author, and to all please don't take my zeal about the
topic or my in-my-head phonetic spelling and sentence structure at all
personally.

---

From: Steve <[email-masked]>
Date: Thu, 30 Oct 2008 02:49:03 -0400

Okay, I lied.  Maybe I won't go back to lurking.

> traffic generated by 'Iron Man' torrent is a drop in the ocean.

I don't really think ease of *use* would be why a person would use a
p2p client.  Instead, I think it's more the ease of access to / robust
retrieval of content that's the draw (as was mentioned slightly later
on).  Users' motivations might be a bit off-topic though.  *shrugs*

> because the constraint is on the uploader.

--quote--

--endquote--

I'd agree with that little clause ("except perhaps as a
side-effect...") you put in parentheses.  It's a pretty big
side-effect.

Also, I'd argue that a higher bandwidth usage in a shorter period of
time would have a more noticeable effect to users than lower bandwidth
consumption over a longer period of time; that's what this whole
charter is about, right?

Personally, I found P4P: Explicit Communications for Cooperative Control Between
P2P and Network Providers by Xie et. al.
(http://www.dcia.info/documents/P4P_Overview.pdf) to be an interesting
read.  Not especially technical, though.

Yet another two cents.

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 30 Oct 2008 03:04:28 -0700

Robb,

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

>>> more efficient and robust than those over client-server.
 file.
> HTTP direct-download sites and NNTP hosters. Sure, they're there, but

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

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

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

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

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

Sure.

> connections any further than normal.

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