BOUNCE multi6@ops.ietf.org: Non-member submission from ["Randall R. Stewart (home)" <randall@stewart.chicago.il.us>] (fwd)

[Kurtis Lindqvist <kurtis@kurtis.pp.se>]

Approved: dual-stack
From randall@stewart.chicago.il.us Wed Feb 25 13:25:27 2004
Received: from [66.93.186.36] (helo=stewart.chicago.il.us)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1Avz2U-000Pxe-U8
	for multi6@ops.ietf.org; Wed, 25 Feb 2004 13:25:27 +0000
Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1])
	by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id i1PDPHMC064744;
	Wed, 25 Feb 2004 07:25:19 -0600 (CST)
	(envelope-from randall@stewart.chicago.il.us)
Message-ID: <403CA23D.90401@stewart.chicago.il.us>
Date: Wed, 25 Feb 2004 07:25:17 -0600
From: "Randall R. Stewart (home)" <randall@stewart.chicago.il.us>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
CC: multi6@ops.ietf.org, Coene Lode <Lode.Coene@siemens.com>,
   "'Barany, Pete'" <pbarany@qualcomm.com>
Subject: Re: I-D ACTION:draft-coene-multi6-sctp-00.txt
References: <57FD2C3A246F76438CA6FDAD8FE9F195A7F4C2@hrtades7.atea.be> <4B9D73E0-66C6-11D8-AF58-000A95C37894@micmac.franken.de> <403B9E51.1040902@stewart.chicago.il.us> <49AD8793-6700-11D8-A77D-000A95DC192A@micmac.franken.de>
In-Reply-To: <49AD8793-6700-11D8-A77D-000A95DC192A@micmac.franken.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
	version=2.63
X-Spam-Level:

Michael Tuexen wrote:

> Randy,
> see my comments below.
> Best regards
> Michael
>
> On Feb 24, 2004, at 7:56 PM, Randall R. Stewart (home) wrote:
>
>> Michael:
>>
>> I agree, the way Lode describes it is generally correct... but an
>> implementation MAY not follow this .. one never knows :->
>>
> That's why I wrote 'there is room for implementations'.
>
>> I believe KAME does as Lode describes.. however I can't
>> rememeber how I coded the "Unconfirmed" address case. Either
>> I thus consider it "confirmed" or refuse to send to it :-D... its
>> the CRS syndrom ... I will look into this when I get a few cycles
>> to see how I did it :-D
>
> I remember that you said that you would handle this as an
> implicit 'confirmation', like using connect_x and then send it.
> But I do not know if this is what the code does...


Well.. I looked at the code... and basically
You get a confirmed address by:

1) Using connect_x() - all addresses
2) Using connect() - the single address
3) Having a HB return to you with correct magic numbers (random stuff).
4) Getting a data chunk acknowledged that was sent to a unconfirmed
    address and WAS NOT retransmitted.

The primary can NEVER be set to an UNCONFIRMED address. However
if you send to an address that is UNCONFIRMED with the message
override.. I will send the data. ... this does NOT however mark the
address as CONFIRMED... you don't get that to happen until that
data gets acknowledged.

R

>
>>
>> R
>>
>> Michael Tuexen wrote:
>>
>>> Dear all,
>>>
>>> the way Lode describes it is OK. However, there is some
>>> room for implementations...
>>>
>>> Best regards
>>> Michael
>>>
>>> On 24. Feb 2004, at 10:28 Uhr, Coene Lode wrote:
>>>
>>>> I am not a specialist on socket issues.. But Michael & Randall
>>>> might know a
>>>> bit more on that...
>>>>
>>>>> -----Original Message-----
>>>>> From: Barany, Pete [mailto:pbarany@qualcomm.com]
>>>>> Sent: zaterdag 21 februari 2004 19:29
>>>>> To: multi6@ops.ietf.org
>>>>> Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt
>>>>>
>>>>>
>>>>> In the SCTP sockets API Internet draft
>>>>> (draft-ietf-tsvwg-sctpsocket-07.txt), there is a sendmsg() flag
>>>>> (MSG_ADDR_OVER) for the one-to-many style that allows the
>>>>> application to
>>>>> request that the SCTP stack override the primary destination
>>>>> address. Do
>>>>> implementations honor (mandatory) this request, or can the SCTP stack
>>>>> override it? Thanks.
>>>>
>>>>
>>>>
>>>> My take is:
>>>> The implementation must send the msg on the IP address provided
>>>> instead of the primary destination address.
>>>> But if the address provided by the application is not reachable at
>>>> that
>>>> particular moment, then the SCTP implementation will try any of the
>>>> alternative addresses of the association(including the primary
>>>> destination
>>>> address)
>>>>
>>>>>
>>>>> Pete
>>>>>
>>>>
>>>> Yours sincerely,
>>>> Lode
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> Randall R. Stewart
>> 815-477-2127 (office)
>> 815-342-5222 (cell phone)
>>
>>
>>
>
>
>


-- 
Randall R. Stewart
815-477-2127 (office)
815-342-5222 (cell phone)