Subject: Re: [P2Prg] Call For Papers: Peer-to-Peer Internetworking

From: Youki Kadobayashi <[email-masked]>
Date: Sun, 24 Aug 2003 23:10:11 +0900

Single *network* can't serve universal purpose, but single
*protocol* (e.g, IPv6) can.  I never said "no single peer-to-peer
protocol can serve universal purposes".  But I personally don't
believe that people will ever come up with a simple and elegant
universal peer-to-peer protocol that can fulfull diverse application
requirements.

Protocol translating gateways are not the only practical means
to accomplish multi-protocol internetworking.  Modern browsers
and IM clients are capable of speaking multiple protocols...

Unlike L3 protocols, L7 protocols are more closely tied with
application's security/privacy/performance/resiliency/QoS requirements.
That's why there has been recent developments in DHT algorithms...

Bill Yeager wrote:
> Do you really believe this? I heard the same thing about network 
> protocols in 1981. Many of us pushed very hard to make the then 
> fledgling IP protocol the standard much to the dismay of DEC and XEROX 
> (DECNet and XNS).  We all know where those two protocols ended up.   An 
> open, IP standard took about 10 years to bury the others. There are many 
> more that became extinct.
> 
> The below reminds me of most the the attempts to create protocol 
> translating gateways. They have never led to anything long lived, and 
> rarely is there a 1-1 mapping. Something is always lost.
> 
> I think the hypothesis for this workshop needs to be closely reexamined. 
> That might make a good paper (-:

You are cordially invited :-)

	Youki.

> Arigato,
> 
> Bill
> 
> On Tuesday, August 19, 2003, at 08:25 PM, [email-masked] wrote:
> 
>> Since no single peer-to-peer network can
>>     serve universal purposes, functional decomposition among multiple
>>     peer-to-peer networks has to occur as peer-to-peer internetworking
>>     framework is defined.
> 
> 
> 
> _______________________________________________
> P2prg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2prg
> 
> 

_______________________________________________
P2prg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2prg

---

From: Scott Michel <[email-masked]>
Date: Tue, 09 Sep 2003 11:23:15 -0700

Bill Yeager wrote:
> On Sunday, August 24, 2003, at 07:10 AM, Youki Kadobayashi wrote:
> 
> It is worth a try.  I never say "never" (-:

IP's biggest win is it's (relatively) simple model, or as Steve Deering once 
put it "the wineglass". It's intentionally narrow at lower down points, 
pushing the more complicated stuff, transport and applications, towards the 
place where that functionality belongs, namely the transport and application 
layer.

What YK is proposing is fairly straightforward: What about an IP-like model 
for P2P services? And I'm a pretty big fan of this approach, since that's 
what my dissertation argues (*).

What are the common elements to the broad range of networked P2P services 
out there (which includes JXTA and the DHTs)?

a) Building a peer network overlay [topology construction]
b) Propagating reachability of service resources and objects
    [routing]
c) Forwarding messages/requests/data flows through one or more
    transit peers from local source to remote peer [forwarding]

At the network layer, topology construction is merely discovering the 
hardware interfaces. At the P2P application layer, there need to be one or 
more protocols that build that peer network. Similarly, IP defines a name 
space for identifying nodes; similarly a P2P service needs to define a name 
space for identifying resources and objects. When there's a network and a 
name space, I'd claim routing and forwarding become pretty straightforward.

The fact that the IP model doesn't claim make one size fit all is the other 
big win, and a successful P2P infrastructure should only impose the minimal 
set of requirements necessary. For example, a P2P infrastructure should only 
define its expectations of what a name space should be, e.g., hierarchical 
and decomposable (domain names, DHT identifiers, XML fall into this 
category) but leave the actual representation up to the actual peer service.

