Subject: [P2PSIP] Extending the (inclusive) merge for P2PSIP

From: "Henry Sinnreich" <[email-masked]>
Date: Sat, 1 Mar 2008 04:12:42 -0800

As mentioned, here is how to extend the inclusive merge for P2PSIP with
the best proposals from various authors. I hope this can make it to the
agenda of the P2PSIP WG meeting.

1.     Merge proposals. 1

2.     What's wrong with the Core Protocol in Reload-03. 1

3.     Discussion of design decisions. 1

4.     Why an editor is required. 1

1.   Merge proposals

*         Replace section 4. Base Protocol with P2PP since P2PP has all
the desirable properties: Works for structured and unstructured
overlays, has a rigorous I-D, freely available code, large scale
deployment and several independent implementations. Hopefully SIPit
testing and the SIP Forum can be engaged for interoperability testing
and debugging as well. By contrast, the present section 4. Base Protocol
is seriously flawed as shown here below. 

*         Subsection for the client protocol: The proposals for the
client protocol, one of which (draft-pascual-p2psip-clients) is based on
P2PP anyway, and should be merged here as well.

*         Security (I like these sections very much): Should the various
sections on certificate security and secure transport be consolidated
into one section on Security? Where does the security for the HIP part
belong? If HIP is secured, when/if is TLS and DTL still useful?

*         Combine the two proposals for using HIP, the high level
HIP-Bone and the detailed, step be step p2p-sip-id-loc should be merged
into one single HIP (optional for P2PSIP) section.

*         There may be more and I apologize for keeping this here to a
short list only.

*         Remove he tutorial section and replace it with references.

2.   What's wrong with section 4. Core Protocol in Reload-03

*         The basic assumption on which the whole section 4. Base
Protocol and the related section 3. Overview is written is based on
symmetric routing from the source to the root and back using the same
path. This is a flawed approach:

a.      Churn can break the return path. For a example a 95% probability
for success in the presence of churn over 10 hops each will result in a
total probability of success of 099^10=0.59, that is 59%. The media path
cannot work well if the two end points cannot see each other and there
is no solution given here for the media path. Perhaps another media
relay or using HIP? This is a missing item. In any case the media path
MUST NOT follow the symmetric search path since the delay will be
unacceptable over so many hops and unknown geographic locations that can
be anywhere on the Internet.

b.      The correct approach for non-transitivity in the DHT is to use
more than one source node for the search in the underlying DHT with
smart timeouts for "node recovery" as described in "Non-Transitive
Connectivity and DHTs", http://srhea.net/papers/ntr-worlds05.pdf  and
http://srhea.net/papers/bamboo-usenix-talk.ppt .

c.      The above shows how the DHT can do the required work and why the
whole routing (forwarding) layer with its routing tables, routing state,
retransmissions, flow control, etc. at the application level in
Reload-09 is redundant. This kills the rationale IMHO also for the
methods described in section 7. Method Definitions.

d.      As mentioned, technical terms such as connection, long hop and
nearby neighbors (leaf set) are treated in a cavalier way and this must
be fixed in the sense of using Internet and P2P terminology common in
the technical literature. A glossary with references would help.

e.      Though the use different DHTs is claimed (but not the use of
unstructured overlays), what is shown is only a nailed-down-like use of
Chord, much less general and modular as in P2PP.

3.    Discussion of design decisions

There are several design decisions that should be discussed on the list
such as the use of SIP GRUU. What is the usage scenario of using GRUU in
P2PSIP and in what cases is it useful? We already have defined how to
connect P2PSIP networks with the DNS world.

4.   Why an editor is required

The emerging P2PSIP protocol document will be on of the most complex in
the IETF, probably exceeding the size of RFC 3261. 

Such a document requires a dedicated editor having adequate quality
time, besides the authors and contributors of the various original
protocol proposals.

Thanks, Henry

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

---

From: [email-masked]
Date: Sat, 1 Mar 2008 08:10:31 -0500 (EST)

> is seriously flawed as shown here below.

The protocol in reload-03 achieves all of the requirements and is the
result of all of the reload-03 authors (yes, all) spending a lot of time
focusing on how to improve its performance.  If you believe it is flawed,
please specify how it is flawed.

> P2PP anyway, and should be merged here as well.

No separate client protocol is required.  What features of a client
protocol do you believe are not met by the base protocol?

> into one single HIP (optional for P2PSIP) section.

With all due respect to HIP and the HIP/P2PSIP authors, HIP is still an
experimental protocol, and I believe it is still a very open issue how
these two aspects of the protocol will interact.  We can try to support
the features HIP-based overlays will need, but specifying the HIP-specific
details in the base draft would be premature.

> *         Remove he tutorial section and replace it with references.

You didn't respond to my previous comment that we need to have this as a
standalone document for protocol engineers to read.

> path. This is a flawed approach:

In my previous response, I pointed you to a thread from November with
detailed discussion of the pros/cons of different routing modes.

> be anywhere on the Internet.

Most people believe that media should never be routed across the overlay
regardless of the routing mode.  TURN is assumed for deployments where a
direct connection can't be established, like regular SIP.

> http://srhea.net/papers/bamboo-usenix-talk.ppt .

That's entirely compatible with what is in reload-03. A DHT can specify
how to manage routing at that level.  It would have to be part of the DHT
specification, since it's specific to the DHT's overlay structure.  I'm
not sure whether it should be part of the base DHT or an extension, due to
the somewhat greater complexity.

> methods described in section 7. Method Definitions.

I'm not sure what you're saying here. How can a peer protocol exist
without messages?

> the technical literature. A glossary with references would help.

My response to your previous message discussed why we chose the
terminology we did.  Please suggest specific terms and what you would like
to see instead.

> Chord, much less general and modular as in P2PP.

unstructured overlays are referred to repeatedly and frequently in reload-03

> connect P2PSIP networks with the DNS world.

Absolutely.  Lots of design decisions need discussion.

Bruce

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 2 Mar 2008 08:10:10 -0800

Bruce,

At a minimum the content and key text from P2PP should have been
included in Reload-03. This has not been done. As a result, Relaod-03 in
no way reflects the code running on 500+ nodes and in other
implementations as well.

The editor(s) of Reload-03 may not have had time to include P2PP and we
understand this is work in progress, and look forward to see the merge
to be more than a claim.

In case the WG may decide to entrust the merge work to an editor
volunteering quality time, this topic may become moot anyway.

Judging from the list, more than just P2PP may be merged by a possible
selected/volunteered/neutral editor. Let's hope such an inclusive merge
will happen.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Saturday, March 01, 2008 7:11 AM
To: Henry Sinnreich
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Extending the (inclusive) merge for P2PSIP

The protocol in reload-03 achieves all of the requirements and is the
result of all of the reload-03 authors (yes, all) spending a lot of time
focusing on how to improve its performance.  If you believe it is
flawed,
please specify how it is flawed.

the features HIP-based overlays will need, but specifying the
HIP-specific

That's entirely compatible with what is in reload-03. A DHT can specify
how to manage routing at that level.  It would have to be part of the
DHT
specification, since it's specific to the DHT's overlay structure.  I'm
not sure whether it should be part of the base DHT or an extension, due
to
the somewhat greater complexity.

My response to your previous message discussed why we chose the
terminology we did.  Please suggest specific terms and what you would
like
to see instead.

> Chord, much less general and modular as in P2PP.

unstructured overlays are referred to repeatedly and frequently in
reload-03

Bruce

---

From: Song Yongchao <[email-masked]>
Date: Mon, 03 Mar 2008 18:15:15 +0800

Please see inline.

>protocol do you believe are not met by the base protocol?

You can find the features of client in draft-pascual-p2psip-clients, only
when you are clear about that, you will know what features are not met with
Reload-03. No matter whether we need a separate client protocol or a
subsection for client protocol, those features should be discussed first. I
support Victor to make a presentation and discussion of "clients" at the
meeting.  

>> belong? If HIP is secured, when/if is TLS and DTL still useful?

I think we need a separate document to discuss security issues.

>detailed discussion of the pros/cons of different routing modes.

I also don't think symmetric routing always works well under churn. But if
you have an operator to deploy these high reliable "Peers", then it will. As
consideration for various application scenarios, other routing modes and
"P2P Relay" concept must be adopted. It maybe depend on the service to
choose the specific routing mode or whether to use a "P2P Relay".

>terminology we did.  Please suggest specific terms and what you would like

