Re: [PATCH net-next-2.6 v4 4/5] sctp: Add ASCONF operation on the single-homed host

[Wei Yongjun <yjwei@cn.fujitsu.com>]

> Yes, I think the association cannot be kept, if the single-homed ASCONF receiver moves to the new network before sending ASCONF-ACK.  
> Am I missing?

Oh, yeah, you are right.:-)

> Thanks,
> - Michio
>
> On Apr 25, 2011, at 11:02 , Wei Yongjun wrote:
>
>>> Hi, 
>>>
>>> Such operation would not be supported by specification, in Sec.5.3 in RFC 5061:
>>>   F1)  When adding an IP address to an association, the IP address is
>>>        NOT considered fully added to the association until the ASCONF-
>>>        ACK arrives.  This means that until such time as the ASCONF
>>>        containing the add is acknowledged, the sender MUST NOT use the
>>>        new IP address as a source for ANY SCTP packet except on
>>>        carrying an ASCONF Chunk. 
>>>
>>> I think this means we cannot send ASCONF-ACK from the new address even if it bundles ASCONF...
>> If so, both side do not have valid address to send the such
>> ASCONF-ACK, and can not recv ASCONF-ACK.
>>
>>> - Michio
>>>
>>> On Apr 25, 2011, at 9:57 , Wei Yongjun wrote:
>>>
>>>>> On Apr 22, 2011, at 13:10 , Wei Yongjun wrote:
>>>>>
>>>>>>> Since the sender MUST NOT use the  new IP address as a source for ANY SCTP
>>>>>>> packet except on  carrying an ASCONF Chunk. And ASCONF chunk can be bundled.
>>>>>>> How about this change. If so, you do not need change to sctp_outq_tail();
>>>>>>>
>>>>>>> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
>>>>>>> index 1c88c89..bd6cc9c 100644
>>>>>>> --- a/net/sctp/outqueue.c
>>>>>>> +++ b/net/sctp/outqueue.c
>>>>>>> @@ -754,6 +754,13 @@ static int sctp_outq_flush(struct sctp_outq *q, int rtx_timeout)
>>>>>>> 	 */
>>>>>>>
>>>>>>> 	list_for_each_entry_safe(chunk, tmp, &q->control_chunk_list, list) {
>>>>>>> +		/* RFC 5061, 5.3
>>>>>>> +		 * F1) This ...
>>>>>>> +		 */
>>>>>>> +		if (q->asoc->src_out_of_asoc_ok &&
>>>>>>> +		    chunk->chunk_hdr->type != SCTP_CID_ASCONF)
>>>>>> SCTP_CID_ASCONF_ACK should be also allowed, the peer may
>>>>>> send ASCONF to do the same thing at the same time.
>>>>> Sorry for my bad understanding, 
>>>>> Do you mean the situation: "the peer (ASCONF receiver) may send ASCONF-ACK to the unconfirmed destination"?
>>>>> Or do you mean following situation?
>>>>> 1. the pear sends ADD/DEL ASCONF to me, 
>>>>> 2. I receive it, 
>>>>> 3. I migrate to the other network and get new address, 
>>>>> 4. I send ASCONF-ACK to the peer from the new address
>>>> Yes, If both side send ADD/DEL ASCONF to del the last one
>>>> address at the same time like this:
>>>>
>>>> ASCONF  -----    ------ASCONF
>>>> (ADD/DEL)    \  /     (ADD/DEL)
>>>>             \/        
>>>>             /\
>>>>       <----/  \----->
>>>> ASCONF-ACK---\  /------ASCONF-ACK
>>>>             \/
>>>>             /\
>>>>       <----/  \----->
>>>>
>>>> But I do not test for it. Not sure we need to do this, can you
>>>> check this before commit your new patchset?
>>>>
>>>>
>>>>>>> +			continue;
>>>>>>> +
>>>>>>> 		list_del_init(&chunk->list);
>>>>>>>
>>>>>>> 		/* Pick the right transport to use. */
>>>>>>> @@ -881,6 +888,9 @@ static int sctp_outq_flush(struct sctp_outq *q, int rtx_timeout)
>>>>>>> 		}
>>>>>>> 	}
>>>>>>>
>>>>>>> +	if (q->asoc->src_out_of_asoc_ok)
>>>>>>> +		goto sctp_flush_out;
>>>>>>> +
>>>>>>> 	/* Is it OK to send data chunks?  */
>>>>>>> 	switch (asoc->state) {
>>>>>>> 	case SCTP_STATE_COOKIE_ECHOED:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>