GitLab

I went over this in IRC tonight to a poor GSOC student who was thinking about doing a CBR plugin, so I'll file a bug while it's fresh on my mind.

Currently there is nothing in place to prevent unbound buffer growth in obfsproxy. This problem arises when the bottleneck link is extremely narrow.

For example, examine the following network topology:

 Client <-> obfsproxy <-> 14.4 kbit modem <-> ISP <-> 100 Mbit <-> obfsproxy <-> Server

The Client opens a connection, and initiates a bulk download from the Server. Since there is no mechanism to indicate congestion, the outgoing buffer in the Server side obfsproxy process will grow because feedback from the Client in the form of the shrinking TCP/IP receive window will not get propagated.

The same thing will happen on the Client side with a bulk upload, because the loopback interface has a gigantic amount of bandwidth compared to the bottleneck link.

Twisted connections have a producer/consumer interface (and can handle stopping reading once the send buffer reaches a certain threshold 'self.bufferSize'), so refactoring the base transport to use this interface to glue the upstream/downstream together would be the "correct" approach to solving this problem.

See https://twistedmatrix.com/documents/current/core/howto/producers.html for more details.