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

[Alan Ford <[e-mail]>]

Hi all,

Costin re-visited the issue of version number bumping in today's interim. In order to clarify matters here, I think it's worth just going back over why working group consensus for -05 was to do this.

The thread can be found here: http://www.ietf.org/mail-archive/web/multipathtcp/current/msg02572.html

The benefits this has so far brought are:

- Support for stateless servers:
  - No need for key in initial SYN (saves option space)
  - Reliability of third ACK (including carrying data)
- Save 1 subtype (ADD_ADDR2 -> ADD_ADDR)

And we can potentially make other protocol-level changes before finalising v1 for standards track, for example the keyless SYN makes the proposal in draft-paasch-mptcp-application-authentication simpler (although it could be done with discarded key whilst retaining compatibility with the SHA-1 exchange).

I guess support for stateless servers could be signalled in the flags, i.e. the client saying "I will echo this reliably in the ACK if you want me to" and the server also sets that flag if it wants the client do this.

What do you think? Bear in mind the MPTCP version negotiation is specified anyway:

   The MP_CAPABLE exchange in this specification (v1) is different to
   that specified in v0 [5].  If a host supports multiple versions of
   MPTCP, the sender of the MP_CAPABLE option SHOULD signal the highest
   version number it supports.  The passive opener, on receipt of this,
   will signal the version number it wishes to use, which MUST be equal
   to or lower than the version number indicated in the initial
   MP_CAPABLE.  Given the SYN exchange is different between v1 and v0
   the exchange cannot be immediately downgraded, and therefore if the
   far end has requested a lower version then the initiator SHOULD
   respond with an ACK without any MP_CAPABLE option, to fall back to
   regular TCP.  If the initiator supports the requsted version, on
   future connections to the target host, the initiator MAY cache the
   version preference.  Alternatively, the initiator MAY close the
   connection with a TCP RST and immediately re-establish with the
   requested version of MPTCP.

Regards,
Alan


On 7 Apr 2016, at 18:34, Christoph Paasch wrote:

> On 06/04/16 - 20:48:04, Yoshifumi Nishida wrote:
>> 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.
> 
> 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
> 
>> 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 <[e-mail]> wrote:
>> 
>>> Hello,
>>> 
>>> On 06/04/16 - 20:47:59, Costin Raiciu wrote:
>>>> 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!
>>> 
>>> 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 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.
>>> 
>>> 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 support both. So we
>>> might kill MPTCP before its even born. But maybe I’m just being pessimistic.
>>> 
>>> 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
>>> 
>>> _______________________________________________
>>> multipathtcp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/multipathtcp
>>> 
> 
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp