Re: [lisp] Review of the LISP-NEXGON draft

Dino Farinacci <farinacci@gmail.com> Fri, 05 August 2022 22:09 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49773C15948F for <lisp@ietfa.amsl.com>; Fri, 5 Aug 2022 15:09:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EF8gcuY7072 for <lisp@ietfa.amsl.com>; Fri, 5 Aug 2022 15:09:18 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16ADC159481 for <lisp@ietf.org>; Fri, 5 Aug 2022 15:09:18 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id a15so2995402qto.10 for <lisp@ietf.org>; Fri, 05 Aug 2022 15:09:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc; bh=PQrPN2M0n8Wy3g8pP32mpW+fyu9TyDQmIOZ+w+WYYqo=; b=N8/B9NwCH1P+kSZtiDWpEd8yeU0prSfHKXu6M1UG3eAAWyvpx44ZLbDV2wprNFA0lW UM4XL/zHPPE6gyCE/LiA6Tv26X4qs8yiUvf86ctb90Ihc3KD4ebBf7F4vUaVCIKoOhq4 VLaeWfhn3vY1mJvvAvisbPqElcqFAvM/rSLvjgNzM6OT9AZGqHSMA+Brx7JfZZAE1IfK F+e8XIHZsXe4SdkV1T2KyImfTT58ZCT08oKyg5a8N2vEy7PQx7EL4IUVLi99gd1q3q1C kuwb+9kKwTzeJmfqzRebCQm2nq5uWHFTSAqK2NDSgf3Ep2F5CtMQn0i5sazvIfp7oBlW ZZbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc; bh=PQrPN2M0n8Wy3g8pP32mpW+fyu9TyDQmIOZ+w+WYYqo=; b=TevaKeQJL6if4FSAvUB66bVuHRcSMwhaR4wwNDLWESkbBAQS1EybtSvST39zrVDKbF Kl5+qLFK2EsEnZTgNRtYrr022q+ula5lBbcRvDSCHSH5+7c33u3QyspqxrtASeCS+yAB zLHzfsiUDuz8vEtyfR9jvBAnDEETsJVPQ1LNIKJE0V0DhnOBnM8Fk+7gCj8KKQZYnleV VuaQFsfBOk8/q8hEw+KbsrN8C0V9xQsL4y3nwQd+RbVfEewJQFribn4GCxxWOYB0FIQA OKxPYL40TXuSmUcuK8b21GsF+yqb6T+5N8QZubFlXeTg/D1iD14eZYKKrD0uloAJCtUw nZ1w==
X-Gm-Message-State: ACgBeo1+RtlqGWXkiQ+AFGetMgiGm+QNxQFPGK4MC53Z2WmVgNQ14YnS TwvRa0plxLDnkqZ/LrySyenL8on5QB0=
X-Google-Smtp-Source: AA6agR72jKXDvrkquwghYNCdCBTbjQl/HPiSdD71BZRh5piWCmnqapycO22gynpLZi6ykllUokuJGQ==
X-Received: by 2002:a05:622a:10:b0:31f:25de:d7ac with SMTP id x16-20020a05622a001000b0031f25ded7acmr7820332qtw.614.1659737357635; Fri, 05 Aug 2022 15:09:17 -0700 (PDT)
Received: from smtpclient.apple ([12.220.136.7]) by smtp.gmail.com with ESMTPSA id cj25-20020a05622a259900b0031eeecd21d6sm2204899qtb.69.2022.08.05.15.09.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Aug 2022 15:09:17 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <CAOZy3yF74+-A4yYnBBmkRsd3351c5eW7F_vJWN+EAZi_Qoni6g@mail.gmail.com>
Date: Fri, 5 Aug 2022 18:09:14 -0400
Cc: "lisp@ietf.org list" <lisp@ietf.org>, Fisher Yu <i@yf.io>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C5D0166-4BE9-420B-9FA7-1D34C54AB11A@gmail.com>
References: <CAOZy3yH7yKGJparQUsA=g41ncn9W2-5XR+mW+ZyJbTQST-Rysw@mail.gmail.com> <F95CCB25-7E92-4FE9-9599-503302D6CCE7@gmail.com> <CAOZy3yF74+-A4yYnBBmkRsd3351c5eW7F_vJWN+EAZi_Qoni6g@mail.gmail.com>
To: Trevor Darrell <trevor@eecs.berkeley.edu>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/W57vyoKkctj-wl8-fRjB9qGjgs8>
Subject: Re: [lisp] Review of the LISP-NEXGON draft
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Aug 2022 22:09:24 -0000

Thanks for the reply Trevor.

Dino

> On Aug 5, 2022, at 2:56 PM, Trevor Darrell <trevor@eecs.berkeley.edu> wrote:
> 
> 
> 
> On Tue, Aug 2, 2022 at 1:16 PM Dino Farinacci <farinacci@gmail.com> wrote:
> Dear Professors Darrell and Yu,
> 
> ...
> > Detections from each area are aggregated in algorithmically (location) addressable shards.
> > 
> > A consolidation process is applied to merge multiple detections from multiple points of view, varying time-stamps, and varying detection and localization errors. The consolidation process emerges the current state - enumeration of the condition of each grid tile aggregated by the shard. Both condition enumeration, data-clustering, and consolidation processing applied on network edge computers are aligned with BDD research.
> 
> One question, what if two detections, roughly at the same time, report different visualizations? Is there a policy, such that if one detected nothing and another detected an object, that you err on choosing there was an object present?
> 
> 
> In general such policies are called "non-maximal suppression", and yes, it is standard to include various heuristics and/or learned decision fusion techniques to resolve unique detections.  While this is still somewhat an area of research to perfect such techniques, they have been already widely deployed for over a decade in e.g., vehicle and pedestrian detectors, both within views and across multiple views.  Each vendor will likely implement a specific policy at first, these policies will generally rely on the network delivering as many samples as possible with minimal disruption to the same AI context, ie EID in this case.
>  
> ...
> > Therefore we believe that LISP@IETF.org is the appropriate review venue for this draft.  Please do not hesitate to contact us for further discussion of this important topic.
> 
> That is great news. We will make sure we contact you if we need any questions answered about the use-case. But Sharon is very fluent with the use-case so he answers most of our questions.
> 
> Cheers and thanks again,
> Dino
> 
> 
> Thanks/Cheers
> t
>