I suggest a term for all those peers in an overlay. We give a term "P2P
Overlay Base" for it in our SEP client protocol
(http://tools.ietf.org/wg/p2psip/draft-zheng-p2psip-client-protocol-01.txt).
I don't know whether other guys have better terms for it. Maybe other
additional terms for other things are still needed in the workgroup.

---

From: songyongchao 64081 <[email-masked]>
Date: Mon, 03 Mar 2008 19:58:39 +0800

----- Original Message -----
From: Song Yongchao <[email-masked]>
Date: Monday, March 3, 2008 6:15 pm
Subject: Re: [P2PSIP] Extending the (inclusive) merge for P2PSIP

> 
> I suggest a term for all those peers in an overlay. We give a term 
> "P2POverlay Base" for it in our SEP client protocol

I remember we don't refer to the term "P2P Overlay Base" in our SEP Client Protocol at present, but we do refer to it in our security analysis and evaluation draft. Sorry for it.

http://tools.ietf.org/wg/p2psip/draft-song-p2psip-security-eval-00.txt

   P2P Overlay Base:A P2P Overlay Base includes all the Peers that
       participate in the p2p overlay. The P2P Overlay Base provides
       distributed storage and routing services to both peers and
       clients.

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 3 Mar 2008 09:13:36 -0500

> support Victor to make a presentation and discussion of "clients"  

Song,

Again, what protocol features do you believe are not supported by  
reload-03?

The source routing and via list allow a client to be reached via the  
peer protocol from anywhere in the overlay.  So the reload-03  
protocol is able to exchange messages both between the client and the  
peer it is using, but also between any other peer (or client)  
attached anywhere in the overlay with a client behind a peer.  In  
general, I think this framework is sufficient to meet the messaging  
needs of the various client proposals.  (It doesn't propose the  
necessary parts to implement them, but with appropriate definition of  
method types and their semantics, the necessary framework from the  
routing layer is there.)

So, as far as the general discussions in section 4, sure, reload-03  
supports clients.

Of the two specific functions proposed in section 5:

- storage provided by clients: You could certainly build this  
functionality on top of reload-03, with the peer exchanging STORE/ 
FETCH messages with its clients (or through other mechanisms).  So  
the underlying routing mechanism is there.  But at ietf-70, the wg  
voted to not focus on solving this problem in the immediate future.

- p2p relay:  I'm not completely clear on this section.  If it is a  
proposal to have clients able to act as TURN servers, there is no  
restriction in reload-03 that the turn servers are peers, clients, or  
even members of the overlay.  So I don't think there's any issue here.

Bruce

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 03 Mar 2008 06:27:13 -0800

At Mon, 03 Mar 2008 18:15:15 +0800,
Song Yongchao wrote:
> Reload-03.

Well, I certainly have reviewed that draft, but I don't think
that there's WG consensus on the exact feature set described
in it. In particular, I'm pretty skeptical about the notion
that clients will be acting as storing nodes.

> No matter whether we need a separate client protocol or a

Well, one of the nice features about RELOAD, IMHO, is that very
little explicit support for clients is needed. Basically, a client
is a node which connects to other nodes but does not issue JOINs
or UPDATEs. Therefore:

- The peers it is explicitly connected to can route to it
  directly.
- It is in their neighbor table but not their route table so
  it never routes packets.
- Because it doesn't JOIN it never stores data.

Note that a client can connect to peers at one of two places:

- At the location indicated by its peer-id.
- At a random location.

In the first case, routing to the clients peer-id simpyly works,
since it goes through the node responsible through that space,
which is directly connected to the client. In the second case,
the client can advertise a destination list [this is one use
for this feature] consisting of the peer it is connected to
and then itself.

> I think we need a separate document to discuss security issues.

I don't in principle have a problem with a separate non-normative
document containing security analysis of P2PSIP systems. 

However, I believe all of the security features need to be part of the
core protocol and the core document, which is why we built them
into RELOAD.

-Ekr

---

From: Ted Hardie <[email-masked]>
Date: Mon, 3 Mar 2008 09:46:12 -0800

>direct connection can't be established, like regular SIP.

I find statements like "media should never be routed across the overlay"
to be invitations to Murphy to muck things up.  It's clear that the base
case should be that media should be routed directly between nodes where
possible.  It's also clear that where a deployment provides adequate infrastructure
(like TURN servers), using those is preferable to routing media over the overlay.

But never?  Sorry, I'm more pessimistic than that.  The overlay ends up being
a path of last resort, and I have a strong suspicion that paths of last resort always
get used sometime.  The protocol document should be clear that it is a last resort
and why, but I believe we need to provide guidance on how to use an
overlay as a media path.  If we don't, it will get used in whatever way is
easiest, with whatever consequences that entails.  After some of the recent
proposals, I can't even come up with a scenario I'm sure is parody.  I
thought about suggesting TCP over DATA URIs, but I'm pretty sure Jonathan
has a draft on that in the works.....

					Ted

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 03 Mar 2008 10:06:28 -0800

At Mon, 3 Mar 2008 12:09:28 -0500 (EST),
Salman Abdul Baset wrote:
> For scenarios where a node initially joins as a client and later 
> decides [upon inviation from another peer] to upgrade itself to a peer, it 
> will need a mechanism to obtain the routing table of its connected peer. 
> In such a scenario, a client needs to issue an UPDATE.
>
> A client may also like to maintain connections with multiple peers incase 
> the peer it is connected to goes offline. Thus, it needs to send an 
> UPDATE to obtain a list of backup peers from its connected peers. If a 
> client connects to multiple peers, does it need to advertise multiple 
> destination lists?

I'm sorry, I don't understand your argument here. 

1. You don't need do do an UPDATE to get the routing table of a
   peer. The ROUTE-QUERY command does this.
2. The only case in which you need to use destination lists is
   you're connected somewhere other than the replica set for
   your own peer id.

> As I mentioned earlier, if a client connects to N peers to mitigate 
> against peer churn, it will need to advertise N destination lists similar 
> to a multihomed router advertising N routes. This increases the 
> state/message complexity.

Yeah, it only makes sense to choose a peer relay outside of your
own replica set if you know specifically about that peer 
and know that it's stable. Otherwise, you should use one
in your replica set.

> Further, routing by destination lists breaks during churn.

Well, sort of.

The way that this works is that the client (with peer ID P) connects
to peer X and advertises the destination list (X P). As long as X is
reachable (no matter how much churn there is) then you should be
reachable as well. Yes, this creates fate sharing with X.
That's not necessarily bad.

-Ekr

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 3 Mar 2008 10:23:54 -0800

Ted,

>The overlay ends up being a path of last resort

Having the media go over 5-10 hops, some of which may pass via several
continents due to the hashing in the DHT makes such real time media
worthless due to the delay and cut-offs.

Bruce: Can you comment on this? Reload-03 has no clear text on symmetric
routing for media.

This is an important topic (though not directly related, so I have
changed the Subject name). 

All commercial products I know have some sort of two hop tunnel via a
media server as the path of last resort or openVPN. Tunnels were however
not presented in any I-Ds, since they violate the IT rules of using well
known ports. I don't know why openVPN is not an IETF standard.
http://en.wikipedia.org/wiki/OpenVPN 

Given the reticence of going public will stuff that IT organizations
don't like, I cannot volunteer any products names, but I know several
products using tunnels.

Unless the IETF comes up with a better 100% sure way of NAT traversal,
tunnels will continue to be used in NAT traversal products.

A better solution would be HIP, but the nitty-gritty work and OS code
for HIP NAT traversal has not yes been published AFAIK. 
If this is not accurate, HIP folks, please correct me.

Thanks, Henry

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Monday, March 03, 2008 9:46 AM
To: [email-masked]; Henry Sinnreich
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Extending the (inclusive) merge for P2PSIP

I find statements like "media should never be routed across the overlay"
to be invitations to Murphy to muck things up.  It's clear that the base
case should be that media should be routed directly between nodes where
possible.  It's also clear that where a deployment provides adequate
infrastructure
(like TURN servers), using those is preferable to routing media over the
overlay.

But never?  Sorry, I'm more pessimistic than that.  The overlay ends up
being
a path of last resort, and I have a strong suspicion that paths of last
resort always
get used sometime.  The protocol document should be clear that it is a
last resort
and why, but I believe we need to provide guidance on how to use an
overlay as a media path.  If we don't, it will get used in whatever way
is
easiest, with whatever consequences that entails.  After some of the
recent
proposals, I can't even come up with a scenario I'm sure is parody.  I
thought about suggesting TCP over DATA URIs, but I'm pretty sure
Jonathan
has a draft on that in the works.....

					Ted

---

From: Ted Hardie <[email-masked]>
Date: Mon, 3 Mar 2008 10:43:54 -0800

>worthless due to the delay and cut-offs.

Not all media, and not even all SIP-arranged media, are necessarily
real time (if Jonathan gets TOTE through, to take one future, SIP
could use TOTE for the delivery of any MIME object).  Once the overlay
built for this exists, I believe we can expect either generic storage
or TOTE-like traversals to consider the overlay as a path of last
resort.  For some of those uses, the additional latency will not be
the problem that it would be for real-time media.

>tunnels will continue to be used in NAT traversal products.

I don't think this is the right place to discuss generic mechanisms for
NAT traversals, but I strongly agree that getting this right is going
to be critical for any system to get real deployment.  Just getting
NAT traversal right for neighbors creates significant overhead in
some topologies designed to reduce the hop count, and it makes the
decisions around how to handle joins and leaves trickier than they
look at first. 

				Ted

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 03 Mar 2008 10:51:10 -0800

At Mon, 3 Mar 2008 10:23:54 -0800,
> worthless due to the delay and cut-offs.

I agree that this is likely to be of marginal value.

> Bruce: Can you comment on this? Reload-03 has no clear text on symmetric

The reason there's no text on this in RELOAD is that it's out of
scope. RELOAD allows the peers to exchange SIP messages, which
(presumably) carry SDP which carries ICE. From there, they do ICE
exactly as non-P2P SIP implementations would. RELOAD isn't involved.
I would assume this would be true for any system like RELOAD.

There are two (potential) ways in which RELOAD interacts here:

- RELOAD provides a service discovery mechanism which could
  be used to find a TURN server. You could then use said
  TURN server to relay your media. Note that this isn't
  the same as having the media go *through* the overlay,
  it's just discovery. Once the TURN server is discovered,
  RELOAD is no longer part of the equation.
- RELOAD *does* have a TUNNEL method which could potentially
  be used to pass media traffic, but you would need to write
  a new usage that described exactly how this works. It's
  certainly not something that as far as I know any of the
  RELOAD authors intended as a standard operational mode.

-Ekr

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 3 Mar 2008 13:55:35 -0500

> Bruce: Can you comment on this? Reload-03 has no clear text on  

I think that's because we assume a TURN server will be used, if  
necessary.  I'm somewhat in Ted's camp of "it will be used as a last  
resort, regardless of what the draft says" although I think some of  
my fellow authors would like to require that implementors explicitly  
prevent it from happening.

With that said, I would say that if you did really, really want to  
relay media through an overlay:

- compress the path as much as possible, i.e. add an edge to the  
connection table that reduces the number of hops to the lowest number  
possible

- implement route optimizations.  Ordinarily I oppose routing options  
other than symmetric because of the complexity involved with the need  
to have fallbacks to symmetric for various healing/joining  
scenarios.  But if you're going to insist on routing media across an  
overlay, you're going to have to pay the complexity cost of fancier  
routing.

I think Henry's point that geography comes into play is very  
important here.  Henning has proposed that AS number be included in  
selection of a TURN server.  It's not clear to me that is the right  
rule in all cases or that  we have a working example of how to really  
implement this that isn't far too researchy at this point, but we  
might have some hope of doing it for TURN service discovery.  Most of  
the DHT proposals I think we've seen for P2PSIP have tried to avoid  
the complexity of using something like PASTRY.

I really want to leave this out of scope for now, except for the TURN  
service discovery portion.  Just too much complexity and too many  
headaches for little gain.

Bruce

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Mon, 03 Mar 2008 16:59:05 -0500

> core protocol and the core document, which is why we built them

With regard to security, IMHO, the most difficult part is how the system deal with the mailicious behavior. Although some papers show that if a large amount of peers are malicious, the system is impossible to be a safe one. But does it mean the malicious behavior need not be taken into account while design the core protocol? I don't think so.  The draft named "P2PSIP Security Analysis and Evaluation" (http://tools.ietf.org/wg/p2psip/draft-song-p2psip-security-eval-00.txt) tries to analysis the security threat from the service perspective and take the autonomy of the peer into acccount. 

On the other hand, P2PSIP system MUST not be exploited to lauch DDoS attack. One of the simple attack is: A malicious peer put a hot resource whose location is pointed to a victim, then the victim will receive too much query or service request. IMHO, P2PSIP protocol should consider this case. 

So P2P security should have a basic assumption first and then we could develop mechanism based on the assumption.

---

From: Miika Komu <[email-masked]>
Date: Tue, 4 Mar 2008 00:07:28 +0200 (EET)

> If this is not accurate, HIP folks, please correct me.

Hi Henry,

can you elaborate about the OS code? We are using existing PJSIP 
implementation for NAT traversal in HIPL implementation in InfraHIP II 
project at HIIT. The code is still unfinished and will be published during 
this Spring. Maybe we could demo it in Dublin.

-- 
Miika Komu                                       http://www.iki.fi/miika/
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 03 Mar 2008 14:22:21 -0800

At Mon, 03 Mar 2008 16:59:05 -0500,
jiangxingfeng 36340 wrote:
> With regard to security, IMHO, the most difficult part is how the
> system deal with the mailicious behavior. Although some papers show
> that if a large amount of peers are malicious, the system is
> impossible to be a safe one. But does it mean the malicious behavior
> need not be taken into account while design the core protocol? I
> don't think so.

Nor do I. That's why RELOAD goes to quite a bit of effort to provide
correct functioning to the extent possible in the face of malicious
peers (at least in certificate mode). 

-Ekr

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Mon, 03 Mar 2008 17:26:32 -0500

Hi, Bruce: 

I have more comments on Reload-3. 

1. After reading P2PP-01 and RELOAD-3, the first impression is that most of the mechanisms in the merged proposal are from the RELOAD-3. Only the diagonstic usage is from the P2PP. Although the two proposals have the nearly same design objectives, the proposed mechanism are still a little bit different. We are very interested in why you made this decisions, such as, why all authors think hop-by-hop reliability modes is not better than the via-list? 

2. Via list and destination list comprise of peer ID which could ensure the reachability in theory. But each peer ID may be of size 128 bits or larger. So the method may make the packet fragmented with high probability. Although Reload-3 provide a built-in frag/reass mechanism, but i really don't like it. Because IP fragmentation algorithm is a attack target of the TCP/IP stack. 

3. In reload-3, with respect to how to use the destination list, it says " If the entry is this peer, it removes this entry from the list and looks at the next entry and if the entry is not this peer, it sends the message to the first peer on the destination list." As we know, due to churn, some peer in the list may leave the overlay when the response is forwarded. In this case, the RELOAD-3 sends the message to the first peer. so my question is: why the destination peer does not send the response to the first peer initially? Although JOIN message could not be routed around the overlay to the JP, it could take semi-recursive or recursive method. 

4. RELOAD-3 has added a large amount of text to describe how to enroll a node, either peer or client. IIRC, P2PSIP WG should not standardize a enrollment protocol. It only make use of the enrollment service to operate the P2P system.
If I am wrong, please point out where it is.

5. In the section 1.1.3, it says "This layer is also responsible for setting up
   connections to other peers through NATs and firewalls using ICE, and
   it can elect to forward traffic using relays for NAT and firewall
   traversal.". I am interested in the concept relay here, could you give me more explanations? In SEP-01(http://tools.ietf.org/wg/p2psip/draft-jiang-p2psip-sep-01.txt), there is a similar concept: relaying peer. 

Regards!

JiangXingFeng

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 3 Mar 2008 18:02:27 -0500

On Mar 3, 2008, at 5:26 PM, jiangxingfeng 36340 wrote:

> 1. After reading P2PP-01 and RELOAD-3, the first impression is that  
> most of the mechanisms in the merged proposal are from the  
> RELOAD-3. Only the diagonstic usage is from the P2PP. Although the  
> two proposals have the nearly same design objectives, the proposed  
> mechanism are still a little bit different. We are very interested  
> in why you made this decisions, such as, why all authors think hop- 
> by-hop reliability modes is not better than the via-list?
>

reload-03 added hop-by-hop reliability from p2pp.  Search for ACK in  
the text.  I view hop-by-hop reliability and via-lists as orthogonal.

> 2. Via list and destination list comprise of peer ID which could  
> ensure the reachability in theory. But each peer ID may be of size  
> 128 bits or larger. So the method may make the packet fragmented  
> with high probability. Although Reload-3 provide a built-in frag/ 
> reass mechanism, but i really don't like it. Because IP  
> fragmentation algorithm is a attack target of the TCP/IP stack.
>

I agree that the fragmentation solution needs more work.  Again,  
there's a state tradeoff.  If you don't use the via-list, you have to  
store more state on the peers.  The vast majority of messages,  
however, won't have a destination list containing more than one ID,  
and won't traverse that many hops on the way to their destination.

> 3. In reload-3, with respect to how to use the destination list, it  
> says " If the entry is this peer, it removes this entry from the  
> list and looks at the next entry and if the entry is not this peer,  
> it sends the message to the first peer on the destination list." As  
> we know, due to churn, some peer in the list may leave the overlay  
> when the response is forwarded. In this case, the RELOAD-3 sends  
> the message to the first peer. so my question is: why the  
> destination peer does not send the response to the first peer  
> initially? Although JOIN message could not be routed around the  
> overlay to the JP, it could take semi-recursive or recursive method.
>

Direct response doesn't work when a NAT is in the way,  
unfortunately.  Hybrid routing approaches that fall back to symmetric  
response if the other techniques don't work are possible, but add a  
lot more complexity.

>    traversal.". I am interested in the concept relay here, could  
> you give me more explanations? In SEP-01(http://tools.ietf.org/wg/ 
> p2psip/draft-jiang-p2psip-sep-01.txt), there is a similar concept:  
> relaying peer.
>

If a direct connection can't be established, the protocol could use a  
TURN relay or could rely on source-routing to relay through another  
peer (this would be how to implement the relaying peer concept used  
in SEP).  We spent some time discussing both of these options.  Right  
now, I think the implicit assumption is that TURN will be used, but  
relaying using the peer protocol directly is another possibility.  We  
talked about this a little bit in working on -03, but it's one of the  
things that just ran out of time.  (to me, one of the hardest  
questions is what you do if you can't establish a direct connection  
with your replica set. If you have to relay, you're introducing  
additional points of failure.)

Bruce

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 3 Mar 2008 16:35:51 -0800

Thanks Miika for this message to the list!

> The code is still unfinished and will be published during 

Until then, can you share some links for us to get up to speed on the
work on NAT traversal for HIP? (I have some links but would prefer an
authoritative source).

Thanks again, Henry

-----Original Message-----
From: Miika Komu [mailto:[email-masked]] 
Sent: Monday, March 03, 2008 2:07 PM
To: Henry Sinnreich
Cc: Ted Hardie; [email-masked]; P2PSIP Mailing List
Subject: Re: [P2PSIP] media path of last resort

Hi Henry,

can you elaborate about the OS code? We are using existing PJSIP 
implementation for NAT traversal in HIPL implementation in InfraHIP II 
project at HIIT. The code is still unfinished and will be published
during 
this Spring. Maybe we could demo it in Dublin.

-- 
Miika Komu
http://www.iki.fi/miika/

---

From: Song Yongchao <[email-masked]>
Date: Tue, 04 Mar 2008 12:01:33 +0800

>From: Bruce Lowekamp [mailto:[email-masked]]
>Sent: Monday, March 03, 2008 10:14 PM

>even members of the overlay.  So I don't think there's any issue here.

Per se, I think TURN Server is suitable for communication between nodes that
have regular interaction, or is used for relaying media for nodes behind
NAT. But it is not suitable for p2p signal routing, because the source
peer/client does not know the IP and Port of the destination peer/client at
the beginning. As a result the source peer/client can not send a "Send"
indication with the destination's IP and Port to allow the traffic(signal)
from the destination. In that case, a "P2P Relay" instead of a TURN server
is preferred in the P2P signaling protocol.

---

From: Miika Komu <[email-masked]>
Date: Tue, 4 Mar 2008 09:50:15 +0200 (EET)

Hi Henry,

the latest HIP NAT traversal draft can be found from here:

http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-03.txt

We are working on improving the draft, so feedback is welcome. There is 
going to be a separate draft on mobility and multihoming.

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Tue, 4 Mar 2008 12:07:41 +0100

Hi,

>  prevent it from happening.

I don't want to take part in the discussion about media routing across
the overlay, I think this is out of scope for now. As far as I see, we
are defining a signaling protocol (control plane), but we are keeping
in mind that it will have implications for other planes (media,
management), this is why we assume a TURN server will be used.

Anyway, I fully agree with Ted: "Not all media, and not even all
SIP-arranged media, are necessarily real time". For example:
- overlay may need to store (and replicate) user's profile, user's
(public) keys, and so on
- IMHO, offline message delivery is a desired feature. We may need to
replicate such information within the overlay

By the way, when talking about real-time media, are you considering
p2p media? (e.g. chunk-based multisource media delivery)

>  selection of a TURN server.

I'd use other term rather than geography. Some kind of performance
diagnose may be used to to decide which server/relay to use in which
context.

Thank you,
-- 
Victor Pascual Ávila
Research Engineer
Tel.  +34 93 542 2906
Fax. +34 93 542 2517

Research Group on Network Technologies and Strategies (NeTS)
Universitat Pompeu Fabra (UPF)
Pg. de Circumval·lació, 8
Office 358
08003 Barcelona (Spain)
http://nets.upf.edu/
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Song Yongchao <[email-masked]>
Date: Tue, 04 Mar 2008 20:07:55 +0800

Bruce,

1. First, I think a Notify message should be supported. A peer or client can
Notify its neighbors with its current status(e.g. busy) when needed, so that
an upstream peer can route around busy downstream peers when necessary. When
a client has multiple associated peers, it can also choose which one to be
the best service peer upon it receives the Notify message with current
status from these associated peers. A Notify message is sent only when one's
status changes. Are you happy with this? I'm sorry if I miss some text in
Reload-03 about it.

2. Second, a general service discovery mechanism should be supported. I
would like to let every peer keep the service capability (e.g. TURN server)
of its neighbors. A LookUpServicePeer request should be added to collect the
service peers along the overlay, when the service peers are found, a
response with the service peers information is sent back. Both clients and
peers can issue this request. With this method, the service capability can
refresh timely. However, TURN server discovery method in Reload-03 needs to
calculate the turn density, and every turn server publishes as many replicas
as the turn density to the overlay. Do you think it is too complicated and
hard to maintain?

>voted to not focus on solving this problem in the immediate future.

I will be glad to see that Reload-03 supports the function of storage
provided by clients, if we consider various applications upon p2p layer in
the future: )

