From: Thomas Graf <tgraf@infradead.org>
To: Vladislav Yasevich <vladislav.yasevich@hp.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net,
Wei Yongjun <yjwei@cn.fujitsu.com>,
Sridhar Samudrala <sri@us.ibm.com>,
linux-sctp@vger.kernel.org
Subject: Re: [PATCH] sctp: Enforce maximum retransmissions during shutdown
Date: Wed, 29 Jun 2011 11:48:14 -0400 [thread overview]
Message-ID: <20110629154814.GD10085@canuck.infradead.org> (raw)
In-Reply-To: <4E0B3DA1.9060200@hp.com>
On Wed, Jun 29, 2011 at 10:58:41AM -0400, Vladislav Yasevich wrote:
> But what you are proposing violates the protocol. Zero-window probes do
> not count against max retransmissions, even when you are in shutdown pending
> state.
>
> You'll come out of this one of 2 ways:
> 1) receiver wakes up and processes data. This will allow for graceful termination.
> 2) receiver dies. Since receive window is full, we have data queued, and this will
> trigger an ABORT to be sent to the sender.
If by die you mean kill the process then this is exactly what I do to trigger
the issue. I simulatenously kill both processes. Not sure what you mean by
trigger an ABORT but I don't see that happen. I also don't see the rwnd reopen
after the socket is closed on the receiver side but that's a separate issue.
> What you patch is doing is taking a perfectly valid scenario and putting a time limit
> on it in violation of the spec.
We also violate the spec by not doing so. The spec says that the number of
SHUTDOWN retransmissions has to be limited by Max.Retrans which we also
can't enforce because of the above.
The scenario is closed sockets on both sides, endpoints on both sides gone
already and retransmissions + heartbeat requests forever.
Any alternative suggestion how to fix this?
next prev parent reply other threads:[~2011-06-29 15:48 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-29 13:57 [PATCH] sctp: Enforce maximum retransmissions during shutdown Thomas Graf
2011-06-29 14:20 ` Vladislav Yasevich
2011-06-29 14:36 ` Thomas Graf
2011-06-29 14:58 ` Vladislav Yasevich
2011-06-29 15:48 ` Thomas Graf [this message]
2011-06-29 16:14 ` Vladislav Yasevich
2011-06-30 8:49 ` Thomas Graf
2011-06-30 14:08 ` Vladislav Yasevich
2011-06-30 16:17 ` Thomas Graf
2011-07-04 13:50 ` [PATCHv2] sctp: Enforce retransmission limit " Thomas Graf
2011-07-06 7:24 ` David Miller
2011-07-06 12:15 ` Neil Horman
2011-07-06 13:16 ` Thomas Graf
2011-07-06 14:19 ` Neil Horman
2011-07-06 13:42 ` Vladislav Yasevich
2011-07-06 14:18 ` Thomas Graf
2011-07-06 14:31 ` Vladislav Yasevich
2011-07-06 15:49 ` Thomas Graf
2011-07-06 16:23 ` Vladislav Yasevich
2011-07-06 21:58 ` Thomas Graf
2011-07-07 10:28 ` [PATCHv3] " Thomas Graf
2011-07-07 13:36 ` Vladislav Yasevich
2011-07-07 21:09 ` David Miller
2011-06-30 13:31 ` [PATCH] sctp: ABORT if receive queue is not empty while closing socket Thomas Graf
2011-06-30 14:11 ` Vladislav Yasevich
2011-06-30 16:19 ` Thomas Graf
2011-06-30 16:27 ` Vladislav Yasevich
2011-07-08 10:57 ` [PATCHv2] " Thomas Graf
2011-07-08 13:49 ` Vladislav Yasevich
2011-07-08 14:29 ` Thomas Graf
2011-07-08 14:37 ` [PATCHv3] sctp: ABORT if receive, reassmbly, or reodering " Thomas Graf
2011-07-08 16:37 ` David Miller
2011-07-08 16:43 ` Vladislav Yasevich
2011-07-08 16:53 ` David Miller
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=20110629154814.GD10085@canuck.infradead.org \
--to=tgraf@infradead.org \
--cc=davem@davemloft.net \
--cc=linux-sctp@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sri@us.ibm.com \
--cc=vladislav.yasevich@hp.com \
--cc=yjwei@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).