Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
SCTP muli-homed retransmission
4 views
Skip to first unread message
Jeremy Brown
May 14, 2013, 9:49:14 AM5/14/13
to
Firstly, if this is not the correct group, I apologize it seemed the
closest match. My question involves a SCTP multi-homed scenario. It
seems a colleague and I are at a little bit of disagreement.
The scenario begins with retransmitted control chunks before the
association is setup. There are two multi-homed endpoints (a1, a2) ->
(b1,b2). Due to a routing problem b1 is not reachable from a1, but it
is from a2. Also, a1 is reachable from b1 and b2.
The Init is sent out from a1 to b1. This reaches the RTO and then the
stack retransmits out from a2 to b2. This reaches b2 and the INIT-ACK
is sent out to a2, however the source address it is sent from is b1,
not b2 as it has been sent.
The Cookie-echo chunk is then first sent from a1 back to b1. This
times out again, and our stack is not trying to send a retransmit from
a2. It just keeps sending out from a1 until it times out and reaches
the max number of re-transmits.
Now my colleague is trying to say this is expected behavior. Since the
INIT-ACK came from b1, and since b1 is unreachable we should fail
sending, and that the INIT-ACK should have come from b2. Since the
INIT-ACK came from b1, it is perfectly valid to assume b1 is a valid
ip and to just keep trying to send to b1 without trying b2. Since b2
did not respond we should consider b2 invalid.
I whole-heartedly disagree. I say that the specs only say that a reply
must be destined to the remote peer endpoint's transport address of
origination. They do not specify which of the local endpoint's
transport addresses it is sent from. And also, if a1 tries to send the
cookie-echo chunk to b1 and this times out, we must actually try the
secondary transport address b2, similar to how the INIT behaved.
My colleague cited references in the rfc section 5.1 and 5.1.2, but
they only seemed to state how the message is to be routed by
destination, they make no mention of from where the message
originates. And I further cited section 6.4 which specifies that in a
multi-homed scenario if the chunk can not be sent to the first address
we should send to the second.
Anyway, I was I was wondering what insight others had into
interpreting the specs.
closest match. My question involves a SCTP multi-homed scenario. It
seems a colleague and I are at a little bit of disagreement.
The scenario begins with retransmitted control chunks before the
association is setup. There are two multi-homed endpoints (a1, a2) ->
(b1,b2). Due to a routing problem b1 is not reachable from a1, but it
is from a2. Also, a1 is reachable from b1 and b2.
The Init is sent out from a1 to b1. This reaches the RTO and then the
stack retransmits out from a2 to b2. This reaches b2 and the INIT-ACK
is sent out to a2, however the source address it is sent from is b1,
not b2 as it has been sent.
The Cookie-echo chunk is then first sent from a1 back to b1. This
times out again, and our stack is not trying to send a retransmit from
a2. It just keeps sending out from a1 until it times out and reaches
the max number of re-transmits.
Now my colleague is trying to say this is expected behavior. Since the
INIT-ACK came from b1, and since b1 is unreachable we should fail
sending, and that the INIT-ACK should have come from b2. Since the
INIT-ACK came from b1, it is perfectly valid to assume b1 is a valid
ip and to just keep trying to send to b1 without trying b2. Since b2
did not respond we should consider b2 invalid.
I whole-heartedly disagree. I say that the specs only say that a reply
must be destined to the remote peer endpoint's transport address of
origination. They do not specify which of the local endpoint's
transport addresses it is sent from. And also, if a1 tries to send the
cookie-echo chunk to b1 and this times out, we must actually try the
secondary transport address b2, similar to how the INIT behaved.
My colleague cited references in the rfc section 5.1 and 5.1.2, but
they only seemed to state how the message is to be routed by
destination, they make no mention of from where the message
originates. And I further cited section 6.4 which specifies that in a
multi-homed scenario if the chunk can not be sent to the first address
we should send to the second.
Anyway, I was I was wondering what insight others had into
interpreting the specs.
0 new messages