Subject: Re: [multipathtcp] charter discussion

From: <[email-masked]>
Date: Thu, 6 Apr 2017 09:06:07 +0000

Behcet,

The slide was intended to be just a very high-level sketch. In both #1 and #2, the objective of the signalling is to get an endpoint’s IP address info into the ‘other’ proxy, so the proxy can do address mapping (translation) on subsequent packets (including the ACK) so that packets can travel between the endpoints. In both #1 and #2, the idea is that this signalling is done along with the TCP SYN, so that the connection via the proxies is set up with no delay (“0 RTT”)

Best wishes,
phil

From: Behcet Sarikaya [mailto:[email-masked]]
Sent: 31 March 2017 16:53
Cc: Eardley,PL,Philip,TUB8 R <[email-masked]>; [email-masked]; Joe Touch <[email-masked]>
Subject: charter discussion

Hi all,

Regarding the charter discussions that happened at the mptcp session on Thursday March 30, I asked a question but I could not understand the answer, let me ask it again.

In chairs slides page 12, TCP SYN shown in Option 1 and Option 2 actually were different although the slides seems to show that they are the same.

In Option 1, if the proxy sends TCP SYN than is it OK in a conversation the destination does not know who the source is?

In Option 2, if TCP SYN sent was the original TCP SYN from the source then

how come the TCP-ACK goes through the proxy?
A node sending a packet without its address as source address means it is router, right?

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 6 Apr 2017 15:48:03 -0500

Phil,

On Thu, Apr 6, 2017 at 4:06 AM, <[email-masked]> wrote:

> Behcet,
>
>
>
> The slide was intended to be just a very high-level sketch. In both #1 and
> #2, the objective of the signalling is to get an endpoint’s IP address info
> into the ‘other’ proxy, so the proxy can do address mapping (translation)
> on subsequent packets (including the ACK) so that packets can travel
> between the endpoints. In both #1 and #2, the idea is that this signalling
> is done along with the TCP SYN, so that the connection via the proxies is
> set up with no delay (“0 RTT”)
>

You did not answer the issues I raised below with each option, plus you
raised another one, how does it work in 0 RTT, e.g. in Option #1 or #2?

Regards,

Behcet

>
>
> Best wishes,
>
> phil
>
>
>
> *From:* Behcet Sarikaya [mailto:[email-masked]]
> *Sent:* 31 March 2017 16:53
> *Cc:* Eardley,PL,Philip,TUB8 R <[email-masked]>;
> [email-masked]; Joe Touch <[email-masked]>
> *Subject:* charter discussion
>
>
>
> Hi all,
>
>
>
> Regarding the charter discussions that happened at the mptcp session on
> Thursday March 30, I asked a question but I could not understand the
> answer, let me ask it again.
>
>
>
> In chairs slides page 12, TCP SYN shown in Option 1 and Option 2 actually
> were different although the slides seems to show that they are the same.
>
>
>
> In Option 1, if the proxy sends TCP SYN than is it OK in a conversation
> the destination does not know who the source is?
>
>
>

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 7 Apr 2017 15:54:38 +0200

Behcet,
> In chairs slides page 12, TCP SYN shown in Option 1 and Option 2
> actually were different although the slides seems to show that they are
> the same.

Option 2 is SOCKS. Option 1 places control information in the SYN and 
SYN+AC while SOCKS places this information in the bytestream.

> the destination does not know who the source is?

This is common with proxies. SOCKS and HTTP proxies for example often 
use their own address to contact
remote servers and not the client address. draft-plain-mode proposes a 
method to allow the proxy to learn the client address and thus use it to 
reach the final detaintion

> how come the TCP-ACK goes through the proxy?

Option 2 is SOCKS, thus the proxy uses its own address as a source to 
contact the final server.

> A node sending a packet without its address as source address means it

The node could have a pool of addresses like a CG-NAT

Olivier

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 7 Apr 2017 15:55:55 +0200

Behcet,
>     __ __
>
>     The slide was intended to be just a very high-level sketch. In both
>     #1 and #2, the objective of the signalling is to get an endpoint’s
>     IP address info into the ‘other’ proxy, so the proxy can do address
>     mapping (translation) on subsequent packets (including the ACK) so
>     that packets can travel between the endpoints. In both #1 and #2,
>     the idea is that this signalling is done along with the TCP SYN, so
>     that the connection via the proxies is set up with no delay (“0 RTT”)
>
>

0-rtt means that the proxy does not introduce an additional delay 
compared to the normal TCP handshake. In option 1, see draft-plain-mode, 
this is achieved by placing the control information in the SYN segments 
only.

Olivier

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 7 Apr 2017 15:19:04 -0500

On Fri, Apr 7, 2017 at 8:54 AM, Olivier Bonaventure <
[email-masked]> wrote:

> This is common with proxies. SOCKS and HTTP proxies for example often use
> their own address to contact
So both Option 1 and Option 2 sends out TCP SYN with proxy own address
as the source. I thought the two TCP SYN s were different?

> The node could have a pool of addresses like a CG-NAT
The way I understand is TCP SYN from each user (possibly many per user) is
effectively tunneled to the proxy using different mechanisms in Option 1
and Option 2, actually Option 2 makes it more implicit.
It seems like not only TCP SYN but all three-way TCP handshake needs to be
tunneled.

CPE has to deal with many parallel MPTCP connections to the same endpoint,
the proxy. I think that HTTP proxy does not have this type of problem.

This is my evaluation.

Regards,

Behcet

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 7 Apr 2017 22:45:05 +0200

Behcet,
>     Option 2 is SOCKS. Option 1 places control information in the SYN
>     and SYN+AC while SOCKS places this information in the bytestream.
>
>     This is common with proxies. SOCKS and HTTP proxies for example
>     often use their own address to contact
>     remote servers and not the client address. draft-plain-mode proposes
>     a method to allow the proxy to learn the client address and thus use
>     it to reach the final detaintion
>
>     Option 2 is SOCKS, thus the proxy uses its own address as a source
>     to contact the final server.
>
>

In Option1, this depends whether the source address has been included in 
the SYN as explained in draft-plain-mode

>
>
>
>         A node sending a packet without its address as source address
>         means it
>         is router, right?
>
>
> The way I understand is TCP SYN from each user (possibly many per
> user) is effectively tunneled to the proxy using different mechanisms in
> Option 1 and Option 2, actually Option 2 makes it more implicit.
> It seems like not only TCP SYN but all three-way TCP handshake needs to
> be tunneled.

There are no tunnels.

>
> CPE has to deal with many parallel MPTCP connections to the same
> endpoint, the proxy. I think that HTTP proxy does not have this type of
> problem.

The HTTP proxy only carries HTTP traffic. The proxy described in 
draft-plain-mode works with anytype of TCP application.

Olivier