So I'm replying to the parent, rather than the follow on conversation, but I think that is appropriate, since the initial argument Cullen makes confuses me a bit. (Ekr's point about the lower 128 being plenty random is true, but sort of irrelevant to the debate about why we are limiting this in the first place)
I guess my question is why do we have the 128-bit limit at all? The argument here is "no one has argued for a reason to be >128", but this seems like a cart before the horse argument. Sort of smacks of the "640K should be enough for anyone" decision of yore... The better question is why did the editors make limit it to 128? In general, RELOAD (and certainly earlier drafts from others) had no such restriction, and have erred in most other places on being flexible. I've never heard a compelling argument in favor of it. I personally don't recall the WG ever debating, and certainly not supporting such a decision. Personally, I see only possible down sides here, and no really good upside to limiting it. If one wants to impose a restriction, the impetus is on them to justify that restriction. (I'm fine with the default algorithm having a fixed value of course, but not the protocol. That seems wrong to me) In the absence of a *very* strong technical argument why truncation and forcing us to a fixed length is a good idea, we should err on the side of flexibility. If nothing else, reuse of code (i.e., allowing reuse of code for DHTs that have already been implemented and tested using >128 bit (or really, less, if they so desire), seems like a logical reason. If we allow various sizes (and this 160 bit IDs), I can grab off the shelf Chord algorithms. Similarly for various lengths for other DHTs. I can't see a single good technical reason *to* limit it. I personally think variable length IDs (again, at the protocol level -- not at the mandatory to implement DHT level) are a far better decision for flexibility, code reuse, and general future-proofing. Again, since as far as I recall, the WG never made a decision to impose this limit, what are the advantages? I might be missing something, but I think the right behavior is unless we have overwhelming reasons to limit it, we don't. Can those supporting 128 bit IDs share what (they think) the advantages are, and maybe we can then debate this point a bit? Thanks, David (as individual) On Wed, Feb 17, 2010 at 5:36 PM, Cullen Jennings <[email protected]> wrote: > > On Dec 10, 2009, at 2:30 PM, Roni Even wrote: > >> >> According to section 1 Reload is based on the concepts introduced in >> ietf-p2psip-concepts. The concept draft is currently expired and I noticed >> some contradictions between the two drafts. I think that the reload draft >> should progress with the concept draft. >> According to the concepts draft "The P2PSIP WG will not standardize how the >> peer-ID and the credentials are obtained, but merely standardize at least >> one acceptable format for each. To ensure interoperability, it is expected >> that at least one of these formats will be specified as >> "mandatory-to-implement"." According to RELOAD the node-id is mandated as a >> 128 bit value. According to the concept draft it can be as mandatory to >> implement format but others should be allowed. I also think that section >> 5.4.1 allows for different node-id length (see "o The length of the >> Resource-IDs and Node-IDs. For DHTs, the hash algorithm to compute the hash >> of an identifier." > > > Sounds like the concepts draft needs some work. > > On the one topic of node-id being fixed length or variable length, we > discussed the length of resource-id and and node-id a lot in the past. I have > never seen someone raise the argument of we need Node-ID short than 128 bits. > Several times people have raised the issue of we need node-id to be longer > than 128. Specifically it is generally requested that they could be 160 bits > because the output of SHA-1 is 160 bits. This request is generally fairly > confused in that it's actually the Resource-Id they are confusing with the > Node-ID. IN reload the resource-id are variable length and could be 160 bits. > This was put in largely because Salman argued strongly that this would be > needed to support unstructured overlays. The only time I can imagine that you > could possible need more than 128 bits in a Node-ID is when you assign > node-id randomly and you have more than approximately 2^64 nodes in a single > DHT or you assign node-id non randomly and you have more than 2^128 nodes in > a ring. > I don't think anyone is arguing either of these are problems and I have not > heard any other technical argument for making these larger. There are a bunch > of advantages of fixed size but ignoring all that, it does not even seem like > it's worth discussing if there is no technical reason to move to larger > node-ids. > > Good catch on section 5.4.1. Fixed that typo - thanks. > > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
