Subject: [P2PSIP] Comments on draft-jiang-p2psip-peer-protocol-requirement-00

From: Philip Matthews <[email-masked]>
Date: Fri, 9 Mar 2007 10:48:53 -0500

Here are some comments on draft-jiang-p2psip-peer-protocol- 
requirement-00.
Overall I think this draft does a decent job of describing the  
situation around
the Peer Protocol and motivating various requirements. Hopefully it  
will motive
some good discussion in Prague.

I have stolen Spencer's commenting style and replicated large  
sections of the
text of the draft below,  with my comments flagged with the text  
"Philip:".

- Philip

[snip]
    4.1 Motivation from C/S SIP to P2P SIP

    Conventional SIP takes Client-server architecture and has a
    centralized location database to store the association between AOR
    and its possible contact locations.  The location database is
    maintained by Registrar which receives REGISTER messages from SIP
    UAs.  Proxy servers or Redirect servers can look up in the location
    database to get the callee's location.

    P2P SIP intends to provide the similar location service to SIP
    entities, including SIP UA, Proxy server, Redirect server.  The
    resulting distributed location service will be provided by all the
    Peers in the overlay.  P2P SIP has some advantages over C/S SIP:

    1.  No centralized servers: There is no necessary to deploy several
        central servers in the system in that Peers in the overlay could
        cooperate to get the user's location.

    2.  Ease of configuration.  C/S SIP system needs to do lots of work
        to configure central servers, but in P2P SIP case, central
        servers are not needed and new peer only need a bootstrap  
node to
        join the overlay.

Philip: I don't think that P2P systems have any intrinsic ability to be
easier to configure than centralized systems.
Consider, for example, the network of BGP peers as used in the Internet
today. This network has all the properties of a P2P system, since  
there is
no centralized server anywhere in the network, yet each peer
requires very careful configuration in order to operate correctly.  
The operator
has to explicitly configure the neighbors of each peer, and the exact  
rules
for accepting and advertising routes. Almost everything requires manual
configuration in this system, and that is the way operators like it.
In this system, the ability to tweak every aspect of the system is  
considered
important, and ease-of-configuration has never been considered very
important at all.
As another example, consider the way people buy music from the Apple
iTunes store. In the way that consumers connect and download music
from the store, this is a client-server system, yet it is very easy  
to use.
Consumers do not have to do any configuration in order to connect to
the system, and the system even makes intelligent guesses as to which
country store you want to connect to. In this system, ease-of- 
configuration
is considered very important.

    3.  Scalability. when a new Peer joins the overlay, it brings extra
        computing and storage resource into the overall system.

    4.2 Peers' characteristics in P2P SIP case

    P2PSIP Peers have different characteristics than C/S SIP servers.
    These characteristics will greatly influence the design of Peer
    protocol.

    o  Transient: Peers join the overlay if they want to communicate  
with
       other members of the overlay.  They may leave the overlay at any
       time for a variety of reasons.  So the time Peers stay in the
       overlay is transient because of their frequent join and leave
       operations.

Philip: In a VoIP system, I don't think peers are a transient as in a
file sharing system. There is a strong incentive for someone to keep
her/his phone on the overlay to receive calls.

    o  More frequent failure: a Peer often runs on a PC.  Its stability
       is much lower than that of a server.  It is easily subject to
       failure without notifying others in overlay.  If that happens,
       overlay topology is not correct, and must be repaired.

Philip: This may be true for peers that run on PCs, but I don't think
it is true for peers that run on hard phones. And even PCs have
become a lot better these days. I suspect that the average uptime
will be on the order of weeks, not days,

    o  Limited processing power: The computer which a Peer resides on  
may
       have limited processing power.  If one Peer receives more  
requests
       than it can queue and process during a given time period, it will

Jiang                    Expires August 5, 2007                 [Page 6]
Internet-Draft                   P2PSIP                    February 2007

       delay at least some of the requests and even drop the excess.

    o  autonomous: The system administrators may not control the  
Peers as
       they control servers.  Peers may be highly autonomous and they  
may
       even do something that administrators and other users don't want
       them to do.  For example, malicious Peers may rewrite the  
