On Tue, 24 Dec 2013 12:38:37 -0500 Tom Ritter <tom@xxxxxxxxx> 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, -- Yawning Angel
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev