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

From: Arno Bakker <[email-masked]>
Date: Thu, 1 Dec 2011 10:10:55 +0100

Hi Csaba,

thanks for the good feedback. Please see answers inline:

On 30/11/2011 10:23, Csaba Kiraly wrote:
>
> 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"
> - "Each peer connects to a random set of other peers"

As mentioned to Richard, I put it in to give people an idea of the 
communication pattern, it not being a strict-tree structure. But it 
seems to be raising more questions than answering them ;o)
Will update.

> - 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?

I'm currently rewriting the draft to allow for different chunk 
addressing schemes (and content integrity protection) and making these 
dependencies clear. This is relatively straightforward, just need a 
protocol option that says which method is used. It is also not required 
for Merkle hash tree integrity protection, that just requires a way of 
addressing nodes in the tree, which can be independent of chunk ID 
addressing.

> - "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

The swift design doesn't depend on fixed size, except for the automatic 
content size detection. Hence, I moved it to a separate section in the
the current 03 revision. But apparently this is not clear enough :-(

> - "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.
>

Can you eloborate a bit? Choking is a mechanism for a peer to manage its 
upload bandwidth, so you may want to have messages for that (although we 
prefer observed behaviour, see reply to Richard).

> - "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.

Will do.

> - "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!
>

In swift we have chosen a fixed policy that has worked for us so far. 
Based on your results we can reevaluate that choice and make it a 
configurable policy. We want to avoid making things generic for 
genericity's sake, instead only if there are good reasons to do so 
(=your results).

> - "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.

Well, to start, PEX is a very security sensitive issue that needs to be 
carefully looked at (see Sec. 6.3.2.2 of swift draft). For efficient 
operation, the addresses need to be of live peers, so we somehow have to 
express that to the protocol implementor. I'll rephrase "recently 
exchanged msgs" to "known to be live, e.g. because recently exchanged 
msgs". "Recently" one could define as "in the last minute". Feel free to 
propose a different wording.

> - "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)?
>

Its function is the same, but using swift protocol messages instead of 
RFC5389.

>
> - 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.
>

As said above, the next revision will allow for different chunk 
addressing schemes.

> - 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.
>

Then please write a proposal that adds the things you need, with a 
reference to an explanation of why you need them ;o)

> - 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.

Please post a proposal ;o)

>
> - 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.
>

Again, please propose an extension if you need this functionality. My 
only "requirement" is that there is a justification of why you need that 
functionality, other than "nice to have" or "may need". This to prevent 
becoming overly generic or trying to optimize for every little use case.

CU,
     Arno