A general-purpose P2P infrastructure is possible and achievable; I've done 
it (http://flapps.cs.ucla.edu)

> Such a mess too. Lots of bad code, bugs, etc ... So much of this is 
> driven by marketing. Hack after hack gets out there. Our group need to 
> really pursue homogeneity. I live with heterogeneity for years, and 
> wrote a huge amount of code to support multiple protocols. That made 
> sense in a research environment ... I don't think it makes sense in a 
> product environment where stability is so important.

No, it doesn't force homogeneity. It's merely suggesting a common P2P 
infrastructure layer that makes building the gateways possible. Which 
protocols are translated by the gateways is a separate question. Code 
quality is not a model problem but an implementation issue.

> DHT algorithms are great. I agree. Still, it may be that one writes 
> software a la jxta where the DHT algorithm is pluggable, and if what the 
> lookup returns is the same object, then crossing DHT lookup boundaries 
> is easy.

You're basically proposing that a common P2P infrastructure layer, which 
should be JXTA. My claim is that the model can be generalized further.

> With respect to security/privacy/performance/resiliency/Qos. Well, that 
> is a nice phrase. Too bad it for the most part is not implemented for 
> most people. Huge efforts need to be made to make this transparent. QoS. 
> Where? Privacy? Take a look at what the governments want to do these 
> days. Performance ... right ... more MIPS to support more bad code as I 
> see it. Where have all the real programmers gone? Retired I guess. When 
> did you last write code that worried about the amount of memory it used, 
> the time it takes to execute, etc ... You may be one of the rare 
> engineers that worries about this, but it is the exception. I recall 
> sitting down with the instruction timing and writing assembler that had 
> had to execute in a few microseconds in the minimal amount of memory. 
> Right, we don't do that anymore, but it is a good metaphor for how to 
> write code ...

A P2P infrastructure model should define where those hooks can be cleanly 
placed and incorporated.

WRT to writing code, most of the undergrads I see these days work at a 
completely different layer of abstraction (I'm saying this as someone who 
wrote 6502 code that flew on STS-113 last year.) Operating at a higher layer 
of abtraction isn't necessarily a bad thing, but there needs to be some 
emphasis on operating at multiple layers of abstraction, as you clearly 
point out. With these layers comes overhead and given the rapid 
time-to-market and time-to-operational-code, examining the overhead is often 
overlooked.

-scooter

(*) It takes longer to graduate when you're doing a systems dissertation and 
your advisor wants a complete working system.

---

From: Bill Yeager <[email-masked]>
Date: Mon, 25 Aug 2003 20:15:22 -0700

I pretty much consider what is going on right now at the App layer as 
chaotic and frantic.
And, right, this may continue to be the case for a long time. And, how 
the users suffer ...

If automobiles were made like computer software we'd all still be 
riding horses and bicycles as I see it.

DHT algorithms are great. I agree. Still, it may be that one writes 
software a la jxta where the DHT algorithm is pluggable, and if what 
the lookup returns is the same object, then crossing DHT lookup 
boundaries is easy.

With respect to security/privacy/performance/resiliency/Qos. Well, that 
is a nice phrase. Too bad it for the most part is not implemented for 
most people. Huge efforts need to be made to make this transparent. 
QoS. Where? Privacy? Take a look at what the governments want to do 
these days. Performance ... right ... more MIPS to support more bad 
code as I see it. Where have all the real programmers gone? Retired I 
guess. When did you last write code that worried about the amount of 
memory it used, the time it takes to execute, etc ... You may be one of 
the rare engineers that worries about this, but it is the exception. I 
recall sitting down with the instruction timing and writing assembler 
that had had to execute in a few microseconds in the minimal amount of 
memory. Right, we don't do that anymore, but it is a good metaphor for 
how to write code ...

We suffer from code glut. Look at the size of the binaries these days. 
I'd like to see all of those MIPs dedicated to doing something useful 
for a change besides covering up for badly written code.

OK. Back to my keynote for the IEEE conference in Linkoping on next 
Monday. And by the way, I don't mean to be harsh. I've been at this 
game since 1965 and have seen a lot of water under the bridge. View it 
from that perspective. And, sure, I'm not always right ...

Bill