Description

Proposal 182 points out that we let the read bucket go negative (by reading the rest of the TLS record, which was already actually read by openssl so we might as well use what it says), but then we don't let the corresponding write occur, so we trap the cells inside Tor until the write bucket can catch up.

If that is so, then the feature is not helping us. And it may even be hurting us when combined with circuit priorities (aka ewma), since we make decisions about cell ordering before we need to.

We should compare 'with' and 'without' to see if this intuition is right.

On further thought, there may be more variables here than I'd hoped. Specifically, if we stop reading the rest of the tls record, there will be nothing that notices that we should read the rest of it next time around (see #5324).

So I am still curious to see answers here, but they won't tell us as much as I'd hoped, without lots more hacking to actually rip out the feature correctly. Shucks.

On further thought, there may be more variables here than I'd hoped. Specifically, if we stop reading the rest of the tls record, there will be nothing that notices that we should read the rest of it next time around (see #5324).

Closing since there's a lot of hacking work to be done before the code change would actually do what I wanted. Oh well.