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

doc/spec/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:
+  Possible solutions are:
-     * In 0.1.2.x:
+    - Drop the property that you can be sure of having the same long
-       * Add a "long version" URL that tools can start using now.  Need to
+      descriptor as others.  This seems unoptimal.
-         design it first.
+    - 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.