From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Sverdlin Date: Wed, 16 Apr 2014 09:02:54 +0000 Subject: Re: [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' Message-Id: <534E473E.20303@nsn.com> List-Id: References: <1397504717-19566-1-git-send-email-dborkman@redhat.com> <534C3DC2.9070604@gmail.com> <534E29D4.60100@nsn.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ext Dongsheng Song , Matija Glavinic Pecotic Cc: ext Vlad Yasevich , Daniel Borkmann , davem@davemloft.net, netdev@vger.kernel.org, "linux-sctp@vger.kernel.org" Hi Dongsheng! On 16/04/14 10:39, ext Dongsheng Song wrote: >>>From my testing, netperf throughput from 600 Mbit/s drop to 6 Mbit/s, > the penalty is 99 %. The question was, do you see this as a problem of the new rwnd algorithm? If yes, how exactly? The algorithm actually has no preference to any amount of data. It was fine-tuned before to serve as congestion control algorithm, but this should be located elsewhere. Perhaps, indeed, a re-use of congestion control modules from TCP would be possible... > http://www.spinics.net/lists/linux-sctp/msg03308.html > > > On Wed, Apr 16, 2014 at 2:57 PM, Matija Glavinic Pecotic > wrote: >> >> Hello Vlad, >> >> On 04/14/2014 09:57 PM, ext Vlad Yasevich wrote: >>> The base approach is sound. The idea is to calculate rwnd based >>> on receiver buffer available. The algorithm chosen however, is >>> gives a much higher preference to small data and penalizes large >>> data transfers. We need to figure our something else here.. >> >> I don't follow you here. Could you please explain what do you see as penalty? >> >> Thanks, >> >> Matija >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- Best regards, Alexander Sverdlin.