[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r9714: Meditate on why 104-short-descriptors cant work as written, (in tor/trunk: . doc/spec/proposals)
- To: or-cvs@xxxxxxxxxxxxx
- Subject: [or-cvs] r9714: Meditate on why 104-short-descriptors cant work as written, (in tor/trunk: . doc/spec/proposals)
- From: nickm@xxxxxxxx
- Date: Fri, 2 Mar 2007 15:00:37 -0500 (EST)
- Delivered-to: email@example.com
- Delivered-to: firstname.lastname@example.org
- Delivered-to: email@example.com
- Delivery-date: Fri, 02 Mar 2007 15:00:44 -0500
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-cvs@xxxxxxxxxxxxx
Date: 2007-03-02 15:00:37 -0500 (Fri, 02 Mar 2007)
New Revision: 9714
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
--- 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%. (!)
+ (Apparently, exit polices are highly compressible.)
+ 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
+ - 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.
+ - ????
- 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
* Routers should upload both once authorities accept them.
@@ -56,4 +90,12 @@
* Have authorities remember short descriptors, and serve them from the
+ 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