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

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 19 Oct 2009 11:43:19 -0700

> -----Original Message-----
> From: Ahrenholz, Jeffrey M
> Sent: Wednesday, September 09, 2009 12:10 PM
> To: [email-masked]
> Subject: [hiprg] draft-ahrenholz-hiprg-dht-05
>
> The DHT draft has been updated to
> draft-ahrenholz-hiprg-dht-05. Here are
> the changes:
> - Reordered Sections 3.2 and 3.1, since the HIT lookup normally occurs
>   before the address lookup.
> - Added text about why two separate lookups are defined.
> - Added text pertaining to the OpenDHT service retiring.

Jeff,
Here are a few questions/comments on the DHT draft:

1) "The current DNS system does not provide a suitable lookup mechanism for these flat, random values, and has been heavily optimized for address lookup."

Oleg Ponomarev's draft (draft-ponomarev-hip-hit2ip-04.txt) suggests that DNS could be used in some situations, so maybe this statement needs to be relaxed, and a reference added.

2) In section 3, regarding the HIT lookup service, should we allow somehow for the possible extension that a user could put a name record that also had a certificate that bound the name to a HIT?  This may allow security to be introduced into this service, such as:  1) when the server authenticates the put() based on certificate, or 2) when the client authenticates the name-to-HIT binding based on certificate retrieved.

3) is it possible for a put() to fail?  If so, how should an implementation handle that event?

4) Section 4:  "Note that this HDRR format is different than the HIP RR used by the Domain Name System as defined in [RFC5205]."  It may be helpful to mention here that the reason it is different is that it is a different record from a functional point of view:  in DNS, the query key is a FQDN, and the return value is a HIT, while here, the query key is a HIT.

5) Should the reader of this HDRR verify that the SRC HIT and DST HIT values are correct, and discard if not, or be permissive about these values?

6) In the last paragraph of section 4, it starts to describe HIP-aware DHT behavior, but then says that it is out of scope.  What would be required to go ahead and specify the HIP aware interface in this draft?  In this case, the put() may fail (see #3 above) and this failure would need to be conveyed to the client somehow.  Is there anything else required to extend the scope to also allow for HIP-aware DHT servers?

7) Section 5's title could probably just be simplified to read "Use Cases"

- Tom

---

From: Andrei Gurtov <[email-masked]>
Date: Mon, 26 Oct 2009 11:00:39 +0200

Thanks for comments, Tom.
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?

Andrei

Henderson, Thomas R wrote:
> _______________________________________________
> hiprg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hiprg

---

From: Ken Rimey <[email-masked]>
Date: Tue, 27 Oct 2009 21:50:15 +0200

> 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