> > I.e., if you're speaking of just an application proxy, then the doc > needs to be very clear of that goal AND use only the required TCP "user" > API -- which does not have any indication of an arriving SYN (it would > only indicate when the connection was established, e.g., after the TWHS > completes). >
SOCKSv6 is an application proxy, just as SOCKSv4 and SOCKSv5. This means you can use it with standard TCP API. But it also understands TFO, and if one client wishes lower RTT, he needs to use TFO API. I think this is pretty clear from the figures in the slides [1], and is the way we are currently implementing it [2]. I think the discussion here is not different from discussions when TFO was adopted: everything works as before with standard API, but you need setsockopt and connect with data if you have idempotent data and want lower RTT. > If you're speaking of something that rewrites TCP segments directly, > then you need to be clear that this is what you intend (and I cannot see > how you can do that and be compliant with TCP). > We are not talking about this in SOCKSv6. > > You can make some *assumptions* about what might happen, and even talk > about ways to configure the outgoing TCP to encourage its putting data > in the SYN (e.g., by writing before connecting). However, if we're > talking about an application layer proxy, you cannot assume availability > of the incoming SYN data unless you also assume TFO - and at best, it's > an assumption (your application would never know). > There are two points here. First, the application NEEDS TO know, because it needs to decide whether to use TFO API, or classic API(legacy apps will be classic API, of course). Second, for SOCKS (v4, v5, or v6), there is the request data which can be put in SYN, even if the user uses classic API, but this is a proxy implementation issue, and our current specification does not preclude or force this. > I.e., if you do everything right, you MIGHT end up looking "LIKE" you > rewrote the TCP SYN as it "passes through", but speaking of that as the > actual mechanism violates TCP. It looks like that IF the client has idempotent data, and IF the client uses TFO API, and IF the proxy enables TFO as a client and as a server, and IF the actual server supports TFO. So, there are a lot of IFs to get that kind of performance, but as shown in slide 9 of the presentation [1], it does work with standard API, only twice as slow. -- Dragoș [1] https://www.ietf.org/proceedings/99/slides/slides-99-intarea-socks6-00.pdf [2] https://github.com/45G/shadowsocks-libev _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
