On 08/27/2015 09:19 AM, lucien xin wrote: >> >> 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. :) >
So one potential way is to have peer.rwnd and peer.a_rwnd, where peer.a_rwnd is the window advertised by peer and peer.rwnd and our estimation based on peer.a_rwnd. This way we will always know where we stand. Although I am not sure yet if we want to grow the peer structure any more. Another way is to have an estimate or 0-window probe bit/flags one the send side and set it when we do 0-window probe. This way we'd know that when 0-window probe bit is set, peer returned 0 window. Just some thoughts. -vlad -- 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
