Date: Sun, 01 May 2011 13:10:48 +0200 From: Schoch Christian <e0326715@student.tuwien.ac.at> To: Michael =?iso-8859-1?b?VPx4ZW4=?= <Michael.Tuexen@lurchi.franken.de> Cc: freebsd-net@freebsd.org Subject: Re: [SCTP] ICMP unreachable message reenables data transmit Message-ID: <20110501131048.22413db5jyxywss8@webmail.tuwien.ac.at> In-Reply-To: <F4802366-A9B4-4515-8E6D-E5C80C06408B@lurchi.franken.de> References: <20110430091148.31393q3py4j4bg38@webmail.tuwien.ac.at> <FD1FC82D-29D1-4186-A0AC-504653C28D85@lurchi.franken.de> <20110430121518.25761cpmtrp0jtpy@webmail.tuwien.ac.at> <F4802366-A9B4-4515-8E6D-E5C80C06408B@lurchi.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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@freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>>>>
>>>
>>> _______________________________________________
>>> freebsd-net@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>>>
>>
>>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110501131048.22413db5jyxywss8>