On 08/24/2015 02:31 PM, Marcelo Ricardo Leitner wrote:
> On Mon, Aug 24, 2015 at 02:13:38PM -0400, Vlad Yasevich wrote:
>> On 08/23/2015 07:30 AM, Xin Long wrote:
>>> when A sends a data to B, then A close() and enter into SHUTDOWN_PENDING
>>> state,
>>> if B neither claim his rwnd is 0 nor send SACK for this data, A will keep
>>> retransmitting this data util t5 timeout, Max.Retrans times can't work
>>> anymore,
>>> which is bad.
>>>
>>> if B's rwnd is not 0, it should send abord after Max.Retrans times, only
>>> when
>>> B's rwnd == 0 and A's retransmitting beyonds Max.Retrans times, A will start
>>> t5 timer, which is also commit f8d960524 means, but it lacks the condition
>>> peer.rwnd == 0.
>>>
>>> Fixes: f8d960524 ("sctp: Enforce retransmission limit during shutdown")
>>> Signed-off-by: Xin Long <lucien....@gmail.com>
>>> ---
>>> net/sctp/sm_statefuns.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
>>> index 3ee27b7..deb9eab 100644
>>> --- a/net/sctp/sm_statefuns.c
>>> +++ b/net/sctp/sm_statefuns.c
>>> @@ -5412,7 +5412,8 @@ sctp_disposition_t sctp_sf_do_6_3_3_rtx(struct net
>>> *net,
>>> SCTP_INC_STATS(net, SCTP_MIB_T3_RTX_EXPIREDS);
>>>
>>> if (asoc->overall_error_count >= asoc->max_retrans) {
>>> - if (asoc->state == SCTP_STATE_SHUTDOWN_PENDING) {
>>> + if (!q->asoc->peer.rwnd &&
>>> + asoc->state == SCTP_STATE_SHUTDOWN_PENDING) {
>>> /*
>>> * We are here likely because the receiver had its rwnd
>>> * closed for a while and we have not been able to
>>>
>>
>> This may not work as expected. peer.rwnd is the calculated peer window, but
>> it
>> also gets updated when we receive sacks. So there is no way to tell that
>> the current windows is 0 because peer told us, or because we sent data to
>> make 0
>> and the peer hasn't responded.
>
> I'm not sure I follow you, Vlad. I don't think we care on why we have
> zero-window in there, just that if we are at it on that stage. Either
> one, if it's zero window, we will go through T5 and give it more time to
> recover, but if it's not zero window, I don't see a reason to enable T5..
No, these are 2 distinct instances. In one instance, the peer is reachable and
is able to communication 0 rwnd state to us. Thus we are being nice and
granting
the peer more time to exit the 0 window state.
In the other state, the peer is unreachable and we just happen to hit the
0-window
condition based on some estimations of the peer window. In this case, we should
be subject to the Max.RTX and terminate the association sooner.
-vlad
>
> Marcelo
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
