<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 7, 2012 at 12:51 AM, Roger Dingledine <span dir="ltr"><<a href="mailto:arma@mit.edu" target="_blank">arma@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On Tue, Nov 06, 2012 at 10:10:15PM -0500, Nick Mathewson wrote:<br>
> > And if a very few do, maybe the solution is to<br>
> > move to a new TLS connection for those rare cases, rather than impose<br>
> > a 2-byte penalty on every cell in all cases.)<br>
><br>
> Maaaybe, but I sure can't think of a sane testable design for that.  Can<br>
> you?  To do this sanely, we'd need to negotiate this before we exchange any<br>
> actual data, and predict in advance that we'd want it. (We wouldn't want to<br>
> do it on-the-fly for connections that happen to have large numbers of<br>
> circuits: that way lies madness.)<br>
><br>
> Also, I think those "rare cases" are communications between the busiest Tor<br>
> nodes.  I think those communications might represent a reasonably large<br>
> fraction of total Tor bytes, such that having a fallback mode might not<br>
> save us so much.<br>
<br>
</div>Ah. By "a new TLS connection", I didn't mean a new design or anything --<br>
I meant simply a second TLS connection.</blockquote><div> </div><div>I wouldn't feel very good about this route: there are enough places in our design that assume one canonical OR connection with any given relay that changing this assumption would be emphatically nontrivial and error-prone.</div>
<div><br></div><div> On the other hand, reports of circuid ID exhaustion might be premature; I get no hits searching for "No unused circ IDs. Failing" except for our source code.  Has anybody seem that warning IRL?</div>
<div><br></div><div></div></div><br></div><div class="gmail_extra">-- </div><div class="gmail_extra">Nick</div>