>even members of the overlay.  So I don't think there's any issue here.

I have clarified the p2p relay concept in another email.

-Song

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 04 Mar 2008 07:11:24 -0800

At Tue, 04 Mar 2008 20:07:55 +0800,
> status changes. Are you happy with this? I'm sorry if I miss some text in

I think it's a mistake to have this be a RELOAD mechanism rather
than a DHT mechanism.

Different DHTs provide a variety of levels of information about their
state and the state of their connection tables (for instance Chord
vs. Bamboo) and use that information differently to make routing
decisions.

Rather than having a generic message, that tries to predict all
possible values, I'd prefer to allow new DHTs to specify the kinds of
information they think is appropriate. This is done in RELOAD
by having the UPDATE message be defined by the DHT. So, a DHT
which knew how to make use of this information would define
an UPDATE mesage that provided it.

> as the turn density to the overlay. Do you think it is too complicated and

I agree that a general service discovery mechanism is something that
we should have. The one in SEP has some interesting features. I'd
very much like to see thw WG have a discussion on the best service
discvery approach.

-Ekr

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Tue, 04 Mar 2008 10:31:50 -0500

> the text.  I view hop-by-hop reliability and via-lists as orthogonal.

I will check it shortly.  

> and won't traverse that many hops on the way to their destination.

