Subject: [multipathtcp] RFC6824bis: knowing if a Data ACK should have been received?

From: Bob Briscoe <[email-masked]>
Date: Fri, 28 Nov 2014 12:45:52 +0000

Alan, Costin, Mark, Olivier,

I am trying to determine how an MPTCP endpoint will know if TCP 
options start to be stripped part-way through a subflow (e.g. due to 
a mobile IP handover that MPTCP is not aware of, which brings a new 
middlebox into the path).

I guess the best way to tell would be absence of DATA ACKs, however 
the RFC6842bis draft does not encourage an implementation to send 
DATA ACKs unless the cumulative Data ACK has advanced (see the para 
quoted below).

* Question: If all the cumulative ACKs of all the subflows have 
advanced, can an implementation be sure that the Data ACK should have 
advanced and therefore be certain that it should have received a Data ACK?

* Edit request: While reading RFC6842bis I noticed a MUST seems to be 
missing...

<https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-02#section-3.3.2>
3.3.2. Data Acknowledgments
CURRENT:
    The Data ACK MAY be included in all segments; however, optimizations
    SHOULD be considered in more advanced implementations, where the Data
    ACK is present in segments only when the Data ACK value advances, and
    this behavior MUST be treated as valid.  This behavior ensures the
    sender buffer is freed, while reducing overhead when the data
    transfer is unidirectional.
SUGGESTED:
    The Data ACK MUST be included when the Data ACK value advances. It MAY
    be included in all segments; however, optimizations SHOULD be considered
    in more advanced implementations, where the Data ACK is present only when
    it advances, and this behavior MUST be treated as valid.  This 
behavior ensures the
    sender buffer is freed, while reducing overhead when the data
    transfer is unidirectional.

Cheers

Bob

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 30 Nov 2014 12:50:13 -0800

Hi Bob,

What if there is no enough option space to put MPTCP option?
--
Yoshi

On Fri, Nov 28, 2014 at 4:45 AM, Bob Briscoe <[email-masked]> wrote:

> I am trying to determine how an MPTCP endpoint will know if TCP options
> start to be stripped part-way through a subflow (e.g. due to a mobile IP
> handover that MPTCP is not aware of, which brings a new middlebox into the
> path).
>
> I guess the best way to tell would be absence of DATA ACKs, however the
> RFC6842bis draft does not encourage an implementation to send DATA ACKs
> unless the cumulative Data ACK has advanced (see the para quoted below).
>
> * Question: If all the cumulative ACKs of all the subflows have advanced,
> can an implementation be sure that the Data ACK should have advanced and
> therefore be certain that it should have received a Data ACK?
>
>    it advances, and this behavior MUST be treated as valid.  This behavior
> ensures the
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

---

From: Olivier Bonaventure <[email-masked]>
Date: Sun, 30 Nov 2014 22:08:20 +0100

Bob,
> handover that MPTCP is not aware of, which brings a new middlebox into
> the path).

This could indeed be a problem. For simplicity, let us assume that the 
new middlebox removes all MPTCP options from all segments (it seems safe 
to assume that this middlebox is not MPTCP aware and thus should treat 
all MPTCP options in the same way). Then, we have to considered two 
different cases :

1- The MPTCP connection uses two subflows, one affected by the middlebox 
and the other not

2- The MPTCP connection uses a single subflow, affected by the middlebox

In case 1, the Data_ack will not arrive anymore on the affected subflow 
and after some time the data (at the MPTCP level) will be retransmitted 
on the other subflow. Data flow will continue on one subflow after a 
slowdown. This is what we already see with some FTP ALG as described in 
http://inl.info.ucl.ac.be/publications/are-tcp-extensions-middlebox-proof

In case 2, the problem is different. The data cannot be retransmitted 
over another subflow. Maybe an implementation could detect this problem 
after N attemtps to retransmit the data. Since MPTCP options are 
stripped, mp_fail and infinite mappings cannot be exchanged to solve the 
problem. Maybe one option could be to close the subflow and restablish 
another one.

>     transfer is unidirectional.

I'm not in favor of forcing a data_ack each time the data ack advances 
because this would prevent the utilisation of delayed acks that are 
useful to reduce the cpu consumption. If we go in this direction, we 
should at least agree to not send more data_ack than subflow level tcp acks

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be