> > 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 > okay, I got you,
we can see that local update their peer.rwnd in sctp_packet_append_data() and sctp_retransmit_mark(), it do that according to a_rwnd and outstanding, so the root reason is that it's hard to know that peer really closed it's window, maybe just so many outstanding lead to that. what we can do is to trust peer.rwnd is the real window in peer. from another angle, even though it's not real, at least we can reduce the * the other state* you mentioned by doing this. especially, if there is only one small packet keep retransmitting in SHUTDOWN_PENDING state, the peer.rwnd is more believable to be the real peer window. I saw bsd code didnot care about Max.Retrans in SHUTDOWN_PENDING, instead it just start T5 timer. but now that we choose Max.Retrans + T5, it's better to process more unreachable by using Max.Retrans. I also hope we can do it better there as Marcelo said, but by now I cannot see it. :) -- 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
