Subscribe to RSS Subscribe to Comments

damien stolarz blog

Academic P2P conference in Linköping, Sweden was high quality education.

I just got back from a great P2P

conference in the university town of Linköping, Sweden (27-29 August 2001). The flight was

long (18+ hrs) but the the city was beautiful and the weather was perfect, crisp,

kind of like Oregon; the light drizzle of rain stopped whenever we needed it to. The

building we were in seemed brand new and was immaculate. I wanted to move there,

it was clean, futuristic, and the cafe was in the center of the building, about

20 feet away from the many, many computer labs. Code, eat, code, eat…

The call for papers was my first clue that this was going to be a clueful conference,

a meeting of the minds and not fluffy marketing pitches. There were 1/2 hour

and 1 hour presentations, and almost all of them were technical. The only thing

I would have asked for was more time for Q/A on the 1/2 hour presentations.

The format was how I like it- one main track, not multiple parallel tracks (which

inevitably overlaps the only two talks you wanted to hear…)

This was a refreshing relief from past conferences I have attended, where P2P

companies would show up at conferences as a sort of roll-call, desperately pitching

solutions to each other (as if there were any customers there.)

As for attendees, it was about a 1/2 split between students and industry, but

the industry reps were all engineers. Sweden IEEE and several other IEEE members

were there. P2PWG was there in the form of

me.

Wireless was represented by Ericson, and a compelling speech by their Philippe

Charas correlated the end of the cold war with the rise of the Internet, social

and technical decentralization. He argued that the AAA (Authentication, Authorization

and Accounting) functions in wireless need to be moved into the end devices

because of the many different mobile end points a consumer may be using.

Gene Kan and Steve Waterhouse from Sun were there as well, and Gene must have

been awed to see students from around the world doing graduate work on the Gnutella

system and protocol. Ross Lee Graham (the

conference chair and a professor from Linköping computer science) pointed

out that his student, Eduard Turcan, had recieved his master’s degree in peer-to-peer!

Steve Waterhouse, Director of Engineering for JXTA Services and Applications,

gave an extremely comprehensible presentation on JXTA,

and I also really learned a lot from his explainations of decentralized search.

Coming from the earlier aquired Infrasearch, he certainly knows something about

the subject, and it is fantastic to recieve knowlege like that directly from

the source.

Oregon University was represented by Zary Segall, who presented his department’s

work on wearable computing

(which obviously involves P2P when they communicate directly.) He showed scenarios

where people interacted on campus, and their computers used XML to meet each

other and decide whether these people liked the same music, studied the same

subjects, or could run errands for each other by comparing their to do lists.

It made me think of specifying the PTBP or pass-the-buck protocol for pawning

off ("delegating") tasks automatically, wirelessly…

The event delved into the commercial realm just a bit on the third day with

a panel discussion on "P2P Business Models". The audience didn’t ask

that many questions but listened attentively as the discussion meandered into

more general business issues like venture capital and the pseudo-recession.

The sponsors of the event, QuickCom,

got a bit pitchy but to be fair they presented a rather novel P2P system that

runs on top of multicast, and they described it in technical detail, so the

in-depth quality of the conference was not compromised. A group of researchers

from Malaysia proposed the use of multicast protocols as a peer discovery system

("Purep2p") as well.


An interesting note is that in Europe, industry still funds university research,

whereas in the United States, research is "funded" by simply hiring

the student, cutting out the middleman. In a sense, one could consider that

research is now returning to its traditional realm, university, instead of being

funded at great risk and expense by a starry-eyed venture community.

Once the final copies of everyone’s presentations are collected, there will

be a final Publication of the Proceedings. I wish there could be more of these

technical, academic P2P conferences. No political wrangling, minimal sponsor

commercials, no careful company posturing, just a very educational meeting

of the minds. They plan to have another conference on P2P in similar style in

the coming year and with the quality of this one I will certainly be going.

System- and Network- wide bandwidth shaping for P2P apps

At my home, with 5 fixed IP’s on Pacbell DSL, I have 1.5Mbit downstream but a meager 128k upstream. Recently, I installed Morpheus on my Win98 box and, predictably, with my fixed IP and always on machine, I guess I became a popular and high-reliability supernode.

