netdev - Re: [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer"

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: <534E6FC4.8020706@nsn.com>
Date:	Wed, 16 Apr 2014 13:55:48 +0200
From:	Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@....com>
To:	Alexander Sverdlin <alexander.sverdlin@....com>,
	ext Dongsheng Song <dongsheng.song@...il.com>,
	ext Vlad Yasevich <vyasevich@...il.com>,
	Daniel Borkmann <dborkman@...hat.com>
CC:	davem@...emloft.net, netdev@...r.kernel.org,
	"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>
Subject: Re: [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to
 reflect real state of the receiver's buffer"

Hello,

On 16.04.2014 11:02, Alexander Sverdlin wrote:
> 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...

Its also worth to note that sctp specifies rfc2581 for congestion 
control. TCP obsoleted that one in favor of 5681.

@Vlad, after Alexanders comment, it seems to be that you were referring 
to performance penalty. At first, I understood you refer to some penalty 
in rwnd calculation against buffer/rwnd value/something else. Thats why 
I asked that.

What also might be is that we are hitting SWS. I remember us observing 
some scenarios in which SWS is broken, new rwnd might have triggered it 
fully.

In any case, after some thought in the meantime, I'm pretty much sure 
that we need to improve congestion control and that new rwnd calculation 
is correct approach.

>> http://www.spinics.net/lists/linux-sctp/msg03308.html
>>
>>
>> On Wed, Apr 16, 2014 at 2:57 PM, Matija Glavinic Pecotic
>> <matija.glavinic-pecotic.ext@....com> 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@...r.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>
--
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