Subject: [Tsvwg] Some queries & comments on SCTP sockets API draft

From: Sridhar Samudrala <[email-masked]>
Date: Fri, 7 Dec 2001 12:30:24 -0800 (PST)

I have some comments and queries after going through the SCTP sockets API draft
draft-ietf-tsvwg-sctpsocket-02.txt 

* The behavior for an inbound SCTP INIT request to a TCP-style SCTP endpoint
  is explicitly mentioned in the draft(sec 4.1.2): Causes an SCTP ABORT to be
  sent. But this is not defined for UDP-style endpoint. Is the expected 
  behavior same even for UDP-style endpoint?
  What should be the reaction for an SCTP INIT request when there is no SCTP 
  endpoint. TCP does send a RESET when a SYN is received on a port nobody is
  listening on.

* In section 
    5.3. SCTP Events and Notifications
  of the draft i noticed the following 2 entirely conflicting statements.
    - Multiple notifications may be returned to a single recvmsg() call.  
    - A recvmsg() call will return only one notification at a time.
  Which one of these statements is the correct one? I assume it is the 
  second one.

* Section 7.2.1 Association Status (SCTP_STATUS)
    " To access these status values, the application calls getsockopt()
    with the option name SCTP_STATUS."
  This is true for a TCP-style socket, but how can this option be used with 
  getsockopt() for a UDP-style socket with multiple associations. May be this
  option also should be used with the new interface sctp_opt_info().
  Even for Read/Write Options, SCTP_RTOINFO, SCTP_ASSOCRTXINFO, 
  SCTP_SET_PRIMARY_ADDR and SCTP_SET_PEER_PRIMARY_ADDR we cannot use 
  getsockopt() to retrieve the current value of these options for a particular 
  association.

  The stat_state field in the sctp_status structure is defined as follows
    sstat_state    - This contains the association's current state one
                     of the following values:
                     
                     SCTP_CLOSED
                     SCTP_BOUND
                     SCTP_LISTEN
                     SCTP_COOKIE_WAIT
                     SCTP_COOKIE_ECHOED
                     SCTP_ESTABLISHED
                     SCTP_SHUTDOWN_PENDING
                     SCTP_SHUTDOWN_SENT
                     SCTP_SHUTDOWN_RECEIVED
                     SCTP_SHUTDOWN_ACK_SENT

  Is it possible for an association to be in the first 3 states. I think the 
  first 3 states correspond to the state of an endpoint.

* The following sentence in the section
    3.3. Non-blocking mode
  needs to be fixed.
     " Whenever the user which want to avoid blocking must call select()
       before calling sendmsg()/sendto() and recvmsg()/recvfrom(), and
       check the socket status is writable or readable. "

* In section
  1. Introduction
      " A mechanism is defined to convert a UDP-style SCTP socket into a
        TCP-style socket."
  I could not find where this mechanism is defined. Is it really needed? 

* I noticed that the terms 'notification' and 'event' are not used consistently
  throughout the draft. As per my understanding, SCTP_ASSOC_CHANGE is a
  notification which can communicate a set of event types, but it is called an
  event in multiple places.

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

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Fri, 07 Dec 2001 19:19:22 -0600

Sridhar Samudrala <[email-masked]> writes:
> I have some comments and queries after going through the SCTP
> sockets API draft draft-ietf-tsvwg-sctpsocket-02.txt 
...
>   Which one of these statements is the correct one? I assume it is the 

This is my error.  I failed to purge the sentence about only returning
a single notification.  Since we changed the notifications into full
TLV's, it is now possible to include more than one notification in a
recvmsg().  We expect this to be a major performance advantage for
very busy servers.

---

From: Randall Stewart <[email-masked]>
Date: Wed, 12 Dec 2001 09:35:03 -0600

Sridhar:

Some comments below..

>   endpoint. TCP does send a RESET when a SYN is received on a port nobody is