I also began, predictably, to notice that surfing the web on this machine could be slow and painful. That shouldn’t be a problem- I have 1.5Mbit down- but the 128k up was so full that the small HTTP GET requests that my browser sends had to wait in line to get out. So it was really a problem of latency, not bandwidth, and anyone with wireless 128k from the dying Metricom will tell you, they’d sometimes rather surf the web with (relatively) low latency modem than a high latency wireless.

Single-Machine Bandwidth Balancing

Now, this problem could be solved with software. All that would be necessary is if my P2P app could tell that I was clicking a link in my browser client, and it could hold off, for just a moment, on sending any data until the tiny request could go out, get established, and then the p2p upload could resume.

From the perspective of the P2P app, we are limiting it’s bandwidth. From the perspective of the Web browser, we are guaranteeing that it will have a minimum amount of bandwidth and delay. So throttling or shaping can be used to implement “QOS” or Quality of Service.

Servers, routers, gateways, cable modems, server apps like FTP, Apache, and even OS’s like linux have throttling, allowing you to set exact limits for how much bandwidth should go through. This is how web hosters make sure one website doesn’t hog the machine from all the other hosted sites, or how Cable modem operators (attempt) to keep the bandwidth fairly spread to the users.

Back to me: I have a Linux box on this LAN said, “Why was my site so slow the other day?” The reason was, of course, that the Win98 machine was using all the bandwidth uploading the Phantom Edit and/or 40’s jazz music to others, and my wife’s attempt to view her own page was inhibited by this.

In this case, the problem was indeed that there was too much upstream traffic, which directly blocked the outgoing traffic of the webpage. But another factor existed as well: even if there had been some system-level software on the Win98 box to detect web browsers on that machine, Morpheus couldn’t possibly know that my linux machine on the same network was trying to serve!

Home Network Bandwidth Balancing

This could be solved in two other ways: One, if there was some sort of two-way protocol between Morpheus and other bandwidth hungry apps, such that apache could send across the network (quickly enough):

Apache: “Hey, Morpheus, I need to send a web page, hold off for a second”

Morpheus: “No prob.”

Apache: “Ok I’m done”.

Of course this conversation would be very rapid and happen many times per second.

Another solution (more likely) is that the techniques migrate down to the gateway or DSL router and some application toolkit goes to the OS level. Then, some local reservation of service would go like this:

Apache: “Hey, gateway, I’m on this linux machine and I’m a service app. I am HTTP, tcp, short connection oriented- I need pretty low latency because there’s a lot of disconnect/connect. I’m the most important app on this network. I don’t want to drown out other apps however.”

Gateway: “Ok lemme see… ok, Apache.”

Morpheus: “Hey, gateway, I run all the time. I have fairly long connection periods compared to connects… but I’m lower priority. Don’t let me mess up the web services.”

Gateway: “Ok gotcha.”

Now, if the website is a bandwidth intensive site and the P2P app is very web-serverish with many small transactions, these profiles are not always correct… the point is, it would be nice if the various apps settled into a rhythm and worked together, if not perfectly, in the optimal way.


I always compare the bandwidth problem to the world hunger problem: Given the proper distribution, there is enough grain to feed everybody. The problem is getting it there. Similarly, there is always unused bandwidth somewhere on the Internet. Even on your home LAN, there is often enough bandwidth, if you distribute it right.

It took years for OS’s to multitask smoothly and balance interactive (user) response with computation and disk use. We now need to see it happen for network applications, and get that multi-tasking effectiveness for our bandwidth.

Some potential solutions (and these have all been invented hundreds of times, they just haven’t trickled down to the end user machine) are:

  • System-wide bandwidth reservation, a software API for accessing it, allowing one machine to make the best use of it’s bandwidth.
  • Centralized (on a small lan) reservation of bandwidth, perhaps centered around a gateway device or DSL/Cable access point
  • Peer-to-peer cooperative reservation of bandwidth, where apps sort of work it out amongst each other (on a network) how they will share the bandwidth