Re: Gap is only retransmitted once

[Shan Wei <shanwei@cn.fujitsu.com>]

Mingyuan Zhu wrote, at 02/18/2011 10:04 PM:
> Is it probably a lksctp usage issue or kinda bug of lksctp?
> I read some source code of lksctp-test and didn't find related test
> cases. Did someone test this scenaria before?

I have just tested it like following:
H2 is the tested Linux with latest kernel 2.6.37.
and it can retransmit again and again.

H1                 H2(2.6.37kernel)
     
   <--------------- D1
   <--------------- D2
   <--------------- D3
   <--------------- D4

  SACK(ACKÑ,gap_start=2,gap_end=2)
  --------------->

  <--------------- D5
  
  SACK(ACKÑ,gap_start=2,gap_end=3)
  --------------->

  <--------------- D2(retransmitted!!)

  SACK(ACKÑ,gap_start=2,gap_end=4)
  --------------->

  <--------------- D2(retransmitted Again!)

  SACK(ACKÑ,gap_start=2,gap_end=4)
  --------------->

  <--------------- D2(retransmitted Again!!)


> 
> Great appreciate if you could provide some information.
> 
> 2011/2/17 Mingyuan Zhu <liyha.zhu@gmail.com>:
>> Please see the result below. Can you give any suggestion from below information?
>>
>> #cat /proc/net/sctp/assocs
>>  ASSOC     SOCK   STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE
>> LPORT RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC
>> ffff880206882000 ffff8801f36be0c0 2   1   4  37699    1     2710
>>  0       0 580897 2944   4944  *169.254.64.6 <-> *192.168.4.103
>>   2500     4     4   10    0    0        0
>>
>> #cat /proc/net/sctp/remaddr
>> ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX REM_ADDR_RTX  START
>> 192.168.4.103  1 1 750 5 0 0
>>
>> #sysctl -a | grep max_retrans
>> net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
>> net.netfilter.nf_conntrack_tcp_max_retrans = 3
>> net.sctp.association_max_retrans = 10
>> net.sctp.path_max_retrans = 5
>>
>>
>> 2011/2/16 Mingyuan Zhu <liyha.zhu@gmail.com>:
>>> I will rerun the test case to get the other two info:
>>> # cat /proc/net/sctp/assocs
>>> # cat /proc/net/sctp/remaddr
>>>
>>>
>>> msw12:~ # sysctl -a | grep max_retrans
>>> net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
>>> net.netfilter.nf_conntrack_tcp_max_retrans = 3
>>> net.sctp.association_max_retrans = 10
>>> net.sctp.path_max_retrans = 5
>>>
>>>
>>> 2011/2/16 Vasil Velichkov <vasil.velichkov@opencode.com>:
>>>> On 15.02.2011 15:58, Mingyuan Zhu wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> I have observed a problem while doing load testing on SCTP. The tested
>>>>> equipment is an open suse linux box with 2.6.34 kernel. The
>>>>> application of the equipment will send/receive messages through linux
>>>>> kernel sctp. The peer is an equipment using Aricent sctp stack.
>>>>>
>>>>> During the load testing, the peer equipment drops sctp chunks and
>>>>> reports gaps through SACK to the tested equipment.
>>>>>
>>>>> The tested equipment (Linux box) retransmitts the missing chunks. But
>>>>> it always retransmit the same #TSN only once even it receives more
>>>>> SACKs with the reporting gap.
>>>>>
>>>>>  From the ethereal captures:
>>>>>
>>>>> - TSN 2254147468 is not received by the peer equipment, so it reports
>>>>> the gap by SACK.
>>>>>
>>>>> - Linux box retransmit TSN 2254147468.
>>>>>
>>>>> - The peer still does not get it. It reports the gap by SACK again and
>>>>> again.
>>>>>
>>>>> - Linux box never retransmit the missing chunk again.
>>>>>
>>>>> - Finally, neither linux box nor the peer can send/receive any more
>>>>> chunks.
>>>>>
>>>>>
>>>>>
>>>>> Could someone help to look at the problem? Any help would be highly
>>>>> appreciated!
>>>>> --
>>>>> 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
>>>>>
>>>>>
>>>>
>>>> Hi Mingyuan Zhu,
>>>>
>>>> On the Linux box, check whether net.sctp.path_max_retrans(MAX_PATH_RTX) or
>>>> net.sctp.association_max_retrans(MAXRT) parameters are set to 1.
>>>>
>>>> # cat /proc/net/sctp/assocs
>>>>  ASSOC     SOCK   STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE LPORT
>>>> RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC
>>>> f2876000 f35ee1c0 2   1   4  38050    1        0        0       0 6429275
>>>> 2975   2985  *127.0.0.1 <-> *127.0.0.1            5000    32    32    5    0
>>>>    0        0
>>>> f444c800 e8407c00 2   1   4  41620    2        0        0     500 6429276
>>>> 2985   2975  *127.0.0.1 <-> *127.0.0.1            5000    32    32    5    0
>>>>    0        0
>>>>
>>>> # cat /proc/net/sctp/remaddr
>>>> ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX REM_ADDR_RTX  START
>>>> 127.0.0.1  1 1 1000 5 0 0
>>>> 127.0.0.1  2 1 1000 5 0 0
>>>>
>>>> # sysctl -a | grep max_retrans
>>>> net.sctp.association_max_retrans = 10
>>>> net.sctp.path_max_retrans = 5
>>>>
>>>> BR
>>>> Vasil Velichkov
>>>>
>>>
>>
> --
> 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
> 


-- 

Best Regards
-----
Shan Wei