RE: [P2PSIP] Proposal for progress on protocols

[Zheng Hewen <[e-mail]>]

Hi,

   Please see inline....

Best regards,
Hewen

-----Original Message-----
From: Wei Gengyu [mailto:[e-mail]]
Sent: 2007Äê11ÔÂ12ÈÕ 22:55
To: Zheng Hewen
Cc: [e-mail]
Subject: Re: [P2PSIP] Proposal for progress on protocols

Hi,

SIP has been widely used between SIP client and proxy or servers, and it is easy to get some testbed results.

And we have to see the fact that there are many mobile terminals installed with SIP UA.
When considering the mobile terminal as a client of P2PSIP overlay, the SIP protocol is cheap and suitable.

[Hewen] You are right. If a peer acts as SIP proxy, then the unmodified SIP protocol can completely act as the communication
protocol between the peer and its associated clients, at this time, a client protocol is not necessary. If a peer does not
couple with any SIP entity as in Reference model, a client protocol is desire and SIP is not the choice since the peer Does
Not couple with a SIP entity. P2PSIP is used in the other scenarios besides mobile communication, do you think so? A suite
of general P2PSIP protocols should be preferred. In IETF69, it is consensus that separate P2P layer is preferred than
extending SIP considering some known limitation of extension of SIP protocol.

While in "Concepts and Terminology for Peer to Peer SIP draft-willis-p2psip-concepts-04"
or "Concepts and Terminology for Peer to Peer SIP" (draft-ietf-p2psip-concepts-00), "An overlay may or may not also include
one or more nodes called
   P2PSIP Clients.  The role of a client in the P2PSIP model is still
   under discussion, with a number of suggestions for roles being put
   forth, and some arguing that clients are not needed at all.  However,
   if they exist, then people agree that they will also be able to store
   and retrieve information from the overlay.  Section 5.5 discusses the
   possible roles of a client in more detail."

In section 5.5:
"In one alternative, a client interacts with the P2PSIP overlay
   through an associated peer (or perhaps several such peers) using the
   Client Protocol.  The client does not run the distributed database
   algorithm, does not store resource records, and is not involved in
   routing messages to other peers or clients.  Though interactions with
   its associated peer, a client can insert, modify, examine, and remove
   resource records.  A client can also send SIP messages to its
   associated peer for routing through the overlay.  In this
   alternative, a client is a node that wants to take advantage of the
   overlay, but is unable or unwilling to contribute resources back to
   the overlay.

   One way to realize this alternative is for a peer to behave as
   [RFC3261] proxy/registrar.  Clients then use standard SIP mechanisms
   to add, update, and remove registrations and to send SIP messages to
   peers and other clients.  If this is done, there is no need for a
   separate Client Protocol and no need for P2PSIP to define a distinct
   "P2PSIP Client" concept."

   And there are also second and third alternatives.

[Hewen] The original Concept document need modification, IMHO, it is primitive somewhere, the definition of a client
character from the Reference model is clear, but the Section 5.5 describes some confused behaviors. In detail, the first
alternative potentially that the peer couples with a SIP entity(proxy/registrar), hence SIP protocol is enough and a client
protocol is not necessary, at the same time any extension of SIP protocol is not necessary, but  P2PSIP provides an
alternative to the SIP discovery process of RFC 3263, it means that a SIP entity is not mandatory for a peer, the true
requirement for a client protocol between a peer without any SIP entity and a client with a SIP UA; the second alternative
requests a client can contribute its storage capacity to its associated peer, in this scenario, if SIP is adopted as the
underlying protocol for the client protocol, we have to extend SIP protocol, but the extension is limited/prohibited by
RFC4485. The third alternative is strange, it thinks that a client has a "Peer-ID", but in IETF69, we think that a client is
a non-overlay-routing node (e.g., the P2PSIP overlay is transparent to any client). In summary, for a client protocol
between a peer and its associated clients, we only need to think about two scenarios: (1). the interaction between a peer
without any SIP entity and a client with SIP UA; (2). a client contributes its storage capacity to its associated peer, and
at the same time, SIP is already not a choice. We need to update Section 5.5 in Concept document according to the Reference
model.

My opinion is that adopting SIP between the client and the associated proxy Peer will be simplify the facilities to support
mobile clients in the reference model.

Best regards,

Gengyu

----- Original Message -----
From: "Zheng Hewen" <[e-mail]>
To: "'Wei Gengyu'" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, November 12, 2007 6:52 PM
Subject: RE: [P2PSIP] Proposal for progress on protocols


