[tor-bugs] #4712 [Tor Relay]: Review and update any existing patches for proposal 182

[Tor Bug Tracker & Wiki]

#4712: Review and update any existing patches for proposal 182
-----------------------+----------------------------------------------------
 Reporter:  karsten    |          Owner:                  
     Type:  task       |         Status:  new             
 Priority:  normal     |      Milestone:  Tor: unspecified
Component:  Tor Relay  |        Version:                  
 Keywords:             |         Parent:  #4682           
   Points:             |   Actualpoints:                  
-----------------------+----------------------------------------------------

Comment(by Flo):

 Replying to [comment:3 arma]:

 > [... ...]
 > - looks like it's doing the credit bucket thing even for conns that do
 not count as relayed traffic (i.e. that fall under BandwidthRate but not
 RelayBandwidthRate). If a Tor client (or relay also used as a client)
 turns on CreditBucket, it will start counting its own traffic and
 directory fetches in some parts of the credit buckets but not others.
 >
 > [... ...]
 > - similarly, here it ignores the changes to global_relayed_foo_bucket.

 Maybe I didn’t get it right, but as far as I understand the difference
 between the global_relay_foo_bucket and global_foo_bucket is that from the
 first one the respective amount of relay-data is deducted only and from
 the second all sorts of data (including directory, client *and* relay
 traffic) is deducted. This results in an hierarchical structure that
 follows the function to limit the relayed data only and/or limit all data
 processed by the node. By saying that, I think your point (counting client
 traffic) already exists in Tor and is not something that comes with this
 patch. Meaning if I currently use my relay as client too, the amount of
 data I produce as client will be deducted from the global_foo_bucket.



 > - "OutgoingBandwidthBurst 10 MB" is a huge default. It's probably better
 set to [Relay]BandwidthBurst.

 Isn't 10 MB the current default BandwidthBurst size in Tor?



 > - That said, I wonder if there are situations where the write bucket
 gets dragged down and it basically lives right around
 "0-[wiki:OutgoingBandwidthBurst]", thus putting the relay right back into
 the situation that this patch is trying to solve. We might instrument the
 patch to warn if the write bucket spends too many seconds too close to
 that value.

 This could happen in very extreme cases only, when the outgoing traffic
 largely exceeds the incoming traffic so that the outgoing burst size
 (OutgoingBandwidthBurst) exceeds. In general, which is the usual case, if
 the written data exceeds the amount of tokens in the write bucket (e.g.
 answering directory reqeusts) we "steal" data from the read bucket which
 compensates the additional generated data; i.e. we read less data.

 In my opinion this is also the reason why it is important to consider the
 global_foo_bucket and not the global_relay_foo_bucket for this proposal.
 Nevertheless, I really appreciate instrumenting the patch in detail. And
 if I can help, just let me know.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4712#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online