Re: [P2PSIP] comments on draft-maenpaa-p2psip-topologyplugin-00

[Jouni Mäenpää <[e-mail]>]

Hi Bruce,

Thanks for your comments! See my answers inline.

> I think drafts that discuss alternative/extension overlay algorithms
> are a great contribution and appreciate the authors writing this
> draft.  Would be really nice to get WG effort behind making some of
> these concepts WG items.

I'm glad to hear that.

> The draft refers to "real world" environments a lot.  This term is
> relatively meaningless (or, more precisely, means different things to
> each reader).  

The term "real world" was a poor choice. We will replace that.

> Define use cases where the draft is necessary or offers
> performance improvements and make concrete claims.  Obviously
> many/most large-scale overlays with moderate churn perform better with
> some of the techniques.  State that or something similar and the
> overlay algorithm features that are needed for that/those use case(s).
>  Similarly, state the use case that requires load balancing.  The
> basic sip usage is probably not one of them given the small size of
> registrations.   But an eventual voicemail usage is likely to be a
> supporting use case, for example.   Remember that there are real world
> use cases where this algorithm behaves more poorly than the default
> RELOAD algorithm.  For example, a small-office phone system is a real
> world use case.  It's one that is typically ignored by much of the P2P
> community, but it is one of the motivating use cases in P2PSIP.

I agree that adding use cases would improve the draft. We'll define them
in the next version.

> I'm not immediately convinced of the usefulness of the load balancing
> concept.  In particular, the load balancing aims to balance out the
> uneven load that is the natural result of hashing and uneven peer
> spacing.  However, for many use cases load imbalance seems to be more
> a function of resource size distribution rather than uneven mapping.
> For example, a file sharing usage might have several orders of
> magnitude variation in resource size, whereas uneven mapping is a
> factor of O(log(N)).  To me, it's much more important to solve the
> large file problem by dividing large files among multiple locations.
> Once that is done, using virtual servers to balance mapping and
> account for device capacity becomes more pressing.  While I can see
> that an optimal chunking might be usage-specific, I can also see a lot
> of use of it as a general service.  The security mechanisms remain a
> challenge there.
> 
> How does one run UpdateAlphaDelta when using an enrollment server/CA
> for certificates?  I don't see this addressed anywhere.
> 
> There are obvious important benefits to using periodic stabilization
> in certain circumstances.  However, the way the virtual server load
> balancing is specified appears to me to be produce at least an order
> of magnitude more traffic in response to peer changes than a reactive
> stabilization algorithm.  For example, in the event of a finger table
> entry failure, the peer Leaves all of its virtual server locations
> (with associated resource transfers), identifies a new set of virtual
> server IDs, then reJoins at the new addresses and transfers resources.
>  By comparison, reactive stabilization sends a few Updates when a
> neighbor fails.

Perhaps Ashwin or Saumitra can answer the load balancing related
questions better than I can, since they wrote those parts of the draft.
If people think that load balancing is needed only in a subset of use
cases, then one possible way forward would be to make load balancing
optional and specify it separately from the rest of the mechanisms.

> In the UpdateReq and a few other places, the sender asserts their ids
> in a message structure.  Those need to be obtained from a certificate,
> not from the message body.

If you are referring to the sender_id parameter, our intention was to
remove it from the current version of the draft (it turned out that it
is not actually needed), but somehow we forgot to do that.

> There are some reactive elements to the periodic stabilization
> algorithm.  For example, on successor failure, the peer walks its
> successor list pulling from each.  A reactive pull rather than a
> reactive push is still a reactive algorithm.

The current draft is the result of a merge of two earlier drafts,
draft-saumitra-p2psip-loadbalance-00 and
draft-maenpaa-p2psip-self-tuning-00. The former used reactive
stabilization (as it was an extension to the Chord algorithm of RELOAD
base), whereas the latter one used periodic stabilization. Our intention
was to make the algorithm in the current draft completely periodic.
However, it seems that we didn't manage to remove all the reactive
elements from the algorithm. We will look into that in the next version
of the draft.

> Section 6 uses almost entirely SHOULD rather than MUST.  I am fairly
> sure that an implementation that did not implement any of the SHOULDs
> would fail to work entirely.  I suspect that almost all SHOULDs should
> be MUST.  It's helpful to indicate what a reason might be for not
> implementing a SHOULD when SHOULD is appropriate.  (Henning can make
> this argument with a lot more passion, if necessary.)

Ok, thanks for pointing this out.

> I really like the effort on adaptive stabilization.   One factor to
> consider, though, is whether keepalives of some sort (possibly NAT
> binding keepalives) need to be sent more often than necessary based on
> peer failure, and those keepalives might as well be a basic Update.
> Sort of a complex question based on the cost of a STUN keepalive vs
> p2p layer, but I think it's an interesting question.

Keepalives or basic Updates would definitely help in detecting peer
failure faster. We will look into this.

> The next two comments are aimed at making the text clearer.  First, I
> should be clear that I'm not going to claim I've never done these in
> writing text (and I think there are still parts of the base draft that
> need to have these applied).
> 
> A lot of the text merges analysis/justification with normative text.
> Implementers don't care about the analysis, and even for those who do
> it makes it harder to find the normative text.  Separate these where
> possible, ideally into separate sections, but at least separate
> paragraphs.
> 
> A number of aspects of the algorithm are of the form (this is not a
> real extract):
> - when y fails, send a probe to ID t for a new entry
> - when receiving response for ID t from peer q, send an Attach to q
> - once the Attach completes, send an Update to q
> While this is great in descriptive text, the implementation is
> entirely different since the implementation has to be asynchronous.
> And while IETF isn't about implementation, there are a lot of protocol
> correctness issues left exposed here (what happens if a better peer
> than q is identified in between sending the Attach and it
> completing?).  Better to write normative text that specifies a single
> reaction when an event happens.  For example, you might write that
> when a better finger table entry is identified, an Attach is sent to
> it.  Specified entirely separately (and possibly somewhere else),
> finger table and neighborhood entries are updated when an Attach
> completes for a better match than the current entry.  This also avoids
> missing stating obvious things everywhere, like in 6.4 where it isn't
> entirely clear that an Attach needs to be completed before updating
> the neighbor list.

We will try to separate analysis and normative text in the next version.

Thanks,
Jouni