Hi Mohamed,
It's great to talk this through. I've inlined my answers.
Cheers,
Vlad
On 7/5/2017 9:00 AM, [email protected] wrote:
Hi Valdimir,
Thank you for your answer.
Please see inline.
Cheers,
Med
*De :*Vladimir Olteanu [mailto:[email protected]]
*Envoyé :* mercredi 5 juillet 2017 01:35
*À :* BOUCADAIR Mohamed IMT/OLN; David Schinazi
*Cc :* [email protected]; multipathtcp
*Objet :* Re: [Int-area] SOCKS 6 Draft
Hi Mohamed,
No problem. BTW, your work on MPTCP Plain Mode has, in fact, served as
inspiration for SOCKS 6.
When coupled with TFO on the client-proxy leg, SOCKS 6 also has a
0-RTT overhead.
[Med] Glad to see that we are pursuing the same goal. That’s said I’m
not sure about the 0-RTT in the current proposal given this text that
puts a dependency on the server side:
In the fast case, when authentication is properly set up, the proxy
attempts to create the socket immediately after the receipt of the
request, thus achieving an operational conection in one RTT (provided
TFO functionality is available at the client, proxy, and server).
^^^^^^^^
Oops, we meant to say a data response in 1 RTT (e.g. HTTP GET, then HTTP
OK).
It can also be stacked as many times as desired for arbitrarily long
proxy chains. However:
* We avoid using the SYN's payload as extra option space (which, I
think, goes against TCP's core philosophy).
[Med] This is also true for MP_CONVERT Information Element which is
not a TCP option, but a data supplied for proxy purposes in the SYN
payload.
Fair enough, but this is not a purely layer 5+ protocol. It seems that
you are strongly tied to TFO (between the client and the proxy).
MP_CONVERT must be part of the SYN's payload, because the following
SYN+ACK depends on the contents of MP_CONVERT and signals that the
remote server has accepted your connection.
The magic number at the start of the MP_CONVERT element implies that
if any MPTCP stream happens to start with 0xFAA8FAA8, the client
should not use TFO.
[Med] This can be fixed by registering a service port for the proxy
service because, after all, the ultimate destination port is conveyed
in the MP_CONVERT.
I think this is more sensible.
I think moving up the protocol stack is a more desirable alternative.
* We support authentication. Connections to the proxy can also be
initiated from networks outside of the operator's control (e.g. home
WiFis).
[Med] Authentication/authorization can be supported by various means.
This depends on the deployment scheme.
* SOCKS 6 is easier to extend. If the client needs to request some
special behavior from the proxy (e.g. what packet scheduler to use),
all we have to do is define (and standardize) a new SOCKS option.
[Med] That’s also true for MP_CONVERT Information Element. You can
define new “Types” if needed.
Can you please let me know if the proposal supports the following
features:
·Support incoming connections (Proxy<---Remote Host): That is the
proxy intercept a TCP connection that it transforms into an MPTCP one.
Yes. See section 7.2. The client makes a request and then has to keep
the connection to the proxy open. When the proxy accepts a connection
from a remote host, it informs the client of the remote host's address
and starts relaying data. SOCKS 5 has the exact same feature. You are
limited to one incoming connection per request, though.
·If such feature is supported, how a host located behind a CPE
(Host----CPE-----Proxy----Remote Host) can instruct dynamically the
CPE so that it can forward appropriately incoming connections?
It does not have to. The connection on the host-proxy leg is initiated
by the client.
·Use MPTCP in the leg between the proxy and server
Yes.
·Notify the client that the server is also MPTCP-capable (so that the
proxy can be withdrawn from the communication)
It depends on the implementation. A basic implementation just listens
for a connection from the client and then opens a socket to the server
using the vanilla socket API. It can't do any fancy stuff.
A smarter implementation (the one we're aiming for) can mirror the
keys/tokens/DSS sequence numbers (also taking the DSS delta(s) incurred
by the request/auth. reply/operation reply into account) and advertise
the server's real address(es) via ADD_ADDR. We plan to go a step further
in -01 and add an option in the operation reply that hints that the main
subflow (the one going through the proxy) should be closed once other
subflows are established.
·Relay untouched the set of TCP options supplied by the client/server
without any alteration from the proxy
Yes-ish. In both SOCKS 6 and MPTCP Plain mode, when you strip away the
initial exchange between the client and the proxy, you end up with the
actual data that has to be relayed, so I would argue that both solutions
are similar and suffer from roughly the same issues.
As long as there is a 1:1 mapping between client-proxy and proxy-server
subflows, I don't think there are many issues. In case you have TFO on
the client-proxy leg, but not on the server, you have to transmit the
SYN's payload in a subsequent packet.
When you have to convert between MPTCP and regular TCP, you can no
longer translate everything packet-by-packet and let end-to-end
congestion control do the work for you (and you can't relay ECN,
either). Further:
* In MPTCP, different subflows may send the same data using different
options and/or DSCP.
* You can't freely mix TCP timestamps from different subflows. (The
only guarantee is that timestamps are numbers that increase
monotonically for each individual subflow.)
I would go even further and say that, on principle, a proxy should not
relay unknown TCP options, but rather strip them.
·IPv6 source address/prefix preservation
I'm not sure what you mean by that.
(I've also CCed the MPTCP WG).
[Med] Thanks.
Cheers,
Vlad
On 07/04/2017 12:09 PM, [email protected]
<mailto:[email protected]> wrote:
Hi Vladimir, all,
(focusing only on this part of the message).
I do fully agree that shortening MPTCP connections setup is key.
Having 0-RTT is an important requirement for this effort.
Achieving it without out-of-band signaling would be even ideal.
Can you please elaborate on the benefits of your proposal compared
to
https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf
which allows to achieve 0-RTT proxying.
Thank you.
Cheers,
Med
*De :*Int-area [mailto:[email protected]] *De la part de*
Vladimir Olteanu
*Envoyé :* vendredi 30 juin 2017 23:37
*À :* David Schinazi
*Cc :* [email protected] <mailto:[email protected]>
*Objet :* Re: [Int-area] SOCKS 6 Draft
Hi David,
*/[/*SNIP]
- Out of curiosity, what specific use case are you using this
protocol for?
We are looking into using MPTCP on mobile devices to "bind"
4G/LTE and WiFi. Mobile data networks have high latency, hence
the drive to shave off as many RTTs as possible and to take
advantage of TFO, at least on the client-proxy leg.
Cheers,
Vlad
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
