[tor-dev] Proposal: Load Balancing with Overhead Parameters

[Tim Wilson-Brown - teor]

> On 15 Jan 2016, at 03:07, Mike Perry <mikeperry at torproject.org> wrote:
> 
> Tim Wilson-Brown - teor:
>>> On 13 Jan 2016, at 00:53, Mike Perry <mikeperry at torproject.org <mailto:mikeperry at torproject.org>> wrote:
>>> 1. Overview
>>> 
>>> For padding overhead due to Proposals 251 and 254, and changes to hidden
>>> service path selection in Proposal 247, it will be useful to be able to
>>> specify a pair of parameters that represents the additional traffic
>>> present on Guard and Middle nodes due to these changes.
>> 
>> I don't know if it's worth noting that proposals 252 and 260 (the Single Onion
>> Services variants) will reduce traffic to guard and middle nodes, as they
>> remove the nodes between the hidden service and client-controlled endpoint
>> (rendezvous point in Rendezvous Single Onion Services, extend point in
>> Single Onion Services).
>> 
>> I think these will just be part of the overhead parameters?
> 
> Probably, though this will require us to have some estimation on the
> amount of network traffic using these services. Will they be broken out
> separately in the extra-info hidden service stats?

Unfortunately, it is not possible to separate the statistics for Rendezvous Single Onion Services (RSOS), as the hidden service statistics are measured at the HSDir and Rendezvous Point relays, and not at the hidden service itself. These relays have no way of knowing whether they are connected to a RSOS or not.

The impact of this is:
* Rendezvous Single Onion Services will appear as Hidden Services in the HSDir and Rendezvous Point statistics
* Single Onion Services will appear as Hidden Services in the HSDir statistics only (they don't do Rendezvous)

However, it is possible to keep separate statistics on cells seen by a relay via Single Onion Service extend requests.
HSDirs can log requests for Single Onion Service descriptors separately, as they are the only descriptors that contain an extend-info line. However, it's may not be worth implementing, as the encryption in proposal 224 will stop HSDirs reading HS descriptors.

We could have Rendezvous Single Onion Services add an identifying line to their descriptors, but we'd have to do it in a way that allowed clients to still parse the descriptors. That would only get us the HSDir statistics anyway.

That said, if we identify RSOS in their descriptor so Tor2web clients don't connect to them, we could use the identifier for statistics as well.

I'll post a similar comment to #18082 and #17945, where this work is being tracked.
https://trac.torproject.org/projects/tor/ticket/18082 <https://trac.torproject.org/projects/tor/ticket/18082>
https://trac.torproject.org/projects/tor/ticket/17945 <https://trac.torproject.org/projects/tor/ticket/17945>

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160201/6ab0ad94/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160201/6ab0ad94/attachment.sig>