message,
       forward message to wrong destination, etc.

    4.3 Comparison between C/S SIP and P2P SIP

    We will compare C/S SIP and P2P SIP in terms of location service in
    the following three perspectives:

    o  Information distribution: In C/S SIP, location information is
       stored on a centralized server for each SIP domain.  But the
       information is distributed among all Peers in the P2P SIP case.

    o  Availability: Availability is an important feature of practical
       systems.  Location service in C/S SIP is not available if the
       central server storing the key information does not work.  In
       order to avoid single point of failure, C/S SIP uses some backup
       servers to improve the availability.  In P2P SIP, every peer
       stores a small part of location information.  If some peers fail,
       the system only lost a few pieces of information which are stored
       on these peers, hence the system has not lost all availability.
       The problem in P2P SIP is that in naive P2P implementations there
       is only one copy of each user's location information.  If Peers
       fail, the unique copy will be lost.  So the Peer protocol should
       be specified in a way that supports the availability of the
       distributed location service.

    o  Efficiency: In C/S SIP, the lookup operation is executed in a
       centralized server.  So, the efficiency could be ignored in this
       case.  But in P2P SIP, lookup operation will trigger messages
       routed through the overlay, hence introducing a significant
       latency.  Although all DHT algorithms ensure that the lookup
       operation succeeds within Log(N) steps, improving lookup
       efficiency makes sense.  The distributed location service is used
       to support interactive communications which have rigid
       requirements for call establishment time.  So the Peer protocol
       shoud be specified in a way that allows improved efficiency.

Philip (nit); You don't say what "N" is, and you don't specify the
base of  your Log (which matters if you are not using the big-O
notation).
More fundamentally, there are DHT algorithms where the lookup takes
O(1) steps. Even the Chord algorithm can be made to run
in less than Log2(N) steps by simply adding more finger table
entries.

5.  Problem statement

    In this section, we will present some problems inherent in P2P
    overlay.  Some assumptions are made before discussing these  
problems:

    o  Bootstrap node is assumed to be known by a Peer before the Peer
       joins the overlay.  The method for Peers to get bootstrap node  
are
       static locations, cached peers, broadcast mechanism, etc.

    o  How to get credential of a Peer is not within the scope of Peer
       protocol, but the format of credential should be standardized in
       P2PSIP to improve security.

    5.1 A example P2PSIP overlay

     + - - - -+        N             + - - - -+
     + Peer A +  - - - A- - - - - - -+ Peer B +
     + - - - -+        T             + - - - -+
         |             N                 |
         |             A                 |
    N A T N A T N A T N A T              |
         |                               |
         |                               |
         |                               |
     + - - - -+                    + - - - -+
     + Peer C + - - - - - - - - - -+ Peer D +
     + - - - -+                    + - - - -+

    Figure 1 Peers in the overlay

    In figure 1, Peer A, B, C and D construct a P2PSIP overlay.  Peer A
    is behind NAT.  The topology is like that the above figure shows.
    These four peers work together to provide a distributed location
    service.  Each of them stores information and routes requests in the
    overlay.  Basically, subsequent discussions are based on the figure.

    5.2 Problem 1: NAT traversal

    If Peer A wants to join the overlay, it should initiate join
    operation as common DHT algorithms do.  Assume that Peer D is the
    bootstrap node that Peer A knows.  If the message goes through the
    path like D->C->B->A, then A communicate with B through the NAT.   
The
    method to traverse NAT is more difficult, if Peer B is also behind
    another NAT.  Peer protocol should make use of the methods which are
    proposed in BEHAVE and MMUSIC WG and provide any unique requirements
    because of P2P to these working groups.

    5.3 Problem 2: Lost Information

Jiang                    Expires August 5, 2007                 [Page 8]
Internet-Draft                   P2PSIP                    February 2007

    Nearly all DHT algorithms could work well even if the Peers join and
    leave the overlay frequently.  But if a Peer fails suddenly, the
    disaster may happen for a naive implementation.  For example, at the
    beginning, the whole user location information is stored among all
    Peers.  All of a sudden, Peer B does not work and does not notify
    others in overlay.  It means that others in the overlay may not
    notice disappearance of Peer B and Peer B has not transferred the
    information stored on it to another peer somewhere in the overlay.
    As a result, the information stored on Peer B is lost.  So, Peer
    protocol must address this problem, otherwise P2PSIP will not work,
    or may work badly.

    5.4 Problem 3: Low efficiency

    One major function of Peers is to route messages through the overlay
    and find the responsible Peer for the message.  Unlike topology in
    Figure 1, real P2P systems often have at least thousands of nodes.
    In such a large system, latency arising from message routing through
    overlay should not be ignored.

    To improve the lookup efficiency, we could consider methods in two
    lines of attack.  One is to optimize routing efficiency and shorten
    the hops of the signalling path.  The other is to put the requested
    information as near to the requesting peer as possible.  The latter
    consideration may require that the users' location information  
