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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
