Subject: Re: [Tsvwg] A couple questions about draft-ietf-tsvwg-sctpsocket-02.txt

From: Randall Stewart <[email-masked]>
Date: Thu, 13 Dec 2001 07:33:40 -0600

Mingqin Liu wrote:
> 
> 1.  In Read/Write options, we have data structures (e.g., sctp_rtoinfo,
> sctp_assocparams, and etc) that have assoc_id in them. If this mechanism
> works for getsockopt or setsockopt, we can get rid of sctp_opt_info.  The
> reason to introducing a new sctp_opt_info function call is to pass assoc_id
> to the SCTP stack. If we can wrap assoc_id in "arg" (as we do in structure
> sctp_rtoinfo) passed to sctp_opt_info, it becomes a getsockopt call.
> 
> For reference, here I included some of the data structures and function
> calls:
> 
> struct sctp_rtoinfo {
>      uint32_t                      srto_initial;
>      uint32_t                      srto_max;
>      uint32_t                      srto_min;
>      sctp_assoc_t          srto_assoc_id;
> };
> 
> int sctp_opt_info(int sd, sctp_assoc_t id, int opt, void *arg);
> 

Yes, I do think you have a very valid point here. In fact I
have discussed this point with Jonathan Woods and one of my
co-developers
Peter Lei. The only valid reason I have heard for introducing
a system call is for mutex locking i.e. making things thread
safe. But many of the calls don't need this... Maybe we need
a careful look at this and eliminate things that don't need to
worry about being thread safe.... 

To clearify, what would happen with a "thread safe" sctp_opt_info() is
that the call would really not be a new system call but instead
only on the user side i.e.

for example in user space the getladdr might look
something like:

sctp_getladdr(...)
{
   int siz;
   pthread_mutex(...lock...);
   getsocketopt(GET_NUM_OF_ADDR,...,&siz);
   foo = malloc((siz * sizeof(struct sockaddr_storage));
   getsocketopt(GET_ADDRS,...,foo);
   pthread_mutex(...unlock...);
   return(foo);
}

> 2. Please explain more about the meaning of "Read/Write Options". I am kind
> of confused by "Read/Write" terms. Is "Read" equivalent to get and "Write"
> to set?

This may need some clearification. A Read/Write is one that you can do
a getsocketopt/setsocketopt respectively.

So when you read you do a getsocketopt()...

> 
> I thought that we can pass the 11 Read/Write options to both getsockopt and
> setsockopt. However, the explanations about those options sound more like
> that they are only used by setsockopt. Furthermore, there are three options
> named as SCTP_SET_PRIMARY_ADDR, SCTP_SET_PEER_PRIMARY_ADDR and
> SCTP_SET_ADAPTION_LAYER_BITS, which makes them even more set-only like or
> write-only like.

Well, SCTP_SET_PRIMARY_ADDR for example seems to be a read only but
if I remember right we made ours so that if you do this with a
getsocketopt() it returns the current value of the primary address
(i.e. the socketaddr storage).

> 
> 3. In Section 5.4.3, the first line reads "[T]he information conveyed via
> SCTP_SNDRCV events ... " I could not find SCTP_SNDRCV event type or
> notification type in Section 5.3. I think that the word "events" here is a
> typo. It should be "ancillary data" instead.
> 

Yeah, the sctp_sndrcv is the ancillary data.. good catch..

R

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

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

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

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Thu, 13 Dec 2001 08:08:46 -0600

> > sctp_rtoinfo) passed to sctp_opt_info, it becomes a getsockopt call.

Randy's comment about thread-safe calls is valid, but I think your
question has more to do with how getsockopt() works today.  In the
SunOS streams implementation, it is not possible to pass data INTO
getsockopt()--it is strictly read-only.  Indeed, passing an assoc_id
into getsockopt() for Linux requires some unpleasant contortions.

One possible way to solve this problem is to add a setsockopt() option
to mark the "current" association, but this is not thread-safe.

---

From: Peter Lei <[email-masked]>
Date: Thu, 13 Dec 2001 11:46:12 -0600

> to mark the "current" association, but this is not thread-safe.

