[p2p-sip] My notes on draft-willis-p2psip-concepts-01
David A. Bryan
bryan at ethernot.org
Wed Sep 27 18:45:43 EDT 2006
I don't believe that adaptor node made it into the terminology draft,
but I'm fine with using it as a label if others are comfortable. (it
just never happened to come up in that discussion).
On 9/27/06, Spencer Dawkins <spencer at mcsr-labs.org> wrote:
> Thanks, both Eunsoo and David, for quick feedback.
> >> > What I was trying to show in this figure was that the UA Client C is
> >> > aware
> >> > of the P2PSIP overlay, while the SIP UAs A and B are not.
> >> A Client node should send its GET/PUT requests to a Peer (or Peers). In
> >> other words, the Client Protocol is spoken between a Client and a Peer.
> >> In that sense, I guess it would be better if the line from UA Client C
> >> is connected to one of Peers. What do you think?
> > Agree
> Cool. Should I just show the Peer as "Peer F", or is there a better term? I
> think I'm asking if I should include David's term "adaptor node" in the
> >> >> Peers are supersets of clients. Everything a client can do, a peer
> >> >> can
> >> >> do.
> >> >
> >> > I really like this sentence - if others agree, I'd like to see it in
> >> > the
> >> > draft.
> >> >
> >> I agree.
> > One caveat to be a bit closer. The statement "all P2PSIP overlay peers
> > are P2PSIP overlay clients" is true. The statement "all P2PSIP overlay
> > peers are SIP UA clients" may not be. There could be adaptor nodes, as
> > described in draft-bryan-sipping-p2p-02. These could serve as P2PSIP
> > overlay peers, but would have no SIP endpoint functionality -- they
> > would only serve to adapt traditional SIP UA clients that are not
> > P2PSIP overlay client protocol aware so they can communicate with the
> > network.
> Thanks for this clarification. It also helps.
> >> How should the Client choose a
> >> > specific overlay peer?
> >> A Client can get information about some existing Peers from P2PSIP
> >> Overlay Bootstrap Server. The Client can keep the information and send
> >> the PUT/GET request to those Peers.
> >> Over the time, the Client may be able to find other Peers. We should
> >> make sure there is a mechanism for that. Otherwise, many Clients may be
> >> stuck with the same set of Peers that are known to the Bootstrap Server.
> >> One possible solution is to assign a Node ID to the Client as well and
> >> let the Client talk to the Peer whose Node ID is closest to the Client's
> >> Node ID. It works because the Client should be able to find a Peer whose
> >> Node ID is closest to the Client's Node ID from DHT.
> > Could be many mechanisms here. Configuration of known persistent peer,
> > broadcast to find peer, etc. One of the many reasons I am so keen on
> > using pure SIP for the client protocol is that if one bootstraping
> > peer is overloaded, it can simply 302 (or perhaps 301 if it wants this
> > requestor to keep using another peer) incoming requests off to a less
> > loaded peer. In my draft, the bootstrap peer basically does a first
> > level lookup and always offloads, keeping the load light on any peer
> > that might be serving as a bootstrap.
> Again, thanks for the clarification.
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
More information about the P2p-sip