[or-cvs] r9714: Meditate on why 104-short-descriptors cant work as written, (in tor/trunk: . doc/spec/proposals)

[nickm@xxxxxxxx]

Author: nickm
Date: 2007-03-02 15:00:37 -0500 (Fri, 02 Mar 2007)
New Revision: 9714

Modified:
   tor/trunk/
   tor/trunk/doc/spec/proposals/104-short-descriptors.txt
Log:
 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.



Property changes on: tor/trunk
___________________________________________________________________
 svk:merge ticket from /tor/trunk [r12375] on c95137ef-5f19-0410-b913-86e773d04f59

Modified: tor/trunk/doc/spec/proposals/104-short-descriptors.txt
===================================================================
--- tor/trunk/doc/spec/proposals/104-short-descriptors.txt	2007-03-02 20:00:33 UTC (rev 9713)
+++ tor/trunk/doc/spec/proposals/104-short-descriptors.txt	2007-03-02 20:00:37 UTC (rev 9714)
@@ -36,16 +36,50 @@
   authorities.  This could help prevent the mistake of using long descriptors
   in the place of short ones.
 
-  Thoughts? -NM
+Other disposable fields:
 
+  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.
+
+  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.
+    - ????
+
 Migration:
 
-  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.
-
-     * In 0.1.2.x:
+  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 @@
        * 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.