ietf
[Top] [All Lists]

Re: SCTP Path Max Retransmission Query

2011-03-14 06:08:56
On Mar 14, 2011, at 3:36 AM, Will Yu wrote:

Hello dear Michael,

Thank you for your reply. There is an additional query about your reply:
In our realization, the remote address is regarded as unreachable until the 
Heartbeat Message from TWO different local address(IP1 and IP2) exceed PMR. 
It means that IP1 sent 4(PMR value) Heartbeat and IP2 sent 4(PMR value) 
Heartbeat as well. In your describing, is this method not accord with RFC?
The RFC only talks about an error counter per remote address, not an error 
counter per local/remote address pair.

However, you should be able to handle a network setup, where no cross routing 
is possible,
so there is only connectivity between IP1 <-> IP3 and IP2 <-> IP4. This is a 
setup which
is often used in SIGTRAN setups.

Best regards
Michael

Thanks again.

Brs,
Will Yu

2011/3/12 Michael Tüxen 
<Michael(_dot_)Tuexen(_at_)lurchi(_dot_)franken(_dot_)de>

On Mar 11, 2011, at 7:44 AM, Will Yu wrote:

Hello,

I have a query on SCTP standard (RFC 4960). In section 8.2 Path Failure 
Detection, it describes the action which end points should take in 
detecting path unavailable.

   When its peer endpoint is multi-homed, an endpoint should keep an
   error counter for each of the destination transport addresses of the
   peer endpoint.
   Each time the T3-rtx timer expires on any address, or when a
   HEARTBEAT sent to an idle address is not acknowledged within an RTO,
   the error counter of that destination address will be incremented.
   When the value in the error counter exceeds the protocol parameter
   ’Path.Max.Retrans’ of that destination address, the endpoint should
   mark the destination transport address as inactive, and a
   notification SHOULD be sent to the upper layer.

In my case, I connected two end points through four IP address. EP1 owns 
IP1 and IP2, EP2 owns IP3 and IP4. And IP1 is the primary address for EP1, 
while IP3 is the primary address for EP2. There is no other packet in this 
association except with Heartbeat and Heartbeat_ACK.

                IP1--------------------IP3
    End                   \ /                   End
   Point1                 *                   Point2
                             / \
                IP2--------------------IP4

When IP4 is unavailable, the heartbeat messages from IP1 and IP2 with the 
destination IP4 cannot received acknowledgement. In this case, PMR in each 
EP is set to 4. I observed that EP1 used IP1 and IP2 as source address to 
send the heartbeat messages to IP4 respectively. When the heartbeat message 
from source address IP2 exceed 4 times, it marked the path(IP2-IP4) is 
unreachable. And then IP1 exceed, it would mark the destination IP4 is 
unavailable. In my opinion, this result is
There is no state for the path IP2-IP4, only for the remote address IP4.
reasonable with the recognition of IP2-IP4 is a path and IP1-IP4 is another 
path for the association. Consequently, the PMR parameter is for 
determining which PATH could regard as unavailable.
SCTP supervises remote addresses. So EP1 is supervising IP3 and IP4. So there 
is one  error counter for IP3
and one for IP4. There is also only a state per remote IP address. So after 
the error counter for IP4
exceeds PMR, the IP address IP4 should be marked as unreachable.
But in the section 8.2 Path Failure Detection, the increasing counter 
action is based on different destination transport address, not on the 
different source-destination address pair. I think it make me confused that 
counter will impact the result in my case with the assumption RFC regard 
the destination address failure as the critical element for Path Failure 
Detection.

Would you kindly help me clarify the behaviors in Path Failure Detection, 
or figure out if I have any misunderstanding in this case?
As said above, SCTP supervises remote addresses, not paths.

Best regards
Michael

PS: It might be better to send SCTP related questions to 
tsvwg(_at_)ietf(_dot_)org

Brs,
Will Yu
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>