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

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




On 15 Jan 2016, at 03:07, Mike Perry <mikeperry@xxxxxxxxxxxxxx> wrote:

Tim Wilson-Brown - teor:
On 13 Jan 2016, at 00:53, Mike Perry <mikeperry@xxxxxxxxxxxxxx> 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/17945

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev