Vlad Yasevich wrote:
> 
> Georgios Cheimonidis wrote:
>> Hi Vlad!
>>
>> I have repeated the test with the net-next kernel tree. It seems that
>> the problem persists. Below, I summarize what I observed from the
>> capture at the server side (the client's capture agrees with these
>> observations). Although the timing differs somewhat from the previous
>> test, the basic observation is still the same. After the server switches
>> primary address and removes the previous primary from the association,
>> some unacknowledged DATA packets that were transmitted to the previous
>> primary (after it became unreachable) are never retransmitted to the new
>> one.
>>
> 
> Thanks for testing.  I am looking to see what can be happening.
> 
> -vlad
> 

Hi George.

I figured out why there were no retransmits.  Because you changed primary
path, you kicked in the SFR-CACC algorithm, and our implementation didn't
deal properly with the fact that some chunks may have moved from the old
primary to the new one without going though a retransmit.

There are really 2 ways to deal with this:
	1).  If we are deleting a transport that had outstanding data,
	automatically retransmit the data on the new transport.

	or.

	2) Under the same condition as above, move the data to the new primary
	destination and let fast-recovery take care of the issue.

Linux implemented (2) from above, and thus this bug surfaced.

Try the attached patch, and let me know if it fixes it for you.

-vlad