Subject: Re: [Gen-art] Gen-ART review of draft-ietf-ppsp-peer-protocol-10

From: Jari Arkko <[email-masked]>
Date: Tue, 8 Jul 2014 08:49:27 -0400

Thank you for the review, Christer.

FWIW, I agree with the points that Christer raises. Any thoughts from the authors?

When I read sections 8.14 and 8.15 they do not give as precise instruction for the implementer about how to handle keepalives and dead peer detection as I’d personally like to see. Perhaps a sentence could be added to explain what a node does (or stops doing) when it declares a peer dead.

Jari

On 30 Jun 2014, at 06:07, Christer Holmberg <[email-masked]> wrote:

> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
> 
> Document:                         draft-ietf-ppsp-peer-protocol-10
> 
> Reviewer:                           Christer Holmberg
> 
> Review Date:                     30 June 2014
> 
> IETF LC End Date:             1 July 2014
> 
> IETF Telechat Date:         10 July 2014
> 
> Summary:                         The document is well written, and almost ready for publication. However, there is a minor issue which I ask the authors to address.
> 
> Major Issues: None
> 
> Minor Issues:
> 
> Section 3.12 talks about keep alive signaling.
> 
> Q1: The sending of keep alives is a SHOULD, and there are no procedures on how to act if keep alives are not received. There isn't even a mechanism to negotiate the sending of keep alives. 
> 
> So, I assume it means that a peer shall not take any actions if it does NOT receive keep alives, or even rely on receiving keep alives to begin with? If so, I think it would be good to clarify that.
> 
> Q2: As the sending of keep alives is a SHOULD, are there example cases when keep alives would NOT be sent?
> 
> Q3: The text saying "to each peer it wants to interact with in the future" sounds a little strange to me. How does a peer know with whom it wants to interact in the future? Perhaps the text instead should talk about peers with whom one wants to maintain a signaling channel, or something like that?
> 
> 
> Editorial nits: None
> 
> 
> Regards,
> 
> Christer
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Arno Bakker <[email-masked]>
Date: Wed, 9 Jul 2014 16:45:01 +0200

Hello Christer and Gen-ART

thanks for the positive review! Please see inline for our responses

Christer Holmberg schreef op 30-6-2014 12:07:
> Q1: The sending of keep alives is a SHOULD, and there are no
> procedures on how to act if keep alives are not received. There isn't
> even a mechanism to negotiate the sending of keep alives.
>

If no keep alives are sent, a peer runs a risk of being declared dead 
following the conditions of Section 8.15. Note that if it does send 
normal messages, this is seen as a sign of liveliness. When a peer is 
declared dead "the connection" should be closed. More correct phrasing 
would be indeed "the channel should be closed", which implies no more 
messages will be sent to the peer and the local administration about the 
peer is cleared. We will change "connection" to "channel".
Does this answer your question?

> Q2: As the sending of keep alives is a SHOULD, are there example
> cases when keep alives would NOT be sent?
>

One example is that of a busy server that hosts complete copies of 
static content. In that case, the server could refrain from sending keep 
alives to save on processing and outgoing messages. In particular,
assume a client establishes a channel with the server, sends a REQUEST, 
and receives a DATA message in reply. The client acknowledges it with an 
ACK, but after that does not attempt any downloads, and just sends keep 
alives.

Ideally, this client should be garbage collected. The server can achieve 
that by not sending keep alives after the DATA message. After 3 minutes, 
the client will conclude that the server is dead and discard
the channel. And after three minutes, the server can clean up his end.
If the client would send new REQUESTs in those three minutes, the 
cleanup would be avoided.

> Q3: The text saying "to each peer it wants to interact with in the
> future" sounds a little strange to me. How does a peer know with whom
> it wants to interact in the future? Perhaps the text instead should
> talk about peers with whom one wants to maintain a signaling channel,
> or something like that?
>

It is indeed about maintaining a signaling channel. Most P2P systems 
have a policy that decides which peers are of interest now and in the 
near future. Examples of interesting peers are peers that have chunks on 
offer that this client needs, or peers that currently do not have 
interesting chunks on offer (because they are still downloading 
themselves, or in live streaming), but gave good performance in the 
past. When they have new stuff to offer they can be used again,
so you want to keep a signaling channel open.

 From a subset of those peers the client will request chunks. In P2P
systems that have tit-for-tat as freeriding prevention this is normally
a small subset as to not fragment the upload bandwidth needed to
reciprocate the peer.

Is it the phrasing that raises your question or should we explain more 
about this policy for deciding which peers are interesting?

Regards,
       Arno Bakker et al.