Subject: SCTP API section 7.1.13

From: David Lehmann <[email-masked]>
Date: Mon, 14 Feb 2005 16:00:52 -0500

Hello,

How does the user set the spp_pathmaxrxt without changing
the hbinterval?  Typically, when the user does not want to
change the value of a parameter, it is set to zero.
In this case, setting hbinterval to zero has quite a different
behavior.

Setting it to UINT32_MAX will not change the parameter, but
has the side effect of sending a HB immediately.
I just want to change pathmaxrxt.

-- 

David Lehmann                          Ulticom, Inc.
AOL/Yahoo IM: davidULCM                1020 Briggs Road
1-856-787-2729                         Mt. Laurel, NJ 08054   USA

---

From: Ryan W Bickhart <[email-masked]>
Date: Mon, 14 Feb 2005 17:48:58 -0500

I believe what you would do is first get all the current peer address
parameter values which are returned in the sctp_paddrparams struct,
change the fields that you want to new values, and then do a set,
passing the struct back to SCTP. Anything you didn't modify would remain
what it was before. Maybe there is a more direct way but that would
definitely work.

Ryan

---

From: David Lehmann <[email-masked]>
Date: Tue, 15 Feb 2005 09:25:53 -0500

> what it was before. Maybe there is a more direct way but that would

How do you "get all the current peer address parameter values" without
setting it?  The draft says that you "should" use sctp_opt_info which
'sets' and 'gets'. Does this mean that you can use getsockopt() as well?
If so, I did not see that statement in the draft.

Even if this is the case, it seems that this API is
inconsistent with the other structures where zero means
"don't change". Also, it is very inconvenient to get a value just
so we can then set it to the same value.

IMHO, zero should mean "don't change". UINT32_MAX could mean
disable heartbeats. (Or ~49 days, which is affectively
disabled.)  How about adding a boolean parameter "spp_send_hb"?
zero would mean don't send a HB; nonzero would mean send it.
That would leave spp_hbinterval to behave like the other parameters.

--

---

From: "Ryan W Bickhart" <[email-masked]>
Date: Tue, 15 Feb 2005 11:05:18 -0500

-----Original Message-----
From: David Lehmann [mailto:[email-masked]] 
Sent: Tuesday, February 15, 2005 9:26 AM
To: SCTP Implementors
Subject: Re: SCTP API section 7.1.13

> If so, I did not see that statement in the draft.

According to UNP (third ed) page 278, sctp_opt_info is a more portable
replacement for getsockopt. It says that some OS implementations may not
support in-out variables with getsockopt, which SCTP needs in some cases.
So you could think of sctp_opt_info as a glorified getsockopt that always
works. On FreeBSD, for example, you can use getsockopt directly, but this
is discouraged for portability reasons.

So you might do:
sctp_opt_info(...) /* get the settings */
/*modify what you want */
setsockopt(...) /* save the changes */

> so we can then set it to the same value.

I agree on both counts.

> That would leave spp_hbinterval to behave like the other parameters.

Even with the boolean, I think we would still have the same type of
consistency problem, just with a different parameter. How would you turn
off heartbeats by setting spp_send_hb to zero if zero means do not change
the current value? :) Maybe the first suggestion might work better...any
other ideas?

Ryan

---

From: David Lehmann <[email-masked]>
Date: Tue, 15 Feb 2005 12:14:08 -0500

> replacement for getsockopt. It says that some OS implementations may not

Who is defining sctp_opt_info?  UNP or SCTP API I-D?
If it is the SCTP API I-D, then usage need to be defined clearly in the I-D.

> is discouraged for portability reasons.

I don't necessarily agree with these statements, but I won't belabor the
point.

> sctp_opt_info(...) /* get the settings */

My understanding is that sctp_opt_info will _set_ the values.
How do you get the values before setting them?

>>so we can then set it to the same value.

Progress! :-)

> the current value? :) Maybe the first suggestion might work better...any

I was suggesting this:
    struct sctp_paddrparams {
        sctp_assoc_t            spp_assoc_id;
        struct sockaddr_storage spp_address;
        uint32_t                spp_hbinterval;
        uint16_t                spp_pathmaxrxt;
        uint8_t                 spp_send_hb;
    };

If spp_hbinterval == 0, do not change the HB interval.
If spp_hbinterval != 0, set the HB interval to the given number
    of milliseconds.  Setting it to UINT32_MAX would disable
    the HBs. (My point above is that if the SCTP implementation did not
    make a special case for UINT32_MAX, the interval would be
    more than 49 days, which effectively disables it.)

If spp_pathmaxrxt == 0, do not change the path max retrans.
If spp_pathmaxrxt != 0, set the path max retrans to that value.

If spp_send_hb == 0, do not send a HB.
If spp_send_hb != 0, send a HB. (spp_hbinterval should not
    cause the immediate sending of a HB.)

Better yet, leave the sctp_paddrparams as it was and create
a new function to send a HB:

