Subject: [ppsp] comments on draft-grishchenko-ppsp-swift-03

From: Csaba Kiraly <[email-masked]>
Date: Wed, 30 Nov 2011 10:23:22 +0100

Hi,

This is not a vote, just a number of comments on the actual swift draft, so I prefer to start a new thread.  I see that some similar comments have also been made by Richard, sorry for the overlap. Feel free to refer to those responses if you deem a specific question identical.

- Abstract: "mesh-like structure"
This might actually be true for most of the systems considered in PPSP, but I do not see anything later in the proposal that derives from this assumption. Is it needed?

- "Each peer connects to a random set of other peers"
The word "random" has no meaning here. Or do you mean uniform random? I don't think so. I know this sounds like a small detail, but these are the details that later create lots of confusion in the interpretation. Better remove it and change it to "Each peer connects to a set of other peers".

- bin numbers
it would be nice to see what is the dependence structure of this proposal. What are the features that depend on this idea of "bin numbers", and what are the ones that do not? What if someone prefers chunk ID lists or bitmaps? As I see it, bin numbers describe chunk ranges. A small subset of possible chunk ranges. Since every range can be described with 2 chunk IDs trivially (start and end), bin numbers do not give a huge advantage. It does reduce the description to half for some ranges, but at the price of reducing descriptive power to a small subset of all the possible ranges.

- "chunk:  The basic unit in which the content is divided. E.g. a block of N kilobyte."
This sounds like if you would think of fixed size chunks. This is quite restrictive (some implementations, like e.g. the PeerStreamer uses variable chunk sizes).
Can you tell me how much would it cost (i.e. what are the protocol features that rely on this) to relax this requirement? I do see later parts where it is mentioned that chunk size does not have to be fixed, then again features that rely on this. I think it would be better to move techniques depending on a fixed chunk size to a separate section.

- "choking"
I think choking is at a different level. It is in the application logic, and has almost nothing to do with other protocol features described in the draft. I feel it is out of scope here.

- "The HINT messages to B and C refer to disjunct sets of chunks."
I suppose this is just an example not a requirement. It would be better to clarify at the beginning of
"2. Overall Operation" that the section describes an example application logic and message sequence.

- "A sends a datagram containing HAVE messages for the chunks it just received to all its peers."
Again, this is very specific to your design. We have experimented with various chunkmap diffusion models and it is far from being trivial which one to use to optimize e.g. bandwidth utilization or delay. I would leave some liberty here to the system designer, I don't think we want to decide which one is more important at this level!

- 3.3.2. HAVE Message
"it MUST send a HAVE message to all peers it wants to interact with"
As I said earlier, I strongly disagree with this MUST. It constrains topology design and peer neighbourhood sizes, and it is not clear to me why this MUST is needed.

- "The addresses MUST be of peers it has recently exchanged messages with to guarantee liveliness."
I think it is a bad ideas to combine fuzzy terms ("recently") with a MUST in a specification. Either you have a definition of what recently means, or this is meaningless. BTW, systems could have other means of guaranteeing liveliness, in which case such a MUST becomes an unnecessary burden.

- "NAT hole punching pattern where the introducing peer effectively acts as a STUN server [RFC5389]."
Do you really mean a STUN server (as defined in the cited RFC), or just that this functionality is similar to some STUN usages, such as Interactive Connectivity Establishment (ICE)?

In general, I miss some message primitives that would make the proposal generic enough to use in a larger variety of systems:

- I miss other encodings of chunk ID sets, such as bitmaps or chunk ID lists. You do mention BINMAP, but I think this part should be extended to extend the scope of the protocol.

- In our system, we do send metadata about chunks, such as chunk priority or mutable information such as overlay hop count and other scheduling related fields. I do not yet see how these things fit your set of message types.

- We also send metadata about peers in our PEX style messages. Again, some extensibility mechanisms might be needed to add this information in a compact form. A solution could be the introduction of a PEER_INFO message type, typically (but not necessarily) sent together with PEX messages.

- In "3.6. HINT" you do mention supporting both push and pull models. There are other mechanisms in literature and in systems, such as e.g. the OFFER-ACCEPT model. I think some more message types are needed to support these models. Anything against such an extension? If not, I can send you some message sequences, so that we can discuss necessary messages in detail.

Csaba