Re: PKS, and the DV/MD choice...

Matt Crawford <crawdad@fnal.gov> Tue, 06 May 1997 22:54 UTC

Received: from cnri by ietf.org id aa06888; 6 May 97 18:54 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa21634; 6 May 97 18:54 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA23961; Wed, 7 May 1997 08:43:07 +1000
Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA23932; Wed, 7 May 1997 08:35:29 +1000
Received: from fnal.fnal.gov by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id WA23806; Wed, 7 May 1997 08:35:27 +1000 (from crawdad@gungnir.fnal.gov)
Received: from gungnir.fnal.gov ("port 39281"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IIK32JO4LE0015FJ@FNAL.FNAL.GOV>; Tue, 06 May 1997 17:35:24 -0600
Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id RAA22685; Tue, 06 May 1997 17:33:57 -0500
Date: Tue, 06 May 1997 17:33:57 -0500
From: Matt Crawford <crawdad@fnal.gov>
Subject: Re: PKS, and the DV/MD choice...
In-Reply-To: "28 Apr 1997 10:43:30 EDT." <"9704281443.AA29183"@ginger.lcs.mit.edu>
Sender: crawdad@gungnir.fnal.gov
To: Noel Chiappa <jnc@ginger.lcs.mit.edu>
Cc: big-internet@munnari.oz.au
Message-Id: <199705062233.RAA22685@gungnir.fnal.gov>
Content-Transfer-Encoding: 7BIT
X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j; Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{<k&QF?d6L7o&zLqb%kXn!!]ykXMKtTiy9#20]$EKP/^Z$T]'P6, 8L#r&mH4PB<ljN,_.=iCpv#N:HIcy5t7{HV:<=g=V?^;-d,J*xkq0r
Precedence: bulk

A little untimely, but I don't see where anyone else made this point:

> 	In an MD system, you should only get updates from R1 when the
> topology next to R1 changes (i.e. it's connect to some other router, or a
> piece of the nework, changes), and each topology change is *guaranteed* to
> send you only a small amount of data (i.e. what R1 is connected to now). I.e.
> you don't get all of whatever routing table entries have changed - which
> could be a lot of data items, each one of which would have to be checked, 

Now you have a large signed item describing old state and a small
signed item describing changes.  Either
	1) You can propagate the former and suppress the latter
or	2) All data expires and is often being re-sent and re-checked
or	3) The source of the data is somehow able to propagate the
	   data past you by some means with which you can't interfere.

I don't believe (3).  (2) either loses big or sets a bound on routing
convergence time.  (1) isn't a fix, just a partial fix and probably a
net waste of effort.

It seems to me that the time to check N bytes of data is AN+B, where
A is the inverse-speed of your hashing function and B is the time to
do a public-key computation.  Certain ranges of a and b favor sending
only complete topology information (or at least, complete at a given
level of abstraction) rather than incremental updates.

				Matt Crawford