Subject: [Sipping] RE: Comments on draft-johnston-sipping-p2p-ipcom-01.txt

From: "Johnston, Alan" <[email-masked]>
Date: Mon, 28 Mar 2005 22:32:44 +0100

Hi Philip,

Thanks for the comments on the draft.  Glad you like the conclusions - I
notice that many of your comments actual strengthen some of the
arguments I make ;-)  See my comments below.

Thanks,
Alan Johnston
sip:[email-masked]

> -----Original Message-----
> From: Philip Matthews [mailto:[email-masked]] 
> Sent: Thursday, March 24, 2005 2:11 PM
> To: Johnston, Alan
> Cc: sipping
> Subject: Comments on draft-johnston-sipping-p2p-ipcom-01.txt
> 
> 
> http://www.ietf.org/internet-drafts/draft-johnston-sipping-p2p
> -ipcom-01.txt
> 
> 
> Alan:
> 
> I liked the new version of your document. I have no major 
> issues with its conclusions. The comments below are just 
> minor comments on the details of your argument, not on the 
> major conclusions.
> 
> I also noticed some minor grammar and punctuation problems -- 
> I can send them to you if you care, but I am assuming this 
> draft is just a position paper and not meant for publication 
> as an RFC.
> 
> *) [Page 6] "The IETF typically does not standardize 
> decomposition protocols,
>         such as these, though there are notable exceptions 
> such as MEGACO."
>     GSMP and especially FORCES are other exceptions. The barrier is
>     crumbling these days.

Yes - these are other good examples.

> 
> *) [Page 6] "Since the IETF does not standardize services ..."
>     What about CPL? This seems to be a standardization of 
> service logic.

Yes, although CPL is made of up primitives which can be combined to
create a particular service.  In fact, CPL has been proposed in the past
as a way of storing service information in a Location Service.

> 
> *) [Page 7] " ... Location Service Protocol (LSP) ... need a 
> better name
>         so to be clear that this protocol has nothing to do 
> with GEOPRIV) ..."
>     Or MPLS (LSP = "Label Switched Paths")
>     Or ISIS (LSP = "Link State Packet")
>     Or ...
> 

:-)  Suggestions?

> *) [Page 7, middle] The proposed Location Service Protocol may need to
>     return more than just a simple Contact URI. In a pure Peer-to-peer
>     SIP network, if the user's phone is not reachable (e.g., it is a
>     wireless phone that is out of range), then we would still like
>     the call to follow the user's call handling preferences. 
> This might
>     involve taking voicemail for the user, or forwarding the call to
>     another AoR. The user might have expressed these call handling
>     preferences by uploading a CPL script to the "network" somehow
>     beforehand.
>     This might be handled by:
>     (a) returning the CPL script to the caller, or
>     (b) returning a primary and some secondary contacts 
> (where the secondary
>         contacts know what to do if the primary contact is 
> not available).
>     I think (a) might have security issues, so my current preference
>     is for (b).

Yes - these are important requirements that we will want to meet with
this protocol.

> 
> *) [Page 7, bottom] If a domain publishes registration information to
>     the public Location Service, it will still need to store 
> registration
>     information because it is participating in this public 
> Location Service
>     and will have to store a portion of the global information.
>     (I guess this assumes the public Location Service is 
> implemented using
>     peer-to-peer technology).

Yes - you are correct - it may not store its own registration
information, but will provide storage functionality for others in the
P2P network.  Hopefully through distribution and replication this will
be a lighter load than just maintaining its own data.

> 
> *) [Page 10, middle] CAN, Pastry, and Tapestry are also DHT 
> algorithms.
> 

Yes, my mistake - they are just different search algorithms than Chord.

> *) You might want to mention that a Location Service protocol could be
>     built on top of a more general peer-to-peer lookup protocol.
> 

Yes - this is true and should be pointed out.  There are, however, some
good reasons to build a separate protocol rather than try to piggy back
on top of some existing file sharing P2P network - these, too should be
pointed out.

> - Philip

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Philip Matthews <[email-masked]>
Date: Tue, 29 Mar 2005 09:23:45 -0500

> on top of some existing file sharing P2P network - these, too should be

In my mind, this is a key question: Do we produce be a peer-to-peer protocol
that is SIP-specific, or do we produce a general peer-to-peer protocol and
layer SIP on top of it.

