[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADvbK_cZhT3crJhP-5HQVpm=iAYTCDkiBNnDNCibvfOvEyzN7w@mail.gmail.com>
Date: Thu, 27 Aug 2015 21:19:32 +0800
From: lucien xin <lucien.xin@...il.com>
To: Vlad Yasevich <vyasevic@...hat.com>
Cc: Marcelo Ricardo Leitner <mleitner@...hat.com>,
network dev <netdev@...r.kernel.org>,
Thomas Graf <tgraf@...radead.org>, davem <davem@...emloft.net>
Subject: Re: [PATCH net v2] sctp: start t5 timer only when peer.rwnd is 0 and
local.state is SHUTDOWN_PENDING
>
> 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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists