[tor-dev] Does TLS round-trip optimization apply do Tor?

[Yawning Angel]

On Tue, 24 Dec 2013 12:38:37 -0500
Tom Ritter <tom at 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,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20131224/ce86f63b/attachment.sig>