From e3128f192dd3621a8840040ab64899ac2629587a Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Fri, 2 Mar 2007 20:00:37 +0000 Subject: r12375@Kushana: nickm | 2007-03-02 13:52:32 -0500 Meditate on why 104-short-descriptors cant work as written, and what needs to get solved before it can get implemented. svn:r9714 --- proposals/104-short-descriptors.txt | 58 ++++++++++++++++++++++++++++++++----- 1 file changed, 50 insertions(+), 8 deletions(-) (limited to 'proposals/104-short-descriptors.txt') diff --git a/proposals/104-short-descriptors.txt b/proposals/104-short-descriptors.txt index 5489116..80d16f0 100644 --- a/proposals/104-short-descriptors.txt +++ b/proposals/104-short-descriptors.txt @@ -36,16 +36,50 @@ Proposal: authorities. This could help prevent the mistake of using long descriptors in the place of short ones. - Thoughts? -NM +Other disposable fields: -Migration: + Clients don't need these fields, but removing them doesn't help bandwidth + enough to be worthwhile. + contact (save about 1%) + fingerprint (save about 3%) + + We could represent these fields more succinctly, but removing them would + only save 1%. (!) + reject + accept + (Apparently, exit polices are highly compressible.) + +Issues: + + Indexing long descriptor or bandwidth reports presents an issue: right now + the way to make sure you have the same copy of a descriptor as everyone + else is to request the descriptor by its digest, and to make sure to that + the digest you request is the one that the authorities like. + + Authorities should presumably list the digests of short descriptors, since + that's what most everybody will be using. Including a second digest for + long descriptors/bandwidth reports in the networkstatus would only bloat it + with information nobody wants. - For long/short descriptors: - * In 0.1.2.x: - * Add a "long version" URL that tools can start using now. Need to - design it first. + Possible solutions are: + - Drop the property that you can be sure of having the same long + descriptor as others. This seems unoptimal. + - Have a separate extra-information-status that also gets generated by the + authorities; use it to tell which long descriptors others have. Also a + pain. + - Have short descriptors include a hash of the corresponding long + descriptor/extra-info. This would keep the same order of magnitude + performance increase (~59.2% savings as opposed to 61% savings.) + This would require longdesc/extra-info downloaders to fetch + router data before they could know which longdescs/extra info to fetch. + - Have each authority make a signed concatenated "extra info" document, + and hope we never need to reconcile them. + - ???? - * In 0.1.2.x: +Migration: + + For long/short descriptor approach: + * First: * Authorities should accept both, now, and silently drop short descriptors. * Routers should upload both once authorities accept them. @@ -56,4 +90,12 @@ Migration: * Have authorities remember short descriptors, and serve them from the 'normal' URL. - + For bandwidth info approach: + * First: + * Rename it; it won't be just bandwidth forever. + * Authorities should accept bandwidth info + * Routers should upload bandwidth info once authorities accept it. + * There should be a way to download bandwidth info + * Once tools that want bandwidth info support fetching it: + * Have routers stop including bandwidth info in their router + descriptors. -- cgit v1.2.3-54-g00ecf