Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:25:43Zhttps://gitlab.torproject.org/legacy/trac/-/issues/7747SENDME doesn't need to trigger packaging so aggressively2020-06-13T14:25:43ZNick MathewsonSENDME doesn't need to trigger packaging so aggressivelyRight now when we process a relay sendme cell, that triggers an attempt to package the stream's inbuf. But that's needlessly aggressive. We could instead have it only attempt to package the stream's inbuf when the window was previously...Right now when we process a relay sendme cell, that triggers an attempt to package the stream's inbuf. But that's needlessly aggressive. We could instead have it only attempt to package the stream's inbuf when the window was previously 0, right?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7743Avoid needless wasted space in cells2020-06-13T14:25:42ZNick MathewsonAvoid needless wasted space in cellsIn #7707, cypherpunks notes that when packaging cells, we can do some really dumb things when bandwidth is low, such reading incoming bytes in a super-slow trickle, and packaging them into cells aggressively.
There are two comparatively...In #7707, cypherpunks notes that when packaging cells, we can do some really dumb things when bandwidth is low, such reading incoming bytes in a super-slow trickle, and packaging them into cells aggressively.
There are two comparatively easy things I want to do to prevent this:
* We should use FIONREAD to determine the number of cells waiting on an incoming edge socket. If we determine that more reading in the future will let us fit more bytes in a cell, we shouldn't package bytes in a cell yet.
* We could avoid packaging incoming bytes from a stream for so long as that circuit has any queued cells that originated here, in case more incoming bytes arrive before we'd transmit the current cell.
This feels like a backport candidate to 0.2.3.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7707Impose a minimum write size for TLS writes2020-06-13T14:25:33ZNick MathewsonImpose a minimum write size for TLS writesReported pseudonymously:
If our TokenBucketRefillInterval is very low, we'll frequently wind up with very small writes, which can be exceptionally bad with TLS. One answer is to say "don't do that then" and keep TokenBucketRefillInterf...Reported pseudonymously:
If our TokenBucketRefillInterval is very low, we'll frequently wind up with very small writes, which can be exceptionally bad with TLS. One answer is to say "don't do that then" and keep TokenBucketRefillInterfal to about 100msec or so. Another answer is to nagle our TLS writes, and never write less than the full amount in the output buffer, or one cell, whichever is smaller.
For non-TLS writes, the kernel should nagle for us, so we're probably fine, though it might be sensible to impose a write threshold there too.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/2681brainstorm ways to let Tor clients use yesterday's consensus more safely2022-03-22T13:28:40ZRoger Dingledinebrainstorm ways to let Tor clients use yesterday's consensus more safelyRight now Tor clients won't use a consensus that's 25 hours old. But if the directory authorities don't agree on a consensus for a day, things can go bad. We need to investigate other tradeoffs in this space than the one we've currently ...Right now Tor clients won't use a consensus that's 25 hours old. But if the directory authorities don't agree on a consensus for a day, things can go bad. We need to investigate other tradeoffs in this space than the one we've currently picked.
For instance: if you got your directory consensus info when it was valid, but you haven't been able to get any new consensus, perhaps you should be more forgiving about the timestamp on the consensus you have. That's a slightly different scenario than believing a new consensus that's 48 hours old.
Another option is just to change 24 to 48, which probably doesn't put clients at much greater harm, but gives us a lot more breathing room for mistakes.
The implementation side of this will be tricky, because we'll need to make sure that clients can handle descriptors that are 36 hours out of date too. We started implementing that feature several times, but I think we've never finished it.Tor: unspecified