Subject: [Tsvwg] Problem with SCTP_DEFAULT_SEND_PARAM

From: Mark Butler <[email-masked]>
Date: Fri, 03 Mar 2006 21:20:44 -0700

The sctpsocket-12 draft currently reads as follows

    7.1.14. Set default send parameters (SCTP_DEFAULT_SEND_PARAM)

    Applications that wish to use the sendto() system call may wish to
    specify a default set of parameters that would normally be supplied
    through the inclusion of ancillary data. This socket option allows
    such an application to set the default sctp_sndrcvinfo structure.
    The application that wishes to use this socket option simply passes
    in to this call the sctp_sndrcvinfo structure defined in Section
    5.2.2) The input parameters accepted by this call include
    sinfo_stream, sinfo_flags, sinfo_ppid, sinfo_context,
    sinfo_timetolive. The user must set the sinfo_assoc_id field to
    identify the association to affect if the caller is using the
    one-to- many style.

The problem is the last sentence - setting association specific 
sndrcvinfo defaults is not particularly useful on a one-to-many socket, 
because one normally needs the sndrcvinfo to select the association, so 
the defaults are pointless aside from the bizarre case where one might 
specify defaults by association id, and but then use sendto(2) to send 
by IP address.

Therefore, I suggest the last sentence be replaced with the following 
language: "The sinfo_assoc_id field specifies the default association 
used for send operations on one-to-many style sockets. It is ignored on 
the one-to-one style."

Having socket level defaults is much more useful and saves memory.    
The default association id would not adversely affect any call to 
sendto(), rather in fact socket level defaults would simplify 
programming sendto(2) calls considerably, because you would not need to 
translate the IP address to an association id first.   And allowing 
send(2) and write(2) calls on one-to-many sockets with a default 
association id would be very useful for some code bases.

Problems?

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

---

From: Randall Stewart <[email-masked]>
Date: Mon, 06 Mar 2006 08:42:02 -0500

Mark:

I interpret this a bit differently.. the sinfo_assoc_id field
identifies WHICH association you want to set the defaults on.
Not what default you want to send to.

So when I do

sinfo->sinfo_assoc_id = foo;
sinfo->sinfo_stream = 3;
/* set other params as you want */
setsocket(... SCTP_DEAULT_SEND_PARAM,sinfo);

sinfo->sinfo_assoc_id = fee;
sinfo->sinfo_stream = 4;
/* set other params as you want */
setsocket(... SCTP_DEAULT_SEND_PARAM,sinfo);

I am making association foo send to stream 3
by default. I am making association fee send
to stream 4 by default.

In fact in the BSD version this also works on
the one-2-one.. the call does.. but the sinfo_assoc_id
field is ignored (since there is only one association).

We obviously need to clearify this :-D

R

-- 
Randall Stewart
ITD - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

---

From: Mark Butler <[email-masked]>
Date: Mon, 06 Mar 2006 10:33:03 -0700

> Not what default you want to send to.

The specification is sufficiently clear to me.  I am suggesting a change 
in semantics, the primary reason being that the only time you need this 
is when you are sending without an association id.  So setting defaults 
by association id is relatively pointless, where setting socket level 
defaults all the time has the advantage of allowing the use of send(2) 
and write(2) on a one-to-many socket, in addition to sendto(2).

The impact of the change would be limited to applications that:

1. Use one to many sockets
2. Look up the association id by IP address (using a means not available 
to them in the draft)
3. Set the defaults by association id
4. Use sendto(2) to send by IP address multiple times in a row without 
resetting the defaults.

One significant flaw in the current scheme is that there is no way to 
set defaults for an initial sendto(), where an association does not 
exist yet.  Fixing that while preserving the current semantics would 
require an extension for pre-allocating not just an association id, but 
also a control block to store the defaults by association id. 

With the change, the process would look like this:

1. Set socket level defaults
2. Use sendto(2) to send by IP address

Or:

1. Set socket level defaults (including association id)
2. Use send(2) or write(2) to send to default association

sendto(2) style applications would not require IP address to association 
id translation for every new client.  Just set the socket level default 
and go.   Since most applications would either use common defaults for 
all messages, or different settings for each message, this is more 
considerably more efficient than doing IP address to association id 
translation and setting association defaults.

- Mark

>> sndrcvinfo defaults is not particularly useful on a one-to-many 
>> socket, because one normally needs the sndrcvinfo to select the 
>> association, so the defaults are pointless aside from the bizarre 
>> case where one might specify defaults by association id, and but then 
>> use sendto(2) to send by IP address.
>>
>> used for send operations on one-to-many style sockets. It is ignored 
>> on the one-to-one style."
>>
>> programming sendto(2) calls considerably, because you would not need 
>> to translate the IP address to an association id first.   And 
>> allowing send(2) and write(2) calls on one-to-many sockets with a 
>> default association id would be very useful for some code bases.
>>
>> Problems?
>>
>>  - Mark
>
>
>

---

From: Randall Stewart <[email-masked]>
Date: Mon, 06 Mar 2006 13:08:32 -0500

Mark:

Hmm this solves one problem at the expense of another.

I would rather see a seperate option for setting
the default send assoc-id.. then to see this
re-used this way.

Already you can have an association level and a
socket level SCTP_DEAULT_SEND_PARAM, this is
done in the 1-2-many model by setting assoc-id=0.

Having a seperate option for assoc-id default sending
might be a better solution imo..

more comments below..

Mark Butler wrote:
> exist yet.

Thats not true.. set the assoc-id =0 and you set the
default on the socket (aka where there is no
assoc id).

I think a new option would do what you want as a
seperate mechanism from this one :-D

R

   Fixing that while preserving the current semantics would

---

From: Mark Butler <[email-masked]>
Date: Mon, 06 Mar 2006 14:56:49 -0700

> done in the 1-2-many model by setting assoc-id=0.

That is not clear in the draft.  However the real problem is that true 
socket level defaults (ones affecting sends on all associations) and 
association level defaults do not get along very well.  I think 
association level defaults are borderline useless because of the need to 
translate IP addresses to association ids, a facility that is currently 
missing anyway.

 - Mark

- Mark.

---

From: Randall Stewart <[email-masked]>
Date: Tue, 07 Mar 2006 07:16:10 -0500

> translate IP addresses to association ids, a facility that is currently 

No its not... I know we talked about this ..

The language is not yet right but we should require that

  SCTP_GET_PEER_ADDR_INFO

Be able to use the address to lookup the information
as well.. You have to supply the address information
anyway...

The BSD version will do this now but it needs
to be specified in the draft...

R