<div dir="ltr">Mashael, Florian,<div><br></div><div>Thanks for the information/reply.</div><div><br></div><div>Best</div><div>Gareth</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 9 July 2014 17:37, Mashael Alsabah <span dir="ltr"><<a href="mailto:malsabah@gmail.com" target="_blank">malsabah@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Gareth,<br>
<br>
You can find more details about the flow control algorithm in Tor and how<br>
Sendmes work in this paper: "DefenestraTor: Throwing out Windows in Tor".<br>
<br>
Mashael<br>
<div><div class="h5"><br>
On Jul 9, 2014, at 11:39 AM, Florian Tschorsch <<a href="mailto:tschorsch@informatik.hu-berlin.de">tschorsch@informatik.hu-berlin.de</a>> wrote:<br>
<br>
><br>
> Dear Gareth,<br>
><br>
> actually the sentence is correct.<br>
><br>
> Every OR maintains a package window and a deliver window for each<br>
> traversing circuit. You can check the source code: In or.h the circuit_t<br>
> struct definition declares a package_window and a deliver_window variable.<br>
><br>
> The reason is that Tor's circuits are originally following the leaky<br>
> pipe principal. Thus it is possible to leave the circuit at every<br>
> intermediate OR (as long as the exit policy allows it) and not only at<br>
> the last OR (i.e. the exit).<br>
><br>
> Eventually the OP maintains a window for each OR in the circuit.<br>
><br>
> As far as I know, this is not used in practice. Therefore to think there<br>
> is only one pair of windows at the OP and at the exit approximates the<br>
> current behavior sufficiently.<br>
><br>
> Cheers,<br>
> Florian.<br>
><br>
><br>
> On 03.07.2014 12:36, Gareth Owen wrote:<br>
>> Just to answer my own question for any others.<br>
>><br>
>> I've played around with it a for a few days and it seems the<br>
>> intermediate ORs don't maintain windows, it's only the edge nodes,<br>
>> maintaining a circuit, and individual stream windows.<br>
>><br>
>> Hope someone can update the spec to be clearer on this to save others<br>
>> the effort.  The offending sentence is:<br>
>><br>
>> /"The OP behaves identically, except that it must track a<br>
>> packaging window and a delivery window for every OR in the circuit."/<br>
>><br>
>> Best<br>
>> Gareth<br>
>><br>
>><br>
>> On 1 July 2014 09:51, Gareth Owen <<a href="mailto:gareth.owen@port.ac.uk">gareth.owen@port.ac.uk</a><br>
>> <mailto:<a href="mailto:gareth.owen@port.ac.uk">gareth.owen@port.ac.uk</a>>> wrote:<br>
>><br>
>>    (sorry re-post - forgot subject)<br>
>><br>
>>    Dear all<br>
>><br>
>>    I'm working on a tor research project and am having difficulty<br>
>>    understanding the SENDME cells.  The tor spec acknowledges that it<br>
>>    isn't particularly clear so I would welcome some clarification please.<br>
>><br>
>>    The spec says that *all* nodes in a circuit maintain a send and<br>
>>    receive window, and that this window is decremented on each<br>
>>    RELAY_DATA and incremented on each SENDME.  Cells that are neither<br>
>>    of these do not affect the window size.  The problem I have<br>
>>    understanding is, that only edge nodes will know whether a cell is a<br>
>>    RELAY_DATA, the intermediate nodes only know that its a RELAY but<br>
>>    not what type.  So, if only RELAY_DATA decrements the window size,<br>
>>    and intermediate nodes cannot spot these, what point is there in<br>
>>    intermediate nodes having a window?<br>
>><br>
>>    Any help greatly appreciated.<br>
>><br>
>>    Gareth<br>
>><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> tor-dev mailing list<br>
> <a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
> <a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Dr Gareth Owen<div>Senior Lecturer</div><div>School of Computing, University of Portsmouth</div><div><br></div><div>Tel: 02392 846423</div><div>

Web: <a href="http://ghowen.me" target="_blank">ghowen.me</a></div></div>
</div>