Subject: [multipathtcp] Bumping the MPTCP version number: some cons

From: Costin Raiciu <[email-masked]>
Date: Wed, 6 Apr 2016 20:47:59 +0300

Hi all,

I first have to admit that I missed the MPTCP version number bump.

While I see it has a few benefits, from what I heard in Christoph’s talk I am not convinced the change is worth those benefits. I’ll take them in turn:
- the SYN cookie reliability bug - a nice feature, but not enough to change version number - after all, TCP works fine without it!
- the load balancer support - we have a solution that requires no protocol changes whatsoever and works fine at datacenter scale. Will present it in the next meeting.
- the TLS key integration - I honestly see no benefit - if you have e2e encryption, the actual routing of paths doesn’t matter that much honestly. The attacker could DDos, at most.

Now about drawbacks: we have a feeble  deployment so far. If we bump the version number, we’ll basically have two protocols running in parallel, since it’s unlikely all (any) implementations will support both. So we might kill MPTCP before its even born. But maybe I’m just being pessimistic.

I understand there was WG consensus during the last meeting - I missed that. Was there a call on the WG mailing list? I think this subject is important enough that it gets more discussion.

Thanks.
Costin

---

From: Christoph Paasch <[email-masked]>
Date: Wed, 06 Apr 2016 18:44:50 -0300

Hello,

> - the SYN cookie reliability bug - a nice feature, but not enough to change version number - after all, TCP works fine without it!

TCP does not have this issue, as it already echoes the information necessary
for the server to create the TCP-state in subsequent segments that do
contain data.

MPTCP doesn't do this yet, as the keys are not sent in the data-segments.

I can see that it might be considered a minor issue (after all, we only fall
back to regular TCP if there is one unfortunate packet-loss). However, when
the packet-loss rate is high, this is the scenario where we really want
MPTCP to work, as that's where it provides the benefits. That's why I would
like to make MPTCP as reliable as possible in scenarios where there is a
high packet-loss.

> - the TLS key integration - I honestly see no benefit - if you have e2e encryption, the actual routing of paths doesn’t matter that much honestly. The attacker could DDos, at most.

I think one more benefit is that splitting the token from the key allows to
easily ensure that the token is unique.
At the moment, a server has to generate a key randomly, hash it to get the
token and then check the hash-table for a colliding token and repeat again
if there is a collision.

> Now about drawbacks: we have a feeble  deployment so far. If we bump the version number, we’ll basically have two protocols running in parallel, since it’s unlikely all (any) implementations will s…

I don't think so, but it is difficult to foresee this.

One thing to consider is that if we don't bump the version-number, how do we
"negotiate" support for the new ADD_ADDR option and other changes that are
already in the bis-version (e.g., RST-option and the experimental one).

Cheers,
Christoph

---

From: <[email-masked]>
Date: Wed, 6 Apr 2016 22:28:45 +0000

Costin,
Happy for this discussion to continue, as it is important.

To answer your question about when we discussed / consensus-called this in the past:

https://mailarchive.ietf.org/arch/msg/multipathtcp/wCN8SBosDGnX7abHkp11Hgl4inA - during the interim & consenus call afterwards 
also reminded /highlighted during the Yokohama meeting. We probably should have done (another) consensus call after the Yokohama meeting, but failed to - sorry.

phil

-----Original Message-----
From: multipathtcp [mailto:[email-masked]] On Behalf Of Costin Raiciu
Sent: 06 April 2016 14:48
To: MultiPath WG <[email-masked]>
Subject: [multipathtcp] Bumping the MPTCP version number: some cons

Hi all,

Thanks.
Costin

_______________________________________________
multipathtcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: <[email-masked]>
Date: Wed, 6 Apr 2016 23:17:36 +0000

I think that the motivation for bumping the version number is to make the MP-CAPABLE signalling reliable - and the argument is that this can't be done whilst being backwards compatible with the MP-CAPABLE signalling in the existing RFC.

phil

-----Original Message-----
From: multipathtcp [mailto:[email-masked]] On Behalf Of Costin Raiciu
Sent: 06 April 2016 14:48
To: MultiPath WG <[email-masked]>
Subject: [multipathtcp] Bumping the MPTCP version number: some cons

Hi all,

Thanks.
Costin

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 6 Apr 2016 20:48:04 -0700

Hello,

Just in case, I might want to clarify some points. I think the new
handshake mechanism in 6824bis can have the two benefits for stateful nodes.
You won't fallback to normal TCP when the 3rd ack is lost. Also, you can
save lots of option space in the first SYN packet which might increase the
chance to combine other features with mptcp.
>From my personal point of view, supporting stateless server looks
additional advantage.

I believe load balancer and TLS key negotiation are not included in 6824bis
yet.
I think we will need more discussions if it is integrated.
Please let me know if I miss some points. (Sorry, I couldn't find time to
check audio archive yet..)

Regards,
--
Yoshi

On Wed, Apr 6, 2016 at 2:44 PM, Christoph Paasch <[email-masked]> wrote:

> > While I see it has a few benefits, from what I heard in Christoph’s talk
> I am not convinced the change is worth those benefits. I’ll take them in
> turn:
> > - the SYN cookie reliability bug - a nice feature, but not enough to
> change version number - after all, TCP works fine without it!
>
> > - the load balancer support - we have a solution that requires no
> protocol changes whatsoever and works fine at datacenter scale. Will
> present it in the next meeting.
> > - the TLS key integration - I honestly see no benefit - if you have e2e
> encryption, the actual routing of paths doesn’t matter that much honestly.
> The attacker could DDos, at most.
>
> > Now about drawbacks: we have a feeble  deployment so far. If we bump the
> version number, we’ll basically have two protocols running in parallel,
> since it’s unlikely all (any) implementations will support both. So we
> might kill MPTCP before its even born. But maybe I’m just being pessimistic.
>

---

From: Christoph Paasch <[email-masked]>
Date: Thu, 07 Apr 2016 14:34:42 -0300

> chance to combine other features with mptcp.

Yes, independent from what we do with the TLS/load-balancer issue I think
that the gain in option-space is a nice addition.

Christoph