Re: [Sidrops] trying to limit RP processing variability

Stephen Kent <stkent@verizon.net> Thu, 09 April 2020 19:59 UTC

Return-Path: <stkent@verizon.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE6B3A0D39 for <sidrops@ietfa.amsl.com>; Thu, 9 Apr 2020 12:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
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 OpJJx_cCQUpx for <sidrops@ietfa.amsl.com>; Thu, 9 Apr 2020 12:59:29 -0700 (PDT)
Received: from sonic312-21.consmr.mail.bf2.yahoo.com (sonic312-21.consmr.mail.bf2.yahoo.com [74.6.128.83]) (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 2CA443A0D37 for <sidrops@ietf.org>; Thu, 9 Apr 2020 12:59:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1586462368; bh=ZcoQhYql2wrqT7LPXuxGio2YzPrMF2geEdLjzdL4IPw=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=imrel3mSnWSWhqr09xL5R26DjDZCG4hCDqPfqvqjRvFy3uhevLMM8uNVFZZrFs24lAETFJJaA5+YIrU4HcxLIMoXKKLrMguaoDHk4oyz8GSGUXFQE+BKyomrTGfPpGpa+YXO7K1JkN1+krAC1H3oo0adyIHakY95CAwltuX472BvUTE+KT1ITdNCsnhsaxSOnmrZKf9pzWBn9I9DQwiKjMLgG1MJ2uD5hOhMjrVqFMe0ismT3ZlRpjfrZ/mLJUDrRQSECd62o1QEutY1BphBFdEGrnfukWd6EiyocYsyuhJathLVkWDICiM2adOBFEZ5zXKicrp7jrM5rqI/I99whA==
X-YMail-OSG: 75gq400VM1nTaDyi.UsSVTXcqRh9GKyLbXLTsUlN02SHaUnKOJovvkd809qsUjS iLL0ivBLIH687Ho1cuihPf8RRP8yjMKM4DS2DmOxH5GCbrNdG2uNs4cXCxnUk.MFyh50WlcWaQ42 4cyox.R6qeoXV_6ISIHMSURcJwQC0JhsBaHsUU0PojKxIXdNhaStn5qqkoCqorWdRZai9PUatbdL RT2iU6UaiwWftA1.7BFFVjQh59E6.2ag1JZ0SD8yhkpjN23NGHflQlQCfOFtajM2.Pn4q4OZ2.Vx Xz_S3Hspq.5K4OJPe8ZbZbjWMK6RYStwzXm58NzDyBbWwnqYXcOQzjUKRwl_4TMjtijXAY2_zH54 NVglA5zk7IjQiAioO9yL5mN1Z05_y3pbjKQlS_BpBuaTM8o_2.yCyY6hniluHbSr5Fx_n8GotiVN 8RCdprYVEkqqtDHjtttmvsHKpIyMVuVrzzVv3iRSK9dwf38xg86IGVYhmVH4.qDRTIX4b2LTSQpO mSCeKoqJiupoKGwPxU68Tz10jwMAZLTsVKSmv8tWSUrN4fqYM8Iw0JSw..IXOO_HBgaC_N4MyTMi 9jxmS52RvQBxy2tBWHOaz0J1mGKjvtFhSgTbhO1aujDFjVfhavsPfQG2qK.AMSzXsplTmyuv28Bk QQFIZVeQ78kFfz1kZxolC3Z6CmzGUBeSPm3nHmyhT_9mx3tjQ1Vg.2H_eosSo8NCFLl.Pq4ihwKy fGRywb9NIVeEpfOZ60SSW41rsAUb5v2GDX6ziCbXSKeliZj_4dHGs2SKhSG2aKQ9AescXndXCjJz U4jEQdzL.uEHEpJ.6u01a83MpwzT5LqFQYGDVrD4PXgixltfN.GGJ3FO2hVADAxqcq2pfxbXu4SO 7QE8CQ8EA_hcLnXrN_NETB07cdkzAsQTVlCBzaG0rP.F.iOWRdQHyx7yF6ZJSWQBsBMwUZ7Fo32y XQVax1Asekdntgu8f2YhtLTJ_58sltpnsoN7giVsoNpM4pMCVNF6gBT9CYqZfPWaUR0TqWsloR.u bvnYtHuJhych0aPoWrXT.IfyAhYniq8JYfb8xaQfrdgEvs4s8aBo79LGjn0nXw8h2ISxFnz0.e6H hKnzJq_lqB9ulX4Zh57RjdCDoVYCsg91qrbxY7ZptpVGo_6Xmv2i9jGXynLmcCDFVPU7A5B8cWjL j0RHDT0KKnxv7_cyRWhxlPlKNPaWuOsl0Ioko7h3Pl.D1x76iJ4Wr.e820U4v1TGejFLoeK.cteO AyZFEylS6PhnNZL9LkHqqXKLGL0kU1F2M82_ZIsd8wdNhWIXxg.JKE93ugb5JaJISOgu68y5K74O icvcPDOPCFCWXbKC8mJjrMdMWuYVCPF0F2xkUe.znlG6FsQdm5YjwY0RT9JktzWtqGmHh6XesVyG uL4BXySK39Ed3xncolOZuEjFq7qmqR7SFfw--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Thu, 9 Apr 2020 19:59:28 +0000
Received: by smtp408.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 16db1356950edc71143b80d88bc03477; Thu, 09 Apr 2020 19:59:26 +0000 (UTC)
To: Robert Kisteleki <robert@ripe.net>, "sidrops@ietf.org" <sidrops@ietf.org>
References: <a9448e54-320f-300c-d4f9-d01aca2b6ef4.ref@verizon.net> <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net> <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <a0067385-adb8-cadd-3a7f-3a362176d265@verizon.net>
Date: Thu, 9 Apr 2020 15:59:26 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15620 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/1YVJzt9u4QomKFtmaESSWDsbfBI>
Subject: Re: [Sidrops] trying to limit RP processing variability
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Apr 2020 19:59:31 -0000

Robert,
> Hi,
>
>> Missing: an object named in a Manifest, but not available for download
>> from a PP, is termed *missing*. An RP has no obvious way to acquire
>> missing objects, but operators SHOULD be warned about which objects are
>> missing.
> IMO an "RP has no obvious way to acquire missing objects" is not
> entirely true.
>
> If, at the previous run, the RP fetched the relevant (now missing)
> object, then I see no reason to not use it again. Think of the previous
> run as an object a cache if you will: if you're looking for an object
> mentioned in the manifest, and you have it already (hash / name / etc.
> matches) then you can reuse it.
I probably should have said that an RP views an object as "missing" if 
the the object is not present in the RP's cache and cannot be retrieved 
from the relevant PP. Because RPs retrieve objects only if the objects 
have changed (newly added or updated), an RP would not be aware that an 
object is not present at a PP if the object is present in the RP's 
cache. I recall a famous quote about whether an object that has not been 
updated makes any noise when it is deleted from a PP, or something like 
that :-)
> Of course it can be useful to check if it still exists in the PP, but it
> seems to me the only benefit is to detect that it is missing from there
> and perhaps warn the PP operator. Otherwise the RP has a hard time
> arguing "no idea what this is since it's not there!".
I think I agree about the utility of detecting an object that has gone 
missing from a PP, when the RP has the object locally cached. But, in my 
experience, RP software was not designed to detect this case.
> For bonus points: an implementation that fetched a PP's manifest,
> detected that it's exactly the same as before, and therefore reused the
> validation outcome from the previous run would not even have to fetch
> *any* other objects from the same PP.
If the manifest was not changed, at all, then it would not be fetched, 
right?
> The downside is that this process
> will not be able to point out the omission. The upside is saves a lot of
> resources (bandwidth, CPU and all). A further upside is that as a
> side-effect this protects against a malicious attacker (selectively)
> hiding objects.
If the only things that changed in the manifest were the updates and 
manifest number, then there would be no need to retrieve any additional 
objects, and with rsync I don't believe there would be any other file 
retrievals. I can't be sure, but I think thge BBN RPSTIR software 
behaved that way.  Do we get bonus points?
> Where this comes back to the current discussion is: would this behaviour
> be mandated, recommended, or considered a big no-no?

Which behavior? I would say recommended.

Steve