Subject: [P2PSIP] architecture presentation and terminology

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 4 Nov 2008 15:44:47 -0500

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-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 8 Nov 2008 11:48:55 -0500

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

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Sun, 9 Nov 2008 20:41:39 -0500

On Sat, Nov 8, 2008 at 11:48 AM, Henning Schulzrinne
<[email-masked]> 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

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 10 Nov 2008 06:43:54 -0800

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-masked]> wrote:

Henning,

Bruce

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Nov 2008 07:20:53 -0800

At Mon, 10 Nov 2008 06:43:54 -0800,
Henry Sinnreich wrote:
> 
> 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).

I'm not Bruce, but I don't think this moves the ball forward very far.

To quote Bruce's message:

	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 know that when I have introduced new terms for RELOAD, I've tried
to use consistent terms if there were any that seemed appropriate
and I suspect Bruce has done the same--including complaining about
some of mine that weren't as standard asyou might have liked.

ISTM that if there are people who believe that a given term in the draft
doesn't match common academic usage (or perhaps some Platonic terminology
ideal) then it's incumbent on them to explain which terms are wrong,
what they need to be changed to, and why.

-Ekr

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 10 Nov 2008 08:13:18 -0800

Eric,

>(or perhaps some Platonic terminology
ideal)

We are back to a glossary of terms such as in openDHT.org
Naming the terms in those papers "platonic" is not helpful.

Henry

On 11/10/08 9:20 AM, "Eric Rescorla" <[email-masked]> wrote:

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Nov 2008 09:15:39 -0800

At Mon, 10 Nov 2008 08:13:18 -0800,
> Naming the terms in those papers "platonic" is not helpful.

Neither is amorphous complaining.

Are there specific terms you don't like in draft-ietf-p2psip-base.
If so, why?

-Ekr