Re: [multipathtcp] A proposal for MPTCP Robust session Establishment (MPTCP RobE)

[Yoshifumi Nishida <[e-mail]>]

Hi Markus,

Thanks for the response. Some points became clearer to me.

On Wed, Oct 25, 2017 at 5:08 AM, <[e-mail]> wrote:

> Dear Yoshi,
>
> see inline
>
> > -----Original Message-----
> > From: Yoshifumi Nishida [mailto:[e-mail]]
> > Sent: Mittwoch, 4. Oktober 2017 09:53
> > To: Amend, Markus <[e-mail]>
> > Cc: multipathtcp <[e-mail]>
> > Subject: Re: [multipathtcp] A proposal for MPTCP Robust session
> > Establishment (MPTCP RobE)
> >
> > Hi Markus,
> >
> > I still need to think about it a bit more, but here's my current
> thoughts.. Sorry
> > for slow response.
> >
> > 1: I am guessing we cannot use this approach with TFO yet. But, if TFO
> cannot
> > be used, it might affect the latency of some apps.
> >
> We assume, RobE can incorporate TFO. Therefore we have different solutions
> in mind. But first we need an aligned understanding of TFO. There is one
> aspect, which isn't fully clear for me or respectively from my view not
> specified explicitly in RFC7413.
> TFO allows payload in a SYN and in case of a valid TFO cookie, this is
> directly delivered to receivers application. Now the question:  Is the
> sender allowed to proceed directly after sending the SYN with further data
> packets or is a SYN/ACK response required?
> By investigating current Linux TFO implementation it seems, sender first
> wait for the SYN/ACK before sending further data packets. But what shall we
> assume? At the end this is pretty important for a possible RobE<->TFO
> integration.
>

Well, I'm not worry very much about whether the sender wait for SYN ACK
before proceed.
Please let me explain...
When you use TFO, I guess you'll send the same payload P in two SYN
segments.
Then, both P payloads can be delivered to application sockets.
In this case, I'm still now sure how we can combine two sockets (on both
sender and receiver side)
For example, should the sender presume that two P have been received by the
receiver and advanced seq no by 2*P?
When I think about these kinds of situations, I thought it might be complex.


> > 3: I guess we'll need another step after SA6.2 to verify the response
> from
> > host B.
>
> no, we don't. data can be sent together with the MP_JOIN_CAP and
> immediately afterwards. if it is not successful, either we receive a RST
> (standard case) or we run into a timeout (error case). In both cases a
> retransmit over the first path is done.
>
> >     Also, MP_JOIN_CAP will require extra RTTs when the other end doesn't
> > support it. (because it will need to send RST and MP_JOIN to establish a
> > subflow)
> >
> yes, indeed this is a problem. there are several possibilities to address
> that problem:
> a) modify the MP_CAPABLE, adding an extra bit in syn/syn-ack. (e.g. one of
>    the A-H bits).
>    however this violates the standard, and thus will be incompatible with
>    existing implementations - unless it is introduced together with
>    ver. 1 - which already is incompatible, so it doesn't matter.
> b) if introduced together with ver. 1 - we know that the server supports
>    it if it supports ver. 1 - however it still might be deactivated.
> c) add an extra MPTCP-option.
>    in version 0, this can exhaust the tcp option space.
>    in version 1, (due to missing key info) this is feasible, if TFO
>    is not active. with TFO we already have that info, an extra option
>    is not necessary.
> d) cache that information, so only the first try adds an extra rtt.
>    later on (until cache expiration) we don't try fast-join again.
> e) sending an MP_JOIN_CAP + sending an MP_JOIN (note the join is a
>    new connection request (SYN), but can be associated with the
>    MP_JOIN_CAP by the key/token).
>    - In case the MP_JOIN_CAP succeeds, the MP_JOIN is ignored.
>    - In case it fails, the join is initiated before the RST arrives
>      on sender site. Avoiding the extra RTT, with the cost of
>      extra packets on the wire.
>    - The problem with reordering on the wire (MP_JOIN arrives before
>      MP_JOIN_CAP), can be avoided using one of the three reserved bits
>      in the MP_JOIN. These should be ignored by current implementations.
> f) a combination of those above.
>
> > 4: I tend to prefer just sending MP_JOIN after SA6.1 for simplicity so
> far. We
> > might be able to do everything in a shim layer.
> >
> Of course it is possible to do it in two steps. First only robustness and
> later on extend it with the fast-join approach.
> But why a shim-layer, do you suspect some incompatibility issues? Or do
> you just want to keep it out of MPTCP?
> But then note: Even that shim-layer needs a path-management. Either MPTCP
> has to provide a standard API to access the path-management from the
> outside world.
>

There's no big reasons for a shim layer approach.
I just thought we might be able to do most of the things without changing
MPTCP, although I miss something.
If doing it in kernel has some advantages, it may be a different story.
I am not sure yet if the shim layer approach will require a path
management.
It looks to me just creating a subflow of the MPTCP session through an API.

Thanks,
--
Yoshi