I agree with you it is a state tradeoff between payload efficiency and the complexity of the peer implementation. What I am afraid of is whether the via list would be exploited by the attacker to threaten the security of the P2P system. I am not clear in this regrad. I hope the P2PSIP community would discuss it. 

> response if the other techniques don't work are possible, but add 

From my understanding, the first peer in the text refer to the peer ID of the source peer. Is my understanding right? If it is, it could route the reponse directly by using the peer ID although it should fail while routing the JOIN response. 

> additional points of failure.)
I am very interested in this topic and hope we could discuss it in the coming WG meeting. 
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Tue, 04 Mar 2008 11:23:17 -0500

> peers (at least in certificate mode). 

Thanks for your effort. For protecting system from malicious behavior, we may get new idea if we change the perspective how to watch the P2PSIP system. Now, I write what I'm thinking and hopefully it will be helpful to the P2PSIP WG. 

1.It's hard to detect malicious behavior online. But the P2PSIP system, IMHO, should have a mechanism to check who has done the malicious behavior. So A peer, at least administrator of the overlay is able to use the mechanism while it is suspicious of the existence of malicious behavior. 

2. On the other hand, the P2PSIP external functions, such as routing and storage, are realized by the action of serving each other. As compared to C/S service model, the server's process logic is not trusted any more in P2P system. So the client in the service model should have do something to faciliate the above audit mechanism or do some check whether the server in the service model has serve them according to the agreement between them. 
From this regard, IMHO, the hop-by-hop reliablity model is more easily used in this work. Let's get back to the specific services. There are two specific services in P2PSIP system, one is routing service and the other storage service. The routing service happen both hop-by-hop and end-to-end. In end-to-end case, the client requesting the routing service wants to know whether the real responsible peer gives the response and it also is called 
identity attack. As for storage service, it is end-to-end. 

any comments? 

Regards!

JiangXingFeng

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 04 Mar 2008 08:35:35 -0800

At Tue, 04 Mar 2008 11:23:17 -0500,
jiangxingfeng 36340 wrote:
> Thanks for your effort. For protecting system from malicious
> behavior, we may get new idea if we change the perspective how to
> watch the P2PSIP system. Now, I write what I'm thinking and
> hopefully it will be helpful to the P2PSIP WG.
> 

Yes.

RELOAD provides most of this functionality already:

1. There is hop-by-hop security via DTLS.
2. End-to-end security can be provided via digital signatures on
   messages. It's in general not clear exactly how useful this 
   is in any system as far as responses go because if you're
   referencing a specific resource ID then you don't know what
   peer will be responding. Obviously, the situation is different
   for requests.
3. Data values are signed by the storing peer, thus providing security
   for stored data, regardless of who is storing this.

There has been some discussion of distributed (decentralized)
auditing systems for P2P networks, but AFAIK it's an open
research problem.[0] So, I'm reluctant to try to build in
too many features explicitly for this. However, we already
provide (and are open to more) diagnostic and discovery features
that would be useful if you had a more clear idea of how to
actually do auditing.

-Ekr

