[SCTP] ICMP unreachable message reenables data transmit

[Schoch Christian]

> On Apr 30, 2011, at 12:15 PM, Schoch Christian wrote:
>>
>>> On Apr 30, 2011, at 9:11 AM, Schoch Christian wrote:
>>>
>>>> During a measurement with CMT-SCTP and PF i figured out, that  
>>>> sometimes a ICMP Destination unreachable message triggers a  
>>>> message transmission on an inactive data path that has been  
>>>> primary before.
>>>>
>>>> It looks as the ICMP message is reseting the inactive state back  
>>>> to active without reseting RTO.
>>>>
>>>> This behavior is triggered by a returning heartbeat message when  
>>>> no ICMP unreachable by data is sent quite before.
>>>>
>>>> Test system are two multi-homed hosts with FreeBSD8.1 and a WANem  
>>>> host between.
>>>>
>>>> A wireshark log can be provided on demand (quite large).
>>> Hi Christian,
>>>
>>> any chance to upgrade the FreeBSD machines to head or to use newer
>>> SCTP sources, which I could provide? It would require a recompilation
>>> of the kernel...
>>
>> It is possible, but the results could be provided not until next week
>> if a reboot is necessary.
>> I can use any sources you could provide me since nothing else is  
>> done at this systems.
> OK, but maybe I can try to understand what is going on.
>
> How many paths do you have? One is inactive, but was primary, so it
> is confirmed. On another one, you get an ICMP (which one? Port unreachable,
> host unreachable, ...). Do you have more than two paths?

Setup looks like this:

       --------     ----cut---
Host A        WANem          Host B
       --------     ----------

Transfer is running on both path from A to B till the primary link is  
cut between WANem and the receiver and the whole transfer switches to  
the second path. The ICMP message (Host not reachable with a Heartbeat  
as attachment) is received on the primary interface from WANem host.

As I tested this morning, the primary path is switching to unreachable  
due to the ICMP message but should be in this state quite before by  
exceeding path.max_retrans.
So this ICMP message does two things:
- Set the primary path to unreachable
- Triggers something to retry data transfer on the primary path.

> The ICMP message would not reset the RTO, since you need an ACKed TSN
> or a HB-ACK to to that. Since it is inactive, it is missing these.
>
> Sending on an inactive path is OK, as soon as you enter the dormant
> state, which means all your paths are inactive.
>
  Transfer is still running on second link which is active.

> Are you using the PF support for CMT?

Yes, but without NR-SACK and DAC.

I uploaded the pcap file to:
http://37116.vs.webtropia.com/cmt_2.pcap

Best regards,
Christian

>
> Best regards
> Michael
>>
>>>
>>> Are you using IPv4 or IPv6?
>>>
>>
>> IPv4
>>
>>
>>> Best regards
>>> Michael
>>>>
>>>> Regards,
>>>> Schoch Christian
>>>> _______________________________________________
>>>> freebsd-net at freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>>>
>>>
>>> _______________________________________________
>>> freebsd-net at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>>
>>
>>
>
>