Subject: Re: [P2PSIP] comments on draft-zheng-p2psip-diagnose-02

From: songhaibin 64081 <[email-masked]>
Date: Mon, 28 Jul 2008 23:48:20 +0800

Hi Bruce,

> 
> Two comments I have after reading through this draft:
> 
> - a minor comment on 1.1.a, I think the BCP for failed node 
> recovery 
> would be to re-add "recovered" neighbor/leaf set peers on a 
> periodic 
> basis (if you have no other choice), but not to re-add recovered 
> routing 
> table peers

What you said may be true. But this issues may depend on the specific p2p algorithm. If it is a bamboo algorithm with candidate peer for each entry, then we can say "re-add recovered routing table peers" also. Thanks for pointing this out.

> 
> - I think the "traceroute" idea is interesting, but I have mixed 
> feelings about it.  On the one hand, it offers the capability of 
> giving 
> a rather quick diagnostic answer to which hop is failing.  On the 
> other 
> hand, it seems like it's in danger of being a "please DoS me" bit. 
> Effectively, the overlay is going to have to route and the 
> requesting 
> peer receive Echo Response messages at 1/3 the sending rate of the 
> peers.  Especially given the load this might impose on the 
> overlay, I 
> think it's safer to implement traceroute the conventional way 
> starting 
> with the ttl set to 1 and receiving a response from each peer as 
> the 
> message exceeds its ttl, then increasing ttl by one.  It takes 
> longer, 
> but it has the virtue of not being an amplification attack.

Bruce, what you propose is interesting an works. Now suppose in a Chord overlay with one million peers, if the successor list length is 32, then if my memory is correct, the average hops for a message is 1/2 * (20-5) = 7.5. There are not so many messages to the source peer. Additionally, the traceroute message is not initiated so often. It is only initiated when a peer wants to diagnose where the problem happens for its failed routing, or t
o collect some information of the overlay for other purposes. So traceroute message works.

The traceroute will not amplify attacks itself. In p2p overlay, each peer can reply to the source node when it receives a message unless you can have a mechanism to only allow the destination peer to repond. However, for diagnostics and error report reasons, you can't do that limit.

Do you satisfy with my clarification?

Best Regards
-Song Haibin

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

---

From: songhaibin 64081 <[email-masked]>
Date: Tue, 29 Jul 2008 03:55:32 +0800

Bruce,

> songhaibin 64081 wrote:
> > Bruce, what you propose is interesting an works. Now suppose in 
> a Chord overlay with one million peers, if the successor list 
> length is 32, then if my memory is correct, the average hops for a 
> message is 1/2 * (20-5) = 7.5. There are not so many messages to 
> the source peer. Additionally, the traceroute message is not 
> initiated so often. It is only initiated when a peer wants to 
> diagnose where the problem happens for its failed routing, or t
> I personally prefer just to look at it as O(log N), which is 20 in 
> this 
> case.  (recognizing that it's not entirely correct, but I think 
> it's 
> better guideline.)
> 
> I have mixed feelings about this.  Overall it's fewer messages to 
> do a 
> traceroute along the entire path at once, and it's lower latency.  
> And 
> there aren't *that* many echo response messages.   But it still 
> strikes 
> me as dangerous.

There are no problems for the source node to handle these responses. I realize that for the convential traceroute, it sets different TTL to track the route may because the consideration of not introducing attacks to the routers in the path (not sure). But in the p2p overlay, things are different, intermediate peers not only forward the messages like routers, they do more than that, at least in Reload, they need to modify the via list, add r
oute-log entry(optionally), and etc.. I have a little confusion here if we look the intermediate peers as just routing peers(compared to the routers), or else. I will consider the details of setting different TTL to construct the Echo traceroute, perhaps it will look more safe in that mode, but it looks more complex, I am not clear about that right now.

> > 
> > The traceroute will not amplify attacks itself. In p2p overlay, 
> each peer can reply to the source node when it receives a message 
> unless you can have a mechanism to only allow the destination peer 
> to repond. However, for diagnostics and error report reasons, you 
> can't do that limit.
> > 
> 
> I'm not sure I understand.  This is the only proposal I've seen to 
> have 
> every peer along a path generate a new unique response.   (route-
> log and 
> similar build a long list, but it is maintained as a single message)

I guess here is a trade-off if you want a big all-in-one report or step-by-step report.

-Song Haibin