RE: SACK from a multihomed endpoint.

Hi Ashwani, 

 

As the RFC 2960 saying 

"An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,

   etc.) to the same destination transport address from which it

   received the DATA or control chunk to which it is replying.  This

   rule should also be followed if the endpoint is bundling DATA chunks

   together with the reply chunk." 

 

This is for the destination address, but for the source address it is
silent. My view is the same should also be followed for the source
address. The problem of if the peer is multi-homed will not arise as RFC
is very clear about the destination address. 

 

I request to others also to provide their view on the same. 

 

Thanks,

Salil

 

 

________________________________

From: ash kat [mailto:[email protected]] 
Sent: Wednesday, May 30, 2007 10:17 AM
To: [email protected]; [email protected]
Subject: [Sigtran] 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
<http://us.rd.yahoo.com/evt=48223/*http:/get.games.yahoo.com/proddesc?ga
mekey=monopolyherenow>  (it's updated for today's economy) at Yahoo!
Games.

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