Re: [Lksctp-developers] Should SCTP send ABORT on its Listen Queue Full?

[Mark B. <bu...@mi...>]

RS, Moorthy (STSD) wrote:

> Thanks to you both for your perspectives.
>
> However, Vlad pointed that RFC 2960 does talk about this in section 
> 5.1 - if we consider listen queue being full as "lack of resources".
>
>    If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but
>    decides not to establish the new association due to missing mandatory
>    parameters in the received INIT or INIT ACK, invalid parameter
>    values, or lack of local resources, it MUST respond with an ABORT
>    chunk.  It SHOULD also specify the cause of abort, such as the type
>    of the missing mandatory parameters, etc., by including the error
>    cause parameters with the ABORT chunk.
>
> So, there are two aspects here:
>
> 1) Should SCTP stack send ABORT packet or not? If we consider listen 
> queue being full as "lack of resources", then SCTP should send an 
> ABORT packet - by clearly specifying the cause of abort. I guess this 
> is the list for talking about this problem.

In general No, but it depends on the traffic load.  The SCTP 
specification should be changed so that "should" recommendation with 
regard to lack of local resources is changed to "may".

>
> 2) What error should the stack do (retry or send an error to the 
> application -- and what error), if it receives ABORT packet with 
> appropriate cause of abort? If the stack has to retry sending INIT 
> packet, then again, I assume this is the list to discuss and arrive at 
> a consensus. If it is an error to application, as Mark pointed out, it 
> would be the SCTP socket draft - which he cross-posted.

It should return ECONNREFUSED just like TCP.  ECONNABORTED appears to be 
intended for higher layer protocols.

>
> Given the inputs, I am for sending an ABORT packet by the server, when 
> the listen queue is full -- and the initiator (client) to retry 
> sending the INIT or COOKIE-ECHO packet again - for lack of resources 
> case alone. Dropping the INIT packet looked easier to me - however the 
> delays involved in retrying and the above RFC text makes me feel that 
> may not be the right thing to do.

Once the ABORT is sent it is game over for that association, the 
application (not the SCTP layer) would need to either give up, try a 
different server, or wait a random amount of time and try again.

If you want the SCTP layer to do this, then a new control chunk would 
need to be defined carrying semantics like 'busy - try again in x 
milliseconds'.  Then the initiating SCTP endpoint could retry as 
specified, until the connect timeout expires.

>
> Any comments?
>
> Thanks
> Moorthy
>
>
> On 04/20/2006 02:51 AM, Mark Butler wrote:
>
>> Well, so far we are all agreed.  This is the type of thing that needs 
>> to be standardized, however, and the SCTP socket draft looks like the 
>> appropriate place.
>>
>> - Mark
>>
>> Michael Tuexen wrote:
>>
>>> Hi,
>>>
>>> I think just dropping the INIT is better because (hopefully) the  
>>> listen queue will
>>> not be full later when an retransmitted INIT arrives. So the  
>>> association can be set up
>>> successfully.
>>>
>>> Best regards
>>> Michael
>>>
>>> On Apr 19, 2006, at 5:07 PM, RS, Moorthy (STSD) wrote:
>>>
>>>> All,
>>>>
>>>> Currently, when SCTP INIT packet is received by server and when 
>>>> the  server's listen queue is full - ( i.e sk->sk_ack_backlog 
>>>> exceeds  the listen() value specified), SCTP server sends an ABORT 
>>>> packet to  the client. This means that the client gets a 
>>>> "connection refused"  error - when there is load on the server, and 
>>>> is not able to  process its incoming connections faster.
>>>>
>>>> While TCP behaves differently - it just drops the SYN packet, when  
>>>> its listen queue is full. However, in this case, applications will  
>>>> retry and connect eventually. Given that, most TCP clients do not  
>>>> retry on "connection refused" errors, they would have problems  
>>>> while using SCTP (TCP-style one-to-one sockets) and would need to  
>>>> change their code. (I have test scenarios, where even after  
>>>> increasing listen() queue value - 10 times of 10000 connection  
>>>> requests are ABORTed).
>>>>
>>>> I would like to see, SCTP too dropping the INIT packet and not  
>>>> sending an ABORT, when its listen queue is full.
>>>>
>>>> Any thoughts of why that should not be the case?
>>>>
>>>> Thanks
>>>> Moorthy
>>>
>>>
>>