Subject: Re: [P2PSIP] reload-04 stun

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 19 Jun 2008 15:31:52 -0400

JiangXingFeng wrote:
>>> Yes, I agree some sort of keep alive is needed to detect liveness on
>>> these connection. We also need to be able to deal with receiving a TCP
>>> RST for the TLS connections.
>> Why should the keepalive be at the peer layer rather than using STUN?
>> It seems like that mechanism is well-understood and lightweight.  Now
>> detecting failure is a slightly different question (and very hard, in
>> general), but in general it seems to me that the stun keepalives solve
>> this.
> 
> 
>> (You're right that the draft doesn't say that you should be using STUN
>> keepalives over TCP/TLS.  But assuming it did, do you think it needs
>> something else at the peer layer?)
> 
> 
> IIRC, STUN keepalive is used to make the middle-box, such as NAT, firewall
> to keep the state valid. It is often sent within a short interval. I also
> think it is a good alternative to carry out the keepalive. But to me, there
> are two questions:
> 1. For a direct connection without the involvement of the middle-box, the
> STUN keepalive is not needed any more;

One of the motivations for using it is that the device does not need 
have an oracle that tells it whether it is in such a situation or not. 
As ekr points out in another email, periodic UPDATEs can serve the same 
purpose.  Doesn't matter what the message is except for UDP where using 
STUN to detect rebinding is very useful.

> 2. Although RELOAD requires all nodes support STUN, but P2P implementation
> and STUN library are separate modules and it requires the modification to
> the current STUN implementations to let the STUN notify other applications
> on the same host what's happening about the connection in question. Do we
> need a standard interface or just leave it to implementation? 

We use our implementation of STUN in multiple components.   STUN is 
small enough that you could just integrate a custom version in each 
protocol.  You can also write something that's pluggable and use the 
same implementation with different components. I think this is just an 
implementation question.

Bruce

> 
> On the other hand, I think keepalive mechanism could be easily extended to
> distribute some state changes about peer's information to its neighbors. SEP
> makes use of the keepalive to realize a light-weight service discovery
> mechanism. 
> 
> -
> JiangXingFeng
> 

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