>
> Hi,
>
>    In my understanding according to P2PSIP Reference model defined in "Concepts and Terminology for Peer to Peer SIP"
> (draft-ietf-p2psip-concepts-00), SIP is not eligible to act as a communication protocol between a peer and its associated
> clients.
>    Further, in detail, considering those reasons as below, SIP is not eligible to be chosen as the signal underlying
> protocol of P2PSIP client protocol:
>   (1). SIP does not exist between a client and its associated peer at some scenarios.
>   According to P2PSIP Overlay Reference Model depicted in Figure 1 in "Concepts and Terminology for Peer to Peer SIP"
> (draft-ietf-p2psip-concepts-00), P2PSIP client protocol runs between a peer without any SIP entity and a client with a SIP
> entity, the peer does not recognize SIP protocol, SIP is not eligible to act as the signal underlying protocol of P2PSIP
> client protocol.
>
>   (2). SIP is not a general Remote Procedure Call (RPC).
>   A P2PSIP client protocol on top of SIP acts as a remote procedure call (RPC) mechanism.  The SIP guidelines document
> [RFC4485] prohibits the use of SIP as a RPC mechanism.
>
>   (3). SIP is not a general purpose transfer protocol.
>   One of P2PSIP client protocol main tasks is to transfer resource object and its content, those contents is irrelevant to
> SIP.  SIP's operation and the SIP guideline document [RFC4485] prohibit sending large amounts of data unrelated to SIP's
> operation.
>
>   (4). SIP is not a lookup protocol.
>   SIP is not a lookup protocol; it relies on DNS to locate an appropriate SIP server.  Insert and lookup functionality is
> essential for any P2PSIP client protocol.  Using SIP as a peer-to-peer protocol requires integrating lookup functionality
> into SIP which goes against its design philosophy.
>
> Best regards,
> Hewen
>
> -----Original Message-----
> From: Wei Gengyu [mailto:[e-mail]]
> Sent: 2007?11?12? 17:28
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [P2PSIP] Proposal for progress on protocols
>
> Hi, all
>
> I have a question.
>
> A peer in a P2PSIP overlay can be the proxy of a mobile client.
> Could SIP(rfc3261) be used between the client and the proxy Peer instead of defining a new protocol?
>
> Best regards,
>
> Gengyu
>
> ----- Original Message -----
> From: <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> Sent: Thursday, November 08, 2007 5:28 PM
> Subject: RE: [P2PSIP] Proposal for progress on protocols
>
>
> Hi all,
>
> I agree with Henning's proposal. There is another issue: support for
> clients.
>
> I can to volunteer for "mobility" or "support for clients".
>
> Marcin
>
>>-----Original Message-----
>>From: ext Emil Ivov [mailto:[e-mail]]
>>Sent: 07 November, 2007 18:53
>>To: P2PSIP Mailing List
>>Subject: Re: [P2PSIP] Proposal for progress on protocols
>>
>>Henning, all,
>>
>>I think this is definitely the way to go and both Enrico and I
>>(as authors of one of the proposals) would be happy to
>>contribute on any of the points in your list. We also thought
>>that there are two other issues that would probably require
>>some consideration:
>>
>>- DHT upgrades - as far as I can see, it is currently most
>>covered by ASP, but the general opinion in Chicago seemed to
>>be that this is indeed an important issue that would have to
>>be addressed by the peer protocol.
>>
>>- Mobility - taking mobility into account would probably
>>influence some of the design choices (underlying protocol,
>>session flexibility, etc..) so it might be worth to try and
>>see to what extent would the existing proposals fit mobile nodes.
>>
>>One last thing. We should probably try and start having some
>>of these discussions before the meeting or, even better, to
>>find some way to foster offline work on each topic, since they
>>are likely to require more than the time we'll have there. I
>>guess that Philip's presentation in Chicago was made with the
>>same intentions, but it was pretty clear that the time we had
>>was insufficient for any meaningful discussions.
>>
>>Cheers
>>Emil
>>
>>Henning Schulzrinne wrote:
>>> 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. 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
>>> - hash algorithm negotiation and usage
>>>
>>> One possibility is to identify a volunteer for each area, so
>>that the
>>> task is more manageable. If there are major philosophical
>>differences,
>>> we should probably discuss those first, however.
>>>
>>> Henning
>>>
>>> _______________________________________________
>>> P2PSIP mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/p2psip
>>>
>>
>>_______________________________________________
>>P2PSIP mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/p2psip
>>
>
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/p2psip
>
>
>
>





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