[0] Actually, just the question of determining whether a specific
server is storing your data turns out to be quite difficult and
was only recently solved satisfactorally by Shacham and Waters.
(http://eprint.iacr.org/2008/073).

---

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 4 Mar 2008 12:15:48 -0500

>>> need not be taken into account while design the core protocol? I

I think right now reload does a pretty good job of addressing  
malicious behavior through cryptography.  One separable aspect of  
security that can be improved in reload-03 is specification of using  
alternate paths to avoid compromised (but authorized) peers.  That  
should be made part of the DHT specification.  There's the usual  
complexity tradeoff here, but I'm thinking that alternate paths are  
going to have to be added (probably as a SHOULD or RECOMMENDED) to  
allow the DHT protocol to function as the number of malicious peers  
grows.

Bruce

---

From: Song Yongchao <[email-masked]>
Date: Wed, 05 Mar 2008 09:45:44 +0800

>From: Eric Rescorla [mailto:[email-masked]]
>Sent: Tuesday, March 04, 2008 11:11 PM

I think the information containing in the Notify message may also be
generic, such as the busy status. DHTs can use this information for their
routing choices. Further more, a client which doesn't run DHT, also needs to
know the status of its associated peers to avoid sending requests to the
congested associated peer. So, UPDATE message is used for routing table
maintenance, but for status notification we need another message.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 04 Mar 2008 19:15:40 -0800

At Wed, 05 Mar 2008 09:45:44 +0800,
Song Yongchao wrote:
> routing choices.

Yes, some of it can be generic, but some of it isn't, and since the
routing needs to be done at the DHT layer anyway--and some DHTs
certainly will want to propagate non-generic information--it's not
clear to me that having the information be split between layers adds a
lot of value.

> Further more, a client which doesn't run DHT, also needs to

Well, in RELOAD the client *is* part of the DHT, so the peers
it is connected to indeed can send it UPDATEs.

-Ekr

---

From: Salman Abdul Baset <[email-masked]>
Date: Mon, 3 Mar 2008 12:09:28 -0500 (EST)

-s

---

From: Salman Abdul Baset <[email-masked]>
Date: Mon, 3 Mar 2008 15:27:24 -0500 (EST)

>   peer. The ROUTE-QUERY command does this.

According to the existing model, clients need to explicilty request the 
connected peer (using ROUTE-QUERY) to transfer its routing table to client 
in an UPDATE message. Is there any particular reason why a client cannot 
request the routing table directly from its connected peer?

>   you're connected somewhere other than the replica set for

This will likely be the case for unstructured overlays.

> That's not necessarily bad.

My Skype client, when acting as a ordinary node, does not have fate 
sharing with its SN.

-s

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Wed, 05 Mar 2008 11:02:47 -0500

> the text.  I view hop-by-hop reliability and via-lists as orthogonal.

After reading the new revision, my concern is how a peer know which kind of method will be used to route the message in a specific transaction?  Does RELOAD-3 plan to support a hybrid way? 

On the other hand, as Henry suggested, we should make clear why we make the design decisions on every potential P2PSIP work items in current proposals.

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Wed, 05 Mar 2008 11:08:31 -0500

> clear to me that having the information be split between layers 
One option is to let the routing decision at the peer protocol level to override the one at the DHT level. Because peer could use the rich information collected by the P2PSIP peer protocol and could do the more optimal decision. This is one way in my mind how the generic information is to be used.

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Wed, 05 Mar 2008 11:24:42 -0500

One more comment on hop-by-hop reliability model:

ACK is only used when the underlying transport protocol is a unreliable one, such as DTLS. But if the TLS/TCP is used, the message could be considered reliable between two TCP entities, but we are not sure whether the receiving peer has really processed the message. In that case, does the sending peer retransmit the message? when? 

Regards!

JiangXingFeng

> > reload-03 added hop-by-hop reliability from p2pp.  Search for 
> ACK 
> > in  
> > the text.  I view hop-by-hop reliability and via-lists as 
> orthogonal.> 
> 
> After reading the new revision, my concern is how a peer know 
> which kind of method will be used to route the message in a 
> specific transaction?  Does RELOAD-3 plan to support a hybrid way? 
> 
> On the other hand, as Henry suggested, we should make clear why we 
> make the design decisions on every potential P2PSIP work items in 
> current proposals. 
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 05 Mar 2008 08:42:51 -0800

At Wed, 05 Mar 2008 11:08:31 -0500,
jiangxingfeng 36340 wrote:
> One option is to let the routing decision at the peer protocol level
> to override the one at the DHT level. Because peer could use the
> rich information collected by the P2PSIP peer protocol and could do
> the more optimal decision. This is one way in my mind how the
> generic information is to be used.

This seems to me like a bad idea. The whole point of the layering
between the DHT layers and everything else is to try to isolate
this kind of routing decision in a single location. Spreading
it out between the peer protocol and the DHT just confuses things.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 05 Mar 2008 08:45:06 -0800

At Wed, 05 Mar 2008 11:24:42 -0500,
jiangxingfeng 36340 wrote:
> ACK is only used when the underlying transport protocol is a
> unreliable one, such as DTLS. But if the TLS/TCP is used, the
> message could be considered reliable between two TCP entities, but
> we are not sure whether the receiving peer has really processed the
> message. 

But this is always the case. The peer protocol stack could
crash right after sending the ACK, after all. (this is of
course the point of Saltzer et al.'s End-To-End paper).

> In that case, does the sending peer retransmit the message?
> when?

Yes, there is an end-to-end retransmit (see S 5.)

-Ekr

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 5 Mar 2008 11:31:58 -0600

> it out between the peer protocol and the DHT just confuses things.

At a minimum, it would give us two routing paths to troubleshoot...

Spencer

---

From: Bruce Lowekamp <[email-masked]>
Date: Wed, 5 Mar 2008 12:57:27 -0500

On Mar 5, 2008, at 11:08 AM, jiangxingfeng 36340 wrote:

> One option is to let the routing decision at the peer protocol  
> level to override the one at the DHT level. Because peer could use  
> the rich information collected by the P2PSIP peer protocol and  
> could do the more optimal decision. This is one way in my mind how  
> the generic information is to be used.

I think there are some opportunities for this type of split between  
the generic peer protocol and the DHT (one example being the use of  
random replicas/random replication factor which can be an application  
decision vs the successor replicas that a chord-based DHT maintains  
based on its routing setup).  However, since only the DHT knows the  
overlay's topology and routing algorithms, I don't see how any other  
layer can make such a decision.  Even the use of alternate paths to  
avoid routing attacks by compromised peers needs to rely on the DHT  
layer to identify an alternate starting peer that will still reach  
the destination ID.

Bruce

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 5 Mar 2008 10:05:56 -0800

(changed to Client protocol) 

It seems UPDATE and ROUTE-QUERY are some of the main reasons why the
client protocol differs from the peer protocol in P2PP. Are there any
other?

Am I missing something?

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Salman Abdul Baset
Sent: Monday, March 03, 2008 12:27 PM
To: Eric Rescorla
Cc: 'P2PSIP Mailing List'
Subject: Re: [P2PSIP] Extending the (inclusive) merge for P2PSIP

According to the existing model, clients need to explicilty request the 
connected peer (using ROUTE-QUERY) to transfer its routing table to
client 
in an UPDATE message. Is there any particular reason why a client cannot

-s

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Wed, 05 Mar 2008 14:04:54 -0500

> layer to identify an alternate starting peer that will still reach 

To me, I am not clear what the relationship between Peer protocol level and DHT level from the RELOAD-3 architecture figure. Could you give me more information on this? thank you.

Regards!

JiangXingFeng

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 05 Mar 2008 11:14:16 -0800

At Wed, 05 Mar 2008 14:04:54 -0500,
> To me, I am not clear what the relationship between Peer protocol level and DHT level from the RELOAD-3 architecture figure. Could you give me more information on this? thank you.

Hmm.. Not sure what to say here. Maybe if you told me what you're
not clear on I could try to explain more.

-Ekr

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Wed, 05 Mar 2008 14:42:52 -0500

> > To me, I am not clear what the relationship between Peer 
> protocol level and DHT level from the RELOAD-3 architecture 
> figure. Could you give me more information on this? thank you.
> 

Ok, Let me clarify it. In order to make the DHT algorithms a independent piece of the implementation, we should have a clear call interface to them. RELOAD-3 has done great work in that regard, I think. 

My concern is: Conventional DHT algorithms only use the routing table to make routing decisions and because NAT is not considered in most algorithms, the destination peer often send the response directly to source peer by using the semi-recusive routing mode( in P2PSIP term). But due to NAT existence, destination list tries to reuse the reverse connection which the request has traversed to improve the performance, but DHT could not find the
 reverse connection in the routing table and instead should lookup in a new state, connection table (if my understanding is right) or using a new method to check its routing table to see whether the peer ID is really his neighbor. In that case, I think it introduces the flexible routing decision which is other than conventional routing method used in DHT. 

So my question is: where will the function finding the reverse connection be realized? If it is implementated in the DHT level, it will break the independence of the the DHT algorithm. If implementated in the Routing and Replication logic, it will introduce a new location to do the routing decision? 

Look forward to your response. Thanks!

Regards!

JiangXingFeng

---

From: Bruce Lowekamp <[email-masked]>
Date: Wed, 5 Mar 2008 15:16:11 -0500

On Mar 5, 2008, at 2:42 PM, jiangxingfeng 36340 wrote:

> Ok, Let me clarify it. In order to make the DHT algorithms a  
> independent piece of the implementation, we should have a clear  
> call interface to them. RELOAD-3 has done great work in that  
> regard, I think.
>
> My concern is: Conventional DHT algorithms only use the routing  
> table to make routing decisions and because NAT is not considered  
> in most algorithms, the destination peer often send the response  
> directly to source peer by using the semi-recusive routing mode( in  
> P2PSIP term). But due to NAT existence, destination list tries to  
> reuse the reverse connection which the request has traversed to  
> improve the performance, but DHT could not find the
>  reverse connection in the routing table and instead should lookup  
> in a new state, connection table (if my understanding is right) or  
> using a new method to check its routing table to see whether the  
> peer ID is really his neighbor. In that case, I think it introduces  
> the flexible routing decision which is other than conventional  
> routing method used in DHT.
>
> So my question is: where will the function finding the reverse  
> connection be realized? If it is implementated in the DHT level, it  
> will break the independence of the the DHT algorithm. If  
> implementated in the Routing and Replication logic, it will  
> introduce a new location to do the routing decision?
>

The overlay routing and storage layer (of which the DHT is a  
pluggable component) only needs to deal with the overlay in terms of  
PeerIDs.  The actual IP address used to communicate with a particular  
peer is actually handled by the Forwarding Layer.  There is a minor  
layering issue in that the DHT and the forwarding layer do need to  
share knowledge of which peers connections are actually established  
with (as only they can be in the DHT's routing table), but the DHT  
still only needs to deal with that at the level of with which PeerIDs  
connections are established.

So for symmetric routing, the via-list encodes the reverse path as a  
list of peerIDs.  To route a reply the via list is switched to the  
destination list and the next peerID popped at each hop.  The  
connection table that is maintained by the forwarding layer will have  
a connection to the peerID at each hop, so that is where the IP  
address used for routing the response will be found.  Routing replies  
actually doesn't require involvement of the DHT (although some DHT  
algorithms do learn/cache based on reply paths).

This all needs worked-out examples in the draft...

Bruce

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Wed, 05 Mar 2008 15:45:27 -0500

> Routing replies  
> actually doesn't require involvement of the DHT (although some DHT  algorithms do 
> learn/cache based on reply paths). 

I don't think so. it is the case if there is no churn in the network. If there is churn, the reverse connection may not be available while routing replies. One of the reason is the neighbor peer in the connection table leaves the overlay or the connection is broken at that moment. In this case, how does the RELOAD process? only give up the transaction or fall back to the overlay routing based on peer ID?

On the other hand, essentially, I think, the forwarding layer introuce flexible routing decision, not only based on the overlay routing, but also reuse the established connection. IMHO, in order to improve performance, some new flexible routing decision may be developed  later in a generic way like what connection table does. We should keep the extensibility.

---

From: Bruce Lowekamp <[email-masked]>
Date: Wed, 5 Mar 2008 16:49:27 -0500

On Mar 5, 2008, at 3:45 PM, jiangxingfeng 36340 wrote:

> I don't think so. it is the case if there is no churn in the  
> network. If there is churn, the reverse connection may not be  
> available while routing replies. One of the reason is the neighbor  
> peer in the connection table leaves the overlay or the connection  
> is broken at that moment. In this case, how does the RELOAD  
> process? only give up the transaction or fall back to the overlay  
> routing based on peer ID?
>

As currently specified, the system would rely on end-to-end  
retransmissions to handle this failure mode.

I'd be interested in any studies that support the concern that  
failure on the return path of a symmetrically routed message are a  
significant issue.  Generally, forward-routing is more likely to fail  
because the link may have been unused for up to the periodic  
maintenance interval plus the timeout period.  So the forward-routed  
request may be the first message in some time to traverse the link.    
The response, on the other hand, will arrive within whatever the  
latency of the request/response time is, which is almost certainly  
orders of magnitude shorter.

Here we're getting into a much more complicated area of DHT  
research.  DHT routing algorithms that want to maximize the success  
rates of individual queries can go to quite extreme lengths of having  
hop-by-hop retransmissions along alternate forwarding paths, fallback  
to iterative routing, etc.   Which of these are worth doing is an  
interesting question.  For a P2PSIP VoIP call, if the system manages  
churn successfully but takes 20 seconds to return the correct value,  
the VoIP phone has already been slammed down and the cell phone is  
being used anyway.  Parallel lookups along alternate paths and  
parallel lookups for alternate replica keys (random replicas) appear  
to me to be better choices for a low-latency response in the presence  
of churn/adversaries.

If we want to devote protocol complexity to better performance in the  
face of churn, I'm not sure it's not better spent on tuning selection  
of peers for the routing table or other similar improvements.  The  
Chord-like algorithm in section 9 currently replaces each finger  
table entry with a "better" entry based on a periodic search.  I  
wanted to rewrite this to give preference to a longer-lived peer  
that's in the right interval rather than a better numerical match (I  
think that idea was first in Kademlia), but didn't take the time to  
write that text.  Godfrey's SIGCOMM06 paper argues convincingly that  
if the peer in your finger table dies, you should actually pick a  
random replacement rather than do a search for the "correct" entry.

