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

[Bruce Lowekamp <[e-mail]>]

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.

Bruce

---------------------

The draft refers to "real world" environments a lot.  This term is
relatively meaningless (or, more precisely, means different things to
each reader).  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'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.

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.

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.

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

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.



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.