Subject: [ppsp] peer protocol in WG last call

From: stefano previdi <[email-masked]>
Date: Mon, 12 Nov 2012 15:42:40 +0100

All,

during our our IETF85 PPSP WG meeting, we agreed to move 
draft-ietf-ppsp-peer-protocol-03 to WG last call.

Please send your comments, concerns, support/non-support, others 
to the list not later than November 30, 2012.

Thanks.
s.

---

From: Riccardo Bernardini <[email-masked]>
Date: Mon, 19 Nov 2012 11:45:47 +0100

Dear all,
please find some comments of mine about the I-D

First, the easy stuff.  Some typos:

== Page 35, First line of 9.5 HAVE ==
   Add an 's' to "consist"

== Page 37, second line of 9.10 REQUEST ==
   Add an 's' to "want"

Now to the "consistent" stuff:

== Page 9, Section 2.3 ==
    "If A crashes ungracefully, peers should remove A from their peer  
list when they detect it no longer send messages."

How long should a peer wait before declaring A crashed?  The case is  
easy if I send REQUEST to A and A does not responds, but what if A  
sent me a CHOKE? In that case I do not send REQUEST to A, but  
(according to the example in the third paragraph of 2.2) I still  
expect to receive HAVE from A.  In this case, I detect that A no  
longer sends messages when the last message from A was received too  
much time ago.  How much is "too much"?  Should we leave the peer free  
to decide or should we give at least some guidelines?

Also, there is the problem that when A crashes it remains registered  
with the tracker, although maybe this is not a problem directly  
related with PPSPP.

== Page 10, Section 3 ==

   It is said that "absence of any response indicates and error" and  
that "Invalid messages are discarded, and further communication with  
the peer SHOULD be stopped."

Isn't this criterion a bit too strong?  If a request is lost (e.g.,  
because of congestion), the sender will interpret the absence of  
response as an error or a bad peer.  Also, how long should a peer wait  
for declaring absence of response?  Should we give guidelines?

== Page 12, Section 3.9. ==

It is said "The CHOKE and UNCHOKE messages are informational as a peer  
is not required to respond to REQUESTs."  However, if I understand  
correctly, if a peer does not respond to REQUESTs, the peer will be  
banned, according to the criterion in Section 3.  Am I missing  
something?

== Page 13, Section 3.10.2 ==

The describe Hole Punching technique requests that

   "When peer A introduces peer B to peer C by sending a PEX_RES  
message to C, it SHOULD also send a PEX_RES message to B introducing C"

I have a couple of doubts about this

   * This supposes that A can send messages to B.  If B is behind a  
NAT, this requires that A already has a hole opened toward B.   
Therefore, A can forward only the addresses of peers it is  
communicating with.  Actually, this is required by 3.10.1

         "The addresses MUST be of peers it has exchanged messages  
with in the last 60 seconds..."

     so this should not be a problem. Would it be worth adding a  
sentence to emphasize this point? (e.g. "Note that A can send a  
message to B since by 3.10.1 A must have exchanged messages with C..."  
This is only an example, if the suggestion is accepted, feel free to  
suit it to your taste)

  * With this model of hole punching, the peer can only connect  
initially to peers with public IP; in particular, the addresses  
provided by the tracker must be public IPs.  Am I right?

== Page 16, last paragraph of Section 4.3.1 ==

   "To record which chunks ...  discussed in detail in [BINMAP]"

This is maybe a stylistic detail of tiny order, so feel free to skip  
over.  This paragraph describes an implementation suggestion that can  
be helpful for someone who wants to write some software, but it is not  
necessary for interoperability.  Maybe it could be worth to emphasize  
this.  I remember I saw in some RFC (do not ask which) something like

    Implementation note:
        To record which chunks ... discussed in detail in [BINMAP]

As I said, this is just a minor stylistic detail.

== Page 16, Section 4.3.2 ==

Another stylistic detail.  It is said that "...an implementation MAY  
choose to use ACK messages..." than later "When a receiving peer has  
successfully checked ... it MUST send an ACK message...".  The two  
verbs MAY and MUST seems to be in contrast; actually, I understand  
that the MUST is conditioned to the first MAY.  Maybe it could be  
worth to emphasize this by adding "If ACK messages are used, " in  
front of "a receiving peer" so that the final text could look like

    "If ACK messages are used, a receiving peer that has successfully  
checked ... MUST send an ACK message ... "

Again, this is just an example, so, if my suggestion is accepted, feel  
free to adapt the form to your taste.

== Top of Page 17, Section 4.4 ==

   "When a range translates to multiple bins, the byte-range peer the  
byte-range peer should send multiple e.g. HAVE message."

This sentence looks a bit garbled, at the very least "the byte-range  
peer" is repeated twice.

== Page 20, Section 5.3 ==

   "The hashes necessary to verify a chunk are in principle its  
sibling's hash and all its uncle hashes ... can be optimized "

