Subject: [P2Prg] RE: SIP

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

> [Jxta]is much, much richer. 

no arguments!!! yet another xml messaging 
protocol; bulky encoding; We learned a lot 
of lesson from many interesting (but nil 
deployed) rpc protocols. not all 
applications have such a requirement.

But, I don't understand why jxta coupled 
the protocol suite with a particular 
transport (i.e.TCP.) It may be an explicit 
design decision...

> I don't see at all where SIP plays.

you have answered yourself in the next few lines.

   > Assume a purely ad-hoc P2P network. No formal 
   > registration except the configuration knowledge 
   > of what Jxta calls a rendezvous/relay. Rendezvous
   > are for discovery and relays are for routing.

but, one difference. It provides rendezvous and relays
and requires formal registration etc. The jxta protocol 
doesn't require formal registration, because it has 
virtualized itself into an overlay network. 

> I'm not going to go any further here. But, I do not
> understand how SIP can begin to emulate all of this.
> ... One can stretch protocols beyond their original 
> scope, and engineers tend to do this.

or how about building a lot of application specific 
   virtualized overlays which floods the Internet by
   its bulky protocol messages.

or how about building informed overlays which overload
   the Internet by pinging the network level nodes for
   clue.

overlays are as harmful as protocol extensions.

For the record, SIP is not a P2P suite but yet-another-
-rendezvous-protocol. It doesn't amount to overloading. 
It doesn't provide DHT or application security or overlay
maintenance etc. It is the work of this research group 
to build them.

> 
> Our first priority is to really understand what we
> must do to implement a collection of P2P protocols 
> that not only deal with today's applications but 
> with those applications we have not even dreamed of. 

I completely agree. Lets kill the SIP thread. It is 
hard to argue without proper proposal on table.

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

---

From: Bill Yeager <[email-masked]>
Date: Thu, 11 Dec 2003 16:45:52 -0800

Hi,

On Dec 11, 2003, at 3:42 PM, Ayyasamy, Senthilkumar (UMKC-Student) 

> transport (i.e.TCP.) It may be an explicit

It doesn't. I just used that in the example. Transports are pluggable. 
There is for example a TLS transport that I wrote that lives on the 
virtual overlay network, and does end-to-end TLS on any underlying real 
transport. It's real cool.

> virtualized itself into an overlay network.

Exactly. That is because purely ad-hoc, autonomous and independent P2P 
networks must be supported.

>    its bulky protocol messages.

Why do this?

>    the Internet by pinging the network level nodes for
Why do this?

> overlays are as harmful as protocol extensions.

I disagree. In fact, I can argue that they are necessary to deal with 
mobility, differing underlying real transports, NAT, Firewalls, etc.., 
in a consistent way. *Any network protocol is harmful if abused, or 
misused." We call that DoS sometimes, don't we (-:

Suitable controls must be placed in the implementations to not get 
caught in the "ping" trap that you point out.

Overlays are not necessary viewed as protocol extensions but rather as 
abstractions of the multiple possible real transports to provide lots 
of features. Again, extreme care must be taken in the definitions and 

> maintenance etc. It is the work of this research group
I see your point there, and it is valid for sure. I had always viewed 
it as a way to set up sessions for communication with its invitations, 
etc ... and thus a rendezvous in the small.

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!

> hard to argue without proper proposal on table.

(-: I've really enjoyed your thoughtful discussions, and have learned 
something. Believe or not I've read the SIP rfc twice. It's very shall 
I say, large. I see it is a very important protocol that we will surely 
leverage in one way or another. Expertise as yours is really 
appreciated.

Bill