should
    be cached in the overlay other than the original information.  The
    overlay will need some synchronization operations to keep the caches
    correct.  The former may require that Peers collect more topology
    information to speed up lookup operation.

6.  Requirements

    In this section, we will summarize the requirements for Peer
    protocol.  The basic requirements are DHT topology related and other
    requirements concern about availability, efficiency of the
    distributed location service.

    6.1 Basic requirement for Peer protocol

    o  Peer protocol should rely on a transport mechanism which could
       guarantee reliable message delivery.  Whichever candidate
       transport protocol will be chosen, it should meet some key
       requirements: 1) extensibility.  The chosen transport mechanism
       should be flexible so that it could accommodate various DHT
       algorithms.  SIP does well in terms of extensibility. 2)
       efficiency.  In DHT algorithms, there are a lot of messages which
       are triggered by some operations.  For example, Chord-based peers
       periodically update their finger table.  This procedure will
       produce a large number of message exchanges.  So the ratio of net
       payload to message size should be kept as high as possible.  One
       message or one fragment fails may result in a failed transaction.

Philip: When you say "transport mechanism" I am thinking of a transport
layer protocol (UDP, TCP, etc.), especially since you talk about  
reliable
message delivery.
However, I don't think that either of your two subpoints  
(extensibility and efficiency)
have anything to do with the transport layer.

    o  Peer protocol must provide a few primitive functions which are
       essential for most DHT algorithms.  These primitive functions
       include: join, leave, put, get, remove.  The above primitive
       functions could be thought of as building blocks of Peer  
protocol.
       As Peer protocol evolves, new primitive functions will be  
added in
       the future.

    o  Peer protocol should provide routing function in the overlay.
       Each Peer should forward or redirect messages for the rest of the
       overlay.

    o  Peer protocol should provide redundant storage function in the
       overlay.

    o  Peer protocol should accommodate a few existing DHT algorithms  
and
       at the same time, be extensible enough to support new DHT
       algorithms in the future.

Philip: I think the requirements should be written in terms of a  
Distributed
Database algorithm, and not make the assumption that it is a DHT.

    o  Peer protocol should allow Peers to communicate with each  
other by
       traversing NAT device.

    6.2 Availability

    Through the comparison between C/S SIP and P2P SIP, we come to a
    conclusion that availability must be addressed in Peer protocol.
    Various specific methods may be used.  After examining some existing

Jiang                    Expires August 5, 2007                [Page 10]
Internet-Draft                   P2PSIP                    February 2007

    works, such as PAST[7], CFS[6], we identified some methods for
    improving availability and present them in following text.

    o  Neighbor detection: Peer protocol maintains dynamic topology of
       overlay network and keeps adjusting topology as Peers join and
       leave overlay, whether gracefully or ungracefully.  If a Peer
       leaves the overlay ungracefully, the rest of overlay must adjust
       the topology.  The availability may be lost during the time.  So,
       Peers who have adjacent relationship should have some methods to
       detect if Peers are alive.

    o  Replication: In case of the unique copy's loss from failed Peers,
       a feasible method to improve availability is to replicate the
       unique copy and place several copies into the overlay.
       Replication function could be thought of as overlay function and
       information requestors are not aware of how the replication  
works.
       In [5], David has proposed another replication method in which
       information producers explicitly produce replicas and information
       requestor should try different replicas until one of them is
       found.

Philip: I don't think that either Neighbor Detection or Replication  
are requirements.
The requirement is robustness against various forms of failure,
and neighbor detection and replication is two ways to implement this  
requirement.
I think it would be very useful to list various failure modes and state
whether protection against this failure mode is a requirement or not.

    6.3 Efficiency

    Because location service is used to support interactive  
communication
    applications, Peer protocol should be designed to have high lookup
    efficiency, even if the route table does not reflect the dynamic
    topology accurately due to Peer's churn.  In order to speed up  
lookup
    process, some enhancements have been specified in existing DHT
    systems, including PAST[7], CFS[6].  Caching is a commonly used
    method.  In future, other methods may be identified and proposed.

    o  Peer protocol should have a cache mechanism to shorten the hops
       traversed from requesting Peer to the destination and speed up
       lookup operation.

Philip: I don't think that having a cache mechanism is a requirement.
The requirement is efficiency, and a cache mechanism is one way
to meet this requirement.

[snip]

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

---

From: JiangXingFeng <[email-masked]>
Date: Sat, 10 Mar 2007 15:47:02 +0800

Hi, Philip:

Thanks for your thorough reading and valuable comments!  Please see in line.

My comments are flagged by [JiangXingFeng].

