Comments on Proposal 105 -- handshake-revision

[Nick Mathewson]

On Sat, Oct 20, 2007 at 02:02:16AM -0400, Roger Dingledine wrote:
 [...]
> Ok, after having written this, I notice that Nick snuck in a revision to
> proposal 118 on Oct 9, though he didn't mention it on or-dev :)
> http://archives.seul.org/or/cvs/Oct-2007/msg00103.html
> This "suggested rule" appears to match my assumption in my previous post,
> which was to be smart when server1 has a descriptor available for server2,
> and otherwise be conservative and open a new connection. But doesn't
> the NETINFO cell plan mean we don't need to look at (or rely on having)
> descriptors at all?

Agreed.  IMO we should still look, but we don't need to rely on being
able to look.  (See other mail.)

> And lest I sound like I've made up my mind: there are an increasing number
> of design decisions that seem like they'll be a lot easier if we can
> assume that most servers have descriptors of most other servers. It would
> mean not needing NETINFO cells at all -- just find a descriptor signed
> by the key that's on the other end of the connection, and compare the IP
> address to the list of acceptable IP addresses in the descriptor. Maybe
> it's time to admit that assumption before we add yet more complexity?
> 
> I am leaning toward "no, we'll never succeed at scaling if we make
> design decisions that force every server to know about every server."
> Anybody else have an opinion?

I too am leaning that way.  True, being scalable requires us to do
things that make our design decisions harder--but that doesn't mean we
can afford not to be scalable.  Back when we made the "all servers
know all servers always" assumption, circuit building could get
mysteriously unreliable, and we didn't have nearly as many servers
then as we do now.

yrs,
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20071020/558d59a2/attachment.pgp>