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

From: Randall Stewart <[email-masked]>
Date: Sun, 10 Jun 2007 08:05:02 -0400

Ash:

 From the BIS:
  (section 6.4)

    However, when acknowledging multiple DATA chunks received in packets
    from different source addresses in a single SACK, the SACK chunk may
    be transmitted to one of the destination transport addresses from
    which the DATA or control chunks being acknowledged were received.

    When a receiver of a duplicate DATA chunk sends a SACK to a multi-
    homed endpoint it MAY be beneficial to vary the destination address
    and not use the source address of the DATA chunk.  The reason being
    that receiving a duplicate from a multi-homed endpoint might indicate
    that the return path (as specified in the source address of the DATA
    chunk) for the SACK is broken.

    Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
    retransmit a chunk that timed out to an active destination transport
    address that is different from the last destination address to which
    the DATA chunk was sent.

Note that I think your issue is an implementation problem.. I know the
BSD implemenation does the following:

a) When it receives data it trys to send the sack to where the
    data came from (source address of data).. per the RFC

b) If it sees a duplicate data chunk, it tries to change the
    src address (if possible) to a alternate.

Of course there is advice in the RFC (above) but there is
no mandate..

R

ash kat wrote:
> 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,
> 
>     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.
>      >
>      > devayya wrote:
>      > 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
>      > >
>      > > (it's updated for today's economy) at Yahoo! Games.
>      > >
>      > >
>      > >
>      >
>     ----------------------------------------------------------------------
>      > --
>      > >
>      > > _______________________________________________
>      > > Sigtran mailing list
>      > > [email-masked]
>      > > https://www1.ietf.org/mailman/listinfo/sigtran
>      >
>      >
>      > Got a little couch potato?
>      > Check out fun summer activities for kids.
> 
> 
> ------------------------------------------------------------------------
> You snooze, you lose. Get messages ASAP with AutoCheck 
> <http://us.rd.yahoo.com/evt=47959/*http://advision.webevents.yahoo.com/mailbeta/newmail_html.html>
> in the all-new Yahoo! Mail Beta.

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)