On Tue, Dec 24, 2013 at 3:46 AM, Benedikt Gollatz ben@differentialschokolade.org wrote:

Tor uses TLS only for node-to-node transport encryption. Any improvements to Tor's TLS behaviour would therefore only result in occasionally faster circuit building times. This may be nice to have, but because Tor builds circuits preemptively and therefore can switch circuits quickly, I doubt that this is an actual bottleneck in the system.

If we're going to mess with the node-to-node encryption Tor uses, switching to a transport that can deliver cells out of order seems like it would have considerably more upside for the effort.

zw

On Tue, 24 Dec 2013 12:38:37 -0500 Tom Ritter tom@ritter.vg wrote:

AFAIK Optimizations that reduce round trips, including that one, are very desirable for websites accessed over Tor. The communication with a website uses TCP, SSL, and HTTP as normal, TCP acks, etc are still needed and transported over SOCKS. So optimizations there will reduce time to first byte for the website accessed over Tor, and with Tor's increased latency, it's even more pronounced. Win.

Kind of. Tor terminates TCP at each hop, so you don't gain much at the TCP level (though reducing round trips that span from the client to the destination are Good Things(TM)). Looking at what is linked, it's all configurations that need to be done on the destination, so none of the information is really all that specific to Tor.

But for TLS used in Tor itself, it's not as analogous. The analogous optimization would be looking at the cell protocol and see if cells are small enough to fit in the initial congestion window. I don't know, but what I would look for is something like Alice sending cells to Bob, but Bob can't reply to Alice's cells because Bob needs more data, but Alice needs to hear Bob's ACK before sending the rest of the data.

This is defined in RFC3390 (though certain people *cough Google* want to increase this).

Per the spec: "min (4*MSS, max (2*MSS, 4380 bytes))"

Linux uses 512 for the MSS (unless PMTUD is enabled in which case it will use the cached value (IIRC, been a while since I looked at the code). Technically it can be slightly larger (536 bytes, see RFC 879), and with IPv6 this is even less of an issue since compliant hosts must be able to receive 1280 byte packets (MSS = 1220).

Note that cwnd gets reset to 1*MSS on a timeout, which isn't great for Tor if the path in question has something that keeps PMTUD from working correctly. Personally I don't think this is useful to worry about since you've lost at the point where your RTO timer triggers from a performance standpoint (network conditions are atrocious to the point where you entirely skipped Fast Recovery).

If people are really concerned about the initial startup latency that accompanies doing a TCP handshake (despite pre-built circuits), then I suggest looking into TCP Fast Open (https://tools.ietf.org/html/draft-ietf-tcpm-fastopen-05), and piggybacking the ClientHello/ServerHello in the SYN/SYN-ACK, assuming Tor does not do this already.

Regards,