All of lore.kernel.org
 help / color / mirror / Atom feed
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 09:30:14 -0400	[thread overview]
Message-ID: <55DF10E6.3010007@redhat.com> (raw)
In-Reply-To: <CADvbK_cZhT3crJhP-5HQVpm=iAYTCDkiBNnDNCibvfOvEyzN7w@mail.gmail.com>

On 08/27/2015 09:19 AM, lucien xin wrote:
>>
>> No, these are 2 distinct instances.  In one instance, the peer is reachable and
>> is able to communication 0 rwnd state to us.  Thus we are being nice and granting
>> the peer more time to exit the 0 window state.
>>
>> In the other state, the peer is unreachable and we just happen to hit the 0-window
>> condition based on some estimations of the peer window.  In this case, we should
>> be subject to the Max.RTX and terminate the association sooner.
>>
>> -vlad
>>
> okay, I got you,
> 
> we can see that local update their peer.rwnd in sctp_packet_append_data() and
> sctp_retransmit_mark(), it do that according to a_rwnd and outstanding, so the
> root reason is that it's hard to know that peer really closed it's window, maybe
> just so many outstanding lead to that.
> 
> what we can do is to trust peer.rwnd is the real window in peer.
> from another angle,  even though it's not real, at least we can reduce the
> * the other state* you mentioned by doing this. especially, if there is only one
> small packet keep retransmitting in SHUTDOWN_PENDING state, the
> peer.rwnd is more believable to be the real peer window.
> 
> I saw bsd code didnot care about Max.Retrans in SHUTDOWN_PENDING,
> instead it just start T5 timer. but now that we choose Max.Retrans + T5, it's
> better to process more unreachable by using Max.Retrans. I also hope we can
> do it better there as Marcelo said, but by now I cannot see it. :)
> 

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.

Just some thoughts.
-vlad

  reply	other threads:[~2015-08-27 13:30 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 [this message]
2015-08-27 14:49           ` lucien xin
2015-08-27 15:14             ` Vlad Yasevich
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=55DF10E6.3010007@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.