If I understand correctly, this optimization requires that a peer MUST  
save and preserve all the received hashes.  Although reasonable, this  
is not necessarly true (unless the protocol mandates so).  With  
reference to the example of 5.3, suppose that when I received chunk C1  
I received also the hash 5, I can use it to verify the correctness of  
C1 and then throw that hash away to save memory (if, for example, I am  
a small device).  If the peer that sends me chunk C7 wants to do this  
optimization, I MUST conserve the uncle hashes I received so far.   
Note that this is not an implementation detail, but it could hurt  
interoperability.  I see two solutions for this: (a) let's write  
somewhere that a node MUST conserve the uncle hashes, or (b) if a node  
does not conserve uncle hashes it can say that during the HANDSHAKING  
by using a suitable option.

== Page 29, Section 8.2. "Version option" ==

Maybe this is thinking a bit in advance, but what should a peer set as  
version value when the peer is able to "speak" more than one protocol  
version?  Is the protocol version "global" for the whole swarm?  If it  
is, could the "negotiation" about the version done at join time,  
making this option redundant? (For example, the peer could receive the  
required version with the swarm ID from the tracker).  If the protocol  
let every pair of peers choose the protocol version, maybe this option  
could be modified to accept a list of versions.  When peer A sends its  
HANDSHAKE to peer B, it could include in the Version option all the  
versions it understands.  If one of those versions is understood by B  
too, B would reply with the chosen version as payload of the Version  
option.  Any thought?

== Page 34, Section 9.3. Channels ==

It is said that

   "... PPSPP-over-UDP uses a multiplexing scheme, called "channels"..."

Later it is said that

   "When channels are used..."

My doubt is: is the use of channels mandatory with UDP?  If yes, the  
hypothesis "when channels are used..." is redundant; if not, how does  
a peer know that channels are going to be used?  Also, if channels are  
not used, is the KEEPALIVE message just an empty packet? Moreover, the  
payload of HANDSHAKE message should change if channels are not used.

== Page 42, Section 13.2.2. ==

This section is about using the tracker as certification authority.   
It is said

   "Upon receipt, the tracker creates a membership certificate from  
the request with swarm ID S, a timestamp T and the external IP and  
port it received the message from..."

Am I wrong, or this scheme could fail if the peer is behind a  
symmetric NAT?  Would it be worth to add at least a note about this?

--

Riccardo

stefano previdi <[email-masked]> ha scritto:

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

-- 
Riccardo Bernardini
DIEGM -- University of Udine
via delle Scienze 208
33100 Udine
Tel: +39-0432-55-8271
Fax: +39-0432-55-8251

----------------------------------------------------------------------
SEMEL (SErvizio di Messaging ELettronico) - AINF, Universita' di Udine

---

From: Arno Bakker <[email-masked]>
Date: Wed, 21 Nov 2012 13:49:54 +0100

Hi Riccardo

thanks for the in-depth review! Please see inline.

> First, the easy stuff.  Some typos:

Will be corrected.

> How much is "too much"?  Should we leave the peer free

Your proposal makes sense, I'm just not sure what is customary in RFCs.
Should this go in this draft or in the planned usage guide?
Chairs?

> with the tracker, although maybe this is not a problem directly

This is addressed in the current base tracker proposal. A peer needs to 
periodically refresh its registration to stay tracked.

> for declaring absence of response?  Should we give guidelines?

We could give guidelines, but again, I'm not sure that is customary. I 
assume implementers apply common sense and, for example, not declare a 
peer dead after 1 packet loss over an unreliable transport. Invalid 
messages mean that there is really something wrong and that sender and 
receiver don't understand eachother, so then the receiver really should 
stop the interaction.

> banned, according to the criterion in Section 3.  Am I missing

No, I don't think you are missing something. The idea is that a peer P 
requesting chunks from peer Q will look for another peer R when Q 
doesn't send chunks, and Q didn't send a CHOKE to announce the fact it 
wouldn't be responding. P should take into account packet loss and swarm 
size (if there is just 1 other peer in the swarm, don't disconnect), of 
course. If P is not getting chunks from Q it moves on.

>     * This supposes that A can send messages to B.
>

Sure.

> provided by the tracker must be public IPs.  Am I right?

Yes.

>          To record which chunks ... discussed in detail in [BINMAP]

You are right.

> successfully checked ... it MUST send an ACK message...".

Will be corrected.

> This sentence looks a bit garbled, at the very least "the byte-range

Will be corrected.

> save and preserve all the received hashes.

Yes. The requirement that a sender must be able to provide these hashes 
implies that you should record them. I'll explicitly add the conclusion 
that this means you MUST record them, *if* you plan to announce you have 
them to others.

In other words, limited devices can circument this requirement by not 
sending HAVEs to others after they received a chunk. Hence they are not 
announcing the availability and are not required to provide them. Not 
sending HAVEs is allowed by the protocol. Note, however, that this does 
require that the implementation uses a reciprocity policy that allows 
this behaviour, as the limited devices are actually freeriding.

> version?

Do you have pointers to protocols where this mechanism is used? This 
could save a few roundtrips of HANDSHAKE messages, so good for 
time-till-playback if there are indeed several incompatible versions, 
which I hope there will not be ;o)

