Prop 110 revisions

[mrwigglet]

That's how I was thinking of doing it also, but I'm content to wait for
however everybody thinks it should all be done.  Meanwhile, I've got the
patches with the minor issues ready and am willing to go along with however
you all want it done, be that with prop 105 changes or other!

Thanks,

Nate

On 8/23/07, Christian Grothoff <christian at grothoff.org> wrote:
>
> On Thursday 23 August 2007 19:31, Nick Mathewson wrote:
> > >  Third question
> > > is about where to put the two fields.  Moving the counter for seen
> > > extend cells to or_circuit_t is fine, but I'm not sure the other can
> > > be moved to origin_circuit_t.  The reason is that the only place I
> > > can find that the CELL_RELAY type is set is in
> > > relay_send_command_from_edge and the type of circuit in that function
> is
> > > circuit_t not
> > > origin_circuit_t.
> >
> > This will probably depend on which implementation we wind up doing.
> > If RELAY_EXTEND cells only originate from the client, then the counter
> > can go into origin_circuit_t, since every client circuit is an
> > origin_circuit_t.  If other nodes in the circuit decide to sometimes
> > originate RELAY_EXTEND cells (as they do in the migration phase in my
> > half-backed idea in my last email in this thread), then everybody
> > needs a count.
>
> How about this: if a peer (starting at patch level 2) receives a normal,
> non-RELAY_EXTEND cell and its counter of # relay-extend-cells received is
> still < MAX, it just converts the cell type (and decrements the
> EXTEND-received counter).  Yes, this will prevent the initiator from
> sending
> RELAY-EXTEND cells after the first 10, but no harm done there (and would
> be
> as in Proposal 110 anyway).  As for anonymity sets, just having a single
> patch-level 2 peer on the path would result in the exit-level seeing
> RELAY_EXTEND, so your anonymity sets are preserved.   In essence, we use
> the
> same counter that we use to reject RELAY_EXTEND to automatically convert
> to
> RELAY_EXTEND.  I think if we do this, we can get away with just a single
> counter.
>
> I think this is either what you were proposing or at least an equally
> effective alternative ;-).
>
> > Cool!  Sorry for the indecisiveness here; I really wish we had this
> > all designed well ahead of time. :/
>
> No problem, these things need to be considered thoroughly.
>
> Cheers!
>
> Christian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070823/5610023f/attachment.htm>