Subject: [P2PSIP] Detecting peer failures in draft-ietf-p2psip-self-tuning

From: Jouni Mäenpää <[email-masked]>
Date: Tue, 09 Feb 2010 10:16:21 +0200

Hi,

Another open issue in the “Self-tuning DHT for RELOAD” draft
(http://www.ietf.org/id/draft-ietf-p2psip-self-tuning-00.txt) is how to
detect peer failure in the case that a peer exits the overlay without
sending a Leave message (the leave rate estimation algorithm specified
in the draft needs information about detected peer failures and
departures in order to work correctly). We can think of at least two
alternative ways to detect failed peers:

(1) Use the lack of received STUN keepalives as an indication of peer
failure. RELOAD uses STUN for keepalives. STUN keepalives are Binding
Indication transactions. Although Binding Indications do not generate a
response, the fact that a peer has failed can be learned from the lack
of packets (Binding Indications or RELOAD messages) received from the
peer. As specified in ICE [1], a peer sends a STUN Binding Indication if
there has been no packet sent on a connection for Tr seconds. Our
proposal is that if no packets have been received on a connection during
the past 2*Tr seconds, a RELOAD Ping request must sent to the remote
peer. If the remote peer fails to reply, it will be considered to have
failed.

(2) Use application-level (i.e., RELOAD) keepalives. If there has been
no packet sent on a connection for N seconds (N could be equal to Tr or
it could be larger), a RELOAD keepalive message (e.g., Ping) must be
sent to the remote peer. The downside of this approach is that the sizes
of RELOAD keepalives are much larger than the sizes of STUN Binding
Indications. Also, there will be additional ACKs (if the transport is
unreliable) sent to acknowledge the reception of RELOAD keepalive
requests and responses.

Any thoughts on this? Our proposal is to go for alternative (1) since it
generates less traffic.

Cheers,
Jouni

[1] Interactive Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal for Offer/Answer Protocols
draft-ietf-mmusic-ice-19

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 13 Feb 2010 17:52:15 -0700

On Feb 9, 2010, at 1:16 AM, Jouni Mäenpää wrote:

> Our proposal is to go for alternative (1) since it
> generates less traffic.

+1

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html