From: Alexander Sverdlin <alexander.sverdlin@nsn.com>
To: ext Dongsheng Song <dongsheng.song@gmail.com>,
Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nsn.com>
Cc: ext Vlad Yasevich <vyasevich@gmail.com>,
Daniel Borkmann <dborkman@redhat.com>,
davem@davemloft.net, netdev@vger.kernel.org,
"linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>
Subject: Re: [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver'
Date: Wed, 16 Apr 2014 09:02:54 +0000 [thread overview]
Message-ID: <534E473E.20303@nsn.com> (raw)
In-Reply-To: <CAE8XmWqgcNAHcKnzdUamQ0T+NP27GKSiRv37JEHSQW-=1Fu=2w@mail.gmail.com>
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
> <matija.glavinic-pecotic.ext@nsn.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@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
Best regards,
Alexander Sverdlin.
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Sverdlin <alexander.sverdlin@nsn.com>
To: ext Dongsheng Song <dongsheng.song@gmail.com>,
Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nsn.com>
Cc: ext Vlad Yasevich <vyasevich@gmail.com>,
Daniel Borkmann <dborkman@redhat.com>,
davem@davemloft.net, netdev@vger.kernel.org,
"linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>
Subject: Re: [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer"
Date: Wed, 16 Apr 2014 11:02:54 +0200 [thread overview]
Message-ID: <534E473E.20303@nsn.com> (raw)
In-Reply-To: <CAE8XmWqgcNAHcKnzdUamQ0T+NP27GKSiRv37JEHSQW-=1Fu=2w@mail.gmail.com>
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
> <matija.glavinic-pecotic.ext@nsn.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@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
Best regards,
Alexander Sverdlin.
next prev parent reply other threads:[~2014-04-16 9:02 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-14 19:45 [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's bu Daniel Borkmann
2014-04-14 19:45 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Daniel Borkmann
2014-04-14 19:57 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' Vlad Yasevich
2014-04-14 19:57 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Vlad Yasevich
2014-04-16 6:57 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' Matija Glavinic Pecotic
2014-04-16 6:57 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Matija Glavinic Pecotic
2014-04-16 8:39 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' Dongsheng Song
2014-04-16 8:39 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Dongsheng Song
2014-04-16 9:02 ` Alexander Sverdlin [this message]
2014-04-16 9:02 ` Alexander Sverdlin
2014-04-16 11:55 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' Matija Glavinic Pecotic
2014-04-16 11:55 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Matija Glavinic Pecotic
2014-04-16 13:32 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' Vlad Yasevich
2014-04-16 13:32 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Vlad Yasevich
2014-04-16 18:50 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' Vlad Yasevich
2014-04-16 18:50 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Vlad Yasevich
2014-04-16 19:05 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' Daniel Borkmann
2014-04-16 19:05 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Daniel Borkmann
2014-04-16 19:24 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' Matija Glavinic Pecotic
2014-04-16 19:24 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Matija Glavinic Pecotic
2014-04-16 19:47 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' Vlad Yasevich
2014-04-16 19:47 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Vlad Yasevich
2014-04-21 19:12 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' Matija Glavinic Pecotic
2014-04-21 19:12 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Matija Glavinic Pecotic
2014-04-14 20:48 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' David Miller
2014-04-14 20:48 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" David Miller
2014-04-15 8:46 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' Alexander Sverdlin
2014-04-15 8:46 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Alexander Sverdlin
2014-04-15 8:57 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' Daniel Borkmann
2014-04-15 8:57 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Daniel Borkmann
2014-04-15 6:43 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' Alexander Sverdlin
2014-04-15 6:43 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Alexander Sverdlin
2014-04-15 7:08 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' Daniel Borkmann
2014-04-15 7:08 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Daniel Borkmann
2014-04-15 14:27 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' Butler, Peter
2014-04-15 14:27 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Butler, Peter
2014-04-16 18:36 ` [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver' Vlad Yasevich
-- strict thread matches above, loose matches on Subject: below --
2015-12-23 7:13 Roger Nyberg
2015-12-23 13:18 ` Marcelo Ricardo Leitner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=534E473E.20303@nsn.com \
--to=alexander.sverdlin@nsn.com \
--cc=davem@davemloft.net \
--cc=dborkman@redhat.com \
--cc=dongsheng.song@gmail.com \
--cc=linux-sctp@vger.kernel.org \
--cc=matija.glavinic-pecotic.ext@nsn.com \
--cc=netdev@vger.kernel.org \
--cc=vyasevich@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.