In any event, the intention of the DHT algorithm in the reload-03  
draft is to be a base DHT that works and is easy to implement.   
There's an assumption (I'm not sure if it's explicitly in the draft  
or not) that an overlay with specific performance/reliability  
requirements, especially a global-scale overlay, may very well want a  
better DHT than the default one.  If you want to write a DHT that  
supports different forms of response routing, you're right, you do  
need to handle that at the higher level.

> On the other hand, essentially, I think, the forwarding layer  
> introuce flexible routing decision, not only based on the overlay  
> routing, but also reuse the established connection. IMHO, in order  
> to improve performance, some new flexible routing decision may be  
> developed  later in a generic way like what connection table does.  
> We should keep the extensibility.

Absolutely other DHTs will have different/more flexible/better  
routing algorithms.  But it still has to be handled by the DHT, not  
the base protocol forwarding layer.   Only the DHT layer knows the  
routing metrics (and possibly even whether the routing metric is  
based on < or xor distance.

Bruce

---

From: Bruce Lowekamp <[email-masked]>
Date: Wed, 5 Mar 2008 16:57:02 -0500

> orders of magnitude shorter.

I hate responding to my own message, but just to clarify, when I used  
the word "forward" in that paragraph, I meant to refer to the steps  
of forwarding the request around the overlay to the destination  
peerID, and to distinguish that direction from the return direction.   
I did not mean to refer to forward-only routing.

Bruce

---

From: Song Yongchao <[email-masked]>
Date: Thu, 06 Mar 2008 10:09:47 +0800

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Henry Sinnreich
>Sent: Thursday, March 06, 2008 2:06 AM
First, when a client has multiple associated peers. I think the client
should get the status of its associated peers for the choice of sending
requests and avoid sending requests to a congested/busy associated peer. In
SEP client protocol, a Notify message is used for the notification. I think
this must be merged for client protocol.

Second, a client must know the departure of its associated peer. Does the
peer also send Leave message to its associated clients? My answer is YES. If
people agree, we should clarify it in the merged client Protocol.

Third, I'd like the service that is provided by the associated peer to its
associated clients to be the general service in the overlay (just like TURN
server service). We mustn't compel each peer to provide that service. A
general service discovery mechanism that we will make a consensus can also
be used for this service. I want to know if there are other people who have
special thought on this point.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 05 Mar 2008 19:14:51 -0800

At Thu, 06 Mar 2008 10:09:47 +0800,
> this must be merged for client protocol.

As with the ordinary peer protocol, I think this should be done with
UPDATE at the DHT layer. 

> people agree, we should clarify it in the merged client Protocol.

Section 7.3.2 already implies this:

   The LEAVE_Q message is used to indicate that a peer is exiting the
   overlay.  The peer SHOULD send this message to each peer with which
   it is directly connected prior to exiting the overlay.

"peer" in this case (in fact, throughout RELOAD) refers to both
client peers and non-client peers. However, I agree that this
could be clearer.

> server service). We mustn't compel each peer to provide that service.

It's not clear to me why this is true. It's not significantly more
effort to be a peer attached to a client than it is to be a peer
attached to another peer, provided that clients aggressively
set up finger tables like any other peer. (This is less clear than
it should be in S 3.2.3.) It's true that the client is free riding
on the ring as a whole, but that's a different question.

> A

Well, as I was discussing with Salman, it's highly desirable for
a client to be connected to peers in the overlay as if it were
a peer, since that means all the ordinary routing mechanisms
work correctly. If you don't do this, the client needs to
advertise destination lists that explicitly reference the small
number of peers it is connected to, and that indeed is a service
that should be advertised.

-Ekr

---

From: Song Yongchao <[email-masked]>
Date: Thu, 06 Mar 2008 13:53:18 +0800

>As with the ordinary peer protocol, I think this should be done with

I don't think Client has the "DHT layer".

>client peers and non-client peers. However, I agree that this

We need a clear rather than an obscure draft for the implementation.

>that should be advertised.

I think the roles and responsibilities are different for clients and peers.
If a peer is not willing to be acting as an associated peer, he can also
discard messages received from the client. Any other people have thoughts on
this?

-Song

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 05 Mar 2008 22:33:33 -0800

At Thu, 06 Mar 2008 13:53:18 +0800,
> I don't think Client has the "DHT layer".

It does in RELOAD.

> We need a clear rather than an obscure draft for the implementation.

Well, I didn't say it was obscure; I just said it could be clearer.
We'll clarify in the next revision.

> discard messages received from the client. 

Again, in RELOAD the difference between a client and a peer is very small.

A peer which refuses to route messages, whether for a client or another
peer, is misbehaving.

-Ekr

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Thu, 6 Mar 2008 10:21:17 +0100

>  Again, in RELOAD the difference between a client and a peer is very small.

Once again, I think we should first reach a consensus on:

- What a client is
- What a client can do for the overlay
- Differences between a client and a peer

and,

- Can we merge the client function in the peer protocol? If we could,
Why should do we do it?
- Do we need a separate protocol?

We tried to discuss it in the following document:
http://tools.ietf.org/html/draft-pascual-p2psip-clients-01

V. Pascual, M. Matuszewski, E. Shim, H. Zheng and Y. Song,  "P2PSIP
Clients" Internet Draft draft-pascual-p2psip-clients-01, February
2008.

It's open for discussion.

Cheers,

---

From: "Jerry Yin" <[email-masked]>
Date: Thu, 6 Mar 2008 10:25:38 -0500

I saw several people pointed that the symmetric routing mechanism used in
the reload-3 will have problems during churn. I am wondering if the
"semi-symmetric" routing protocol would solve this problem. The protocol is
like this:

1. Unlike the symmetric protocol in reload-3 that each peer will insert it's
Peer-ID in the Request messages, the semi-symmetric protocol requires only
those peers that are interested (or required) in receiving the response
messages insert the Peer-IDs in the via list. This works similar to the
"Record-Route", and "Route" header in SIP protocol.

2. The request will route the same way as the reload-3.
3. When a peer receives a response message, it will do following processing:
	a. Check if the top via is pointing to this peer. If yes, remove the top
via, send the response towards the next top via in the via list (see d).
	b. If the top via is not this peer, check if this peer is responsible for
the Peer-ID in the top via, this could happened when that peer left the
overlay. If it is responsible for that Peer-ID, remove the top-via, do the
same thing as a).
	c. If this peer is not the peer identified or responsible for the peer-ID
in the top via, it will do nothing about the via list, just forward the
message towards the top-via Peer (see d)
	d. When a peer sends the message towards next peer, it has two choices. It
can forward the message directly to the peer in the top-via (DTLS), or
forward to its neighbor peer closer to the top-via Peer (TLS). This way,
this peer don't need to create new TCP/TLS connections to the designated
peer, but use it existing connections.
	e. If a client depends on this peer, or this peer is the outbound of other
peers, this peer always insert it's Peer-ID in the requests. This way, it
guarantees that all the responses will go through this peer.

This protocol should solve the problem that the via-list broken during
churn. It also have the similar advantages as the symmetric routing.

Just my two cents.

Regards,
Jerry

> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Bruce Lowekamp
> Sent: Wednesday, March 05, 2008 4:57 PM
> To: Bruce Lowekamp
> Cc: 'Henry Sinnreich'; 'P2PSIP Mailing List'
> Subject: Re: [P2PSIP] :Re: Extending the (inclusive) merge for P2PSIP
>
>
>

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 6 Mar 2008 11:16:54 -0500

For DHTs that can route in both directions, this could work.   
Standard Chord can't guarantee reachability if you try to route  
backwards, however.

The other problem is with routing during overlay healing.  If the  
overlay is partitioned and peer A is trying to route a message back  
to B through some peer C, if this message is recovering from a  
partition, C may not be in the same partition as B, so ultimately  
following a path through C may not lead to B, even if C appears to be  
"closer" to B.  Full symmetric (or iterative) are still the most  
reliable routing methods for these situations.

