From: Vlad Yasevich <vyasevic@redhat.com>
To: lucien xin <lucien.xin@gmail.com>
Cc: Marcelo Ricardo Leitner <mleitner@redhat.com>,
network dev <netdev@vger.kernel.org>,
Thomas Graf <tgraf@infradead.org>, davem <davem@davemloft.net>
Subject: Re: [PATCH net v2] sctp: start t5 timer only when peer.rwnd is 0 and local.state is SHUTDOWN_PENDING
Date: Thu, 27 Aug 2015 11:14:57 -0400 [thread overview]
Message-ID: <55DF2971.5080009@redhat.com> (raw)
In-Reply-To: <CADvbK_eZfJpQtvM_zTyS=3yTuCkdK0RM-zbMbFvUx5L-U9u5jQ@mail.gmail.com>
On 08/27/2015 10:49 AM, lucien xin wrote:
>>
>> 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.
>>
> I think updating 0-window may happen in sctp_process_init() and
> sctp_outq_sack(),
> I don't think 0-window can be probed, cause unreachable and closing
> window both has
> no reply from peer. but we can update the 0-window bit in those two
> functions. I just do
> not know where there is a available bit we can use if won't change the
> peer structure.
You can ignore INIT as the window will never be 0 (not allowed).
The updates could happen at the end of sctp_outq_sack(). There some spare
bits in peer if you want to go that way.
-vlad
>
>> Just some thoughts.
>> -vlad
next prev parent reply other threads:[~2015-08-27 15:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-23 11:30 [PATCH net v2] sctp: start t5 timer only when peer.rwnd is 0 and local.state is SHUTDOWN_PENDING Xin Long
2015-08-24 13:01 ` Marcelo Ricardo Leitner
2015-08-24 18:13 ` Vlad Yasevich
2015-08-24 18:31 ` Marcelo Ricardo Leitner
2015-08-24 18:36 ` Vlad Yasevich
2015-08-24 19:13 ` Marcelo Ricardo Leitner
2015-08-27 13:19 ` lucien xin
2015-08-27 13:30 ` Vlad Yasevich
2015-08-27 14:49 ` lucien xin
2015-08-27 15:14 ` Vlad Yasevich [this message]
2015-08-27 16:40 ` lucien xin
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=55DF2971.5080009@redhat.com \
--to=vyasevic@redhat.com \
--cc=davem@davemloft.net \
--cc=lucien.xin@gmail.com \
--cc=mleitner@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=tgraf@infradead.org \
/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.