READ Marketplace story on FCC and Comcast

[David Farber <dave () farber net>]

________________________________________
From: Dr. Lawrence Roberts [lroberts () anagran com]
Sent: Sunday, July 13, 2008 8:38 PM
To: DV Henkel-Wallace; lroberts () anagran com
Cc: David Farber
Subject: Re: [IP] Marketplace story on FCC and Comcast

DV,
Re "all it can get":
Today TCP/IP networks use as the basic fairness, "all flows get equal capacity". This is a result of our thinking in 
the early days where each person had one flow in each direction like a voice call. But today, an application can start 
up 100 or 1000 flows. Each flow gets "all it can", perhaps 100 Kbps. So do other users on the same cable or DSLAM. But 
the P2P application started 100 flows so it gets 10 Mbps and the other users still get 100 Kbps. That is fairness as 
the network works today. If you wished your FTP to operate at 10 Mbps, you also could start 100 flows and send a part 
of the file in each one. Then others would do this and soon all your flows would be operating at 10 Kbps since the 
cable is overloaded and must slow them all down. This is the problem we face today with P2P. It is better at getting 
capacity than any normal application. So a few users get most of the capacity.

Re modeling:
The problem is simple to model after observing the behavior of P2P programs. It is at layers 3 & 4 not 7. The P2P 
application finds a list of other users with a movie the user wants. It opens a flow to get part of the movie from the 
first other site. There is no concern about closeness in the net, in fact a majority of these flows go overseas. Then 
it opens a flow to another site and starts getting another part of the movie. It keeps doing this so long as it keeps 
increasing its total throughput or runs out of sites. When many P2P applications are in the same University, they all 
add flows out across the Internet access (since close is unlikely) and soon the Ineternet trunk is congested, and 
reduces the rate of every flow. The P2P applications then generate more flows at the lower rate and push the normal 
users rate down. In the end, 5% of the users have got 95% of the capacity and the average user is operating at 5% of 
the rate he could have without the P2P. Thats how it works today. Yes it would be better to share within the campus LAN 
 but there is no incentive to do this for the application. Nor does it know which users are close in general.

Larry


At 03:22 PM 7/13/2008, DV Henkel-Wallace wrote:
From: Dr. Lawrence Roberts [lroberts () anagran com]
Sent: Saturday, July 12, 2008 11:43 PM

...In fact, as I have been testing and modeling P2P I find it taking
up even higher fractions of the capacity as the total capacity
expands. This is because each P2P app. can get more capacity and it
is designed to take all it can. ...But raise the capacity per user
and the capacity of the upstream choke point and watch out! P2P can
consume virtually any capacity.

Dr Roberts, I am afraid I don't understand.  Any server application is
designed to take (i.e. provide) all it can, and these applications are
merely combinations of servers and clients.    Somehow nobody
complains that an ftp server is "using all the bandwidth it can" nor
usually do people complain about users "ftping to their site all that
they can."

I'm curious about your modeling.  It's not really possible to
adequately model the behavior of anything at layer 7 (which at the end
of the day is really all these apps are) in a conventional lab
setting, but I presume you have the university traffic to work with.
It does seem to me that universities might be ideal communities of
interest: presumably if they're downloading ISOs it's mostly the same
ISOs; if they're downloading movies or whatnot it's likely mostly the
same.  Do you see this?  Is there much internal sharing (and thus
presumably decreased use of the backbone)?  Does the network
management prevent the P2P system from understanding who's "close" (or
are the apps merely poorly written)?

Thanks!
-d



Dr. Lawrence G. Roberts,  Ph:+1 650-906-8746,  W:  www.anagran.com<http://www.anagran.com/>, E:    lroberts () anagran 
com
Founder, Chairman, Chief Architect, Anagran, Inc., 580 Pastoria Ave., Sunnyvale, CA 94085 USA
If not for you, please return. Any use other than the intended recipient is unauthorized.





-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com