SACK from a multihomed endpoint.

Hello All
   
  I have a query related to sending the SACK from a multihomed endpoint.
   
  1. There is an association between endpoint-1 and endpoint-2.
2. Endpoint-1 has 2 IP address ( IP-1, IP-2) while endpoint-2 has only one IP address (IP-3).
3. IP-1 is the primary IP address of the Endpoint-1.
4. Endpoint-2 sends the DATA from IP-3 to IP-2.
5. As the RFC does not mandate to send the SACK from the destination address of the DATA so Endpoint-1 is sending the SACK from it's primary IP ( IP-1).
6. Now due to the problem in IP-1 network, or due to some other reasons, the SACK is dropped in the network.
7. Endpoint-2 will retransmit the DATA on both the paths i.e, From IP-3 to IP-2 and  also from IP-3 to IP-1.
8. But as Endpoint-1 point one is sending the SACK always from the IP-1 so it will never reach the Endpoint-2.
 As SCTP RFC 2960 does not suggest anything related to the source address of the replay chunks so the above behavior (point-8) is true.
9. Now, after assoc.max.retrans the Endpoint-2 will send the ABORT to Endpoint-1 and the association will be down even there was one path available.
   
  My concerns is that - as RFC does not cover this kind of situation so what should be the behavior of stack.
  
IMO either 
a] The SACK should be sent from the same address from which the DATA is coming.
or
b] When the duplicate DATA chunks are received then the source address of the SACK should also be changed.
   
  Currently RFC recommend to change only the destination address of the SACK in such cases, but as we have only one destination address so that wouldn't help.
Hence, we have to change the source address also as suggested in point [b] above.
   
  The similar problem will appear if the peer also is multihomed.
   
  So I would request you to provide your valuable suggestions and if RFC covers such scenario then please provide the related section reference.
   

       
---------------------------------
Boardwalk for $500? In 2007? Ha! 
Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.

_______________________________________________
Sigtran mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sigtran