Subject: FW: [P2PSIP] Proposal for progress on protocols

From: JiangXingFeng <[email-masked]>
Date: Wed, 07 Nov 2007 10:53:47 +0800

Hi, all:
Sorry for not copying to the list. 
Regards!
--
Jiang XingFeng

> -----Original Message-----
> From: JiangXingFeng [mailto:[email-masked]]
> Sent: Wednesday, November 07, 2007 10:53 AM
> To: 'Henning Schulzrinne'
> Subject: RE: [P2PSIP] Proposal for progress on protocols
> 
> Hi, Henning:
> 
> See inline.
> 
> --
> Jiang XingFeng
> > -----Original Message-----
> >
> > I'd like to propose a mechanism to make progress on converging on a
> > protocol. My high-level impression is that most of the proposals, with
> > the exception of the HIP-based ones, are philosophically not that far
> > removed, and the differences are more at the mechanical level. One way
> > to make progress would be to identify some of the major pieces, and
> > then, in Vancouver, systematically go through them.
> I agree with your proposal. We could discuss these issues one by one and
get the
> best solution to them, then we could assemble them into a integrated
protocol.
> 
> An initial list,
> > definitely incomplete, includes
> >
> > - packet format
> > - NAT traversal for p2p messages (not media or SIP signaling)
> > - channel security for p2p messages
> > - recursion vs. iterative
> IMHO, we should consider semi-recursive and overlay native routing mode
(it
> means that in some cases the response will be returned to the source peer
in the
> same way as the request which are forwarded through the overlay.)
> > - hash algorithm negotiation and usage
> 
> I'd like to add the following two items:
> >- Service discovery mechanism which could be used to find out which peers
in the
> overlay provides which kinds of service which may be helpful to overlay
operations.
> >- an end-to-end reliability mechanism; source peer could retransmit the
request,
> but how do the destination peer knows whether the response has returned to
the
> source peer correctly. It may be helpful to some operations in the
overlay. For
> example, if Peer A and Peer B should perform the ICE procedure to traverse
NAT
> between them, in P2P overlay, it often relies on the preceding transaction
to
> exchange their own candidate to the other. So the question is: when the
destination
> peer B sends the response, when will the destination peer start the ICE
connectivity
> check? Maybe the response has been dropped in transit.

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Wed, 7 Nov 2007 10:02:01 +0100

Hello,

> > > then, in Vancouver, systematically go through them.

IMHO the key point is completing and updating the concepts document
specifying issues like: one or two protocols, requirements for the
overlay, basic functionalities, etc. I think is more important to
define P2PSIP philosophy instead of defining if chord will be used to
implement the DHT or peer protocol will be binary or not.

I suggest to include a 'comments on concepts document' session in the
meeting agenda

> > overlay provides which kinds of service which may be helpful to overlay

We (Krzysztof Hennig, Michal Giermasinski and me) are working in SOA-P2PSIP.

This project aims to define an open, decentralized and service
oriented architecture for P2PSIP (Peer-to-Peer Session Initiation
Protocol) based overlay networks. Such architecture will allow the
easy and rapidly deployment of advanced services in such environments
where centralized servers are damaged, not available or just want to
be redundant. Open architecture will also provide end users with
possibility for creating their own services independently or with
cooperation with communication companies.

Our goal is to design a framework for providing advanced communication
services based on p2psip overlay network.

Scope of project covers:

 * Building design open architecture that allows deployment  new
advanced services in distributed and serverless environment without
modifying current architecture.

 * Suggested open architecture should provide following functions for
service enabling:

	- Implement and Delivery: a node should be able to cover a new
functionality or service, that is: a node should contain an executable
code that implements desired service logic along with all required
media processing, db queries and signaling in order to deliver a
service or functionality as a modular, self-contained and independent
block for requesting peers, e.g. a new application that translates
voice flows into other languages

	- Publishing: a node should be able to include a new functionality or
service into a global directory, one accessible by all other nodes.
e.g.: include the translation application as a new translation service
into the global service directory

	- Discovery: a node should be able to look up a service or a single
functionality implemented by any node in a global directory along with
obtaining a description about the service and its usage, interfaces
and functionality, e.g.: discover and learn how to use the translation
service
	
     	- Composing: a node should be able to discover already existent
functionalities or services, and implement other new by combining
existent ones. This new service should be able to be published as a
self contained entity in order to be discovered by other nodes, e.g.:
integrate the translation service with the already existent service
known as 'voicemail'. Then, messages stored in the voicemail could be
translated into many languages.

 * Framework should reuse existing protocols together with currently
developed peer-to-peer protocol preserving full backward compatibility

 * Framework should allow for providing advanced services in ad-hoc
p2p networks without external network services like DNS, STUN, X.400,
etc. In other words framework MUST NOT depend on any other systems or
applications. Peer may interact with different networked systems,
however this should be a subject for service delivery (implemented
functionality in one or more peers) but not for our framework which
covers service publishing, lookup and composition. In example: a peer
implementing service X may fetch data from other systems during
service delivery. However during service publishing, discovery or
composition only service related details describing the service X
should be exchanged in the framework instead of data from external
system.

 * Framework should be IP based, either IPv4 and IPv6. We therefore
abstract from L2 network type, however should be possible to provide
services over any radio, xDSL or Ethernet network taking into
consideration specific characteristics like bandwidth, latency or
error rate.

 * Framework should enable services to be "pluggable" by any service
provider - either associated with human or not. In other words anyone
on the Internet could publish services developed by his/her own (or
his/her UA). Such service could be discovered and used by other peers
(their friends).  Framework should not constrain mechanism for
publishing of services within P2PSIP overlay network especially should
not introduce central registrars for names etc.

In case you are interested in this project, we could arrange a small
presentation during the meeting.

Regards,
-- 
Victor Pascual Ávila