1.    o  Transient: Peers join the overlay if they want to communicate with
       other members of the overlay.  They may leave the overlay at any
       time for a variety of reasons.  So the time Peers stay in the
       overlay is transient because of their frequent join and leave
       operations.

Philip: In a VoIP system, I don't think peers are a transient as in a file
sharing system. There is a strong incentive for someone to keep her/his
phone on the overlay to receive calls.

[JiangXingFeng] You are right. Nodes in a file sharing system behave more
transient than in P2PSIP. It means that the P2PSIP overlay topology does not
change rapidly as what other P2P overlays do. But here what I want to
express is that Peers in P2PSIP overlay is more transient than servers in
Client-server application. This characteristic will influence the stability
of overlay topology. So we should consider it in the design of Peer
protocol.

Maybe we could further consider the difference about transient quality
between VoIP and other P2P applications and design a peer protocol more
adapted to VoIP situations. What about do a comparison between peers in
different P2P applications in transient quality in the next version? 

2.    o  More frequent failure: a Peer often runs on a PC.  Its stability
       is much lower than that of a server.  It is easily subject to
       failure without notifying others in overlay.  If that happens,
       overlay topology is not correct, and must be repaired.

Philip: This may be true for peers that run on PCs, but I don't think it is
true for peers that run on hard phones. And even PCs have become a lot
better these days. I suspect that the average uptime will be on the order of
weeks, not days,

[JiangXingFeng] This characteristic is also gotten by comparing peers with
servers. IMHO, although hardware where peers reside on are more stable than
before, we still couldn't assume that peer will always be available. For
example, peers will leave the overlay ungracefully because of failure.  But
this comment is good and I will consider analyzing the peer's
characteristics in P2PSIP situation. 

3.    o  Efficiency: In C/S SIP, the lookup operation is executed in a

Philip (nit); You don't say what "N" is, and you don't specify the base of
your Log (which matters if you are not using the big-O notation).
More fundamentally, there are DHT algorithms where the lookup takes
O(1) steps. Even the Chord algorithm can be made to run in less than Log2(N)
steps by simply adding more finger table entries.
[JiangXingFeng] you are right. I will correct it. There are some more
efficient algorithms in academic research. Do you think it could be applied
to P2PSIP? Is this paper " Achieving One-Hop DHT Lookup and Strong
Stabilization by Passing Tokens" written by Ben Leong and Ji Li that
introduce the algorithm which take o(1) step to complete lookup operation?
	
4.

Philip: When you say "transport mechanism" I am thinking of a transport
layer protocol (UDP, TCP, etc.), especially since you talk about reliable
message delivery.
However, I don't think that either of your two subpoints (extensibility and
efficiency) have anything to do with the transport layer.
[JiangXingFeng] I agree with you that the two subpoints haven't tightly
relations with the transport layer. I will modify this section later. But I
think the transport efficiency mentioned in my draft should be considered in
the design of Peer protocol. What about your opinion? 

5.
Philip: I think the requirements should be written in terms of a Distributed
Database algorithm, and not make the assumption that it is a DHT.
[JiangXingFeng] there are a lot of distributed Database algorithms. Some of
them are DHT-related, but most of them are non-DHT related? Does peer
protocol have all distributed Database algorithms in mind?  Comments are
welcome!

6.

Philip: I don't think that either Neighbor Detection or Replication are
requirements.
The requirement is robustness against various forms of failure, and neighbor
detection and replication is two ways to implement this requirement.
I think it would be very useful to list various failure modes and state
whether protection against this failure mode is a requirement or not.

    6.3 Efficiency

    Because location service is used to support interactive communication
    applications, Peer protocol should be designed to have high lookup
    efficiency, even if the route table does not reflect the dynamic
    topology accurately due to Peer's churn.  In order to speed up lookup
    process, some enhancements have been specified in existing DHT
    systems, including PAST[7], CFS[6].  Caching is a commonly used
    method.  In future, other methods may be identified and proposed.

Philip: I don't think that having a cache mechanism is a requirement.
The requirement is efficiency, and a cache mechanism is one way to meet this
requirement.

[JiangXingFeng] As for these two comments, you think robustness and
efficiency are requirements and methods proposed in this draft are not
requirements. 

IMHO, availability and efficiency are performance parameters of a system. It
is too vague to standardize them. So my idea is to identify some methods
which we could call them function requirements to meet the requirements of
availability and efficiency. We should identify some basic function
requirements first. Maybe as peer protocol evolves, some other methods
appeared and may be chosen as a function requirement to be standardized.
What about your opinions, Philip.  Comments are welcome.
--
Jiang XingFeng