netdev - Re: [PATCH net v2] sctp: start t5 timer only when peer.rwnd is 0 and local.state is SHUTDOWN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55DF10E6.3010007@redhat.com>
Date:	Thu, 27 Aug 2015 09:30:14 -0400
From:	Vlad Yasevich <vyasevic@...hat.com>
To:	lucien xin <lucien.xin@...il.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

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html