So given that there's at least one OS where getsockopt is "read-only"
(are there others??) doesn't that imply that *all* of the read/write
and read options that contain an "assoc_id" parameter need to get
passed into sctp_opt_info, not just the three options currently
listed in 8.7??

This assumes, as I have in our implementation, that the read/write
options are valid in a getsockopt call; example: getsockopt[SCTP_RTOINFO]
and even for things like getsockopt[SCTP_SET_PRIMARY_ADDR] to get the
value of the current primary address.

If we do require that sctp_opt_info take all options which have an
assoc_id parameter, I suggest that we clarify that the application
must set the assoc_id parameter in the sctp_opt_info call and the
one contained within the struct passed in the arg parameter (and
that they should be the same).

--peter

---

From: Randall Stewart <[email-masked]>
Date: Thu, 13 Dec 2001 16:51:53 -0600

> that they should be the same).

I am rather against doing this. But if we do I must suggest that we
not require the assoc_id to always be set. One at least (don't
have the draft in front of me now) has both a sockaddr_storage
AND a assoc_id parameter. This provides a VERY VERY easy way
to find the assoc_id if I only know the sockaddr_xx. I send it
down with a get() call (however we are doing it) and it comes
back with the assoc_id for that address. Very nice....

Now on the subject of (g/s)etsockopt, I would like
more than La Monte's opinion on what the sun-streams implementation
CAN and CAN'T do.. I have done a bit of streams work in
a past life and you DO send a message down a stream queue
(in the end). I somehow doubt that the message is limited to
the socket request you are making. The message moves down
the stream queue to each protocol until it hits the addressed
protocol. There the protocol engine gets the message and then
sends back up the response to the request.. check out the
DLPI specification... (I think that is the FLA :>)

It looks something like

  Stream Head
  -----------
   v       ^
   |       |
   |       |
 +-+-------+-+
 |  Prot 1   |
 |           |
 +-+-------+-+
   |       |
   v       ^
   /       \
   .       .
   .       .
   \       /
   |       |
 +-+-------+-+
 |  Prot N   |
 |           |
 +-+-------+-+
   |       |
   v       ^
   |       |
   ---------
   stream end

The message moving down the stream can be anything. Including
a socket address or a assoc_id... If it can't be how could
you ever send data out?

I just don't get this contention that you cant send data
down in a get request... especially when it translate into
a message put down a stream head...

Jonathan, I know you left sun but a comment would be nice...

R

---

From: Jonathan Wood <[email-masked]>
Date: Thu, 13 Dec 2001 15:32:18 -0800

> Jonathan, I know you left sun but a comment would be nice...

Hmm I thought I had switched my subscription to TSVWG to my new email 
address prior to leaving, but I guess it didn't take... Thanks for 
CC'ing me; I haven't been intentionally ignoring this.

Without the source code in front of me I can't be 100% sure now, but 
here goes:
The problem isn't with STREAMS, but with this gnarly SVR4 option 
processing framework in Solaris inherited from AT&T - that's the part 
that doesn't pass down arguments given to getsockopt(). I remember 
evaluating the effort needed to fix this, and decided it was somewhere 
between hard and impossible (mostly due to backwards compat issues). 
Kacheong also felt that there other OS's out there that would have 
similar problems (I can point at him now, since he's on vacation and 
can't defend himself :)

Jonathan

---

From: Peter Lei <[email-masked]>
Date: Thu, 13 Dec 2001 17:55:31 -0600

> back with the assoc_id for that address. Very nice....

Sorry, I was unclear-- the options you refer to are listed in 8.7
for sctp_opt_info (which by the way says that these assoc_id element
in the structure be filled in by the application; this should be
corrected).  Here, the address is the primary key, since the desired
operation is on a specific address and I expect the assoc_id's to be
ignored. 

I was really referring to those where the assoc_id is the primary
key-- what I was really looking for is a clearer statement on which
assoc_id should be used, the one passed as the assoc_id parameter
vs. the one containted in the structure passed when the assoc_id is
the primary key.  If we have to wrap all the options with sctp_opt_info,
then I interpret the draft to currently require the application set
the assoc_id in the structures as in section 7 as well as the assoc_id
parameter in the set_opt_info call...

thanks,
--peter