Subject: [multipathtcp] Regarding the release of sending buffer

From: Vincent Stone <[email-masked]>
Date: Wed, 9 Aug 2017 11:34:58 +0800

Hi all,
I have a question about when the packet can be freed from the send buffer.
In section 3.3.2 of RFC 6824:
   An MPTCP sender MUST NOT free data from the send buffer until it has
   been acknowledged by both a Data ACK received on any subflow and at
   the subflow level by all subflows on which the data was sent.  The
   former condition ensures liveness of the connection and the latter
   condition ensures liveness and self-consistence of a subflow when
   data needs to be retransmitted.  Note, however, that if some data
   needs to be retransmitted multiple times over a subflow, there is a
   risk of blocking the sending window.  In this case, the MPTCP sender
   can decide to terminate the subflow that is behaving badly by sending
   a RST.

If data is acknowledged by Data ACK, that means it has been already received by receiver. There is no need to wait for the subflow level ACK. Even if the subflow decides to retransmit the data, we can just retransmit a fake/dumb packet, because that packet will be ignored by the receiver (out of receive window) anyway. Or we can advance the send window of the subflow upon the receiving of data ack to prevent the subflow level retransmission. So my question is: can the data be freed from the send buffer once it has been acknowledged by the Data ACK?

Best regards,

Vincent

---

From: Christoph Paasch <[email-masked]>
Date: Tue, 08 Aug 2017 20:48:15 -0700

Hello,

> If data is acknowledged by Data ACK, that means it has been already received by receiver. There is no need to wait for the subflow level ACK. Even if the subflow decides to retransmit the data, we…

the problem is that when you do this, the subflow on which you are
preventing the retransmission by advancing the send-window or where you are
sending a fake-packet, won't look like "regular" TCP anymore.

Middleboxes and firewalls will start blocking this traffic and the receiver
must also be able to gracefully handle this.

That's the reason why MPTCP tries hard to make every subflow look like it is
regular TCP, besides a few TCP-options.

Cheers,
Christoph

---

From: Vincent Stone <[email-masked]>
Date: Thu, 10 Aug 2017 16:42:18 +0800

Thanks for your response. Let us say we take the preventing retransmission approach. Can the middlebox/firewall notice that? 
There is only 1 scenario in which the middlebox will deem the data should be retransmitted( keep in mind that the data has already been delivered correctly to the receiver because it has already been acknowleged by Data ACK): 
all following ACKs after the data has been lost/dropped(Just dropped single ACK for the data is not enough because of accumulative ACK). In that case the flow should be terminated anyway. 
In fact, there is no way in which a middlebox can distinguish between sender don't retransmit the packet and the retransmitted packet has been lost. So I think it is safe to prevent the retransmission, thus we can free the data upon receiving Data ACK safely.

Best regards,
Vincent

> On Aug 9, 2017, at 11:48, Christoph Paasch <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 't look like "regular" TCP anymore.
>

---

From: Vincent Stone <[email-masked]>
Date: Thu, 10 Aug 2017 16:47:41 +0800

Best regards,
Vincent

---

From: Christoph Paasch <[email-masked]>
Date: Thu, 10 Aug 2017 09:21:26 -0700

Hello,

> Thanks for your response. Let us say we take the preventing retransmission approach. Can the middlebox/firewall notice that? 

yes, because the firewall will see a hole in the sequence-number space.

> In fact, there is no way in which a middlebox can distinguish between sender don't retransmit the packet and the retransmitted packet has been lost. So I think it is safe to prevent the retransmiss…

What the middlebox will see with regular TCP is that first there is a hole in the
sequence-number space and then the sender will retransmit it, thus filling
the hole.

If we don't retransmit, the hole will never be filled up and the middlebox
might stall the flow.

Christoph

---

From: Vincent Stone <[email-masked]>
Date: Sat, 12 Aug 2017 16:50:14 +0800

> If we don't retransmit, the hole will never be filled up and the middlebox
The hole in sequence-number space can be filled either by retransmitted packet or subsequent accumulative ACK. Even if we don't retransmit the packet, the hole will be filled up by accumulative ACK sooner or later. If not, that means all following ACKs have been lost. In that case the flow should be terminated anyway. 
And middlebox can not distinguish between no-retransmition of the packet and the lost retransmitted packet. 

Best regards,
Vincent.

> On Aug 11, 2017, at 00:21, Christoph Paasch <[email-masked]> wrote:
> 
> Hello,
>