Re: [hiprg] draft-ahrenholz-hiprg-dht-05

[Ken Rimey <[e-mail]>]

On Mon, Oct 26, 2009 at 11:00 AM, Andrei Gurtov <[e-mail]> wrote:
> To me this draft looks quite mature and ready for publication.
> Ken Rimey also implemented this draft as an interface for a GoogleApp as
> well as standalone server. So it should be quite reasonable interface.
> Do you Ken have any change requests or suggestions?

Well, I'm not so sure the OpenDHT interface is ideal for this sort of
application, but it is reasonably simple, and there is software out
there that has been written to use it.  It's good for getting started
with.

On a more fundamental level, I'm not convinced we know yet whether a
practical public lookup service for a flat namespace can really be
both scalable and administratively decentralized.  The situation is
not so bad if the keys are literally host identifiers.  It's really
bad if applications are to be allowed to freely generate identifiers
to name abstract communication endpoints.

Here are a few comments on the draft.

In the introduction, mentioning that OpenLookup is not a DHT might
avoid some misunderstandings.  Maybe something like this: "OpenLookup,
while not a DHT, is another deployment of open source software
compatible with the OpenDHT interface."

Near the end of Section 3.1, the text incorrectly indicates that
OpenDHT does not promise to honor the time-to-live.  I'll quote from
"OpenDHT: A Public DHT Service and Its Uses"
(http://opendht.org/f230-rhea.pdf):

    Our goals for the OpenDHT storage allocation algorithm are as
    follows. First, to simplify life for its clients, OpenDHT should offer
    storage with a definite time-to-live (TTL). A client should know exactly
    when it must re-store its puts in order to keep them stored, so rather
    than adapting (as in Palimpsest), the client can merely set simple
    timers or forget its data altogether (if, for instance, the application’s
    need for the data will expire before the data itself).

Finally, the first paragraph of Section 6 incorrectly assumes that get
operations return values in the order in which they were put into the
DHT:

    Each put operation appends the new value to any existing values.
    If a host does not remove its old HDRR before adding another,
    several entries may be present.  Therefore when performing an
    address lookup, the last HDRR in the DHT response list should
    be used and considered to contain the current preferred address.
    Before performing each put a host should remove its old HDRR
    data using the rm operation.

Actually, the ordering of the returned values is determined by a
cursor based on just the value and the secret hash.  That's how
placemarks work.

Ken