[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-bugs] #21212 [Core Tor/Tor]: Write and analyze proposals for transmitting microdescriptors with less bandwidth

#21212: Write and analyze proposals for transmitting microdescriptors with less
bandwidth
------------------------------+--------------------------------
     Reporter:  nickm         |      Owner:
         Type:  defect        |     Status:  new
     Priority:  Medium        |  Milestone:  Tor: 0.3.1.x-final
    Component:  Core Tor/Tor  |    Version:
     Severity:  Normal        |   Keywords:  sponsor4
Actual Points:                |  Parent ID:  #21209
       Points:  3             |   Reviewer:
      Sponsor:                |
------------------------------+--------------------------------
 '''The idea:''' I can think of a few ways to lower the amount of bandwidth
 we use for downloading microdescriptors, without actually fetching any
 fewer.  Would any of them be worthwhile?  We should analyze them and write
 proposals for them.

  * Do we frequently download small batches of microdescriptors?  If so,
 fetching them in larger batches would get us better compression.

  * Do we frequently download small batches of microdescriptors?  If so,
 zlib dictionaries would get us better compression.

  * When a client moves from one consensus to another, the set of
 microdescriptors that the client wants is almost determined by the
 difference between those two consensuses.  (I say "almost" because the
 client may have other mds that occurred in even earlier consensuses.)  Can
 we have clients download microdescriptors in batches that depend on the
 consensus, rather than batches that are named by the microdescriptor
 digests?  This would have these benefits:
     * HTTP requests would get much shorter.
     * Batching many microdescriptors together would improve compression.
     * Batching a ''predictable group'' of microdescriptors together would
 enable us to spend more CPU on compressing those groups, since we wouldn't
 need to compress so many different groups. (See #21211)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21212>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs