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

[Christer Holmberg <[e-mail]>]

Hi Arno,

I am very sorry that it took this long for me to reply. I'll blame it on the IETF meeting, summer vacation, etc...

>> 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.
>
> 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?

I think it would be good to have some text on what happens when a node is declared dead - e.g. based on your text above.

In addition, perhaps the text in section 8.15 could be moved to section 3.12, which talks about keep alive signalling in general?

----------------------------

>> 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.

But, doesn't that mean that the receiver will consider the node dead?

> 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.

So, you are saying that declaring the node is actually a GOOD thing in this case?

If so, I think it would be useful to explain in which cases declaring a node dead is good.

------------------------------

>> 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?

I think it would be good to say that the document does not specify a policy, but to give some examples on when a node is interested for the "future" - e.g. based on your text above.

Regards,

Christer