Re: [multipathtcp] Regarding the release of sending buffer

[Vincent Stone <[e-mail]>]

> If we don't retransmit, the hole will never be filled up and the middlebox
> might stall the flow.
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 <[e-mail]> wrote:
> 
> 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.
>>