Subject: [ppsp] Question about using Peer-ID in peer list

From: [email-masked]
Date: Wed, 3 Nov 2010 16:38:55 +0800

Hi all,

   In the latest draft of peer protocol and tracker protocol it is 
proposed that
the peer list only contains Peer-ID, and RELOAD is used for peer location 
and NAT
traversal:

draft-gu-ppsp-peer-protocol-01:page 3-4

"The peer contacts the tracker to obtain a Peerlist containing a
list of peers participating in the particular swarm the peer is
interested in.

...

* This list does not contain IP addresses, but rather RELOAD
Peer-IDs."

My concern about this design choice is that some related protocols, such 
as ALTO, 
implicitly assume that the IP address is used in the peerlist. If the 
tracker 
only records the Peer-ID, it will not be able to consult ALTO server using 
the 
RELOAD Peer-ID, which is specific to the overlay and possibly not known to 
the ALTO
server maintained by the ISP. It would also quite difficult for the ALTO 
server to 
relate the Peer-ID to a network location.

As ALTO aim to serve for similar applications as ppsp, we need to find out 
a way to use 
it for PPSP based systems. One solution would be asking the tracker to 
record both the 
IP address and the Peer ID. But, it would be strange not to return the IP 
address when it 
is already available in the tracker. Another way is to ask peers to 
consult the ALTO server 
after the ICE procedure. However, this solution brings much more overhead. 

Wang Wei

ZTE 
Email: [email-masked]

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 3 Nov 2010 10:43:28 -0400

Yep, this needs to be included in the design, but I still think
peer-IDs are the right way to go for transport. We may very well need
to include IP address in the supplemental information that is carried
in a peerlist (or provided in a search for find peers) to let peers
select appropriate matches. There will be many bits of supplemental
information (often self-reported, so used as a guide only) that may be
included in a peerlist returned from a tracker to help peers choose
which other peers they should connect to. These could include IP
address (which can then be used with ALTO), capabilities such as
connection type or CPU, etc.

Using Peer-ID for the actual connection/routing ensures all peers are
reachable via messages before NAT traversal (and RELOAD then provides
a good mechanism for NAT traversal). IP addresses can be provided
along with other supplemental information to be used to select which
peer(s) are best to connect to, but using them for connectivity is a
bad idea. When peers are behind certain kinds of NATs, even having
valid peer addresses will not allow them to connect. With a DHT
structure and using Peer-IDs, this isn't a concern. If ALTO is used
and requires IP addresses, this can be included as supplemental
information, but at least in my thoughts so far, Peer-IDs seem like a
better choice for location and initial message routing between peers.

David

On Wed, Nov 3, 2010 at 4:38 AM,  <[email-masked]> wrote:
>
> Hi all,
>
>    In the latest draft of peer protocol and tracker protocol it is proposed
> that
> My concern about this design choice is that some related protocols, such as
> ALTO,
> As ALTO aim to serve for similar applications as ppsp, we need to find out a
> way to use
> is already available in the tracker. Another way is to ask peers to consult
> the ALTO server

---

From: Ye Wang <[email-masked]>
Date: Wed, 03 Nov 2010 16:53:09 -0400

On Wed, 2010-11-03 at 10:43 -0400, David A. Bryan wrote:
> peer-IDs are the right way to go for transport. 

I agree.  Using peer ID in protocols can enable more general transport
solutions and more general application designs.

For example, we can have an application that allows a client to
concurrently participate in multiple streaming channels (P2P sessions)
like this: the client listens on a single IP address:port, while it uses
different peer IDs in different channels.

> We may very well need

Encoding IP address in peer list certainly allows each peer to use this
info in its peering.  However, we probably don't want to force the peer
list to always include IP address, as we can envision that some
applications may not like this, due to privacy or other concerns.
We just want to make sure it is easy to extend protocol messaging so
that the supplement peer info (including IP address) can be added.

Another comment is: since the tracker has IP address information of each
peer, the tracker can directly apply ALTO info in its peer selection
process.  The application should already enjoy a lot of ALTO benefits
using this approach.

> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp

---

From: [email-masked]
Date: Thu, 4 Nov 2010 08:24:27 +0800

Yes, I agree that Peer-ID is a better way for transport. Maybe we should 
allow
IP address and other identities in the supplemental information, as there 
are 
cases where Peer-IDs are not available:
  -- Third party CDN servers which do not wish to participate in RELOAD
  -- Other ppsp systems which operates on their own RELOAD overlays
  -- CDN systems which wish to do load blancing by themselves

