Subject: [P2Prg] overlay issue (was re: SIP)

From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" <[email-masked]>
Date: Thu, 11 Dec 2003 21:51:23 -0600

>> overlays are as harmful as protocol extensions.
>>
>>
>
>I disagree. 

Let me explain the whole issue...

application level overlays are introduced to deploy disruptive 
technologies which doesn't find takers at network level (as 
backbone operators have become bell heads;-) Overlay networks 
differ depending on the purpose, construction and infrastructure. 
It can roughly be classified into:

 o Infrastructure overlay ( RON, CDN, DHT based overlays etc)
 o end-host based overlay  ( gnutella, end system multicast etc)
 o network level overlay   ( mbone, 6bone)

I am not arguing against end-host based overlays. They are very 
successful as it doesn't require explicit infrastructure. All I 
am against (or rather see lot of open issues) is certain type 
of infrastructure overlays.

The infrastructure overlays differ depending on applications
needs and method of construction like 

  o informed reactive overlays ( probe based)
  o mesh based overlays ( semantic based)    
  o virtualized overlays (VPN based)        

 p1. customer participation issue: A subset of above mentioned 
     overlays provide application specific service. It requires 
     the interested user to be a participant of the overlay.
     But, a particular user may require more than one 
     application. So, do you expect every user to subscribe to 
     different overlays? or do you think a joe user has required 
     expertise to participate in the overlay?

 p2. network management issue: How do you manage those overlays? 
     Is it possible for an end-user (not a participant of the 
     overlay) to interact with the overlay node to debug stuff?

 p3. end pt control issue: Overlay empower end user by delegating
     path control/decision to end points. But, till now, Internet 
     routes are controlled by providers. Do this result in selfish 
     behavior by users (it will; given practical p2p systems exhibit
     free riding behavior.)

 p4. Inter-overlay communication: how do different overlays interact?
     From a SOA perspective, work-flow systems require overlay 
     inter-working. A output from media encoding overlay may act as 
     input to streaming network. 

 p5. Performance issue: flooding of protocol messages and measurement
     control messages depending on the type of overlay. But, this is 
     not a big issue. For example, jxta/FLAPPS etc serve as a good 
     overlay construction platform. Also, proposals like RON++ provides
     an underlay overlay to avoid ping trap. 

 p5. overlay node issue: overlay nodes are still Internet based nodes.
     Its performance/reliability are same as any other Internet node. 
     So, we should not think overlay as some new network.

The point of the whole above discussion and relevance to this RG is 
that, we should weigh relative pros and cons before considering overlay 
for a particular application. If overlays are used, we should try doing 
protocol message micro-optimizations at every level. For example, I 
consider overlays for reactive re-routing as not useful. It interacts
poorly with network level routing. Also, we should remember that 
reliability(unlike performance) is the bottleneck for the Internet. 
A lot of start-ups which tried doing smart routing by overlays are 
in chapter 11. So, we should consider lot of design choices before 
choosing overlay based solutions.

On the other hand, it should also be noted that their are lot of 
successful overlays( the present Internet is a best example.) also,
overlays are very important for rendezvous/referral function. We can 
shortly expect a new RG which specifically focus on design issues 
related to referral servers. They will be used for mapping locators 
to identifiers functionality of IP addressing(as many recent ietf 
proposals call for id/loc split.) DHT is a likely candidate for
such a mapping system.

>In fact, I can argue that they are necessary to deal with 
>mobility, differing underlying real transports, NAT, Firewalls, etc.., 
>in a consistent way. 

I accept that overlays can be used to twine multiple address space
across middle boxes. But, from an e2e perspective, overlay node
has the same architectural property as NAT, firewall etc. probably,
We should come up with design principle (but should be compatible
with e2e argument) for the present Internet (which consist of 
NATs, tunnels, proxies, protocol boosters,overlay nodes and other
kludges etc...) 

>Our work on jxta has shown that building rendezvous + relays  is very 
>difficult. Still, I do think the Jxta implementation has completely 
>avoided the ping problem. It's performance is not bad at all. It has 
>more or less been live and learn. Trying to set up rendezvous on the 
>public network leaves one wide open to all sorts of attacks. A good 
>initiation by fire!

A lot of options are available to avoid the DoS problem:

  - use a cryptographic name space for identifiers
  - use challenge/response mode for communication.
    e.g., client puzzles. 

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

---

From: Bill Yeager <[email-masked]>
Date: Thu, 11 Dec 2003 22:49:48 -0800

Hi,

Rather than belabor a reply, let me just say we are for the most in 
agreement with respect to how to approach an overlay network. It took 
us a little time to gain an understanding, and your issues are 
thoughtful and for the evolution of Jxta has taken many of them into 
account. I'm not saying Jxta is the overlay network of choice, but 
rather, that we can learn from it as we move into the research. I'm 
sure some very active Jxta people from Sun will join us too.

I think that DoS will need more than what you mention. These are the 
known tactics. I'm hoping we can come up with more methods. I know we 
can ...

OK. Let's end this thread, and pick it up again in our Overlay 
subgroup. I hope to get these subgroup mailing lists done this weekend.

Thanks again,

Bill

On Dec 11, 2003, at 7:51 PM, Ayyasamy, Senthilkumar (UMKC-Student)

---

From: Bernard Traversat <[email-masked]>
Date: Mon, 15 Dec 2003 20:48:07 -0800

Bill Yeager wrote:

> Hi,
>
>  I'm not saying Jxta is the overlay network of choice, but rather, 
> that we can learn from it as we move into the research.

For people interested, we just released JXTA 2.2

http://www.jxta.org/servlets/ReadMsg?msgId=89531&listName=announce

Cheers,

B.

-- 
"As Java implies platform independence, and XML implies language
independence, then JXTA implies network independence."