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

Ken Rimey <> Tue, 27 October 2009 19:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B24293A68A6 for <>; Tue, 27 Oct 2009 12:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jlqLuik4S2uv for <>; Tue, 27 Oct 2009 12:50:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 510733A63EC for <>; Tue, 27 Oct 2009 12:50:03 -0700 (PDT)
Received: by ewy7 with SMTP id 7so78102ewy.7 for <>; Tue, 27 Oct 2009 12:50:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=eoQheDHiop7JO3SX6qiBbJv8CCA9vbWH5eQIZvP7ATo=; b=Nq45n3ajhVozVqGShJb84xEfhC5J135sNmP5uKk5SobToh8mSihj2T6dLBh6NDwjVd kC6G9h392KnCRiQw7o8rMWBi6urUxCWWUOS02BLtHLDjjxerBYad8MvaALaJVXkVdym9 opvrznx2F8czgDgHYZ+NdiMDxLO/hapIxqwlQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=mOCvxnP/tQv8zivz6yeZLwD9HxgohqGvnVGlbYGLkMMdRRtZe4znvMtLp318pxI7u5 +xhV6JbsFNxSRjUg1+RVe6MmZIBGQWtFfxGHNz3OUWEEnB6G99SY2eSNlYnflPt48d8P oZWW9eQP6LIcmzR4nYIJRdvQQsVya0LCWJI4U=
MIME-Version: 1.0
Received: by with SMTP id g62mr145595wef.216.1256673015770; Tue, 27 Oct 2009 12:50:15 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Tue, 27 Oct 2009 21:50:15 +0200
X-Google-Sender-Auth: dacb4f8c80bbb34e
Message-ID: <>
From: Ken Rimey <>
To: Andrei Gurtov <>, "" <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 27 Oct 2009 13:47:40 -0700
Subject: Re: [hiprg] draft-ahrenholz-hiprg-dht-05
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Oct 2009 19:52:45 -0000

On Mon, Oct 26, 2009 at 11:00 AM, Andrei Gurtov <> 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

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"

    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

    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.