Re: [Ppm] Seeking input on DAP PR #297

Simon Friedberger <simon@mozilla.com> Fri, 12 August 2022 10:23 UTC

Return-Path: <simon@mozilla.com>
X-Original-To: ppm@ietfa.amsl.com
Delivered-To: ppm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404CAC157B44 for <ppm@ietfa.amsl.com>; Fri, 12 Aug 2022 03:23:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=mozilla.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 mIYob5LFgTDX for <ppm@ietfa.amsl.com>; Fri, 12 Aug 2022 03:23:26 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 BF0ACC157B42 for <ppm@ietf.org>; Fri, 12 Aug 2022 03:23:26 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id o22so767042edc.10 for <ppm@ietf.org>; Fri, 12 Aug 2022 03:23:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=in-reply-to:subject:from:references:to:content-language:user-agent :mime-version:date:message-id:from:to:cc; bh=xVe+6Sp1FNm2nitGKLRSNiAj2KghoeJ0kdc3lDmn5lM=; b=FhEtlmt+oJZhFnXi+UTaYHuYVWV/EfGruFgbOSTQi93Dv7wumlbndEnIySzlA6Tjml pVy6FdQtaB7pgbVpS1smWmmIHMTdzPsb3pkIR35C6JWBdrtxV4KMb60ZoFP1SxzeafIM 9ZZR7741l4zhnmNddcYBu1e5TRnI3RQ5o3TcE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:subject:from:references:to:content-language:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc; bh=xVe+6Sp1FNm2nitGKLRSNiAj2KghoeJ0kdc3lDmn5lM=; b=i9w6WuI+e5YhtVmT0Aec5ae8SKPGuXgdFxftKygJpNF+7Caonnetx90LcsJF15Rbyz OoDD+eUwj+tXbiM8C4big+/wCIZyyp9GjXZgQh7PzVIarpJiiGpNdgh6FqwJ86V/QOLC 2ww3Pk6Il5+Soi+CPq05SUaszJGYYBUdxL1fFcztpArRL+cHVGnvAFNsN6SDdZpmzrna gh295do5kMDKOhSTSMDrRV3kBmb59LmBkPoP/M48L9h2hVW4Xu8AWMfBgz8dtKB0h413 ERZQGkV5/1a4he3xP1abkXfrdiJoywqq5UHATlCzGx5q3ffYgsPDO56V/9uNFxQO+o62 UaNA==
X-Gm-Message-State: ACgBeo1VhRKUBPC0Iujv1QEAUpwW54d/4Ddd/JWeGoD/tYFaWE+k60Rm yNR8rnaB2e8/cB3nZQ7aJFQK+ORJv7C7nw==
X-Google-Smtp-Source: AA6agR5NXrAnF4JMjcr9ME+88A1qD77lWITRkUi+aWTRJh+nW7GYuN1/XW0ByFwv+umVRrUELZhxvw==
X-Received: by 2002:a05:6402:11cd:b0:43d:7862:7c25 with SMTP id j13-20020a05640211cd00b0043d78627c25mr3050893edw.96.1660299804882; Fri, 12 Aug 2022 03:23:24 -0700 (PDT)
Received: from ?IPV6:2003:eb:cf22:68e:9dd9:3272:9b3e:c333? (p200300ebcf22068e9dd932729b3ec333.dip0.t-ipconnect.de. [2003:eb:cf22:68e:9dd9:3272:9b3e:c333]) by smtp.gmail.com with ESMTPSA id g3-20020a170906538300b007307c4c8a5dsm646160ejo.58.2022.08.12.03.23.23 for <ppm@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Aug 2022 03:23:23 -0700 (PDT)
Message-ID: <2aa207b5-7db5-cff5-aa41-eb00c8dc147b@mozilla.com>
Date: Fri, 12 Aug 2022 12:23:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.12.0
Content-Language: en-US
To: ppm@ietf.org
References: <CAG2Zi22BUdB+PhjWVneBSDb-c8-MnrpiYk5zV8PF4-mo6k7hqA@mail.gmail.com>
From: Simon Friedberger <simon@mozilla.com>
In-Reply-To: <CAG2Zi22BUdB+PhjWVneBSDb-c8-MnrpiYk5zV8PF4-mo6k7hqA@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------tIttHhq0KHTxrwMa1RAJtGb6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ppm/0-6LMSyfy2clggqnx1214y5U8iQ>
Subject: Re: [Ppm] Seeking input on DAP PR #297
X-BeenThere: ppm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Privacy Preserving Measurement technologies <ppm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ppm>, <mailto:ppm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ppm/>
List-Post: <mailto:ppm@ietf.org>
List-Help: <mailto:ppm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppm>, <mailto:ppm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Aug 2022 10:23:31 -0000

Hi all,

I think property (3.) is probably not particularly important.

First, the statement "the Client knows exactly which batch its report is 
included" is dubious. While the client technically knows that its report 
is in a batch that covers its timestamp, this does not constrain when 
that batch starts or ends, how many other reports there are in it, which 
reports from the same time window have been dropped, etc. So what kind 
of useful assurances can the client derive from this?

Second, there are technical issues. It is not clear that property (1.) 
holds because it clashes with 
https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/issues/183. We just 
have it because we haven't sorted out 
https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/issues/195 yet.

Best,

Simon


On 11.08.22 22:44, Christopher Patton wrote:
> Hi all,
>
> The following PR adds support for the "fixed-size batch" use case 
> discussed at IETF 114:
> https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/pull/297
>
> It's in pretty good shape, but there is one outstanding question we'd 
> like to tease out before merging. At a very high level, it would be 
> useful if the protocol could be spelled in a way that makes the Helper 
> completely agnostic to the query type. In particular, its behavior 
> should be the same regardless of the query sent from Collector to the 
> Leader.
>
> Consider the following properties of DAP-01:
>
>     (1.) a report can belong to exactly one batch
>     (2.) batches are disjoint
>     (3.) a query determines a unique batch
>
> Together these properties ensure the Client knows exactly which batch 
> its report is included in (assuming at least one Aggregator is 
> honest). This is because of the timestamp included in its report and 
> the fact that batches are defined by non-overlapping time intervals.
>
> If we drop the requirement for (3.) then we guarantee only that a 
> Client's report is included in at most one batch. In particular it has 
> no assurance of which batch it is included in.
>
> I guess a good question to start with is: How important is (3.)? Can 
> we achieve it in a way that makes the Helper oblivious to query types?
>
> Happy aggregating,
> Chris P.
>