> hypothesis "when channels are used..." is redundant;

Yes it is mandatory. Pardon me if I'm wrong, but your point may just be 
grammatical, "When X" in English implies that X will be the case at some 
point. So you say "When I die" not "If I die", but I'm not a native 
speaker myself. I'll make it clearer.

> symmetric NAT?  Would it be worth to add at least a note about this?

You are right, but that problem applies for any tracker registration.
I'll add a note.

CU,
     Arno

---

From: zhangyunfei <[email-masked]>
Date: Thu, 22 Nov 2012 09:49:26 +0800

Hi Arno, Riccardo,
    Please see inline.

BR
Yunfei

zhangyunfei

From: Arno Bakker
Date: 2012-11-21 20:49
To: [email-masked]
Subject: Re: [ppsp] peer protocol in WG last call
Hi Riccardo

Will be corrected.

[Yunfei] I think Riccardo's suggestion makes sense. It's better to have some 
metrics to judge this in both protocol specification and usage guide.

Sure.

Yes.

You are right.

Will be corrected.

Will be corrected.

CU,
     Arno

---

From: Riccardo Bernardini <[email-masked]>
Date: Fri, 23 Nov 2012 18:13:28 +0100

Hi Arno,
please see inline.

Arno Bakker <[email-masked]> ha scritto:

> This is addressed in the current base tracker proposal. A peer needs  
> to periodically refresh its registration to stay tracked.
>
>
>> == Page 10, Section 3 ==
>>
> We could give guidelines, but again, I'm not sure that is customary.  
> I assume implementers apply common sense and, for example, not  
> declare a peer dead after 1 packet loss over an unreliable  
> transport. Invalid messages mean that there is really something  
> wrong and that sender and receiver don't understand eachother, so  
> then the receiver really should stop the interaction.
>
>
> No, I don't think you are missing something. The idea is that a peer  
> P requesting chunks from peer Q will look for another peer R when Q  
> doesn't send chunks, and Q didn't send a CHOKE to announce the fact  
> it wouldn't be responding. P should take into account packet loss  
> and swarm size (if there is just 1 other peer in the swarm, don't  
> disconnect), of course. If P is not getting chunks from Q it moves on.
>
>
> Yes. The requirement that a sender must be able to provide these  
> hashes implies that you should record them. I'll explicitly add the  
> conclusion that this means you MUST record them, *if* you plan to  
> announce you have them to others.
>
> In other words, limited devices can circument this requirement by  
> not sending HAVEs to others after they received a chunk. Hence they  
> are not announcing the availability and are not required to provide  
> them. Not sending HAVEs is allowed by the protocol. Note, however,  
> that this does require that the implementation uses a reciprocity  
> policy that allows this behaviour, as the limited devices are  
> actually freeriding.
>
>
> time-till-playback if there are indeed several incompatible  
> versions, which I hope there will not be ;o)

[Riccardo]
No specific protocol comes to my mind.  I checked the RFC 6709 "Design  
Considerations for Protocol Extensions"  
(http://tools.ietf.org/html/rfc6709) for hints.  In Section 4.1 there  
is a list of possible solutions for protocol versioning.  Should I  
propose a solution here "on the spot," I would suggest, inspired by  
the RFC, to make the payload of the version option a string of bytes,  
one for every supported version.
Suppose node A initiates the connection toward node B. Node A puts in  
the option all the version it supports, B picks a supported version  
(maybe the largest one?[supposing that later versions are better]) and  
sends back the HANDSHAKE with a single value in the option field.
An alternative solution, where the option payload has a fixed length,  
could be that A puts the numbers of the oldest and the newest  
supported version and B picks one version in that interval.

> Yes it is mandatory. Pardon me if I'm wrong, but your point may just  
> be grammatical, "When X" in English implies that X will be the case  
> at some point. So you say "When I die" not "If I die", but I'm not a  
> native speaker myself. I'll make it clearer.

[Riccardo]
I am not a native speaker, either. Maybe some native English speaker  
could help us here.

Riccardo

---

From: Arno Bakker <[email-masked]>
Date: Thu, 29 Nov 2012 13:35:53 +0100

Hi Riccardo

please see inline:

On 23/11/2012 18:13, Riccardo Bernardini wrote:
> is a list of possible solutions for protocol versioning.
[...]
> supported version and B picks one version in that interval.

I like the min/max versioning you propose here. I'll add a protocol 
option to hold the minimum version supported that is sent on the first 
HANDSHAKE in addition to the existing optional that will carry the max. 
The reply handshake will just have the existing version option that will 
contain the protocol selected by the receiver to use. If no common 
version is found, a closing HANDSHAKE is sent.

I'll update the draft soon to accommodate your and Yunfei's suggestions.

CU,
     Arno