Subject: Re: [multipathtcp] Multipath TCP Address advertisement 1/5 - Load Balancing

From: Alan Ford <[email-masked]>
Date: Tue, 2 Aug 2016 14:56:47 +0100

Hi Fabien, all,

I support the addition of this flag - it seems useful for the two use cases you have identified below, could be added at little implementation and spec cost, and could potentially find new useful purposes in the future.

I look forward to mails 2-5 of this series ;-)

Regards,
Alan

> On 28 Jul 2016, at 13:18, Fabien Duchêne <[email-masked]> wrote:
> 
> Hello,
> 
> As agreed in Berlin during IETF96, I'm sending a series of emails to
> discuss the different contributions proposed
> inhttps://datatracker.ietf.org/doc/draft-duchene-mptcp-add-addr/
> 
> To allow Multipath TCP to operate for servers residing behind unmodified
> layer 4 load balancers we propose to define the "B" flag in the
> MP_CAPABLE option.
> 
> This flag can only be used during the three-way handshake. When this
> flag is set, it indicates that the source IP address of the segment
> containing this flag does not accept the establishment of additional
> subflows for this connection. Otherwise, the source IP address of this
> segment can be used as destination address to create additional subflows.
> 
> There are two use cases for this flag :
> 
> - servers behind a load balancer can use this flag in the SYN+ACK to
> indicate that the IP address of the load balancer should not be used to
> establish subflows. Those servers will typically announce one or more
> other addresses with the ADD_ADDR option.
> - clients behind firewalls or NAT can use this flag in the SYN. If set
> in the SYN, the flag MUST also be set in the third ACK to support
> stateless servers.
> 
> We would appreciate your feedback on this proposition.
> 
> Thanks!
> 
> Fabien
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: <[email-masked]>
Date: Tue, 2 Aug 2016 14:36:20 +0000

Makes sense to me
phil

-----Original Message-----
From: multipathtcp [mailto:[email-masked]] On Behalf Of Alan Ford
Sent: 02 August 2016 14:57
To: Fabien Duchêne <[email-masked]>
Cc: [email-masked]
Subject: Re: [multipathtcp] Multipath TCP Address advertisement 1/5 - Load Balancing

Hi Fabien, all,

Regards,
Alan

> To allow Multipath TCP to operate for servers residing behind 
> unmodified layer 4 load balancers we propose to define the "B" flag in 
> the MP_CAPABLE option.
> 
> indicate that the IP address of the load balancer should not be used 
> to establish subflows. Those servers will typically announce one or 
> more other addresses with the ADD_ADDR option.

---

From: Christoph Paasch <[email-masked]>
Date: Wed, 03 Aug 2016 20:53:45 -0700

> On Jul 28, 2016, at 5:18 AM, Fabien Duchêne <[email-masked]> wrote:
> 
> Hello,
> 

I also support the addition of the B-flag.

Christoph

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 16 Aug 2016 10:47:29 -0700

Hello Fabien, all,

On Thu, Jul 28, 2016 at 5:18 AM, Fabien Duchêne <[email-masked]
> wrote:

> in the SYN, the flag MUST also be set in the third ACK to support

I basically agree with "don't try to establish subflows with this" feature.
But, I am wondering if we can use MP_PRIO for this. (I also think it's fine
to use MP_CAPABLE as well if needed)

If we use this feature in MP_CAPBLE, we can only use this feature in the
first subflow.
If we use MP_PRIO, we can apply this feature to any subflows.
In addition, if the node want to change the status for some reasons, it can
send another MP_PRIO to update it.

Thanks,
--
Yoshi

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 18 Aug 2016 10:18:19 +0200

Yoshifumi,

> But, I am wondering if we can use MP_PRIO for this. (I also think it's
> fine to use MP_CAPABLE as well if needed)

I think MP_CAPABLE is required for the addresses of the initial subflow. 
You cannot wait for an additional message (MP_PRIO or whatever) to 
determine whether you can use this address or not for subsequence 
subflows. This would delay the establishment of subflows.

> In addition, if the node want to change the status for some reasons, it
> can send another MP_PRIO to update it.

If you used the bit in the MP_CAPABLE option to indicate that the 
address of the initial subflow should not be used and you later change 
your mind, you can simply send an ADD_ADDR option that advertises the 
same address as the initial subflow.

But this raises another question concerning the utilisation of addresses 
to create subflows. Consider two dual-homed hosts.

C ----- S
+-------+

C has two addresses, C1 and C2. S also has addresses S1 and S2. C does 
not accept subflows on C1 and C2.

The initial subflow is C1->S1. Neither C1 nor S1 should be used to 
establish subflows. S advertises S2 through an ADD_ADDR option.

At this point, C creates a new subflow C2->S2. S learns that address C2 
is also available. What should S do with the address C2 that it has 
learned ? Can this address be used to establish additional subflows ?
Should we add the same bit in the MP_JOIN option as in the MP_CAPABLE 
option to indicate that C2 should not be used to create subflows or 
should we simply say that only addresses advertised with ADD_ADDR can be 
used to create subflows ?

Olivier

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 21 Aug 2016 01:43:33 -0700

Hi Olivier,

On Thu, Aug 18, 2016 at 1:18 AM, Olivier Bonaventure <Olivier.Bonaventure@
uclouvain.be> wrote:

>> to
> determine whether you can use this address or not for subsequence subflows.
> This would delay the establishment of subflows.

Right. If we care about the delay rather than conserving a flag, I think we
should use MP_CAPABLE.
But it seems that opening a subflow immediately is a bit orthogonal to
what's written in 3.10.2.
This might not be a major issue, though.

> If you used the bit in the MP_CAPABLE option to indicate that the address
> of the initial subflow should not be used and you later change your mind,
> you can simply send an ADD_ADDR option that advertises the same address as
> the initial subflow.
>

I agree sending ADD_ADDR is another way for this. But, in my view,
 ADD_ADDR seems to be meant for notifying new addr and MP_PRIO is meant for
changing the attribute of the addr. Although this might be just my personal
preference.

> C has two addresses, C1 and C2. S also has addresses S1 and S2. C does not
> accept subflows on C1 and C2.
>
> At this point, C creates a new subflow C2->S2. S learns that address C2 is
> also available. What should S do with the address C2 that it has learned ?
> Can this address be used to establish additional subflows ?
> option to indicate that C2 should not be used to create subflows or should
> we simply say that only addresses advertised with ADD_ADDR can be used to
> create subflows ?
>

I personally think the spec doesn't need to limit the candidate addresses
for subflows. I think a peer should be able to try any possible addresses
as long as its local policy allows.
So, I agree using a bit in MP_JOIN as long as we care about the delay
rather than conserving a flag.

--
Yoshi