Re: [Tsvwg] A comment on "draft-briscoe-tsvwg-relax-fairness-00" re file-sharing

[Bob Briscoe <[e-mail]>]

Robb,

At 22:28 14/04/2008, Robb Topolski wrote:
>Hello Bob, thanks for the reply!
>
> > a) Could my scenario become common, even if it's not currently prevalent?
>
> > c) Who is actually correct for the Internet today? (split out into
> > next posting)
>
>One problem with applications, as you are aware, is that some users often
>don't follow configuration guidance or instructions.  So the answer to the
>two questions above is possibly and partially.
>
>For the users that won't follow instructions, there will be users like your
>friend (mentioned elsewhere), who was running about 40 torrent
>simultaneously.

Er no - I said he was running 3 torrents.
I suspect you have misread "~40/torrent" for ~40 torrents.

This is a tricky area - I have tried to be as accurate as I can - so 
pls read carefully.

>Using Azureus, presuming all 45 torrents had sufficient
>"leechers," such a mis-configuration would create an instance of a user with
>over a hundred active uploading TCP connections (unless he changed the
>setting that also limits each task to 3-4 upload slots).  But there will
>also be users that accept the reasonable installation defaults, and never go
>into "Advanced mode" to break away from the parameters set at install time.
>
>
>Please, though, if your statement is about some future possible condition, I
>ask you to please write it up making that point clear.

No, my statement was about a present case. And you will see I said 
the Azureus client and the OS was in its out-of-the-box config state.

Another colleague also did measurements with a symmetric 9Mbps 
symmetric access (6x T1 bonded together) and detected 450 
simultaneously active connections - no special effort - he just ran 
up a standard BitTorrent client and started downloading movies 
(varying between 3 & 6 over the period measured). This was well 
within the numbers expected from configuration guidelines (1200 max 
active connections at 9M upstream). However, I don't have full 
version nos of all his software for that case.

Certainly these may not be typical cases, but there was no intention 
to do an exhaustive study to find what is typical, as protocol 
engineering isn't about just typical cases. However, the fact they 
'just happened' shows they're not totally abnormal.

I believe it is mostly a function of how community spirited the 
user-base for a particular swarm is (how many seeders). My colleague 
(the 8M ADSL one) is a member of a p2p community that prides itself 
on its exclusive membership, which it limits in size, and 
collectively they police for copyright violation very fastidiously.

>Your statements
>about the present condition are being relied upon in certain serious debates
>in numerous circles

I'm aware that this is important, which is why I'm trying to be careful.

>  -- including other WGs of the IETF.

Which?

>We ARE (hopefully) going to continue to transition to more symmetric
>connection model.  I don't think I have any confidence in any particular
>view of how things will look then.

Who is 'We'? The IETF is an international organisation. It has to 
cater for the situation anywhere in the world. Have a look at Korea, 
Japan, Hong Kong, Sweden, Denmark, Norway.
(e.g. <http://www.bharatbook.com/detail.asp?id=25141>)

Anyway, not wishing to break the habit of a lifetime, the IETF is 
allowed to re-design protocols before the old ones cause predicted 
problems. And it's certainly allowed to try to understand problems 
that are likely to arise in the future.

>Personally, I've seen enough fads come and go, and I see part of the
>behavior on today's P2P networks being a fad of "appropriation."  Some (or
>many) of these kids are downloading media faster than they can possibly
>consume it.  It's either a hoarding reaction (e.g. "someday it will go
>away") or it's a bragging-rights thing (e.g. "he who dies with the biggest
>DVD stack, wins").  I have no data, it's just a hunch.

On what basis is an evolution like p2p likely to go away? 
Swarmcasting is cool. Even ancient institutions like the BBC are 
using it underneath their client to deliver their content. 
Appropriation isn't a new phenomenon. For decades now some people 
have been leaving their TVs on all day - sometimes 3 or 4 on 
different channels in different rooms. Cable networks were built to 
cope with that level of volume - it's not appropriation, but it has 
the same effect.

I'm just using swarmcasting as an example of why the "flow-rate 
equality" thinking prevalent at the IETF needs a serious update.

> > equality was the dominant sharing regime (e.g. if, as access speeds
> > increased, most congestion moved further into the network where FQ is
> > too unscalable, e.g. border links).
>
>You're over my head at the "FQ is too unscalable" part, but since you
>mentioned border links, as you consider this future issue, also consider
>that there may be more borders than we all might assume.  This might offload
>some of the danger, I don't know if you've included it in your
>considerations.

If you mean many borders in parallel, yes certainly. But the 
scalability problem with FQ hits you for much smaller no's of users 
than you currently see at borders even today. And once you get to 
borders, you no longer have knowledge of which IP addresses should be 
weighted differently as you do on remote access servers. At a border, 
at the IP address level, a server farm looks like my gran.


