[tor-dev] [Stegotorus] Fundamental problem with ack/retransmission mechanism

[vmonmoonshine@xxxxxxxxx]

Hello Zack,

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
client receives packet 2 partially (4k) and waits for the 60k to come.
client sends ack to the server saying that packet one is lost
server retransmits pack 1
client consider packet 1 as a part of packet 2, and thinks that now it
has 8k of packet 2
client again sends ack to the server saying that packet one is lost
server retransmits pack 1
client thinks now it has 12K of packet 2
client again sends ack to the server saying that packet one is lost
server retransmits pack 1
client thinks now it has 16k of packet 2
etc

Soon the transmit queue on the client side will get filled up by the
ack packets, cause the client won't realize its mistake before it
receives 64k of garbage and be able to compute the mac. Hence the
server and the clients will remain in this deadlock for ever. 

Originally, Stegotorus was dropping any circuit with full transmit
queue. But this was causing lots of problem because lots of time the
client lags behind the server for a while to process all the packet and
sends ack.

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. 

Otherwise, if the ack/retransmit was meant to withstand partial packet
drop, then we need to redesign it so it doesn't get trapped in such a
deadlock. Maybe we should have a timer so the circuits with full
transmit queue gets a grace period before getting dropped.

This is not specific to chop protocol. I'm wondering how TCP is
dealing with such a situation. 

Thanks,
Vmon

 
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev