Re: [ppsp] peer protocol in WG last call

[Riccardo Bernardini <[e-mail]>]

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 <[e-mail]> ha scritto:

> 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.
>
>
> _______________________________________________
> ppsp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ppsp
>



-- 
Riccardo Bernardini
DIEGM -- University of Udine
via delle Scienze 208
33100 Udine
Tel: [phone]
Fax: [phone]

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