If we want to improve the routing performance, I would prefer the  
ability to do direct response with optional full-symmetric return if  
the hop-by-hop ACK on the direct response isn't received.  (this  
option was evaluated in "Non-Transitive Connectivity and DHTs,"  
WORLDS'05.)   It's a slight increase in complexity, but it has the  
virtue of working in the majority of situations without any other  
special cases.  Of course, DHTs that learn/cache on response routing  
might still want to specify other routing options.

Bruce

---

From: Salman Abdul Baset <[email-masked]>
Date: Thu, 6 Mar 2008 12:19:50 -0500 (EST)

The client discussion has received much discussion. Below, I want to 
summarize what I think are the requirements for a client which have been 
previously deliberated but not necesarily put together.

I will define client as a peer subentity that does not process incoming 
STORE, FETCH, and FIND messages.

-Like a peer, a client has an ID. A client obtains its ID in the same 
manner as a peer.

-Over its life time, a node may not be permanently designated as a client 
or a peer. Although, for certain low-end mobile devices this distinction 
may be permanent.

-A node may join the overlay as a client. Later, it may be invited by a 
peer to upgrade itself to the overlay. A client may also decide to upgrade 
itself to a peer.

-A node's attempt to join as a peer may be defered by a peer because 
it has not been up for certain time. The peer can then ask the node to 
join as a client.

-A client may not be a 'dumb terminal' hanging from a peer. It can provide 
TURN service. However, it cannot process incoming STORE, FETCH, and FIND 
messages.

-A client may be connected to multiple peers for fault tolerance purposes. 
A client can connect to multiple peers in an overlay (DHT) protocol 
[in]dependent manner. A client may also maintain a list of other peers 
without necessarily connecting to all of them.

-Peers need a mechanism to balance the number of clients connected to a 
peer.

-Does a client need to be overlay (DHT) protocol aware (RELOAD-03)?

How to upgrade/downgrade from a client to peer and vice versa?
-Metrics such as uptime, ewma_bytes_sent[rcvd], and estimation of number 
of peers in the overlay play a role.

-s

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Mar 2008 09:43:42 -0800

At Thu, 6 Mar 2008 12:19:50 -0500 (EST),
> it has not been up for certain time. The peer can then ask the node to 

I don't see the point of either the peer refusing to let you join
as a peer or asking you to join as one. The client knows its
own properties better than the peer does and the peer has no
special standing--it just happens to ahve a peer-id 
close that of the client.

> -Peers need a mechanism to balance the number of clients connected to a 

I think this depends on whether clients attach to peers as a service,
as in RELOAD-03 with explicit routing, or simply as a peer that
doesn't JOIN, as in the non-explicit RELOAD client mode. Unless I've
missed something, this doesn't impose more load on the adjacent
peers (provided that the client creates a robust set of fingers
as it should) than if the client were a peer.

-Ekr

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 06 Mar 2008 19:01:26 +0100

> close that of the client.

A reason for allowing only some of the /best nodes/ to join the DHT is
to keep search delay as well as churn and maintenance traffic low.  Such
an approach seems successful, at least for Skype.

-- 
Ciao,
Enrico

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 6 Mar 2008 09:38:09 -0800

All these items on p2p clients would make a nice list to discuss on the
agenda, no to solve them in the meeting, but to flag them for
resolution.

IMO one of the authors of client I-Ds would be best positioned to
volunteer making such a list :-)

If it comes to the worst, I could make on as well.

Henry

-----Original Message-----
From: Song Yongchao [mailto:[email-masked]] 
Sent: Wednesday, March 05, 2008 9:53 PM
To: 'Eric Rescorla'
Cc: Henry Sinnreich; 'Salman Abdul Baset'; 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] Client protocol

>> requests and avoid sending requests to a congested/busy associated
peer.
In

>> peer also send Leave message to its associated clients? My answer is
YES.
If

>> Third, I'd like the service that is provided by the associated peer
to
its
>> associated clients to be the general service in the overlay (just
like
TURN

>> be used for this service. I want to know if there are other people
who
have
>that should be advertised.

I think the roles and responsibilities are different for clients and
peers.
If a peer is not willing to be acting as an associated peer, he can also
discard messages received from the client. Any other people have
thoughts on
this?

-Song

---

From: Salman Abdul Baset <[email-masked]>
Date: Thu, 6 Mar 2008 13:19:19 -0500 (EST)

> close that of the client.

A peer may refuse to let a node join as a peer because a node is 
considered 'abusive' by the admitting peer or does not meet desired 
security properties.

For unstructured networks, client-ID and peer-ID have no closeness 
meaning.

> as it should) than if the client were a peer.

For DHTs it is easy to understand that such a load balancing happens 
implicitly. However, this is not the case for unstructured overlays.

-s

---

From: "Jerry Yin" <[email-masked]>
Date: Thu, 6 Mar 2008 16:18:04 -0500

Hi Bruce,

thanks for the response, please see the in-line comments.

thanks
Jerry

> Sent: Thursday, March 06, 2008 11:17 AM
> To: Jerry Yin
> Subject: Re: semi-symmetric routing protocol for reload-3?
>
>
>

For semi-symmetric routing, it's not necessary for the responses to travel
backwards all the same peers as the requests in a reverse order. As long as
the peers in the via-list are in the response path, the protocol should work
for any p2p algorithm. Isn't it?

> reliable routing methods for these situations.

This could be a problem. Unless the symmetric routing will always use direct
response, it will have the same problem.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Mar 2008 13:50:27 -0800

At Thu, 6 Mar 2008 13:19:19 -0500 (EST),
> considered 'abusive' by the admitting peer or does not meet desired 

Actually, I think this is a really bad idea. There's no practical
way to distinguish this from the admitting peer just being
malicious.

-Ekr

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 6 Mar 2008 16:55:50 -0500

> way to distinguish this from the admitting peer just being

That's probably true, but there's a pretty wide variety of algorithms  
(especially in those overlays that use superpeers) for deciding on  
promotion criteria, and I think the decision is made by existing  
members extending invitations in quite a few of those algorithms.  I  
don't think it's something we can/should prohibit at the peer  
protocol level.  Seems like it should be a decision of the DHT  
algorithm.

Bruce

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 6 Mar 2008 22:35:08 -0500

> for any p2p algorithm. Isn't it?

Unfortunately, no.  Unless the DHT guarantees that you can route in  
both directions, you can't do things like 3c routing "toward" the  
peer at the top of the via list.  Well, you can do that, but that  
peer won't necessarily be able to reach it.

> response, it will have the same problem.

No, it's not a problem if you use symmetric routing.  Let's say you  
follow the periodic stabilization in 9.2.6.3 and repeat the initial  
discovery process.  If peer A discovers peer Z and routes a PING  
through A to its ID, then the peer R that responds to the PING will  
only be able to reply to it by routing backward along the original  
path through Z.

If the overlay you're using supports bi-directional routing, then a  
semi-symmetric algorithm's approach of routing backward to Z can work  
fine.  But not all DHTs support that.  (chord, in particular,  
doesn't, although variants that guarantee bi-directional routing are  
used.)

Bruce

---

From: "Jerry Yin" <[email-masked]>
Date: Fri, 7 Mar 2008 09:36:00 -0500

Hi Bruce,

thanks for your excellent explanation!

Jerry

> Sent: Thursday, March 06, 2008 10:35 PM
> To: Jerry Yin

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 7 Mar 2008 08:59:36 -0800

Folks,

I have just seen that the mail archive does not go back before March 5
and this message is not available in the archive, so I hope people who
may have missed it, can see it now. My apology to those who have already
read it and answered (almost only Reload authors). Well, the proposal to
have an editor with quality time, and being neutral dare I say has not
been yet discussed. 

The neutral editor with quality time should be an agenda item with a
hum.

Henry

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henry Sinnreich
Sent: Saturday, March 01, 2008 4:13 AM
To: P2PSIP Mailing List
Subject: [P2PSIP] Extending the (inclusive) merge for P2PSIP

1.     Merge proposals. 1

1.   Merge proposals

 

Thanks, Henry

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Mar 2008 12:30:22 -0500

Henry

I responded to the author issue in a message sent on 3/3 with the subject
"Re: [P2PSIP] Agenda for IETF-71"

The response was:
> Editor issues will be discussed between the authors and the chairs if/when

> a draft is made into a WG item.

Editors are not chosen by hums.  Editors for WG items are appointed by
chairs. 

I don't think agenda time for this is warranted.  There will be agenda bash
time.  If you feel otherwise, bring it up then.

Brian

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henry Sinnreich
Sent: Friday, March 07, 2008 12:00 PM
To: P2PSIP Mailing List
Subject: Re: [P2PSIP] Extending the (inclusive) merge for P2PSIP

Folks,

I have just seen that the mail archive does not go back before March 5 and
this message is not available in the archive, so I hope people who may have
missed it, can see it now. My apology to those who have already read it and
answered (almost only Reload authors). Well, the proposal to have an editor
with quality time, and being neutral dare I say has not been yet discussed. 
The neutral editor with quality time should be an agenda item with a hum.
Henry

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henry Sinnreich
Sent: Saturday, March 01, 2008 4:13 AM
To: P2PSIP Mailing List
Subject: [P2PSIP] Extending the (inclusive) merge for P2PSIP

As mentioned, here is how to extend the inclusive merge for P2PSIP with the
best proposals from various authors. I hope this can make it to the agenda
of the P2PSIP WG meeting.

1.     Merge proposals. 1
2.     What’s wrong with the Core Protocol in Reload-03. 1
3.     Discussion of design decisions. 1
4.     Why an editor is required. 1

1. Merge proposals