int sctp_send_heartbeat(
	int sd, sctp_assoc_t id, const struct sockaddr *addr);

--

---

From: Randall Stewart <[email-masked]>
Date: Tue, 15 Feb 2005 15:31:50 -0500

> I don't necessarily agree with these statements, but I won't belabor the

But that IS the whole point of the sctp_opt_info.. i.e. a replacement
for getsockopt that allows in-out parameters...

I can say that with authority since I was there when all of
us authors debated the need for it.. and this was the ONLY reason
to create it...

The text currently says:
****************************************************************
<t>
   For some IP stacks getsockopt() is read-only, so a new
   interface will be needed when information must be passed both in to
   and out of the SCTP stack. The syntax for sctp_opt_info() is,
</t>
<figure>
<artwork>
int sctp_opt_info(int sd,
                   sctp_assoc_t id,
                   int opt,
                   void *arg,
                   socklen_t *size);
</artwork>
</figure>
<t>
     For one-to-many style sockets, id specifies the association to 
query. For
     one-to-one style sockets, id is ignored.
</t>
<t>
     opt specifies which SCTP socket option to get. It can
     any socket option currently supported that requests information
     (either read/write options or read only) such as:
</t>
*******************************************************

You may be being confusred by that last line in ()'s

What that is eluding to is the "classification" of the socket
options.. i.e. the document classify's all options as read-only,
or read-write options... This is NOT saying anything about
sctp_opt_info being used to set an option..

And I think that first bit clearly states this is as Ryan
implied.. due to some O/S's not allowing in/out in a
getsockopt().

> How do you get the values before setting them?

No.. its used for read only .. but with an in parameter.
>     int sd, sctp_assoc_t id, const struct sockaddr *addr);

I can live with either approach... but I think the heart of
this problem is that you are assuming that sctp_opt_info() is
a write option.. it is NOT meant to change any values.

That definetly needs to be clearified in the next pass.

R
-- 
Randall Stewart
ITD
803-345-0369 <or> 815-342-5222

---

From: David Lehmann <[email-masked]>
Date: Tue, 15 Feb 2005 16:49:32 -0500

> for getsockopt that allows in-out parameters...

OOOhhhh... The light bulb just turned on!

I remember this issue when speaking to one of  the authors of RFC 3542.
In section 11.4, it states "there is no way to pass the destination via
getsockopt()", even though the given struct ip6_mtuinfo has a spot for
the destination.

Thinking out loud...
Maybe there should be a generic sock_opt_info().

int sock_opt_info(int s, int level, int optname, void  *optval, int *optlen);

The association id can be put in each structure so it could be used
in  sock_opt_info().  Actually, the association id is in each structure.
Why is the association id needed on sctp_opt_info()?

> The text currently says:

I think you are missing a "get" after the "can".

>     (either read/write options or read only) such as:

Got it.  Maybe a statement is needed to explicitly state
what you just wrote: "Sctp_opt_info() is  a replacement
for getsockopt() only and will not set any options associated
with the specified socket. Setsockopt() must be used to
set these options."

> ...

Yep, I did misunderstand the functionality of sctp_opt_info.
Thanks for belaboring the point even though I didn't want to. :-)

Nonetheless, I would like to see the authors discuss the
issue of making 'spp_hbinterval == 0' do nothing on a
setsockopt().

> That definetly needs to be clearified in the next pass.

Agreed.

--

---

From: Randall Stewart <[email-masked]>
Date: Wed, 16 Feb 2005 07:57:13 -0500

> Maybe there should be a generic sock_opt_info().

That maybe.. or getsockopt() needs to be re-defined to require
it to allow in-out parameters.. its that way on most
BSD's but I don't think so on most other O/S's :-D

> Why is the association id needed on sctp_opt_info()?

Well, in the case of the 1-to-N model, you need to figure
out which association id is being requested information
on...

> with the specified socket. Setsockopt() must be used to
I have fixed the missing "get" (I noticed that to when I cut
and pasted into the email :-0)

And put in most of the wording above verbatim.. with one
minor change.. it will read:

<t>
   For some IP stacks getsockopt() is read-only, so a new
   interface will be needed when information must be passed both in to
   and out of the SCTP stack. The syntax for sctp_opt_info() is,
</t>
<t>
The sctp_opt_info() call is a replacement for getsockopt() only
and will not set any options associated with the specified socket.
A setsockopt() must be used to set any writeable option.
</t>

That hopefully will cover it :-D

> issue of making 'spp_hbinterval == 0' do nothing on a

Maybe we can have an authors and interested folks pow-wow
at the IETF..

R

---

From: David Lehmann <[email-masked]>
Date: Wed, 16 Feb 2005 08:18:07 -0500

Agreed.

> out which association id is being requested information

Isn't the association id in all of the structures used by
sctp_opt_info()?

> That hopefully will cover it :-D

Yep, looks good.

--