Re: [tipc-discussion] Link level packet loss

[Ying X. <yin...@wi...>]

Erik Hugne wrote:
>> What i have yet to discover is _why_ this occurs, packets should always
>> be put on the deferred queue if they are not 'next_in_no', and the
>> deferred packets should only be replayed back on the receive loop when
>> we have all previous packets..
>>
>
> When the link supervision timer kicks in, we will flush ongoing 
> reassemblies if they have not successfully received a fragment within 
> [link tol]*4 seconds.
>
> This will then lead to the problem explained in the previous mail, 
> since we obviously have dropped the buffer.
>
> I think this is a fault from which we cannot recover nicely, since the 
> dropped buffer is built up of packets already acked on the link.
>
> So i'm suggesting that we reset the link immediately and print a 
> helpful error message when this occurs.
> The problem will be mitigated by increasing link window size and/or 
> tolerance levels.
>

Reseting link is not a good idea. If we are not in the worst case, we 
definitely don't do that.
I also cannot understand why link_check_defragm_bufs() is used. We 
should not flush acked packets in general except that its link will be 
reset.

> Jon: do you the remember the reasoning for flushing stale reassembly 
> buffers every fourth link timeout, if we have not received a fragment 
> for this ongoing reassembly yet?
> http://lxr.free-electrons.com/source/net/tipc/link.c#L2584
>
>
> //E
>
>
>