Re: [multipathtcp] Regarding the release of sending buffer

[Christoph Paasch <[e-mail]>]

Hello,

On 10/08/17 - 16:47:41, Vincent Stone wrote:
> 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.

> 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.

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

> 
> Best regards,
> Vincent
> 
> > On Aug 9, 2017, at 11:48, Christoph Paasch <[e-mail] <mailto:[e-mail]>> wrote:
> > 
> > '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.
>