Subject: Re: I-D ACTION:draft-coene-multi6-sctp-00.txt

From: "Randall R. Stewart (home)" <[email-masked]>
Date: Wed, 25 Feb 2004 07:25:17 -0600

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:[email-masked]]
>>>>> Sent: zaterdag 21 februari 2004 19:29
>>>>> To: [email-masked]
>>>>> 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)