On Thu, Apr 18, 2013 at 3:49 PM, vmonmoonsh...@gmail.com wrote:
In testing the retransmission algorithm, I encounter situations that
the ack/retransmission algorithm is unable to resolve by design. It
happens when the header of a packet gets deliver but the middle part
gets dropped. For example in the following scenario
Server sends packet 1 len 4k
packet 1 gets lost
Server sends packet 2 len 64k
the last 60kb of packet 2 gets lost
This isn't supposed to be possible. The steg-in-use (whichever one it
is) is supposed to ask the chopper for blocks that are small enough
that they will either be delivered entirely or not at all.
That isn't supposed to mean that we have to limit ourselves to blocks
smaller than the MTU, because TCP is supposed to deliver entire
streams reliably. In your example, the last 60kb of packet 2 ought
to be delivered by TCP before anything else can arrive on that
connection, and the retransmit of packet 1 ought to be happening on a
*different* connection, if we have one. (Which steg are you using?)
...
If ack/retransmit by design wasn't meant to recover from partial packet lost
and was only a defense for complete packet lost, then the dropper
proxy isn't doing a good job simulating the intended threat model.
So I'm not understanding exactly what the dropper proxy does. Does
it prevent TCP from providing reliable delivery? If so, how?
I'm not saying you're wrong, btw. The ack/retransmit design happened
in a tearing hurry at a dog-and-pony show last year, in response to
terrible network conditions at the venue (we were seeing something
like one out of five IP packets just disappear), and we (me and Vinod)
*thought* we had it right, but we never did finish debugging, and it's
entirely possible that it doesn't work.
TCP *did* cope with the terrible network, it was just stegotorus that
didn't, and honestly I'm not sure the ack-retransmit notion was the
right way to go. It was never 100% clear to me what was happening to
the connections that froze up. ST absolutely *does* need a congestion
control mechanism, though, to prevent the entire circuit from getting
killed because it overran the fixed-size reassembly queue, and as long
as we have to do that ...
zw
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