I think RFC2960 covers this... which by the way is the decisive
reference.. the socket draft is only going to be informational...

RFC2960 requires an Abort be sent...(with T bit set etc).

>   Which one of these statements is the correct one? I assume it is the

La Monte already addressed this one :>

>   getsockopt() to retrieve the current value of these options for a particular

I believe (at least the way I implemented this in the FreeBSD version)
one
would examine the association id... this is pretty much in about every
one of these requests. There is an issue here though. Many of these
parameters are also applicable to an endpoint.. to solve this issue
I made it so that if the assoc_id is set to 0 and (if applicable) the
sockstorage is 0, then the request is against the endpoint. Otherwise
the sockaddr_storage or assoc_id is used to find the real association
and
then request is against the particular association...

>   first 3 states correspond to the state of an endpoint.

This looks to me like we have a error that needs to be removed the
BOUND stuff should NOT be present :> good catch.. don't know
how we missed it.. I will have to check how we implemented it :>>

>        check the socket status is writable or readable. "

Did you want a specific change or just a differnt phrasing?

>   I could not find where this mechanism is defined. Is it really needed?

I think this refers to the sctp_peeloff() but I will take a closer
look at this when I get back from the IETF...

>   event in multiple places.

Yes, good point, next pass we will attempt to tighten the terminology up
a bit...

R

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

---

From: Sridhar Samudrala <[email-masked]>
Date: Wed, 12 Dec 2001 11:39:20 -0800 (PST)

> then request is against the particular association...

I was referring to the issue of having to pass assoc_id to get information for
a particular association. As getsockopt() is a read-only interface, i am not
sure if we can pass in the assoc_id as part of optval parameter. I think the new 
interface sctp_opt_info() is specifically introduced to address this read-only 
issue. 
    8.7 sctp_opt_info()

        getsockopt() is read-only, so a new interface is required when
        information must be passed both in to and out of the SCTP stack. The
        syntax for scpt_opt_info() is,

        int sctp_opt_info(int sd, sctp_assoc_t id, int opt, void *arg);

So if a user wants to get association specific information for the above options,
sctp_opt_info() may have to be used instead of getsockopt().  
 
> Did you want a specific change or just a differnt phrasing?

I felt the sentence is semantically incorrect. It may be changed to 
     " To avoid blocking, the user must call select() before calling 
       sendmsg()/sendto() and recvmsg()/recvfrom(), and check the socket 
       status is writable or readable. "

> look at this when I get back from the IETF...

Later i too realized that most probably this was referring to sctp_peeloff(). But
'CONVERT' seems to be too strong. Once a UDP-style association is peeled off,
i guess it can be considered as a TCP-style socket with socket type SOCK_SEQPACKET. 
Does the peeloff change the socket type too?

Thanks
Sridhar

---

From: Randall Stewart <[email-masked]>
Date: Wed, 12 Dec 2001 16:57:41 -0600

> interface sctp_opt_info() is specifically introduced to address this read-only

This is hard for me to believe since I have it implemented and working
and you do have to pass some information from any system call. I.e. 
what your command is.. most all o/s's that I have dealt with (which
is quite a great number of unix variants) have some sort of
copyin/copyout routine that allow you to get arguments.

It works fine for our kernel BSD implementation :>

> sctp_opt_info() may have to be used instead of getsockopt().

Hmm, I have always wondered if this is worthwhile. Even Jonathan told
me that you almost always imnplement these things with getsockopt
wrapped in the user lib..

>        status is writable or readable. "

ok...sounds fine to me :>

> Does the peeloff change the socket type too?
Internally I don't necessarily think you  will have a SOCK_SEQPACKET
flag in place.. it will be a different kernel flag in the socket. Of
course
implementations will differ. No matter what the flag it MUST take
on the behavior of a SOCK_SEQPACKET type socket. In my case it will
dump the sctp_inpcb into a different set of hash tables for specific
endpoint point to point endpoints. 

R