Maybe allowing different types of identities and letting the peers choose 
the way for
transport is a more flexible way.

Wang Wei

ZTE

"David A. Bryan" <[email-masked]> 
发件人:  [email-masked]
2010-11-03 22:43

收件人
"wang.wei108" <[email-masked]>
抄送
guyingjie <[email-masked]>, "[email-masked]" <[email-masked]>, 
"meng.yu" <[email-masked]>, "hao.zhenwu" <[email-masked]>, 
"li.lichun1" <[email-masked]>
主题
Re: Question about using Peer-ID in peer list

David

>    In the latest draft of peer protocol and tracker protocol it is 
proposed
> My concern about this design choice is that some related protocols, such 
as
> is already available in the tracker. Another way is to ask peers to 
consult

---

From: lichun li <[email-masked]>
Date: Thu, 4 Nov 2010 21:17:32 +0800

Hi, David

A peer may have multiple IPs, and mobile peers may change their IPs.
So I believe that
using peer ID to identify peer is a must. But using RELOAD should be an option.

In RELOAD's NAT traversal mechanism, RELOAD protocol is only used to exchange
ICE parameters including candidate addresses and other parameters for
connectivity checks.
Then ICE connectivity checks are used to test connectivity of address pairs.
If candidate addresses can be extracted from peer list, there is no need to use
RELOAD for NAT traversal.

When peers are behind certain kinds of NATs, they can’t be connected
via their host addresses
or reflexive addresses. But they can be connected via their relayed
addresses or proxy addresses.
If these peers’ relayed addresses or proxy addresses can be found in
peer list, there is no need to
use RELOAD for NAT traversal.

There are also some disadvantages of using RELOAD. First, RELOAD is a
heavy protocol.
Introducing RELOAD complicates the implementation of PPSP peer, and
requires deploying
RELOAD's configuration/enrollment server. Second, exchanging ICE
parameters with RELOAD
APPATTACH requires O(log N) overlay hops, which causes high latency.
Third, using RELOAD to discover TURN service node also requires O(log
N) overlay hops.

BR
Lichun Li
ZTE Corporation

---

From: "David A. Bryan" <[email-masked]>
Date: Thu, 4 Nov 2010 10:54:44 -0400

Hi, comments inline...

> using peer ID to identify peer is a must. But using RELOAD should be an option.

Yep, that is another good reason to use Peer-ID. I'm a bit confused
what you have in mind here, however. If you want to use PeerIDs for
routing, you need to provide some mechanism to locate peers based on
that ID. The alternatives I see off the top of my head are a large
unstructured P2P network, which has many problems (including no
guarantee of routing success), defining a completely new DHT and
protocol (which seems pointless since the IETF has a protocol for this
already) or the tracker must serve as a registration server ala SIP (I
ask it to provide the IP address/relay address for a given PeerID
everytime I need to connect). I really don't like the idea of a
centralized registration server. I might be missing another
possibility however, so I'd be curious what you had in mind to allow
you to locate a peer given the Peer-Id.

I'd definitely be fine with designing the tracker protocol in such a
way that you could use different peer protocols, with a RELOAD style
peer protocol being only one option. For example, I could imagine
small deployments wanting to just use an unstructured mesh between the
peers or something. In a private, managed network, they may not even
need to worry about NAT traversal. However, for an internet wide
deployment, after thinking for a while, it really looks like we need
something like RELOAD, although I'm certainly still interested in
hearing other options and recognize the complexity it introduces.

more comments below...

> use RELOAD for NAT traversal.

Peers can of course be reached via relayed or proxy addresses, but if
this information is stored in the tracker, it seems like a big problem
with churn. With RELOAD you have multiple paths to route via the DHT
to reach the peer.

I have only taken a quick look, so I may be missing something, but in
an approach were some peer is serving as a designated relay or proxy
(for example the proposal in draft-li-ppsp-nat-traversal), don't we
need to build in a new mechanism to keep multiple connections, and
would need to send an update to the tracker each time a relay or proxy
leaves? I'm also worried about orphans here. If I am connected via a
proxy peer and my proxy dies or leaves, no one (except maybe the
tracker, who I have a direct connection to?) could reach me.

We then need to add protocol mechanisms to:

1) Provide registrar-style capabilities that need to be built into the
tracker to provide Peer-ID to IP/relay peer IP mapping in place of
DHT-style routing
2) Detect that my proxy has failed (tracker pings? peer pings? How often)
3) Decide which address to try if I have multiple relays, or else send
requests over many paths?
4) Update the proxy and peers I am providing proxy services to when I leave.
5) Fall back that if I fail to a reach a peer via relay, I need to
notify the tracker, which then either has to serve as a relay or else
it must have mechanisms to invalidate the current proxy peer on
record, contact the target peer, inform it that it has a new proxy,
negotiate the connection and then finally provide the new proxy to the
sending peer.

With all these extra capabilities added, I'm personally not convinced
this is actually simpler than a DHT. If you don't add this, this
approach does have less overhead than a full DHT, but also provides a
far more brittle system.

I'm not saying it isn't worth considering, but the current proposal is
far too simplistic to actually work, and until I see a proposal that
addresses all these concerns and is still lightweight, I don't think
the overhead of a RELOAD style DHT is so high when you consider what
it gains you.

> There are also some disadvantages of using RELOAD. First, RELOAD is a

Well, that is debatable. It certainly isn't tiny, but the capabilities
it provides are quite large, and the encoding is actually rather light
(personally I like text protocols, but since RELOAD is binary, it is
lighter).

I'm not yet convinced that by the time you build in all the things
needed for an approach like draft-li-ppsp-nat-traversal, with the
error handling capabilities I mentioned above, plus add
registrar-style peer-ID to address mapping in the tracker that you
won't actually have just as much complexity.

> RELOAD's configuration/enrollment server.

It is true that RELOAD will complicate the implementation of the peer
slightly, but again, see above, I don't think it is much more than
other approaches. The configuration/enrollment server is contacted
once, at enrollment, not even at join time.

Second, exchanging ICE
> Third, using RELOAD to discover TURN service node also requires O(log

True, but the O(log N) cost is not on each data packet, it is at setup
time. Not sure about this yet, but my gut tells me that this isn't
likely to be a problem, although we need to carefully consider channel
changes. A topology aware DHT, combined with an ALTO server for peer
selection could radically reduce this cost. This is a big concern
however, and I'd like to hear the experiences of those who have
deployed systems.

I'm certainly not saying RELOAD is the only choice. We have been
debating this ourselves for sometime. As you point out, there are some
drawbacks, but I think the complexity of other solutions, and
particularly the difficulty in making them properly handle NAT
traversal under high churn is a major problem. If we can make a
simpler approach than a DHT work, that would be great, I'm just not
convinced we can yet.

David

---

From: lichun li <[email-masked]>
Date: Fri, 5 Nov 2010 11:02:58 +0800

Hi, comments inline

> hearing other options and recognize the complexity it introduces.

I didn't say locating peer with peer ID. I think using RELOAD is an
option, because RELOAD is not the best solution for locating peer and
NAT traversal at least in some scenarios. I have proposed another
solution without RELOAD in draft-li-ppsp-nat-traversal. Both solutions
have some pros and cons. Also, as you pointed out, NAT traversal is
not required in some scenarios.

> We then need to add protocol mechanisms to:> 1) Provide registrar-style capabilities that need to be built into the

> the overhead of a RELOAD style DHT is so high when you consider what

About the 5 mechanisms you proposed, I agree that most of them are
required. However, Reload's client routing also requires similar
mechanisms. Moreover, comparing with RELOAD's other mechanisms (peer
routing, overlay maintaining, fetching/storing/replicating,
diagnostics, self-tuning and TURN service discovery), these mechanisms
are much simpler.
Mechanism 1) is also required by using ALTO and STAT_QUERY. NAT
traversal just utilizes this existing mechanism. About mechanism 2),
tracker protocol has a keepalive message. I think peer protocol may
also need a keepalive message not just for NAT traversal. Mechanism 5)
is not necessary. Peer can simply update peer list, and let mechanism
3) and 4) update relayed/proxy address.

> however, and I'd like to hear the experiences of those who have

Some scenarios have strict requirements on latency. We should consider
not using RELOAD in these scenarios

> simpler approach than a DHT work, that would be great, I'm just not

With the mechanisms you proposed, handling churn wouldn't be a problem.
As I analyzed above, I think these mechanisms are much simpler
compared with RELOAD.

-- 
Sincerely yours,

Lichun Li
ZTE Corporation