I confess that I am attracted to the latter simply because it seems like
the RIGHT THING to do. A general purpose protocol is always much more useful
than a specific protocol.

I remember someone (I think it was Cullen, but I may be wrong) saying at
the last IETF meeting that he was worried that a general purpose protocol
would cause certain network administrators to want to block it. Though I certainly
understand why he said that, to me this says that we are doing what is wrong
technically for political reasons.

- Philip

---

From: Arjun Roychowdhury <[email-masked]>
Date: Tue, 29 Mar 2005 10:05:44 -0500

Alan,
one quick comment: It may be worth reinforcing in the draft that 'LSP'
(or whatever you choose to call it) is only needed when there is a
requirement for a well defined protocol for location information
distribution. Though this is a p2p draft,  it may be worth
re-inforcing that LSP may not be needed for 'traditional non-p2p
networks' (I really don't want all customers to come screaming back
about whether a certain proxy supports 'LSP' or not [3 lettered
acronyms are a rage, these days ;-) ]

Another comment on your response to Philip's comment below

> Yes - these are important requirements that we will want to meet with

Why is this an important requirement ? If the goal of this draft is
pure p2p, then there is no intelligent network inbetween that needs to
be relied on from a service perspective. If CPL needs to be invoked,
it would be a part of the User Agent either originating or terminating
a call and not some node in between.

-- 
Arjun Roychowdhury

---

From: Xiaotao Wu <[email-masked]>
Date: Tue, 29 Mar 2005 10:58:17 -0500 (EST)

> a call and not some node in between.

I agree with Arjun's point. In a P2P network, you cannot put your
service scripts in the network due to both reliability and privacy
concerns. If you want it to be reliable, you must have your scripts
distributed to all potential routing nodes, which you never know whether
they are trustable or untrustable, and the privacy will be a big concern.

There could be some exceptions, such as spam filtering, a user may like to
push it into the network so he does not have to keep a copy for all his
devices. But, keeping service script copies on every device and
synchronize the copies would not be a big problem in a P2P network.

For services on endpoints, we have extended CPL to the Language for End
System Services (LESS), which can be found at

http://www.ietf.org/internet-drafts/draft-wu-iptel-less-00.txt

The new language removes the 'proxy' action in CPL since you would not
expect your endpoints to proxy calls. The language will just fit the P2P
environment for services.

Thanks!

-Xiaotao

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 29 Mar 2005 11:09:20 -0500

I think this is not true.  All you need is multiple contacts with q values
so that eventually, one endpoint gets the call; voicemail in this case.

Forwarding can also be done if an endpoint is allowed to forward.  The
endpoint has to be trusted by the user, but that's the nature of p2p.
I imagine that what happens really is that I have an endpoint which is mine,
and under my control that is last in the contact list.  It has CPL, or
whatever I want, and forwards the call if necessary.

Brian

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Xiaotao Wu
> Sent: Tuesday, March 29, 2005 10:58 AM
> To: Arjun Roychowdhury
> Cc: Johnston, Alan; sipping
> Subject: Re: [Sipping] RE: Comments on draft-johnston-sipping-p2p-ipcom-
> 01.txt
>

---

From: [email-masked]
Date: Wed, 30 Mar 2005 16:44:13 -0600

> produce a general peer-to-peer protocol and layer SIP on top of it

We could then have one protocol for both IP communications and file
sharing/media distribution (the legal way only!). Intuitively, this could be
very attractive.

Thanks, Henry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2005 8:24 AM
To: Johnston, Alan
Cc: sipping
Subject: [Sipping] Re: Comments on draft-johnston-sipping-p2p-ipcom-01.txt

would cause certain network administrators to want to block it. Though I
certainly

- Philip

---

From: [email-masked]
Date: Wed, 30 Mar 2005 17:04:17 -0600

> I think this is not true.  

It is true.

Nobody will accept a P2P voice mail service if they know the storage is on
someone else's PC. Storing on your own PC is however a better choice, as is
done here:

http://www.hotrecorder.com/ 

Henry

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2005 10:09 AM
To: 'Xiaotao Wu'; 'Arjun Roychowdhury'
Cc: 'Johnston, Alan'; 'sipping'
Subject: RE: [Sipping] RE: Comments on
draft-johnston-sipping-p2p-ipcom-01.txt

Brian