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

Re: [tor-bugs] #28804 [Core Tor/Tor]: Add circuit padding to padding-spec.txt and write a doc for researchers



#28804: Add circuit padding to padding-spec.txt and write a doc for researchers
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  High                                 |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,        |  Actual Points:
  padding, tor-spec, 041-proposed, network-      |
  team-roadmap-2019-Q1Q2                         |
Parent ID:                                       |         Points:  2
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor2
-------------------------------------------------+-------------------------

Comment (by mikeperry):

 Ideas that are popping into my head now that #28634 is done:

 One section of the doc should walk the reader through the fields of
 circpad_machine_spec_t, circpad_state_t, and their interaction with
 circpad_machine runtime_t (which is invisible to them but feature choice
 has consequences on how much memory and CPU time circpad_machine_runtime_t
 requires). This section of the doc should also describe potential features
 from the wtf-pad tag ticket list, but make it clear we're unlikely to
 implement them unless someone tells us them need them. And also mention
 that we're happy to accept patches for any useful feature or flag.

 The second section of the doc should have a pile of example machines, to
 show that the system can do much much more than we're currently using it
 for. We should not only explain #28634 and why it chose the options it did
 for performance reasons, but also explain that there's more features we
 can implement easily. We should highlight a few of those from the wtf-pad
 tag ticket list, and also show some example machines that do the
 following:

  * Implement our netflow/channelpadding as circuitpadding to the guard
  * Implement original WTF-PAD
  * Implement APE
  * Implement constant rate cover traffic from the guard (will require
 #29494 implementation to make cell delivery decisions based on cmux queue
 status, but as far as machines are concerned, this will just be a flag
 they set)
  * Explain our load balancing plans
  * Show an example of a reduced padding machine vs not (perhaps using a
 heavier-padding-count #28634 example)
  * Explain how machine precedence is meant to work when multiple machines
 exist for the same conditions

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28804#comment:10>
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