Subject: [multipathtcp] comments on draft-paasch-mptcp-syncookies

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 22 Sep 2015 01:13:48 -0700

Hello,
I have several comments on draft-paasch-mptcp-syncookies. Please point out
if I miss some points.

1:  I personally would like to ask authors to clarify the cases where
clients don't send the first data packet or clients cannot fit the option
in the first data packet in this draft so that we can make sure not to miss
corner cases.

2: This scheme presumes that the server behaves statelessly in mptcp level.
But, I think the server doesn't have to be stateless in tcp level. Or, this
method should be applied to stateless tcp server only? I think the draft
needs to clarify this point.

3: In Section 3.1.3
    "Coalescing segments:
      the second half of the payload is not covered by a mapping. Thus, the
server will do a seamless fallback to regular TCP as defined by RFC6824"

     Is this true? RFC6824 says:
     "Therefore, even if a mapping does not exist from the subflow space to
the data-level space, the data SHOULD still be ACKed at the subflow. This
data cannot, however, be acknowledged at the data level"

     Also, when MP_CAPABLE_ACK option is missing, if server is not
stateless in tcp level, I am wondering if we can ask the sender to resend
the first data by sending an ack for seq 1 (with SACK block if possible). I
know this is suboptimal, but maybe better than resetting.

Thanks,
--
Yoshi

Thanks,
--
Yoshi

---

From: Christoph Paasch <[email-masked]>
Date: Tue, 22 Sep 2015 23:17:17 -0700

Hello Yoshifumi,

> I have several comments on draft-paasch-mptcp-syncookies. Please point out

thanks for your comments. Please see my replies below.

> in the first data packet in this draft so that we can make sure not to miss

When the server is the first to send data, he either disables SYN-cookies
(to be sure to actually receive the third ACK, because he will be
retransmitting the SYN/ACK), or if he doesn't disables SYN-cookies then he
is vulnerable to never establish the state (which is the same issue in
regular TCP).

I will clarify this in the draft more in detail.

> needs to clarify this point.

That's actually an interesting point. One could actually setup a server that
behaves statefully at the TCP-level and stateless at the MPTCP-level.

We can discuss this as well in the draft.

> data cannot, however, be acknowledged at the data level"

Indeed, but during the first window worth of data on the initial subflow,
every segment must contain a DSS-option to "proof" that the path is fully
MPTCP capable and DSS-options get through also after the SYN.

This is explained in Section 3.6 of the RFC6824.

We will cite this section more explicitly in the draft.

> know this is suboptimal, but maybe better than resetting.

I'm not sure I understand what you mean. Can you elaborate?

Thanks,
Christoph

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 24 Sep 2015 19:06:24 -0700

Hi Christoph,

Thanks. My concern here is it's a bit difficult for a TCP stack to tell if
it's going to send data first or not.
So, the applications must tell their intentions to TCP before it starts a
connection, which might be a bit tricky to do.

> We can discuss this as well in the draft.

I think that some implementations don't support or don't activate
syn-cookie by default.
If this negotiation method will be the standard way for mptcp, I think we
need to think about this kind of situations.

> We will cite this section more explicitly in the draft.

I see. But, the difference between DSS and MP_CAPABLE_ACK is not big from
my point of view.
So, I'm thinking that it might not violate the split of the RFC6824 even if
we relax this rule a bit.

> I'm not sure I understand what you mean. Can you elaborate?

Sorry. although I might be misunderstanding something here, please let me
explain. I was thinking about TCP level stateful server.
Even if middlebox coalesces the first and the second data segment and
removes MP_CAPABLE_ACK, I believe this is not a problem at TCP level.
So, I guess it might be possible for the server to ack for seq 1 (TCP
level) to urge the retransmission of the first data packet.
This might be a pretty adhoc logic, however, I didn't want to see what is
fine for 6824 is not fine for this proposal.

Thanks,
--
Yoshi

---

From: Christoph Paasch <[email-masked]>
Date: Fri, 25 Sep 2015 21:15:41 -0700

Hello,

> connection, which might be a bit tricky to do.

from the client's point-of-view he does not need to change the behavior when
it is not the first one to send data.

And on the server side (if the sys-admin enabled SYN-cookies), he is indeed
vulnerable to this if the server initiates the transfer. But that's the case
for regular TCP as well.
As most app-protocols start with the client initiating the transfer, I think
that's fine.

> need to think about this kind of situations.

Oh, I see now. I think I misunderstood your question originally.

I think that the handshake we are suggesting does not imply that the server
has to operate in a stateless way at the TCP-level (nor at the MPTCP-level).
The handshake will still work even if both layers (TCP and MPTCP) are stateful.

> fine for 6824 is not fine for this proposal.

Let me try to draw of packet-flow of what you mean (please correct me if I'm
wrong).

You suggest the following:

Client                           Server

   (the coalesced segment whose MP_CAPABLE_ACK has been removed)
   TCP-seq: 1, Len: 100
   DSS-option: Dseq X, subseq 50, len 50
   -------------------------------->

   TCP-ack: 1, SACK: 50-100
   <--------------------------------

   TCP-seq: 1, Len 50
   MP_CAPABLE_ACK
   -------------------------------->

This would be a change in behavior compared to RFC6824 as well, because as
of today the server would fallback to regular TCP in this case (fallback
without sending a RST, just seamlessly stop using MPTCP-options).
He does this because he does not have a mapping for seq 1 to 50.

I think we could do this above behavior, but it has downsides as well, as it
increases latency (we need one more RTT in case this happens).

Christoph

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 28 Sep 2015 22:25:31 -0700

Hi Christoph,

Thanks for the response and sorry for my slow response.

On Fri, Sep 25, 2015 at 9:15 PM, Christoph Paasch <[email-masked]> wrote:

> > > > in the first data packet in this draft so that we can make sure not
> to
> > > miss
> > > > corner cases.
> > >

It seems you're saying that sending MPCAPABLE_ACK is not mandatory when the
server initiates data transfer.
I hope you can elaborate this part in the next version.

> > > > But, I think the server doesn't have to be stateless in tcp level.
> Or,
> > > this

OK. I personally think this is an important point. I hope you'll add more
texts to clarify it.

> > > 3: In Section 3.1.3
> > > >     "Coalescing segments:
> > > >       the second half of the payload is not covered by a mapping.
> Thus,
> > > the
> > > >      "Therefore, even if a mapping does not exist from the subflow
> space
> > > to

Yes. This is what I meant. Thanks.
As I said earlier, this would be suboptimal. But, I thought it might be
better than resetting a connection.
I am hoping someone bring a more sophisticated solution here or some
evidences to neglect this case.

Thanks,
--
Yoshi