home bbs files messages ]

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