lkml.org 
[lkml]   [2013]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] net: sctp: recover a tranport when an ack comes
On 11/15/2013 02:59 PM, Chang wrote:
> I've tried to catch you guys up~
>
> Here's a quick question:
>
> Where are the default [transport->pf_retrans] and
> [transport->pathmaxrtx] set?

They are initially set through the sctp_net_init. Later
they can be changed through sysctl or via socket options.

> I could figure out that they could be set
> through setsockopt(SCTP_PEER_ADDR_THLDS, ...) (but it seems like the
> SCTP library has not supported such option yet, maybe that's due to my
> library is out of date). So by default both of the two threshold are zero.

pf_retrans starts at 0. pathmaxrtx has always started at 5.

You should be able to use the socket option directly, but you might need
a newer header. You can always add the value to your application as well.

>
> Here's my question: Does it go conflict with "the recommended value for
> Path.Max.Retrans in the standard is 5"?

Path.Max.Retrans is set to 5 (at least on my system...)

-vlad

>
> Thanks!
>
> On 11/15/2013 03:56 PM, Neil Horman wrote:
>> On Fri, Nov 15, 2013 at 09:00:58AM -0500, Vlad Yasevich wrote:
>>> On 11/15/2013 07:30 AM, Neil Horman wrote:
>>>> On Thu, Nov 14, 2013 at 09:34:55PM -0500, Vlad Yasevich wrote:
>>>>> On 11/14/2013 03:40 PM, Chang Xiangzhong wrote:
>>>>>> Expected Behavior:
>>>>>> When hearing an ack from a tranport/path, set its state to
>>>>>> normal/on if it's
>>>>>> in abnormal(__partial_failure__ or inactive) state.
>>>>>>
>>>>>> state machine of tranport->state
>>>>>> Whenever a T3_RTX timer expires, then transport->error_count++.
>>>>>> When (association->pf_retrans < transport->error_count <
>>>>>> tranport->pathmaxrtx)
>>>>>> transport->state = SCTP_PF //partial failure
>>>>>>
>>>>>> When a heartbeat-ack comes or conventional ack acknowledged its
>>>>>> availability,
>>>>>> transport->state = SCTP_ON
>>>>>>
>>>>>> Signed-off-by: Chang Xiangzhong <changxiangzhong@gmail.com>
>>>>>> Fixes: 5aa93bcf66f ("sctp: Implement quick failover draft from
>>>>>> tsvwg")
>>>>> I don't think this is right. The spec states:
>>>>> 8. ACKs for retransmissions do not transition a PF destination back
>>>>> to Active state, since a sender cannot disambiguate whether
>>>>> the
>>>>> ack was for the original transmission or the
>>>>> retransmission(s).
>>>>>
>>>>>
>>>>> Now, the proper way to this would would be modify
>>>>> sctp_assoc_control_transport() to transition the transport state to
>>>>> ACTIVE if it was PF transport that was chosen to send data.
>>>>>
>>>>> -vlad
>>>>>
>>>> I agree, this patch doesn't agree with the spec, the only time we
>>>> transition
>>> >from PF to ACTIVE should be on receipt of ack of new data.
>>>
>>> You mean HB ACK, right? The 02 spec that see on the ietf site doesn't
>>> mention anything about transition on SACKs. Also, there is no way to
>>> tell right now if the ack is for new or retransmitted data. We could
>>> mark chunks that are retransmitted though.
>>>
>> Yes, sorry I wasn't clear, I was speaknig about HB Acks.
>>
>>>> I'm not even sure if
>>>> we should allow PF transports to be selected to send new data.
>>>> Currently a
>>>> potentially failed transport will get ignored when specified, and
>>>> the stack will
>>>> use the active path in its place. Only if all transports are PF
>>>> will a PF
>>>> transport be chosen.
>>> Not even that :(. If all transports are PF, we are going to camp on
>>> the primary path instead of choosing a PF transport with the lowest
>>> error count.
>>>
>> Yes, we don't do the smallest error count check, though I have to
>> wonder if
>> thats really worthwhile. If all your transports are PF, you're a step
>> away from
>> a connection reset anyway.
>> Neil
>>
>>> -vlad
>>>
>>>> Neil
>>>>
>>>>>> ---
>>>>>> net/sctp/outqueue.c | 1 +
>>>>>> 1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
>>>>>> index 94df758..2557fa5 100644
>>>>>> --- a/net/sctp/outqueue.c
>>>>>> +++ b/net/sctp/outqueue.c
>>>>>> @@ -1517,6 +1517,7 @@ static void sctp_check_transmitted(struct
>>>>>> sctp_outq *q,
>>>>>> * active if it is not so marked.
>>>>>> */
>>>>>> if ((transport->state == SCTP_INACTIVE ||
>>>>>> + transport->state == SCTP_PF ||
>>>>>> transport->state == SCTP_UNCONFIRMED) &&
>>>>>> sctp_cmp_addr_exact(&transport->ipaddr, saddr)) {
>>>>>> sctp_assoc_control_transport(
>>>>>>
>>>>>
>>> --
>>> 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
>>>
>



\
 
 \ /
  Last update: 2013-11-15 22:01    [W:0.390 / U:0.928 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site