>Having never seen the topography on paper before, one thing that surprised
>me was learning that the Cable MSOs cannot be modeled as a single network.
>Instead, they are several smaller metro-area networks -- one in each area,
>and each with its own border/gateways to upper-tier transit providers (one
>of which may be a company-owned backbone to other metro-areas).
>
> > I don't mind altering the figures in the draft accordingly, or
> > qualifying their applicability.
>
>Thanks, that would definitely help.  Can I also suggest using something
>other than the word, "trick?"  It's not like any of these P2P apps are
>setting up redundant connections to the same host (such as "download
>accelerators" do).

I used the word trick, because I was trying not to put a value 
judgement on it (ie I wouldn't have said 'cheat'). I guess I could 
just say 'technique'. But personally I thought 'trick' wasn't 
perjorative. In the same vein, I have written that http browsers use 
the trick of opening 2-4 connections.

>Knowing some of these P2P developers as I do, the last
>thing they want to do is harm the network

I also know p2p developers. Yes, it's not their fault personally. 
They are trapped in an arms race. That's why I'm trying to work out a 
way out of the arms race.

I also want to say explicitly that the draft is NOT intended to say 
that p2p is the root cause of the problem. It's trying to say that 
the goals of the IETF's protocols are the root cause, and we need to 
understand the problem (in the context of p2p) to find better 
protocol goals (at run-time not design-time).

>-- they just want to fill the
>space available.

The Internet was designed to take advantage of the cost efficiency of 
packet multiplexing. If everyone filled the space available, they 
might as well have a circuit-switched network.

I find nearly everyone latches on to the multiple flow issue and 
hardly anyone clocks the issue of activity factor over time.

---
Finally, does this draft at least help towards understanding that we 
have a problem in the way we are reasoning about this issue?

It was heading towards a sister requirements draft (in preparation 
with others) introducing a proposed metric to reason about fairness. 
But that's for another thread.



Cheers


Bob


>Robert M. "Robb" Topolski <[e-mail]>
>Hillsboro, Oregon USA
>
>Variables won't; constants aren't.
>Osborn
>
> > -----Original Message-----
> > From: Bob Briscoe [mailto:[e-mail]]
> > Sent: Monday, April 14, 2008 5:06 AM
> > To: Robb Topolski
> > Cc: 'IETF Transport Area working group mailing list'
> > Subject: Re: [Tsvwg] A coment on "draft-briscoe-tsvwg-relax-fairness-00"
> > re file-sharing
> >
> > Robb,
> >
> > There's three types of responses to this (expanded below):
> > a) Could my scenario become common, even if it's not currently prevalent?
> > b) The discussion is over what the correct fairness /goal/ should be
> > c) Who is actually correct for the Internet today? (split out into
> > next posting)
> >
> > Anyway, TCP doesn't actually determine capacity sharing for
> > residential backhaul links - operators generally use per-user fair
> > queuing. This draft merely shows how bad things would be if rate
> > equality was the dominant sharing regime (e.g. if, as access speeds
> > increased, most congestion moved further into the network where FQ is
> > too unscalable, e.g. border links).
> >
> > a) Could my scenario become common, even if it's not currently prevalent?
> > ---------------------------
> > The discussion below shows that (as you say) the main reason
> > swarmcasting like BitTorrent doesn't open many connections is
> > asymmetric access. If you look at the situation in countries like
> > Japan (the [Res_p2p] reference), where symmetric 100M FTTH has become
> > very prevalent over the last few years, this constraint disappears.
> > Campus & enterprise networks are already symmetric.
> >
> > We're designing protocols today so they will be available in a couple
> > of years. We have to look ahead.
> >
> > b) The discussion is over what the correct fairness /goal/ should be
> > ---------------------------
> > The draft is about the /combination/ of multiple connections and high
> > activity factors. It's designed to show that the /goal/ of equal flow
> > rates is not the one we should be pursuing. Even if my figure of
> > 500-5000 times more traffic intensity is an order of magnitude wrong
> > for most of today's Internet, 50-500 times more intensity (or even
> > 5-50) still shows the original goal of equal flow rates is inappropriate.
> >
> > I don't mind altering the figures in the draft accordingly, or
> > qualifying their applicability.
> >
> >
> >
> > Bob
> >
> > At 05:30 12/04/2008, Robb Topolski wrote:
> > >Comment on
> > >
> > >Problem Statement: We Don't Have To Do Fairness Ourselves
> > >draft-briscoe-tsvwg-relax-fairness-00
> > >
> > >
> > >Dear Working Group members,
> > >
> > >Thank you for your time working on this committee and issues such as
> > these.
> > >
> > >The above quoted paragraph requires a number of corrections.  This
> > paragraph
> > >is a basis for the problem statement that follows it -- so getting the
> > basis
> > >down right is key to analysing the issue and sizing up the problem.  The
> > >corrections that I hope to effectively communicate seem to me to reduce
> > the
> > >stated size of the problem.
> > >
> > >--Quote--
> > >Even though file-sharing generally uses TCP, it uses the
> > >well-known trick of opening multiple connections--currently around
> > >100 actively transferring over different paths is not uncommon. A
> > >competing Web application might open a couple of flows at a time, but
> > >perhaps only actively transfer data 1-10% of the time (its activity
> > >factor). Combining 50x less flows and 10-100x lower activity factor
> > >means the traffic intensity from the Web app can be 500-5,000x less.
> > >However, despite being so much lighter on the network, it gets 50x
> > >less bit rate through the bottleneck.
> > >--EndQuote--
> > >
> > >I am relatively certain that the draft is talking about BitTorrent above,
> > >and it unforunately misinterprets what it does.  BitTorrent is the #1 P2P
> > >File Sharing protocol in use today.  Furthermore, neither #2 P2P file
> > >sharing protocol ED2K (aka eDonkey, eDonkey2000, eMule, or MFTP) nor #3
> > >Gnutella (aka G1, G2, or Gnutella2) work like BitTorrent, nor as
> > Briscoe's
> > >draft described above.
> > >
> > >In the case of BitTorrent, between 35-70 TCP connections are generated.
> > >However, only three or four of these connections are actively
> > transferring
> > >data.  Therefore, any benefit to the "trick" is erased.  The reason the
> > >remainder sit idle is described in the specification
> > >(http://wiki.theory.org/BitTorrentSpecification#Choking_and_Optimistic_Un
> > cho
> > >king), chief of which is the desire that BitTorrent NOT interfere with
> > TCP
> > >congestion control.
> > >
> > >It is important to remember that P2P users are largely residential users,
> > >most using connections that are configured with asymmetric connections
> > where
> > >the maximum download bandwidth allowance is several times that of their
> > >upload allowance.  In all of the discussions about "fairness" that I've
> > been
> > >involved in, it has to do with sharing the tiny upload pipe.  Filling the
> > >generously-configured download pipe is seldom a user fairness concern (it
> > is
> > >also very difficult to control at the receiving end).  A trend is barely
> > >beginning toward more symmetrical residential accounts, but it is
> > probably
> > >too small to accurately determine changes in usage patterns created by
> > it.
> > >
> > >That BitTorrent uses "hundreds of connections" that are simultaneously
> > >active is a common misperception.  While the draft likely did not mean to
> > >inject emotionalism, the label of "trick" is both inaccurate and
> > >inflammatory.  The reason that BitTorrent makes these idle connections is
> > to
> > >allow for one connection to "hunt" for the best reciprocating peer, which
> > >allows two efficiently located peers to detect and reciprocate with each
> > >other.  If not interfered with by network operators, this pretty much
> > >ensures that the lowest-latency peers will eventually find one another
> > and
> > >engage in a long-term exchange of data.  This is not only fast for the
> > user,
> > >choosing the most efficient (lowest latency) pairings is friendliest to
> > the
> > >local ISP network and the Internet as a whole.
> > >
> > >All three of the top P2P protocols do open multiple upload connections.
> > >ED2K seems happiest with 3-4 KB/s upload flows, Gnutella with 10 KB/s
> > upload
> > >flows, and BitTorrent with anywhere from 3 KB/s to 7 KB/s flows.
> > Therefore,
> > >the number of upload flows that a single peer might generate (think
> > >different archives being sent by the same client simultaneously) is a
> > >function of dividing the configured upload bandwidth by the amounts
> > >decribed.
> > >
> > >An example:
> > >
> > >BitTorrent:  Upload limit set to 20 KB/s, 3-6 upload TCP connections
> > >(remainder are idle or downloading only)
> > >ED2K:  Upload limit set to 20 KB/s, 5-6 uploading TCP connections
> > (remainder
> > >of connections are downloading only or performing light-bandwidth
> > >housekeeping, such as queue placement requests or updates)
> > >Gnutella:  Upload limit set to 20 KB/s, 1-2 uploading TCP connections
> > >(remainder, same as for ED2K).
> > >
> > >All three of the above have a UDP component, which is used for searching
> > or
> > >other light network housekeeping.  There is an emerging use of UDP for
> > "NAT
> > >hole punching" but these "connections" are still quite rare.
> > >
> > >I am happy to answer any questions or further clarify anything that I
> > can.
> > >
> > >Sincerely,
> > >
> > >Robert M. "Robb" Topolski
> > >[e-mail]
> >

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does 
not necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    [phone]