[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Proposal 328: Make Relays Report When They Are Overloaded
On Wed, Dec 09, 2020 at 10:09:51AM -0500, David Goulet wrote:
> On 07 Dec (15:36:53), Ian Goldberg wrote:
> > On Mon, Dec 07, 2020 at 03:06:43PM -0500, David Goulet wrote:
> > > Greetings,
> > >
> > > Attached is a proposal from Mike Perry and I. Merge requsest is here:
> > >
> > > https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/22
> > >
> > > Cheers!
> > > David
> >
> > Nice!
> >
> > Is there a way to distinguish "not overloaded" from "does not support
> > this extension"? (Ideally in a better way than checking the tor release
> > version number and inferring when support was added?)
>
> Gooood point.
>
> So in theory, we have protocol version[1] in order to differentiate relays but
> I do not believe such a change would be a wise thing to use a new "Desc="
> since tor will just ignore the unknown fields.
>
> The other reason for that is that "tor functionalities" as in to function
> properly won't depend on that descriptor field so it is a bit a stretch to
> justify this as a new protocol version :S ...
>
> So yeah, either one looks at the tor version or "you don't see it, not
> overloaded" which is ofc a lie until the entire network migrates.
What if, once a day or 72 hours or something, a relay explicitly outputs
"not overloaded" if they're not?
> We expect our sbws (bandwidth scanner tool) to be the main customer
> for this.
I know at least one research group that would be very interested in
these stats as well. :-)
--
Ian Goldberg
Canada Research Chair in Privacy Enhancing Technologies
Professor, Cheriton School of Computer Science
University of Waterloo
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev