Subject: [multipathtcp] Modified MP_CAPABLE handshake

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Wed, 7 Sep 2011 10:02:58 -0500

Hi all,

I'd need clarification on the modified MP_CAPABLE handshake introduced in draft-ietf-mptcp-multiaddressed-04.txt:

Since key A is sent for the first time in the third message of the SYN/ACK handshake, it needs to be acknowledged with an additional ACK (fourth message). In case the connection-initiating host is the one who sends the first data (typical client-server session), does it have to wait until this additional ACK has been received?

The present WG draft seems to indicate that the host has to hold back on data transmission since the connection is only in PRE_ESTABLISHED state until this fourth message has been received.

Are we aware that this would prolong the connection setup procedure from 1RTT to 2RTT for all client-server sessions?

Thanks,

Georg

---

From: Christoph Paasch <[email-masked]>
Date: Wed, 7 Sep 2011 18:26:10 +0300

Hi,

On Wednesday 07 September 2011 wrote Hampel, K Georg (K Georg):
> Since key A is sent for the first time in the third message of the SYN/ACK
> handshake, it needs to be acknowledged with an additional ACK (fourth
> message). In case the connection-initiating host is the one who sends the
> first data (typical client-server session), does it have to wait until
> this additional ACK has been received?

Yes, that's the intention.
I must admit, that we haven't implemented it yet either.

> The present WG draft seems to indicate that the host has to hold back on
> data transmission since the connection is only in PRE_ESTABLISHED state
> until this fourth message has been received.
> 
> Are we aware that this would prolong the connection setup procedure from
> 1RTT to 2RTT for all client-server sessions?

Mark Handley proposed another solution on this list (http://www.ietf.org/mail-
archive/web/multipathtcp/current/msg01529.html)
I personally prefer this solution to the one in the draft, because adding a 
retransmission-timer for a non-data packet (the third ack) is not that easy 
and clean from an implementation point-of-view.

Another solution might be to just not handle the loss of the third ack 
(assuming that this is a relatively rare event). If the third ack gets lost, 
and the client is the first one to send data, the server will reply to this 
data  without an mptcp-option (because from his point-of-view we are in non-
mptcp-mode) and thus the client will fallback to regular TCP as specified in 
section 3.5 of the proto-draft.
This would be much cleaner for an implementation and avoid the additional RTT 
as in the proto-draft, or the reduced option-space (even timestamps don't fit 
anymore in the first data-packet) in Mark's solution.

Cheers,
Christoph

--
Christoph Paasch
PhD Student

IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain

www.rollerbulls.be
--

---

From: Alan Ford <[email-masked]>
Date: Wed, 7 Sep 2011 16:32:07 +0100

Hi,

2011/9/7 Christoph Paasch <[email-masked]>

> I must admit, that we haven't implemented it yet either.

Indeed. The intention was to save option space, however it looks as if it
may be causing more problems than it is worth.

> and clean from an implementation point-of-view.

Mark's solution is unfortunately not feasible since we do not have enough
option space to fit both a DSS and a MP_CAPABLE in the same packet.

> anymore in the first data-packet) in Mark's solution.

Indeed, that would work.

However, I think it may well be safest, and easiest, to go back to the -03
version where the keys are in both the SYN and SYN/ACK, and only echoed in
the ACK for reliability.

If a server wants to act statelessly and thus rely on the third ACK for its
keys, then fallback would be the only sensible option in the event of the
third packet loss.

Regards,
Alan

---

From: Alan Ford <[email-masked]>
Date: Wed, 7 Sep 2011 16:40:19 +0100

On 7 September 2011 16:32, Alan Ford <[email-masked]> wrote:

>> archive/web/multipathtcp/current/msg01529.html<http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01529.html>
>> )

Actually, there might be another solution: As long as a DSS covering that
first packet is sent on a following packet (i.e. if the sender had more than
one packet of data to send, or even if not a DSS could be sent on an empty
ACK), then data could be included in the third ACK that contains the
MP_CAPABLE.

This isn't very neat, however, and it may be simpler to revert to keys in
the SYN. What do people think?

Regards,
Alan

---

From: Christoph Paasch <[email-masked]>
Date: Wed, 7 Sep 2011 18:40:22 +0300

> option space to fit both a DSS and a MP_CAPABLE in the same packet.

The DSS can also be reduced to 32-bit sequence numbers. Then, this would fit, 
as the MP_CAPABLE in the third ack is 20 bytes long and the DSS fits in the 
remaining 20 bytes. But there is no more space left for timestamps, which are 
not necessary on each packet.

> keys, then fallback would be the only sensible option in the event of the

Yes, I think that would be best. Put the key back in the SYN and ignore the 
loss of the ACK.

Christoph

--
Christoph Paasch
PhD Student

www.rollerbulls.be
--

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Wed, 7 Sep 2011 13:19:28 -0500

All,

I think that delaying client requests from 1RTT to 2RTT is pretty unacceptable. In the tcpm WG, Google tries to push for data on the SYN packet to reduce the client request time from 1RTT to 0 RTT. In this light, MPTCP wouldn't quite meet the trend.

I would tend to ask the question how much security we gain by pushing the key A transfer from the first SYN to the second ACK.

I further see a philosophical problem in the 3rd ACK solution: MPTCP-level messages (e.g. DSN, data FIN) should be acknowledged via MPTCP-level messages (e.g. data ACKs) and not via subflow level ACKs. The -03 version of the draft was consistent in that respect.

My vote: Go back to -03.

Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christoph Paasch
Sent: Wednesday, September 07, 2011 11:40 AM
To: Alan Ford
Cc: [email-masked]
Subject: Re: [multipathtcp] Modified MP_CAPABLE handshake

Christoph

--
Christoph Paasch
PhD Student

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

---

From: Costin Raiciu <[email-masked]>
Date: Thu, 8 Sep 2011 13:37:26 +0300

Hi,

I also think moving back to -03 is the way to go for the initial handshake.
Costin