Subject: RE: [Tsvwg] question: addip-sctp draft

From: [email-masked]
Date: Fri, 30 Mar 2001 09:52:04 +0300

Hi!

	I also had some trouble to understand it at the beginning. I already
asked and proposed this text below, and Randall accepted it, so I hope that
it means the same that is written in the draft ;-)

   "D6) An endpoint MUST NOT send a REL-REQ chunk from a source address
        (of the IP packet containing the SCTP packet) that is asked to be
        deleted inside that REL-REQ chunk."

	Hope it helps!

	BR Iván Arias Rodríguez

> -----Original Message-----
> From: ext Armando L. Caro Jr. [mailto:[email-masked]]
> Sent: 30. March 2001 4:11
> To: [email-masked]
> Subject: [Tsvwg] question: addip-sctp draft
> 
> 
> I am having a hard time understanding the following item in 
> section 4.1:
> 
> D6) An endpoint MUST NOT use the source address (of the IP packet
>     containing the SCTP packet) for a REL-REQ to delete an IP 
> address from
>     the address being deleted.
> 
> Can anyone please explain to me what it means?
> 
> Thanks,
> Armando
> 
> --------------------------------------------------------------
> ---------
> Armando L. Caro Jr.                                  
> [email-masked]
> University of Delaware                   
> http://www.cis.udel.edu/~acaro
> --------------------------------------------------------------
> ---------
> 
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg
> 

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

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Fri, 30 Mar 2001 12:37:23 -0500 (EST)

Ivan,

It does help, thanks. I *thought* that is what the draft was trying to
say, but the sentence just didn't make sense to me.

Ok, so if that is what it means... my question now is why? If there is a
request to delete the IP address which is the source address for this
request, can't the ack for the request simply be sent back to another IP
which is valid in the association?

in other words...

 --------                                                        --------
| HOST A |							| HOST Z |
|        | 		[src x	dst u [DEL IP x]]		|        |
| IP x   | ---------------------------------------------------->| IP u   |
| IP y   |							| IP v   |
 -------- 							 --------

 --------                                                        --------
| HOST A |							| HOST Z |
|        | 		[src u	dst y [ACK(DEL IP x)]]		|        |
| IP x   | <--------------------------------------------------- | IP u   |
| IP y   |							| IP v   |
 -------- 							 --------

>         deleted inside that REL-REQ chunk."

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

---

From: Janardhan Iyengar <[email-masked]>
Date: Fri, 30 Mar 2001 12:55:24 -0500 (EST)

> which is valid in the association?

I had the same Q in mind but I don't know if it even matters that the ACK
be sent to another IP. The deletion is  done only after the DEL IP ACK
gets back. The Q would be valid even if the ACK is sent back to the same
IP.

So, my Q is - why is the following not acceptable?

> | IP x   | -------------------------------------------------->| IP u   |
> | IP y   |							| IP v   |
>  -------- 							 --------
>
>  --------                                                      --------
> | HOST A |							| HOST Z |
> |        | 		[src u	dst x [ACK(DEL IP x)]]		|        |
> | IP x   | <------------------------------------------------- | IP u   |
> | IP y   |							| IP v   |
>  -------- 							 --------

regards,
Jana

Deliver yesterday, code today, think tomorrow.
if [ -z "$IDEAS" ]; then cd /pub ; more beer ; fi

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 30 Mar 2001 12:16:36 -0600

Armando,

This is the alternative way of doing it and it may be easier to
implement because it is normally easier to control which destination
address to send a packet to than which source address to appear in an
outbound IP packet. This is a tricky thing to do especially when the
implementation is sitting in the user space.

But the original approach has other motivations behind it, which is to
prevent the initiator from deleting its only IP address. The original
approach is also intended to preserve the consistency of the "ack back
to where the packet came from" handling principle of the receiver.

regards,
-Qiaobing

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Fri, 30 Mar 2001 14:41:46 -0500 (EST)

> implementation is sitting in the user space.

ok, this part makes sense, but i am not sure how this is relevant.

> prevent the initiator from deleting its only IP address.

i understand wanting to NOT delete your last IP address, but this is a
separate point altogether which is covered in the draft. anyway, who says
that the source address is necessarily the last? in my example, host A has
2 ip addresses it can use. so unless u are deleting the last ip address,
deleting the source should be fine.

> The original

two questions:

1. why should the "ack go back to where the packet came from" ??

2. as jana pointed out, the ack should still be able to go back to where
the packet came from. the sending host (host a) does not delete the
address until it receives the ack. therefore, the ack will be received
just fine if addressed to the deleted ip address. am i missing something
here??

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 30 Mar 2001 14:40:22 -0600

> ok, this part makes sense, but i am not sure how this is relevant.

Yes, it is. For example, if you have sctp running in user space and you
have addr A and B on your local host, then what system call or socket
opt allows you to exclude, say, addr B from appearing in your next
out-going IP packet? 

> deleting the source should be fine.

When you have only one addr existing or left, all your outbound packets
WILL carry this addr as the source addr, the original rule effectively
prevents you from doing a delete on this addr, unless you deliberately
want to violate it. 

> 1. why should the "ack go back to where the packet came from" ??

This is in RFC2960 and applies to INIT ACK, HB ACK, SHTDWN ACK... and
SACK whenever possible.

> just fine if addressed to the deleted ip address. am i missing something

This is a valid point.

-Qiaobing