Subject: [Tsvwg] Re: [Sigtran] SACK from a multihomed endpoint.

From: devayya <[email-masked]>
Date: Wed, 30 May 2007 16:17:17 +0530

Ashwani,

I think when the Endpoint-1 detects problem in sending the SACK, the 
Endpoint-1 should have detected the path failure by retransmitting 
HEARTBEAT and not getting HEARTBEAT ACK and subsequently should have 
changed the primary path to IP address IP-2.

Best regards.

Salil Agrawal wrote:
> 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-masked]]
> Sent: Wednesday, May 30, 2007 10:17 AM
> To: [email-masked]; [email-masked]
> 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?gamekey=monopolyherenow> 
> (it's updated for today's economy) at Yahoo! Games.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Salil Agrawal" <[email-masked]>
Date: Wed, 30 May 2007 10:31:22 +0530

Hi Ashwani, 

As the RFC 2960 saying 

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

   together with the reply chunk." 

Thanks,

Salil

________________________________

Hello All

IMO either 

  

________________________________

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.

---

From: ash kat <[email-masked]>
Date: Wed, 30 May 2007 07:24:28 -0700 (PDT)

Hello Devayya,
   
  As the Endpoint-1 is continuously receiving the DATA from endpoint-2 ( IP-3 ), so it will not send the HeartBeats to this address (IP-3).
  and as a result of this, the Endpoint-2 will retransmit the data assoc.max.retrans times and will ABORT the association.
   
  Regards,
  Ashwani Kathuria.

devayya <[email-masked]> wrote:
  Ashwani,

Best regards.

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

---------------------------------
Got a little couch potato? 
Check out fun summer activities for kids.

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 30 May 2007 16:39:41 +0200

Hi,

please note that you can not conclude from receiving packets from  
IP-3 that you are able
to send packets to IP-3. Paths can be asymmetric. Therefore you can  
not disable sending
HEARTBEATs.

Best regards
Michael

On May 30, 2007, at 4:24 PM, ash kat wrote:

> Hello Devayya,
>
> As the Endpoint-1 is continuously receiving the DATA from  
> endpoint-2 ( IP-3 ), so it will not send the HeartBeats to this  
> address (IP-3).
> and as a result of this, the Endpoint-2 will retransmit the data  
> assoc.max.retrans times and will ABORT the association.
>
> Regards,
> Ashwani Kathuria.
>

---

From: ash kat <[email-masked]>
Date: Wed, 30 May 2007 08:23:56 -0700 (PDT)

Hello Michael
   
  Thanks for correcting me.
   
  One more doubt.
   
  let us say if Endpoint-1 has detected a path with the peer endpoint-2 as down.
and after that it starts receiving data on the same path from the endpoint-2. so it will not mark that path UP until it receives some HB-ACK or SACK from peer on that path.
So, my question is that - when a path is down, does in that state also an endpoint-1 can send SACK for the DATA received on that path from endpoint-2.
   
  Also reframing my first Qsn. wrt above correction.
   
  When there are 2 endpoints EP-1 and EP-2
EP-1 has IP-1 and IP-2. EP-2 has IP-3
So there are 3 path 
PATH-1 ( IP-1 , IP-3 )
PATH-2 ( IP-2 , IP-3 )
   
  EP-2 is sending DATA on PATH_2. But as EP-1 has PATH-1 as primary so it will send the SACK via PATH-1
==== RFC does not mandate about the source address of the SACK chunk ====
   
  Now let us suppose, the Heartbeats were going fine on both the paths, from both the Endpoints. 
However, just before sending the SACK the PATH-1 faces some problem.
BUT, before the EP-1 detects this problem ( or DOWN PATH-1) via Heartbeat, the Assoc.Max.retrans of EP-2 are over and it marked the EP-2 as DOWN.
So, what could be done in this case??
   
  If there is some recommendation in SCTP RFC about changing the source address of the SACK or sending SACK from the same address on which DATA arrives then this problem could be solved.
   
  I may be missing out something and please correct me where ever I am wrong. Also provide your valuable suggestions.
   
  Regards,
  Ashwani Kathuria.

Michael Tuexen <[email-masked]> wrote:
  Hi,

Best regards
Michael

On May 30, 2007, at 4:24 PM, ash kat wrote:

> devayya wrote:

---------------------------------
You snooze, you lose. Get messages ASAP with AutoCheck
 in the all-new Yahoo! Mail Beta.