Re: [Ideas] Computing collisions

Padma Pillay-Esnault <padma.ietf@gmail.com> Tue, 13 December 2016 22:47 UTC

Return-Path: <padma.ietf@gmail.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31A3129C4A for <ideas@ietfa.amsl.com>; Tue, 13 Dec 2016 14:47:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qe5ZV_d-nEdh for <ideas@ietfa.amsl.com>; Tue, 13 Dec 2016 14:47:26 -0800 (PST)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A202B129C40 for <ideas@ietf.org>; Tue, 13 Dec 2016 14:47:26 -0800 (PST)
Received: by mail-qk0-x234.google.com with SMTP id n21so1679956qka.3 for <ideas@ietf.org>; Tue, 13 Dec 2016 14:47:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TkVbFKuylS2Tceti7HnrfFeHrBTJ0H9e4R3pP1kNFLY=; b=NubiETYh3nXjB6NGUTugYJjxjzoEOnxUr/qiu1h0sZAoEA/EKvNsASBdrJzvGYnDaU 6t6rml5Idy0Z80MIeNHUcagZGVpoAcG2kf15PFQOwNtLGksmYPy4BmQmBFkSDVKMNzQq 0wbOX0TUpbL/ZJCZGPSACSiQbP/8pn1E19DenBf/yY9xE+QtVoduanBw1SNFeDd3kfEp OiGfgxZOqmqGnaITxEtPGahqI+quy6I2+uk3L5ooYJDrq+3uyTHzC+BKZikYApJD3V5q 9XbX6LehoyzhcfZB9l+S1ycEly75h1RhblbS0QdKVJIhnjxAhYyeLTxhsWpsKYzn5s5Y rZBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TkVbFKuylS2Tceti7HnrfFeHrBTJ0H9e4R3pP1kNFLY=; b=SYU7eUPRcfuEQHgdtc03BcZbHeUJcRqGhrzaeoIVMsjYTVz5DRuezB2++Jypmb9y3D 9+PqY0pptk1XgeOKDZ2X2IeRE+stTCdh2ahzP0y+BzMywYb8bRQrWwur5DjSI69LAm0p J8n6SGlFgor6cu46nj+VhwZ1WS8f/Tk1oVAhhDpOcBU+ZbhwdX21Ak3PqbaXq9PIuLRC b7+lSIPjV5bog4v5wfogMaEp++tq8LUIotc12HsknZ2jCfArO3egqGeQSpEu16ev7xNS o3G7paGpZEoJGfm5Drc9+jzFBX88hGK9JQtPFv4lv/c4nBgp0cpYNCzudnb1+VTilMmr zPFA==
X-Gm-Message-State: AKaTC02jpCJybbvNSnA2FNRo00Nagi65Sik1kt+jY9ts78aOGWYCLoM8Q9P8dSGpzgc1yogxJCkhnpRj2mzADQ==
X-Received: by 10.55.190.66 with SMTP id o63mr84947723qkf.254.1481669245805; Tue, 13 Dec 2016 14:47:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.41.198 with HTTP; Tue, 13 Dec 2016 14:47:25 -0800 (PST)
In-Reply-To: <83be2a30-1b46-2397-976e-6e2736921e19@htt-consult.com>
References: <fb888f85-22ed-5e87-bf84-2b6244d587e6@htt-consult.com> <CAG-CQxqds9osqTTAi_Gm-VCVKGo49pW5OVALxYiYCrqNQ2yvRA@mail.gmail.com> <83be2a30-1b46-2397-976e-6e2736921e19@htt-consult.com>
From: Padma Pillay-Esnault <padma.ietf@gmail.com>
Date: Tue, 13 Dec 2016 23:47:25 +0100
Message-ID: <CAG-CQxpvLrpGX5-WW--QmMLnd6ZtxXfF3wFNNjywJJLboj_spg@mail.gmail.com>
To: Robert Moskowitz <rgm-ietf@htt-consult.com>
Content-Type: multipart/alternative; boundary="94eb2c04395c122bf80543920126"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/Awkl_sFc4ILkoRusyGmakV4slmw>
Cc: ideas@ietf.org, Padma Pillay-Esnault <padma.ietf@gmail.com>
Subject: Re: [Ideas] Computing collisions
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Dec 2016 22:47:29 -0000

It is interesting to see that with an intelligent spread we actually can
reduce the collision probability significantly.
Will add some text regarding this in the next iteration of the problem
statement.

Padma


On Tue, Dec 13, 2016 at 2:35 PM, Robert Moskowitz <rgm-ietf@htt-consult.com>
wrote:

> Here is some results.
>
> On 12/11/2016 12:03 PM, Padma Pillay-Esnault wrote:
>
> Hello Bob
>
> Thanks for sending this formula.
>
> If we assume that the population is not necessarily a flat space and that
> it is in different separate instances, this could help reduce the collision.
>
> Per the ideas problem statement draft, we have discussed about the
> different types of devices and whether we could have some policy on what
> they can do. Eg. a camera should not be shopping for clothes or access bank
> accounts .... wouldn't it make sense to put them in different instances
> with different access policies?
>
> What are your thoughts on this?
>
>
> Let's work with a 24 bit ID space which is a population of 16,777,216
>
> Let's then assume a random distribution of 2^14 (16,384) devices.  This is
> a 99.97% probablity of a collision.  A sure thing.
>
> Now let's assume that there are 256 (2^8) classes of devices and that the
> population is evenly divided.  That is 64 devices per class.  We now have
> reduced our ID space to 16 bits (65,536), but the probablity of a collision
> with only 64 devices is 3.08%!
>
> But if the division is not equal between the classes and one class has 512
> devices the probablity jumps up to 84.67%; again an almost sure thing.
>
> So we can see from this little exercise that dividing our ID space into
> groupings can actually reduce the collision risk.  Two caveats are clear
> though.  How many classes to use (you can see my effort at this in
> draft-moskowitz-hierarchical-hip) and what if one class out classes all
> the rest?
>
> You still need to manage collisions.  You just may be telling fewer losers
> to select a new ID.
>
> Now if instead you are talking about reusing your ID space on the
> assumption that these devices are NEVER interacting and thus never 'seeing'
> the inevitable collisions, then, yes, reuse the ID space.  But we all know
> what assume also spells.
>
>
> Padma
>
> On Thu, Nov 17, 2016 at 1:48 AM, Robert Moskowitz <
> rgm-ietf@htt-consult.com> wrote:
>
>> Here is the equation:
>>
>> probability of collision = 1 - e^{-k^2/(2n)}
>>
>> Where n is your max population size (e.g. 2^64)
>>
>> and k is your deployed population (e.g. 7B)
>>
>> Bob
>>
>> _______________________________________________
>> Ideas mailing list
>> Ideas@ietf.org
>> https://www.ietf.org/mailman/listinfo/ideas
>>
>
>
>