Subject: RE: [Tsvwg] Source IP address Control

From: "Khan, Mohammad" <[email-masked]>
Date: Wed, 24 Apr 2002 04:09:21 -0700

Hi Jacob,
As u said "you cannot expect your peer to know that A is down and therefore
expect
him to send the SACK to B". Through heartbeats peer is knowing that A is
down and what extra it has to do is to check the status of the address on
which it is sending SACK if it is down it has to send the SACK to another
address of the same association which is alive. As far as piggybacking the
data with sack is concerned offcourse sending SCTP shall send it to the
locally know alive address of the peer.  
Regards
kashif

-----Original Message-----
From: Jacob Heitz [mailto:[email-masked]]
Sent: Wednesday, April 24, 2002 10:21 AM
To: Khan, Mohammad
Cc: [email-masked]'; Pillai, Hari
Subject: Re: [Tsvwg] Source IP address Control

I don't think it is illegal, but why would you want
to do this ?

If your peer receives a data chunk with source address
A, he will, with high probability, send a SACK back to
address A. He may SACK to another address, for example,
if he has his own DATA to send and piggybacks a SACK
on it. You should accept a SACK to any address belonging
to your endpoint. The main point is that you cannot
expect your peer to know that A is down and therefore expect
him to send the SACK to B. He MAY do this, but you cannot
expect that he will.

"Khan, Mohammad" wrote:
> 
> Hi All,
> One concern i have regarding SCTP source address control.
> Can we keep the IP header source address of an outgoing sctp packet as one
> which is down and this is known to peer through heartbeats
> 1)Should peer discard this data it receives from down interface address.
> 2)Should peer check the state of the peer address it is sending SACK,
> HEARTBEAT-ACK, INIT-ACK and COOKIE-ACK.
> 
> Motive of doing this is implementation of Dynamic IP address modification
> when i don't know the status of local interface IP address and one node
e.g.
> has four interface IP address A, B, C and D. One Endpoint E1 is using IP
> addresses A , B, C and D and has opened an association A1 which has source
> IP addresses A and B. If  I open IP_ANY socket for all the addresses on
this
> host and SCTP sends some data to the peer on association A1with source
> address as A but even if A is down IP kernal shall send this packet out
> through some other interface keeping header IP source address unchanged to
> the network and the peer would receive the data but peer is knowing that
> this interface A is down. Is it legal.
> 
> Regards
> kashif khan
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg

-- 
// Jacob Heitz. Tel:510-747-2917

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Jacob Heitz <[email-masked]>
Date: Wed, 24 Apr 2002 07:31:14 -0700

Are you trying to add a requirement to SCTP like this:

  If an endpoint knows that a transport address of a peer
  endpoint is down, then it MUST send SACK to a different
  address if one is available.

?

Best of luck to you.

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Wed, 24 Apr 2002 12:22:07 -0400 (EDT)

Hi Mohammad,

I haven't followed this thread carefully. So, if I have missed something
let me know.

I think there is a flaw in your argument. If A is down, the peer may
notice that HBs are not being acked, but the peer may not realize yet that
A is down. So until Path.Max.Retrans is reached, the peer still
considers A to be up. Hence, the peer may very well send the SACK to A.

Now, if Path.Max.Retrans has been reached, then the peer DOES knows that A
is down. However, as Jacob pointed out, you are attempting to add an
additional requirement to the protocol by requiring that the peer send the
SACK to B.

~armando

0--                                                --0
| Armando L. Caro Jr.     |       [email-masked] |
| University of Delaware  |  www.cis.udel.edu/~acaro |
0--                                                --0

---

From: Randall Stewart <[email-masked]>
Date: Wed, 24 Apr 2002 15:43:28 -0500

Armando:

I don't see this as a needed requirement... it is just an implementation
decision on how they wish to handle SACK's.

I know one of the things we did when we did the FreeBSD work
is make it so that if you see a duplicate packet you send the
SACK to an alternate.. i.e. not return it to where the Data Chunk came
from but pick an alternate.. We also do the same thing once
the destination (that was the src of the Data chunk) is marked
unreachable (by hitting its threshold). 

Now I would be opposed to making this a requirement... It can
be a smart thing to do if you are implementing but I don't see
the need for it to be a requriment...

In fact there may well be other reasons which we have not thought
about where you WOULD NOT want to do what I did in our implementation.

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Wed, 24 Apr 2002 17:16:04 -0400 (EDT)

> decision on how they wish to handle SACK's.

I just thought from what I read that they wanted the peer to act a
particular way based on what they were doing. Expecting certain behavior
from your peer is basically making it a requirement. But like I said
before, I didn't read the thread carefully... so I may have missed
something.

> the need for it to be a requriment...

I agree.

> about where you WOULD NOT want to do what I did in our implementation.

maybe.

~armando

0--                                                --0