From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Cc: David Miller <davem@davemloft.net>,
linux-sctp@vger.kernel.org, netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH] SCTP: enable cookie-echo retransmission transport switch
Date: Fri, 13 Jun 2008 08:57:54 -0400 [thread overview]
Message-ID: <48526ED2.50006@hp.com> (raw)
In-Reply-To: <4851C3AD.9030600@cn.fujitsu.com>
Gui Jianfeng wrote:
> Vlad,
>
> Thanks for your comments.
>
> Vlad Yasevich wrote:
>> Gui Jianfeng wrote:
>>> Vlad,
>>> This patch enables cookie-echo retransmission transport switch
>>> feature. If COOKIE-ECHO retransmission happens, it will be sent to the
>>> address other than the one last sent to.
>>>
>> NAK.
>>
>> You can't blindly choose a different transport since they could
>> be unconfirmed and can't really be used until we confirm them
>> with HBs. So, you can only do this when the user issued an
>> sctp_connectx() and we have multiple confirmed transports.
>>
>> In this case only confirmed transports are allowed, otherwise
>> there is a possibility of hijacking associations.
>>
> Choosing a transport here just gives a suggestion for sctp_outq_flush(),
> sctp_outq_flush() will judge again. If the selected transport is in
> INACTIVE or UNCONFIRMED, active_path will be used.
> So COOKIE-ECHO won't be sent to a unconfirmed address.
>
Yep, and this completely nullifies the thing you are trying to do. So, instead
of trying other available transports, we end up just sending on the active path
is at this stage of association is the same as primary.
>> Also, looking at this, the same problem exists in current
>> code for selection INIT transports.
>>
>> We don't correctly treat peers passed to connectx() as confirmed
>> and don't select the correct transport.
>>
>> Once you fix that above, you can just re-use the function and
>> re-use init_last_sent_to.
>
> Will do.
Just an FYI, here is a way BSD handles this:
a. they assume all destinations passed to connectx() are
reachable/confirmed.
b. when processing INIT-ACK, they tag all the existing destinations
with a flag, and clear the flag if the destination is in INIT-ACK.
c. they free all destinations that have the flag set at the end of
INIT-ACK.
I think a simpler way would to add another state to the transport that allows
sending handshakes and correctly transitions to confirmed when association is
fully formed. In BSD, they end up walking the destination chain 3 times, which
is just a waste.
-vlad
>
>> -vlad
>>
>
>
>
>>
>
prev parent reply other threads:[~2008-06-13 12:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-12 4:37 [PATCH] SCTP: enable cookie-echo retransmission transport switch Gui Jianfeng
2008-06-12 15:07 ` Vlad Yasevich
2008-06-13 0:47 ` Gui Jianfeng
2008-06-13 12:57 ` Vlad Yasevich [this message]
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=48526ED2.50006@hp.com \
--to=vladislav.yasevich@hp.com \
--cc=davem@davemloft.net \
--cc=guijianfeng@cn.fujitsu.com \
--cc=linux-sctp@vger.kernel.org \
--cc=netdev@vger.kernel.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 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).