Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.protocols.tcp-ip    |    TCP and IP network protocols.    |    14,669 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 14,010 of 14,669    |
|    Jeremy Brown to All    |
|    SCTP muli-homed retransmission    |
|    14 May 13 06:49:14    |
      45d7bab7       From: bjeremy32@gmail.com              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.              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca