Re: [Add] Looking at the problem space for real numbers....

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 17 June 2019 14:56 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E9612011A for <add@ietfa.amsl.com>; Mon, 17 Jun 2019 07:56:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Hf5w0dErZpXk for <add@ietfa.amsl.com>; Mon, 17 Jun 2019 07:56:47 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51777120144 for <add@ietf.org>; Mon, 17 Jun 2019 07:56:47 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [75.98.19.133]) by relay.sandelman.ca (Postfix) with ESMTPS id 272D91F450; Mon, 17 Jun 2019 14:56:45 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 2C75C3810; Mon, 17 Jun 2019 10:56:55 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Winfield, Alister" <Alister.Winfield=40sky.uk@dmarc.ietf.org>
cc: "add@ietf.org" <add@ietf.org>
In-reply-to: <2C83F6FC-F7DA-429B-84D7-0083229CBF8C@sky.uk>
References: <2C83F6FC-F7DA-429B-84D7-0083229CBF8C@sky.uk>
Comments: In-reply-to "Winfield, Alister" <Alister.Winfield=40sky.uk@dmarc.ietf.org> message dated "Mon, 17 Jun 2019 10:42:13 -0000."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 17 Jun 2019 10:56:55 -0400
Message-ID: <888.1560783415@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/nI94ieuZgvczJSS_UGaVTdlKjCQ>
Subject: Re: [Add] Looking at the problem space for real numbers....
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jun 2019 14:56:49 -0000

Winfield, Alister <Alister.Winfield=40sky.uk@dmarc.ietf.org> wrote:
> Does anyone here have any measurements to define the sizing in terms
> of:

I have no data, but I can suggest how to get the data.

> Query rates vs plain DNS assuming that in the end solutions may well
> lose all DNS caching at the OS / Customers Access Device (CPE) layers
> / Other.
>
> (Before anyone says it yes some of these caches are bypassed already
> that’s one reason simple modelling of the system to get a likely
> scaling factor is so complex)

Are you asking on behalf of sky.uk, which I think is an ISP?

Assuming that you have no IPv6 and no CGN, and your customer's CPEs do NAT44
for clients behind the CPE, then you should be able to measure number of
requests to port-53 outgoing from your clients.  That should be a simple
netflow (or equivalent) sampling of counters.

OSes and applications, even if they are talking to 8.8.8.8/etc. do cache
answers, usually for longer than they ought to.  Some ignore TTLs, asking too
often.

That would give you some data on the lower bound; I think you are right that
if DoH goes directly to the device, and the CPE does not eventually get
involved, then we lose a lot of caching.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-