Re: [multipathtcp] Regarding the release of sending buffer

[Christoph Paasch <[e-mail]>]

Hello,

On 09/08/17 - 11:34:58, Vincent Stone wrote:
> 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?

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