• Replace section 4. Base Protocol with P2PP since P2PP has all the
desirable properties: Works for structured and unstructured overlays, has a
rigorous I-D, freely available code, large scale deployment and several
independent implementations. Hopefully SIPit testing and the SIP Forum can
be engaged for interoperability testing and debugging as well. By contrast,
the present section 4. Base Protocol is seriously flawed as shown here
below. 

• Subsection for the client protocol: The proposals for the client protocol,
one of which (draft-pascual-p2psip-clients) is based on P2PP anyway, and
should be merged here as well.

• Security (I like these sections very much): Should the various sections on
certificate security and secure transport be consolidated into one section
on Security? Where does the security for the HIP part belong? If HIP is
secured, when/if is TLS and DTL still useful?

• Combine the two proposals for using HIP, the high level HIP-Bone and the
detailed, step be step p2p-sip-id-loc should be merged into one single HIP
(optional for P2PSIP) section.

• There may be more and I apologize for keeping this here to a short list
only.

• Remove he tutorial section and replace it with references.
2. What’s wrong with section 4. Core Protocol in Reload-03

• The basic assumption on which the whole section 4. Base Protocol and the
related section 3. Overview is written is based on symmetric routing from
the source to the root and back using the same path. This is a flawed
approach:

a. Churn can break the return path. For a example a 95% probability for
success in the presence of churn over 10 hops each will result in a total
probability of success of 099^10=0.59, that is 59%. The media path cannot
work well if the two end points cannot see each other and there is no
solution given here for the media path. Perhaps another media relay or using
HIP? This is a missing item. In any case the media path MUST NOT follow the
symmetric search path since the delay will be unacceptable over so many hops
and unknown geographic locations that can be anywhere on the Internet.

b. The correct approach for non-transitivity in the DHT is to use more than
one source node for the search in the underlying DHT with smart timeouts for
“node recovery” as described in “Non-Transitive Connectivity and DHTs”,
http://srhea.net/papers/ntr-worlds05.pdf  and
http://srhea.net/papers/bamboo-usenix-talk.ppt .

c. The above shows how the DHT can do the required work and why the whole
routing (forwarding) layer with its routing tables, routing state,
retransmissions, flow control, etc. at the application level in Reload-09 is
redundant. This kills the rationale IMHO also for the methods described in
section 7. Method Definitions.

d. As mentioned, technical terms such as connection, long hop and nearby
neighbors (leaf set) are treated in a cavalier way and this must be fixed in
the sense of using Internet and P2P terminology common in the technical
literature. A glossary with references would help.

e. Though the use different DHTs is claimed (but not the use of unstructured
overlays), what is shown is only a nailed-down-like use of Chord, much less
general and modular as in P2PP.

3.  Discussion of design decisions
There are several design decisions that should be discussed on the list such
as the use of SIP GRUU. What is the usage scenario of using GRUU in P2PSIP
and in what cases is it useful? We already have defined how to connect
P2PSIP networks with the DNS world.
4. Why an editor is required
The emerging P2PSIP protocol document will be on of the most complex in the
IETF, probably exceeding the size of RFC 3261. 
Such a document requires a dedicated editor having adequate quality time,
besides the authors and contributors of the various original protocol
proposals.

Thanks, Henry

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 7 Mar 2008 09:46:44 -0800

Brian,

>" I responded to the author issue in a message sent on 3/3 with the subject

Sorry, I could not find this message in the archive either - the archive starts from 3/5.
http://www.ietf.org/mail-archive/web/p2psip/current/ 

I am still curious if the editor item will be on the agenda.

>> Editor issues will be discussed between the authors and the chairs

Did you mean the authors of all the proposals or only the authors of Reload-03?

Thanks again, Henry

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, March 07, 2008 9:30 AM
To: Henry Sinnreich; 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] Extending the (inclusive) merge for P2PSIP

Henry

Brian

Folks,

1.     Merge proposals. 1

1. Merge proposals

* Replace section 4. Base Protocol with P2PP since P2PP has all the

* Subsection for the client protocol: The proposals for the client protocol,
one of which (draft-pascual-p2psip-clients) is based on P2PP anyway, and
should be merged here as well.

* Security (I like these sections very much): Should the various sections on
certificate security and secure transport be consolidated into one section
on Security? Where does the security for the HIP part belong? If HIP is
secured, when/if is TLS and DTL still useful?

* Combine the two proposals for using HIP, the high level HIP-Bone and the
detailed, step be step p2p-sip-id-loc should be merged into one single HIP
(optional for P2PSIP) section.

* There may be more and I apologize for keeping this here to a short list
only.

* The basic assumption on which the whole section 4. Base Protocol and the
related section 3. Overview is written is based on symmetric routing from
the source to the root and back using the same path. This is a flawed
approach:

"node recovery" as described in "Non-Transitive Connectivity and DHTs",

Thanks, Henry

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Mar 2008 13:05:47 -0500

Not sure what happened to the archive, but we'll look into it.

The editor item will not be on the agenda.  As I said, if you disagree,
bring it up at agenda bash.

We will discuss editorship with the authors of the document that is accepted
as a WG item.  "Discuss" doesn't mean they decide.  As you know, it is not
uncommon for chairs to appoint an editor who is not in the author group.  At
this point, I have NO OPINIONS on the subject.  Anyone wishing to comment on
editing is welcome to email the chairs or find us at IETF-71.  This all
assumes we have consensus to create a WG item.

While editorship is an important ingredient of an IETF document with lots of
authors, the editor's power to control what goes in the document is limited.
Once the document is a WG item, anyone can propose ideas and/or text.  If
the WG agrees it should go in the document, the editor must incorporate it.
A WG item does not "belong" to the editor, or even the authors. It belongs
to the WG.

Brian

> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Friday, March 07, 2008 12:47 PM
> To: Brian Rosen; P2PSIP Mailing List
> if/when
> Of
> Of
> the
> unstructured
> such
> the

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 7 Mar 2008 11:06:44 -0800

Brian,

Thanks for the clarification!

> We will discuss editorship with the authors of the document that is accepted
as a WG item

Is this meant as one single document proposal (Reload), or does it include the other proposals as well? 

Thanks again,

Henry

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, March 07, 2008 10:06 AM
To: Henry Sinnreich; 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] Extending the (inclusive) merge for P2PSIP

Brian

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Fri, 7 Mar 2008 20:30:26 +0100

>  Is this meant as one single document proposal (Reload), or does it include the other proposals as well?

Actually, authors of SEP would like to be considered at least to
discuss some distinctive features. We already requested a time slot.

Thank you,

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Mar 2008 14:38:26 -0500

We have an agenda item to discuss the merged protocol
We have an agenda item to discuss other protocols.  So far, no one has
requested to speak on the latter item.

We intend to call for a hum on consensus following those discussions, and
follow up with subsequent list discussion to confirm consensus if it appears
we have one on protocol direction.

If we have consensus to move a document such as Reload-03, or any other
protocol document, to be a work group item, the chairs will undertake to
appoint an editor for that item.

If we don't have consensus to move any document forward as the basis of a
p2psip protocol, we'll figure out another way forward.

Brian

> Sent: Friday, March 07, 2008 2:07 PM
> and
> > desirable properties: Works for structured and unstructured overlays,
> has
> > a
> sections
> > on
> whole
> > retransmissions, flow control, etc. at the application level in Reload-
> 09
> > is
> > neighbors (leaf set) are treated in a cavalier way and this must be
> fixed
> > in
> time,

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Mar 2008 14:42:29 -0500

There are two agenda items:
Open discussion of alternate protocols as alternatives to merged protocol -
20 min
Open discussion of ideas from alternate protocols to be included in
consensus protocol - 30 min

I understood your request to present ideas from SEP in the latter agenda
item (Ideas from other protocols that should be considered for inclusion in
a consensus protocol).  Was that your intention?

Brian

> From: Victor Pascual Ávila [mailto:[email-masked]]
> Sent: Friday, March 07, 2008 2:30 PM
> To: Henry Sinnreich
> Cc: Brian Rosen; P2PSIP Mailing List

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Fri, 7 Mar 2008 21:12:04 +0100

>  a consensus protocol).  Was that your intention?

Exactly. You are right.

Thank you,

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Fri, 07 Mar 2008 15:00:49 -0500

> requested to speak on the latter item.

Recently, there are lots of discussion in the mailing list. I have requested the time slot for the latter item.  You could checked the link http://www.ietf.org/mail-archive/web/p2psip/current/msg03876.html;

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Mar 2008 15:15:41 -0500

See the prior email from Victor.

Brian

> From: jiangxingfeng 36340 [mailto:[email-masked]]
> Sent: Friday, March 07, 2008 3:01 PM
> To: Brian Rosen
> Subject: 回复:Re: [P2PSIP] Extending the (inclusive) merge for P2PSIP
> 
> 
> Recently, there are lots of discussion in the mailing list. I have
> requested the time slot for the latter item.  You could checked the link
> http://www.ietf.org/mail-archive/web/p2psip/current/msg03876.html;

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Sat, 08 Mar 2008 09:53:31 -0500

Hi:

What happened to the list? The response I'd sent last day is just posted on the mailing list? Some mails are out of order.

Regards!
JiangXingFeng

> requested the time slot for the latter item.  You could checked 
> the link http://www.ietf.org/mail-
> archive/web/p2psip/current/msg03876.html;

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 8 Mar 2008 21:10:46 -0500

The data link to some of the IETF servers went down last nigh. When  
people got it back up this morning, their was a large backlog of  
messages.

On Mar 8, 2008, at 9:53 AM, jiangxingfeng 36340 wrote:

> Hi:
>
> What happened to the list? The response I'd sent last day is just  
> posted on the mailing list? Some mails are out of order.
>
> Regards!
> JiangXingFeng
>
>>