Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-06.txt

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 1 Mar 2012 11:50:37 -0800

Hello,

2012/2/24 Christoph Paasch <[email-masked]>:
> Hello Alan, all,
>
>
> On 02/23/2012 01:30 PM, Alan Ford wrote:
>>>>> ============
>>>>> * Retransmission of the third ACK, to ensure reliable delivery of the
>>>>> keys in MP_CAPABLE (page 14):
>>>>>
>>>>> The retransmission of the third ack was introduced to allow lost third
>>>>> acks, if the server is operating stateless. However, this introduced an
>>>>> additional RTT before the client is able to send data and thus, we now
>>>>> allow the client to send data before he receives the acknowledgment of
>>>>> his third ack (in PRE_ESTABLISHED state).
>>>>>
>>>>> I now realize, that the retransmission does not buy us a lot:
>>>>>
>>>>> E.g., if the third ACK gets lost, but the client already starts to send
>>>>> data and this data reaches the stateless server.
>>>>> The server then can only send a subflow-ack without DATA_ACK and thus
>>>>> behave as in regular TCP.
>>>>> The client then should interpret this subflow-ack not as the one
>>>>> acknowledging the third ack (the one with the MP_CAPABLE), but rather
>>>>> fallback to regular TCP. Because, otherwise the client and server are no
>>>>> more in-sync.
>>>>>
>>>>> Thus, the retransmission only buys us something if the server is
>>>>> behaving stateless, the third ack got lost and the server is the one
>>>>> trying to send data first. This same problem is already present for
>>>>> stateless servers operating with regular TCP.
>>>>>
>>>>> I'm not sure that this current behavior of sending data in
>>>>> PRE_ESTABLISHED state is safe (e.g., how to behave if the third ack and
>>>>> the first data-packet got lost, but the second data-packet reaches the
>>>>> server? - the server sends a duplicate subflow-ack without
>>>>> MPTCP-options. How will the client interpret this subflow-ack?).
>>>>>
>>>>> I think we should remove the retransmission of the third ack, as it does
>>>>> not buy us a lot, and keep with the simpler and more straight-forward
>>>>> mechanism of not caring about lost third-acks (as in draft v02).
>>>>
>>>> It is true that if we removed the retransmission of the third ACK was added
>>>> for this corner case. But this is a well-known flaw in stateless operation
>>>> and SYN cookies, and our motivation for doing this was to make MPTCP's
>>>> handling of this better than regular TCP today.
>>>>
>>>> I agree, however, that it would make things simpler, and faster in the
>>>> majority of circumstances, to revert to a simple three-way handshake.
>>>>
>>>> Does anybody else have any thoughts?
>>>
>>> I realize one more thing, "conflicting" with the fact that no new
>>> subflows may be established while in PRE_ESTABLISHED, as described in
>>> section 3.1. Because, in section 3.6, we say that no new subflows are
>>> allowed as long as we did not receive a DATA_ACK. And, we will always
>>> enter PRE_ESTABLISHED before (or at the same time) receiving the first
>>> DATA_ACK.
>>>
>>> Thus, section 3.1 does not need to specify this, or may
>>> forward-reference to section 3.6.
>>
>> Thanks, we'll change that - that simplifies things.
>
> Good.
>
> So, retransmission of the third ack will stay?
>
> I just wanted to favor simplicity to make the protocol less complex. The
> more complex MPTCP is, the harder it will be to get it deployed.
>
> If the argument, that we want to fix with MPTCP the "broken" TCP
> SYN-cookies with regular TCP, is strong enough to justify the additional
> complexity, I'm fine with it.

I'm wondering if we need to specify this behavior in the protocol spec.
it might be an implementor's choice. An implementor might prefer
simple way. if it doesn't implement retransmission of the third ack,
it should fallback to normal TCP when the third ack is lost. But, this
is only sender's behavior and doesn't break the communication.

--
Yoshifumi

---

From: Christoph Paasch <[email-masked]>
Date: Sun, 04 Mar 2012 20:44:42 +0100

> is only sender's behavior and doesn't break the communication.

Yes, I think that's the best option.

Christoph

-- 
Christoph Paasch
PhD Student

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