Re: [Lksctp-developers] [PATCH] sctp: Fix to handle SHUTDOWN in SHUTDOWN-PENDING

Re: [Lksctp-developers] [PATCH] sctp: Fix to handle SHUTDOWN in SHUTDOWN-PENDING

[Vlad Yasevich]

Hi Wei

If I can't take that without a patch that processes SHUTDOWN chunks in
SHUTDOWN_RECEIVED state.

The problem is that if B in your example has more data to send,
it will ignore subsequent SHUTDOWN chunks.  If A uses only SHUTDOWNS
to acknowledge data, then this would results us ignoring acks and
retransmitting and eventually ABORTING the association.

-vlad

Wei Yongjun wrote:
> If SHUTDOWN is received in SHUTDOWN-PENDING state, enpoint should enter
> the SHUTDOWN-RECEIVED state and check the Cumulative TSN Ack field of
> the SHUTDOWN chunk (RFC 4960 Section 9.2). If the SHUTDOWN chunk can
> acknowledge all of the send DATA chunks, SHUTDOWN-ACK should be sent.
> 
> But now endpoint just silently discarded the SHUTDOWN chunk.
> 
> SHUTDOWN received in SHUTDOWN-PENDING state can happend when the last
> SACK is lost by network, or the SHUTDOWN chunk can acknowledge all of
> the received DATA chunks. The packet sequence(SACK lost) is like this:
> 
> Endpoint A                       Endpoint B       ULP
> (ESTABLISHED)                    (ESTABLISHED)
> 
>                <-----------      DATA
>                                              <--- shutdown
>                                  Enter SHUTDOWN-PENDING state
>   SACK         ----lost---->
> 
>   SHUTDOWN(*1) ------------>
> 
>                <-----------      SHUTDOWN-ACK
> 
>  (*1) silently discarded now.
> 
> This patch fix to handle SHUTDOWN in SHUTDOWN-PENDING state as the same
> as ESTABLISHED state.
> 
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
> ---
>  net/sctp/sm_statetable.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/net/sctp/sm_statetable.c b/net/sctp/sm_statetable.c
> index dd4ddc4..a5b5590 100644
> --- a/net/sctp/sm_statetable.c
> +++ b/net/sctp/sm_statetable.c
> @@ -266,7 +266,7 @@ const sctp_sm_table_entry_t *sctp_sm_lookup_event(sctp_event_t event_type,
>  	/* SCTP_STATE_ESTABLISHED */ \
>  	TYPE_SCTP_FUNC(sctp_sf_do_9_2_shutdown), \
>  	/* SCTP_STATE_SHUTDOWN_PENDING */ \
> -	TYPE_SCTP_FUNC(sctp_sf_discard_chunk), \
> +	TYPE_SCTP_FUNC(sctp_sf_do_9_2_shutdown), \
>  	/* SCTP_STATE_SHUTDOWN_SENT */ \
>  	TYPE_SCTP_FUNC(sctp_sf_do_9_2_shutdown_ack), \
>  	/* SCTP_STATE_SHUTDOWN_RECEIVED */ \

Re: [Lksctp-developers] [PATCH] sctp: Fix to handle SHUTDOWN in SHUTDOWN-PENDING

[Wei Yongjun]

Hi Vlad:

> Hi Wei
>
> If I can't take that without a patch that processes SHUTDOWN chunks in
> SHUTDOWN_RECEIVED state.
>
> The problem is that if B in your example has more data to send,
> it will ignore subsequent SHUTDOWN chunks.  If A uses only SHUTDOWNS
> to acknowledge data, then this would results us ignoring acks and
> retransmitting and eventually ABORTING the association.
>   

I think the current kernel has the same problem when process SHUTDOWN in 
ESTABLISHED state:

Endpoint A                       Endpoint B       ULP
(ESTABLISHED)                    (ESTABLISHED)

               <-----------      DATA (TSN=1)
               <-----------      DATA (TSN=2)
  SHUTDOWN(TSN=1) ------------>  enter SHUTDOWN-RECEIVED state
               <-----------      DATA (TSN=2)
  SACK(TSN=2)  ------------>
  SHUTDOWN(TSN=2) ------------>  discard

I have not test it, and check it later.

RFC4960 said:
   Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT
   send a SHUTDOWN in *response to a ULP request*, and should *discard*
   subsequent SHUTDOWN chunks.

So maybe the RFC is wrong, and we still need to process the SHUTDOWN 
chunk in
SHUTDOWN-RECEIVED state, or when we received SHUTDOWN, we only enter
SHUTDOWN-RECEIVED state if the TSN can ack all its outstanding DATA chunks.

Wei Yongjun

> -vlad
>
> Wei Yongjun wrote:
>   
>> If SHUTDOWN is received in SHUTDOWN-PENDING state, enpoint should enter
>> the SHUTDOWN-RECEIVED state and check the Cumulative TSN Ack field of
>> the SHUTDOWN chunk (RFC 4960 Section 9.2). If the SHUTDOWN chunk can
>> acknowledge all of the send DATA chunks, SHUTDOWN-ACK should be sent.
>>
>> But now endpoint just silently discarded the SHUTDOWN chunk.
>>
>> SHUTDOWN received in SHUTDOWN-PENDING state can happend when the last
>> SACK is lost by network, or the SHUTDOWN chunk can acknowledge all of
>> the received DATA chunks. The packet sequence(SACK lost) is like this:
>>
>> Endpoint A                       Endpoint B       ULP
>> (ESTABLISHED)                    (ESTABLISHED)
>>
>>                <-----------      DATA
>>                                              <--- shutdown
>>                                  Enter SHUTDOWN-PENDING state
>>   SACK         ----lost---->
>>
>>   SHUTDOWN(*1) ------------>
>>
>>                <-----------      SHUTDOWN-ACK
>>
>>  (*1) silently discarded now.
>>
>> This patch fix to handle SHUTDOWN in SHUTDOWN-PENDING state as the same
>> as ESTABLISHED state.
>>     

Re: [Lksctp-developers] [PATCH] sctp: Fix to handle SHUTDOWN in SHUTDOWN-PENDING

[Wei Yongjun]

Hi Vlad:
>> Hi Wei
>>
>> If I can't take that without a patch that processes SHUTDOWN chunks in
>> SHUTDOWN_RECEIVED state.
>>
>> The problem is that if B in your example has more data to send,
>> it will ignore subsequent SHUTDOWN chunks.  If A uses only SHUTDOWNS
>> to acknowledge data, then this would results us ignoring acks and
>> retransmitting and eventually ABORTING the association.
>>   
>>     
>
> I think the current kernel has the same problem when process SHUTDOWN in 
> ESTABLISHED state:
>
> Endpoint A                       Endpoint B       ULP
> (ESTABLISHED)                    (ESTABLISHED)
>
>                <-----------      DATA (TSN=1)
>                <-----------      DATA (TSN=2)
>   SHUTDOWN(TSN=1) ------------>  enter SHUTDOWN-RECEIVED state
>                <-----------      DATA (TSN=2)
>   SACK(TSN=2)  ------------>
>   SHUTDOWN(TSN=2) ------------>  discard
>
> I have not test it, and check it later.
>
> RFC4960 said:
>    Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT
>    send a SHUTDOWN in *response to a ULP request*, and should *discard*
>    subsequent SHUTDOWN chunks.
>
>   

The old RFC 2960 said:
   While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
   respond to each received packet containing one or more DATA chunk(s)
   *with a SACK*, a SHUTDOWN chunk, and restart the T2-shutdown timer. If
   it has no more outstanding DATA chunks, the SHUTDOWN receiver shall
   send a SHUTDOWN ACK and start a T2-shutdown timer of its own,
   entering the SHUTDOWN-ACK-SENT state.  If the timer expires, the
   endpoint must re-send the SHUTDOWN ACK.

The old RFC2960 force to send a sack to the DATA sender, so after 
received the
sack, the assoc can be shutdown correctly.

Endpoint A                       Endpoint B       ULP
(ESTABLISHED)                    (ESTABLISHED)

               <-----------      DATA (TSN=1)
               <-----------      DATA (TSN=2)
  SHUTDOWN(TSN=1) ------------>  enter SHUTDOWN-RECEIVED state
               <-----------      DATA (TSN=2)
  SHUTDOWN(TSN=2) ------------>  discard
  SACK(TSN=2)  ------------>     accept
               <-----------      SHUTDOWN-ACK


SACK in SHUTDOWN-RECEIVED state will cause a SHUTDOWN-ACK be sent, if
the SACKcan ack all of the outstanding DATA chunks.

But new RFC 4960 said:
   While in the SHUTDOWN-SENT state, the SHUTDOWN sender MUST
   immediately respond to each received packet containing one or more
   DATA chunks with *a SHUTDOWN chunk* and restart the T2-shutdown timer.
   If a SHUTDOWN chunk by itself cannot acknowledge all of the received
   DATA chunks (i.e., there are TSNs that can be acknowledged that are
   larger than the cumulative TSN, and thus gaps exist in the TSN
   sequence), or if duplicate TSNs have been received, then a SACK chunk
   MUST also be sent.

This maybe wrong since the SACK will not send if the SHUTDOWN chunk can
acknowledge all of the received DATA chunks, and SHUTDOWN chunk is discard
in SHUTDOWN-RECEIVED state.

We need to fix RFC4960, either force to send SACK in SHUTDOWN-SENT state
or accept the SHUTDOWN in SHUTDOWN-RECEIVED state. (The current code
is force send SACK)


>
>   
>> -vlad
>>
>> Wei Yongjun wrote:
>>   
>>     
>>> If SHUTDOWN is received in SHUTDOWN-PENDING state, enpoint should enter
>>> the SHUTDOWN-RECEIVED state and check the Cumulative TSN Ack field of
>>> the SHUTDOWN chunk (RFC 4960 Section 9.2). If the SHUTDOWN chunk can
>>> acknowledge all of the send DATA chunks, SHUTDOWN-ACK should be sent.
>>>
>>> But now endpoint just silently discarded the SHUTDOWN chunk.
>>>
>>> SHUTDOWN received in SHUTDOWN-PENDING state can happend when the last
>>> SACK is lost by network, or the SHUTDOWN chunk can acknowledge all of
>>> the received DATA chunks. The packet sequence(SACK lost) is like this:
>>>
>>> Endpoint A                       Endpoint B       ULP
>>> (ESTABLISHED)                    (ESTABLISHED)
>>>
>>>                <-----------      DATA
>>>                                              <--- shutdown
>>>                                  Enter SHUTDOWN-PENDING state
>>>   SACK         ----lost---->
>>>
>>>   SHUTDOWN(*1) ------------>
>>>
>>>                <-----------      SHUTDOWN-ACK
>>>
>>>  (*1) silently discarded now.
>>>
>>> This patch fix to handle SHUTDOWN in SHUTDOWN-PENDING state as the same
>>> as ESTABLISHED state.
>>>       

Re: [Lksctp-developers] [PATCH] sctp: Fix to handle SHUTDOWN in SHUTDOWN-PENDING state

[Michael Tüxen]

Hi Wei,

this is an RFC 4960 issue.
Can you bring this up on tsvwg@ietf.org?

Thanks a lot.

Best regards
Michael

On Oct 13, 2008, at 5:25 AM, Wei Yongjun wrote:

> Hi Vlad:
>>> Hi Wei
>>>
>>> If I can't take that without a patch that processes SHUTDOWN  
>>> chunks in
>>> SHUTDOWN_RECEIVED state.
>>>
>>> The problem is that if B in your example has more data to send,
>>> it will ignore subsequent SHUTDOWN chunks.  If A uses only SHUTDOWNS
>>> to acknowledge data, then this would results us ignoring acks and
>>> retransmitting and eventually ABORTING the association.
>>>
>>>
>>
>> I think the current kernel has the same problem when process  
>> SHUTDOWN in
>> ESTABLISHED state:
>>
>> Endpoint A                       Endpoint B       ULP
>> (ESTABLISHED)                    (ESTABLISHED)
>>
>>               <-----------      DATA (TSN=1)
>>               <-----------      DATA (TSN=2)
>>  SHUTDOWN(TSN=1) ------------>  enter SHUTDOWN-RECEIVED state
>>               <-----------      DATA (TSN=2)
>>  SACK(TSN=2)  ------------>
>>  SHUTDOWN(TSN=2) ------------>  discard
>>
>> I have not test it, and check it later.
>>
>> RFC4960 said:
>>   Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST  
>> NOT
>>   send a SHUTDOWN in *response to a ULP request*, and should  
>> *discard*
>>   subsequent SHUTDOWN chunks.
>>
>>
>
> The old RFC 2960 said:
>   While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
>   respond to each received packet containing one or more DATA chunk(s)
>   *with a SACK*, a SHUTDOWN chunk, and restart the T2-shutdown  
> timer. If
>   it has no more outstanding DATA chunks, the SHUTDOWN receiver shall
>   send a SHUTDOWN ACK and start a T2-shutdown timer of its own,
>   entering the SHUTDOWN-ACK-SENT state.  If the timer expires, the
>   endpoint must re-send the SHUTDOWN ACK.
>
> The old RFC2960 force to send a sack to the DATA sender, so after
> received the
> sack, the assoc can be shutdown correctly.
>
> Endpoint A                       Endpoint B       ULP
> (ESTABLISHED)                    (ESTABLISHED)
>
>               <-----------      DATA (TSN=1)
>               <-----------      DATA (TSN=2)
>  SHUTDOWN(TSN=1) ------------>  enter SHUTDOWN-RECEIVED state
>               <-----------      DATA (TSN=2)
>  SHUTDOWN(TSN=2) ------------>  discard
>  SACK(TSN=2)  ------------>     accept
>               <-----------      SHUTDOWN-ACK
>
>
> SACK in SHUTDOWN-RECEIVED state will cause a SHUTDOWN-ACK be sent, if
> the SACKcan ack all of the outstanding DATA chunks.
>
> But new RFC 4960 said:
>   While in the SHUTDOWN-SENT state, the SHUTDOWN sender MUST
>   immediately respond to each received packet containing one or more
>   DATA chunks with *a SHUTDOWN chunk* and restart the T2-shutdown  
> timer.
>   If a SHUTDOWN chunk by itself cannot acknowledge all of the received
>   DATA chunks (i.e., there are TSNs that can be acknowledged that are
>   larger than the cumulative TSN, and thus gaps exist in the TSN
>   sequence), or if duplicate TSNs have been received, then a SACK  
> chunk
>   MUST also be sent.
>
> This maybe wrong since the SACK will not send if the SHUTDOWN chunk  
> can
> acknowledge all of the received DATA chunks, and SHUTDOWN chunk is  
> discard
> in SHUTDOWN-RECEIVED state.
>
> We need to fix RFC4960, either force to send SACK in SHUTDOWN-SENT  
> state
> or accept the SHUTDOWN in SHUTDOWN-RECEIVED state. (The current code
> is force send SACK)
>
>
>>
>>
>>> -vlad
>>>
>>> Wei Yongjun wrote:
>>>
>>>
>>>> If SHUTDOWN is received in SHUTDOWN-PENDING state, enpoint should  
>>>> enter
>>>> the SHUTDOWN-RECEIVED state and check the Cumulative TSN Ack  
>>>> field of
>>>> the SHUTDOWN chunk (RFC 4960 Section 9.2). If the SHUTDOWN chunk  
>>>> can
>>>> acknowledge all of the send DATA chunks, SHUTDOWN-ACK should be  
>>>> sent.
>>>>
>>>> But now endpoint just silently discarded the SHUTDOWN chunk.
>>>>
>>>> SHUTDOWN received in SHUTDOWN-PENDING state can happend when the  
>>>> last
>>>> SACK is lost by network, or the SHUTDOWN chunk can acknowledge  
>>>> all of
>>>> the received DATA chunks. The packet sequence(SACK lost) is like  
>>>> this:
>>>>
>>>> Endpoint A                       Endpoint B       ULP
>>>> (ESTABLISHED)                    (ESTABLISHED)
>>>>
>>>>               <-----------      DATA
>>>>                                             <--- shutdown
>>>>                                 Enter SHUTDOWN-PENDING state
>>>>  SACK         ----lost---->
>>>>
>>>>  SHUTDOWN(*1) ------------>
>>>>
>>>>               <-----------      SHUTDOWN-ACK
>>>>
>>>> (*1) silently discarded now.
>>>>
>>>> This patch fix to handle SHUTDOWN in SHUTDOWN-PENDING state as  
>>>> the same
>>>> as ESTABLISHED state.
>>>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id\x100&url=/
> _______________________________________________
> Lksctp-developers mailing list
> Lksctp-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>

Re: [Lksctp-developers] [PATCH] sctp: Fix to handle SHUTDOWN in SHUTDOWN-PENDING

[Wei Yongjun]

Michael Tüxen wrote:
> Hi Wei,
>
> this is an RFC 4960 issue.
> Can you bring this up on tsvwg@ietf.org?

I had posted a query to tsvwg@ietf.org. Link is:

http://www.ietf.org/mail-archive/web/tsvwg/current/msg08653.html

>
> Thanks a lot.
>
> Best regards
> Michael
>
> On Oct 13, 2008, at 5:25 AM, Wei Yongjun wrote:
>
>> Hi Vlad:
>>>> Hi Wei
>>>>
>>>> If I can't take that without a patch that processes SHUTDOWN chunks in
>>>> SHUTDOWN_RECEIVED state.
>>>>
>>>> The problem is that if B in your example has more data to send,
>>>> it will ignore subsequent SHUTDOWN chunks.  If A uses only SHUTDOWNS
>>>> to acknowledge data, then this would results us ignoring acks and
>>>> retransmitting and eventually ABORTING the association.
>>>>
>>>>
>>>
>>> I think the current kernel has the same problem when process 
>>> SHUTDOWN in
>>> ESTABLISHED state:
>>>
>>> Endpoint A                       Endpoint B       ULP
>>> (ESTABLISHED)                    (ESTABLISHED)
>>>
>>>               <-----------      DATA (TSN=1)
>>>               <-----------      DATA (TSN=2)
>>>  SHUTDOWN(TSN=1) ------------>  enter SHUTDOWN-RECEIVED state
>>>               <-----------      DATA (TSN=2)
>>>  SACK(TSN=2)  ------------>
>>>  SHUTDOWN(TSN=2) ------------>  discard
>>>
>>> I have not test it, and check it later.
>>>
>>> RFC4960 said:
>>>   Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT
>>>   send a SHUTDOWN in *response to a ULP request*, and should *discard*
>>>   subsequent SHUTDOWN chunks.
>>>
>>>
>>
>> The old RFC 2960 said:
>>   While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
>>   respond to each received packet containing one or more DATA chunk(s)
>>   *with a SACK*, a SHUTDOWN chunk, and restart the T2-shutdown timer. If
>>   it has no more outstanding DATA chunks, the SHUTDOWN receiver shall
>>   send a SHUTDOWN ACK and start a T2-shutdown timer of its own,
>>   entering the SHUTDOWN-ACK-SENT state.  If the timer expires, the
>>   endpoint must re-send the SHUTDOWN ACK.
>>
>> The old RFC2960 force to send a sack to the DATA sender, so after
>> received the
>> sack, the assoc can be shutdown correctly.
>>
>> Endpoint A                       Endpoint B       ULP
>> (ESTABLISHED)                    (ESTABLISHED)
>>
>>               <-----------      DATA (TSN=1)
>>               <-----------      DATA (TSN=2)
>>  SHUTDOWN(TSN=1) ------------>  enter SHUTDOWN-RECEIVED state
>>               <-----------      DATA (TSN=2)
>>  SHUTDOWN(TSN=2) ------------>  discard
>>  SACK(TSN=2)  ------------>     accept
>>               <-----------      SHUTDOWN-ACK
>>
>>
>> SACK in SHUTDOWN-RECEIVED state will cause a SHUTDOWN-ACK be sent, if
>> the SACKcan ack all of the outstanding DATA chunks.
>>
>> But new RFC 4960 said:
>>   While in the SHUTDOWN-SENT state, the SHUTDOWN sender MUST
>>   immediately respond to each received packet containing one or more
>>   DATA chunks with *a SHUTDOWN chunk* and restart the T2-shutdown timer.
>>   If a SHUTDOWN chunk by itself cannot acknowledge all of the received
>>   DATA chunks (i.e., there are TSNs that can be acknowledged that are
>>   larger than the cumulative TSN, and thus gaps exist in the TSN
>>   sequence), or if duplicate TSNs have been received, then a SACK chunk
>>   MUST also be sent.
>>
>> This maybe wrong since the SACK will not send if the SHUTDOWN chunk can
>> acknowledge all of the received DATA chunks, and SHUTDOWN chunk is 
>> discard
>> in SHUTDOWN-RECEIVED state.
>>
>> We need to fix RFC4960, either force to send SACK in SHUTDOWN-SENT state
>> or accept the SHUTDOWN in SHUTDOWN-RECEIVED state. (The current code
>> is force send SACK)
>>
>>
>>>
>>>
>>>> -vlad
>>>>
>>>> Wei Yongjun wrote:
>>>>
>>>>
>>>>> If SHUTDOWN is received in SHUTDOWN-PENDING state, enpoint should 
>>>>> enter
>>>>> the SHUTDOWN-RECEIVED state and check the Cumulative TSN Ack field of
>>>>> the SHUTDOWN chunk (RFC 4960 Section 9.2). If the SHUTDOWN chunk can
>>>>> acknowledge all of the send DATA chunks, SHUTDOWN-ACK should be sent.
>>>>>
>>>>> But now endpoint just silently discarded the SHUTDOWN chunk.
>>>>>
>>>>> SHUTDOWN received in SHUTDOWN-PENDING state can happend when the last
>>>>> SACK is lost by network, or the SHUTDOWN chunk can acknowledge all of
>>>>> the received DATA chunks. The packet sequence(SACK lost) is like 
>>>>> this:
>>>>>
>>>>> Endpoint A                       Endpoint B       ULP
>>>>> (ESTABLISHED)                    (ESTABLISHED)
>>>>>
>>>>>               <-----------      DATA
>>>>>                                             <--- shutdown
>>>>>                                 Enter SHUTDOWN-PENDING state
>>>>>  SACK         ----lost---->
>>>>>
>>>>>  SHUTDOWN(*1) ------------>
>>>>>
>>>>>               <-----------      SHUTDOWN-ACK
>>>>>
>>>>> (*1) silently discarded now.
>>>>>
>>>>> This patch fix to handle SHUTDOWN in SHUTDOWN-PENDING state as the 
>>>>> same
>>>>> as ESTABLISHED state.
>>>>>

Re: [Lksctp-developers] [PATCH] sctp: Fix to handle SHUTDOWN in SHUTDOWN-PENDING state

[Michael Tüxen]

Hi Wei,

thanks.

Best regards
Michael

On Oct 14, 2008, at 2:30 AM, Wei Yongjun wrote:

> Michael Tüxen wrote:
>> Hi Wei,
>>
>> this is an RFC 4960 issue.
>> Can you bring this up on tsvwg@ietf.org?
>
> I had posted a query to tsvwg@ietf.org. Link is:
>
> http://www.ietf.org/mail-archive/web/tsvwg/current/msg08653.html
>
>>
>> Thanks a lot.
>>
>> Best regards
>> Michael
>>
>> On Oct 13, 2008, at 5:25 AM, Wei Yongjun wrote:
>>
>>> Hi Vlad:
>>>>> Hi Wei
>>>>>
>>>>> If I can't take that without a patch that processes SHUTDOWN  
>>>>> chunks in
>>>>> SHUTDOWN_RECEIVED state.
>>>>>
>>>>> The problem is that if B in your example has more data to send,
>>>>> it will ignore subsequent SHUTDOWN chunks.  If A uses only  
>>>>> SHUTDOWNS
>>>>> to acknowledge data, then this would results us ignoring acks and
>>>>> retransmitting and eventually ABORTING the association.
>>>>>
>>>>>
>>>>
>>>> I think the current kernel has the same problem when process  
>>>> SHUTDOWN in
>>>> ESTABLISHED state:
>>>>
>>>> Endpoint A                       Endpoint B       ULP
>>>> (ESTABLISHED)                    (ESTABLISHED)
>>>>
>>>>              <-----------      DATA (TSN=1)
>>>>              <-----------      DATA (TSN=2)
>>>> SHUTDOWN(TSN=1) ------------>  enter SHUTDOWN-RECEIVED state
>>>>              <-----------      DATA (TSN=2)
>>>> SACK(TSN=2)  ------------>
>>>> SHUTDOWN(TSN=2) ------------>  discard
>>>>
>>>> I have not test it, and check it later.
>>>>
>>>> RFC4960 said:
>>>>  Once an endpoint has reached the SHUTDOWN-RECEIVED state, it  
>>>> MUST NOT
>>>>  send a SHUTDOWN in *response to a ULP request*, and should  
>>>> *discard*
>>>>  subsequent SHUTDOWN chunks.
>>>>
>>>>
>>>
>>> The old RFC 2960 said:
>>>  While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
>>>  respond to each received packet containing one or more DATA  
>>> chunk(s)
>>>  *with a SACK*, a SHUTDOWN chunk, and restart the T2-shutdown  
>>> timer. If
>>>  it has no more outstanding DATA chunks, the SHUTDOWN receiver shall
>>>  send a SHUTDOWN ACK and start a T2-shutdown timer of its own,
>>>  entering the SHUTDOWN-ACK-SENT state.  If the timer expires, the
>>>  endpoint must re-send the SHUTDOWN ACK.
>>>
>>> The old RFC2960 force to send a sack to the DATA sender, so after
>>> received the
>>> sack, the assoc can be shutdown correctly.
>>>
>>> Endpoint A                       Endpoint B       ULP
>>> (ESTABLISHED)                    (ESTABLISHED)
>>>
>>>              <-----------      DATA (TSN=1)
>>>              <-----------      DATA (TSN=2)
>>> SHUTDOWN(TSN=1) ------------>  enter SHUTDOWN-RECEIVED state
>>>              <-----------      DATA (TSN=2)
>>> SHUTDOWN(TSN=2) ------------>  discard
>>> SACK(TSN=2)  ------------>     accept
>>>              <-----------      SHUTDOWN-ACK
>>>
>>>
>>> SACK in SHUTDOWN-RECEIVED state will cause a SHUTDOWN-ACK be sent,  
>>> if
>>> the SACKcan ack all of the outstanding DATA chunks.
>>>
>>> But new RFC 4960 said:
>>>  While in the SHUTDOWN-SENT state, the SHUTDOWN sender MUST
>>>  immediately respond to each received packet containing one or more
>>>  DATA chunks with *a SHUTDOWN chunk* and restart the T2-shutdown  
>>> timer.
>>>  If a SHUTDOWN chunk by itself cannot acknowledge all of the  
>>> received
>>>  DATA chunks (i.e., there are TSNs that can be acknowledged that are
>>>  larger than the cumulative TSN, and thus gaps exist in the TSN
>>>  sequence), or if duplicate TSNs have been received, then a SACK  
>>> chunk
>>>  MUST also be sent.
>>>
>>> This maybe wrong since the SACK will not send if the SHUTDOWN  
>>> chunk can
>>> acknowledge all of the received DATA chunks, and SHUTDOWN chunk is  
>>> discard
>>> in SHUTDOWN-RECEIVED state.
>>>
>>> We need to fix RFC4960, either force to send SACK in SHUTDOWN-SENT  
>>> state
>>> or accept the SHUTDOWN in SHUTDOWN-RECEIVED state. (The current code
>>> is force send SACK)
>>>
>>>
>>>>
>>>>
>>>>> -vlad
>>>>>
>>>>> Wei Yongjun wrote:
>>>>>
>>>>>
>>>>>> If SHUTDOWN is received in SHUTDOWN-PENDING state, enpoint  
>>>>>> should enter
>>>>>> the SHUTDOWN-RECEIVED state and check the Cumulative TSN Ack  
>>>>>> field of
>>>>>> the SHUTDOWN chunk (RFC 4960 Section 9.2). If the SHUTDOWN  
>>>>>> chunk can
>>>>>> acknowledge all of the send DATA chunks, SHUTDOWN-ACK should be  
>>>>>> sent.
>>>>>>
>>>>>> But now endpoint just silently discarded the SHUTDOWN chunk.
>>>>>>
>>>>>> SHUTDOWN received in SHUTDOWN-PENDING state can happend when  
>>>>>> the last
>>>>>> SACK is lost by network, or the SHUTDOWN chunk can acknowledge  
>>>>>> all of
>>>>>> the received DATA chunks. The packet sequence(SACK lost) is  
>>>>>> like this:
>>>>>>
>>>>>> Endpoint A                       Endpoint B       ULP
>>>>>> (ESTABLISHED)                    (ESTABLISHED)
>>>>>>
>>>>>>              <-----------      DATA
>>>>>>                                            <--- shutdown
>>>>>>                                Enter SHUTDOWN-PENDING state
>>>>>> SACK         ----lost---->
>>>>>>
>>>>>> SHUTDOWN(*1) ------------>
>>>>>>
>>>>>>              <-----------      SHUTDOWN-ACK
>>>>>>
>>>>>> (*1) silently discarded now.
>>>>>>
>>>>>> This patch fix to handle SHUTDOWN in SHUTDOWN-PENDING state as  
>>>>>> the same
>>>>>> as ESTABLISHED state.
>>>>>>
>
>