There is an astonishing agreement in terms used in academic papers, and even with what is the in the Wikipedia. Why not use these terms?
A glossary for p2p targeted at SIP seems to be necessary, but until there are volunteers to write it, using the common terminology found in the p2p literature and in the Wikipedia seems the best choice. Your quote of the paper Rhea's "handling churn" in usenix'04 is fortunate indeed, since it is a good start. There are many more p2p papers at http://opendht.org/pubs.html and they all have the terminology well under control. So why not use the terminology used at http://opendht.org/pubs.html and in Wikipedia? (Where applicable - exceptions should be explained). Henry On 11/9/08 7:41 PM, "Bruce Lowekamp" <[EMAIL PROTECTED]> wrote: On Sat, Nov 8, 2008 at 11:48 AM, Henning Schulzrinne <[EMAIL PROTECTED]> wrote: > In my opinion, to the extent possible, we should re-use common terminology > in this field, rather than make up our own. We are just a small player in a > 1000-paper universe, so creating terminology that differs too much is > probably unhelpful. > Henning, I think we can all agree with that, but it doesn't actually make useful progress toward an answer. I had actually spent some time a few weeks ago looking at this, and as far as I can tell, there isn't a universal terminology here. I couldn't find anything useful in RFCs for overlay networks. I looked for academic papers, but the vast majority of the academic papers don't use a terminology that's useful for implementers because they're not addressing the problem at that level. Looking for the term "layer" in the collection of papers I have on my laptop generates remarkably few hints, and I didn't come up with much useful in google, either. What I did find is that Rhea's dissertation adopts the term lookup layer and storage layer, where lookup layer refers generally to an interface encompassing everything except for storage and replication, which is handled by the storage layer. The common API paper from IPTPS03 introduces the KBR interface, but that's trying to define a programmatic interface that doesn't have an exact analogue in our model. "Vulnerabilities and Security Threats..." by Srivatsa and Liu uses "network layer" to refer to TCP/IP and overlay layer to refer to all of the P2P software. "Non-transitive connectivity and dhts" uses the term "routing layer" for everything below the application. Rhea's "handling churn" in usenix'04 divides the world into "routing layer" and "storage layer", essentially the same as lookup/storage above. The chord TON paper only divides the software into a generic block storage layer sitting above the chord layer. I also looked at more general overlay network papers as well and the best I came up with was "The Case for Wireless Overlay Networks" by Katz and Brewer , which uses the term "overlay subnetwork layer" to describe what is the bottom layer in reload's architecture diagram and "overlay network management layer" to describe everything else. So in the time I've had to devote to the topic, I haven't come up with anything useful in existing literature for this type of architectural presentation. Certainly I haven't identified common terminology that we could adopt. If you know of something that you believe is common terminology, I really appreciate pointers. Bruce > > Henning > > On Nov 4, 2008, at 3:44 PM, Bruce Lowekamp wrote: > >> There were a lot of questions, many of them from Alan, about reload's >> previous architecture presentation. The most recent revision to >> reload introduced a new architecture model presented together with the >> older model. >> >> http://tools.ietf.org/html/draft-ietf-p2psip-base-00#section-1.2 >> >> The new model, referred to as the "overlay perspective" tries to more >> clearly specify the roles of the various layer and establishes a very >> clear parallel between the functionality of the overlay layers and the >> general internet model. In a lot of ways, this model is much clearer >> than the old one. It does have some drawbacks along the lines of >> saying that TCP/TLS is an Overlay Link Protocol, which is a bit >> counterintuitive to those of us used to thinking of TCP as a transport >> protocol, but Overlay Link is more accurate for its purpose in reload. >> >> We don't want to present two different architectures. If we adopt the >> new one, terminology in the remainder of the draft will be altered to >> reflect the new model. We would really appreciate comments on whether >> the new model makes (or would make if the rest of the document is >> updated to reflect it) the presentation clearer. >> >> Henning has pointed out that "API" is probably wrong in the new figure >> and those should simply be layered "Interface". >> >> Bruce >> _______________________________________________ >> P2PSIP mailing list >> [EMAIL PROTECTED] >> https://www.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________ P2PSIP mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2psip
