Subject: [P2PSIP] Review of draft-vidya-p2psip-eclients-00

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Jul 2009 09:47:58 -0700

$Id: draft-vidya-p2psip-eclients-00-rev.txt,v 1.1 2009/07/27 14:42:14 ekr Exp $

After reading this draft, I don't see what it brings to the party.

RELOAD currently supports clients in two ways:

1. Clients can attach to the peer responsible for their node ID
   (I'll call this RP). At this point they're universally reachable,
   but through the RP.

2. Clients can attach to arbitrary other peers in the overlay.
   They can immediately send request through those peers,
   and responses will pass back through those peers via
   symmetric routing. If you advertise a route stack, you can
   arrange that requests go to you directly. Otherwise, requests
   have to go through the RP.

Note that these approaches can be used in tandem. I.e., you connect
to the RP for requests *to* you and to other (topologically closer
on the real network) closer to you for requests from you.

As I understand the value proposition of this draft, it is intended
to serve in cases where either the RP is unreachable from the
client or merely unattractive. The way it does this is by having
the client connect to a Direct Attachment Point (DP) which then
connects to the RP (called OAP here). As before, requests to
the client go through the OAP and then the DAP, but the client
can originate requests through the DAP. This is presented as an
optimization, and it is over method (1), but it's not really
an optimization over methods (1) and (2) used together.

The one respect in which it is an improvement, that I can see,
is that it covers cases in which the client cannot connect
directly to the RP or in which the client is mobile and would
have to repeatedly reconnect to the RP, whereas the DAP can
be used as a stable point. 

However, it seems to me that this same effect could be achieved
simply by having the DAP actually be a TURN server. The client
could then connect to the TURN server and through it to the
RP. You get the same message paths, but there's no additional
protocol mechanisms required to tell anyone that this is
a client--everything just works. It also has the additional advantage
that because TURN servers have public IPs, you know you won't
have to send OAP-DAP messages through the overlay.

-Ekr

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 27 Jul 2009 18:54:03 +0200

> have to send OAP-DAP messages through the overlay.

This doesn't work when peers can be behind NATs.  There's no way to
ensure that the responsible peer has a public IP and can be a TURN
server.

I think the concept of allowing a client to be contacted by routing a
message to the client's Node-ID regardless of whether it is directly
attached or not is a very useful one.  I think a couple minor changes
might be needed to the base draft to allow an extension or usage to
specify how to do/manage this behavior, but I believe it's definitely
worth the effort.

Bruce

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Jul 2009 10:08:55 -0700

On Jul 27, 2009, at 9:54 AM, Bruce Lowekamp <[email-masked]> wrote:

> On Mon, Jul 27, 2009 at 6:47 PM, Eric Rescorla<[email-masked] 
> > wrote:

That's not what I said. The dap, which has no special node  
relationship with the client, is the turn server.

> specify how to do/manage this behavior, but I believe it's definitely
1. I'm unconvinced. The arguments presented so far seem weak
2. The changes in this draft don't seem minor to me

Ekr
> Bruce
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 27 Jul 2009 19:17:01 +0200

On Mon, Jul 27, 2009 at 7:08 PM, Eric Rescorla<[email-masked]> wrote:
> That's not what I said. The dap, which has no special node relationship with
> the client, is the turn server.

The DAP was being selected for other criteria, such as having an
existing bluetooth connection to the client.  That doesn't make it a
good candidate for a turn server, either.

> 2. The changes in this draft don't seem minor to me

I think the changes needed to the base draft to support
extensions/usages for client routing are minor.  Managing it properly
is more complicated, which I think is a good topic for this draft.

Bruce

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 28 Jul 2009 06:43:26 -0700

At Mon, 27 Jul 2009 19:17:01 +0200,
> good candidate for a turn server, either.

Well, you don't actually need to be a full TURN server, just one
good enough to do ordinary connections. 

But that said, I don't find this Bluethooth special case very
compelling. If you're going over Bluetooth, this is much more like
having a split client and much less like having a client with an
IP connection to some DAP.

-Ekr

---

From: [email-masked]
Date: Tue, 28 Jul 2009 17:23:50 +0200

[email-masked] 写于 2009-07-28 15:43:26:

> > >> On Mon, Jul 27, 2009 at 6:47 PM, Eric 
Rescorla<[email-masked]>
> IP connection to some DAP.

I think there are two scenarios where the client should not always connect 
to the OAP:
1. For traffic localization purpose, the client attaches to a 
geographically nearer peer.
2. To keep the service more reliable, the client connects to two or more 
peers.

Russell Wang

> -Ekr

--------------------------------------------------------
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.