Subject: [ppsp] Review of draft-gu-ppsp-peer-protocol-03.txt

From: Martin Stiemerling <[email-masked]>
Date: Thu, 1 Dec 2011 13:35:42 +0000

[speaking as individual contributor and not as chair of the PPSP WG]

Hi there,

Here is my review of draft-gu-ppsp-peer-protocol in the light of selecting a peer protocol proposal as basis for the PPSP peer protocol:

- The complete semantics of the protocol is missing. There are message types defined, but even there is not clear what requests and what response are. 

- Good: I like Section 3.1, as introduces the overall interplay between the tracker and the peers.
- (Where are the reply messages to GET_PEERLIST, what is in there?)
- Leech peer vs peer: the definition is clear in the context of how has how many parts of the content, but IMO does not make sense in the protocol specification. You typically have a peer who is requesting something and the other is responding to the request. 
- GET_CHUNKMAP: Technically, it is better to let the GET_CHUNKMAP not to be an explicit request/response mechanism, but to piggy-back this request with some other messages. 
- When is TRANSPORT_NEGOTIATION executed? The semantics of this might of interest, but I cannot fully understand it. 
- General about request messages: The description is a better expansion of the message's name, but the underlying semantics is competely unclear.
- Section 5.1 "Authentication": I have not seen an enrollment server in PPSP yet. I understand that somebody wants to have an enrollment server and authentication, but this has not been discussed in PPSP until know, as far as I can tell.
- does the first message between 2 peers, I assume it is TRANSPORT_NEGOTIATION but I'm not sure at all, creating state at the peer that is receiving the request?
- there are no error messages and conditions defined. 
- it is really a bad idea to run any application level protocol on top of IP (Appendix A). 
- the draft lacks some important details to make a technical decision about the protocol, such as, how are bitmaps used/constructed/etc, how can a peer deny a request for a chunk download, etc

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014