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]

Date:	Wed, 16 Apr 2014 09:32:23 -0400
From:	Vlad Yasevich <vyasevich@...il.com>
To:	Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@....com>,
	Alexander Sverdlin <alexander.sverdlin@....com>,
	ext Dongsheng Song <dongsheng.song@...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"

On 04/16/2014 07:55 AM, Matija Glavinic Pecotic wrote:
> 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.

I am not sure where congestion control is broken.  It might be nice to
add a periodic SCTP_STATUS call to netperf/iperf to see what the state
of the congestion window and peer receive window is.

Alternatively, an quick stap script to examine these values could also
be useful.

-vlad

> 
>>> 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