Subject: [Tsvwg] comments and questions on draft-ietf-tsvwg-sctpsocket-15

From: Stephane Chazelas <[email-masked]>
Date: Wed, 11 Jul 2007 17:39:47 +0100

Hi guys,

while looking at the details of what should be done upon send*()
with no data, I found some areas of the Socket draft that
confused me.

Could you please help me clarify them?

3.1.5: (knitpicking)
  > To gracefully shutdown a specific association represented by the one-
  > to-many style socket, an application should use the sendmsg() call,
  > and including the SCTP_EOF flag.  A user may optionally terminate an
  > association non-gracefully by sending with the SCTP_ABORT flag and
  > possibly passing a user specified abort code in the data field.  Both

  What "data field"? 5.2.2 indicates that that's msg_iov, but that field
  is described as "scatter/gather array", not "data".

  > flags SCTP_EOF and SCTP_ABORT are passed with ancillary data (see
  > Section 5.2.2) in the sendmsg call.

5.1:

  > The scatter/gather buffers, or I/O vectors (pointed to by the msg_iov
  > field) are treated as a single SCTP data chunk, rather than multiple
  > chunks, for both sendmsg() and recvmsg().

  possible confusion with protocol DATA chunks. Shouldn't it be "single
  SCTP message". A stack may still fragment the message into several
  DATA chunks to fit in the MTU. All those DATA chunks would have the
  same SSN.

5.2:

  > There are two kinds of ancillary data used by SCTP: initialization
  > data, and, header information (SNDRCV).  Initialization data (one-to-
  > many style only) sets protocol parameters for new associations.
  > Section 5.2.1 provides more details.  Header information can set or
  > report parameters on individual messages in a stream.  See
  > Section 5.2.2 for how to use SNDRCV ancillary data.

  Why 1-to-many only? Especially when 4.1.5 mentions explicitely that you
  can use an SCTP_INIT if you want to send data at the same time as you
  connect?:

  > Note that SCTP allows data exchange, similar to T/TCP RFC1644
  > [RFC1644], during the association set up phase.  If an application
  > wants to do this, it cannot use connect() call.  Instead, it should
			           ^
                                  the
  > use sendto() or sendmsg() to initiate an association.  If it uses
  > sendto() and it wants to change initialization behavior, it needs to
  > use the SCTP_INITMSG socket option before calling sendto().  Or it
  > can use SCTP_INIT type sendmsg() to initiate an association without
  > doing the setsockopt().

  Inconsistency?

6.1:
  > Note, if an application calls a send function with no user data and
  > no ancillary data the SCTP implementation should reject the request
  > with an appropriate error message.  An implementation is NOT allowed
  > to send a Data chunk with no user data RFC2960 [RFC2960].

  OK, but then what about a sendmsg() with ancillary data and no user
  data?

  The draft suggests that we may send a SCTP_SNDRCV structure with
  SCTP_EOF and no data if we want to close a 1-to-many association.

  It suggests as well that we may be able to use SCTP_ABORT with no data
  if we want to abort an association without giving a reason.

  But what about the other possible usages of SCTP_SNDRCV and SCTP_INIT?

  If we do a sendmsg() with an SCTP_INIT and no user data,
  should it automatically start an association without sending
  data?

  If yes, then why not allowing a user to do a sendmsg() with neither
  data nor ancillary data, to allow him to establish an association
  using the default init parameters?

  Also, what about a sendmsg() with SCTP_ABORT (or SCTP_EOF and no data)
  to a destination to which we're not associated yet? Should it
  establish and then close an association?

Best regards,
Stephane

---

From: Stephane Chazelas <[email-masked]>
Date: Fri, 20 Jul 2007 10:51:49 +0100

> Could you please help me clarify them?

Hi there,

doesn't look like those considerations raise a lot of interest
:). I guess the point I was mostly interested in having your
opinion about is the one below.

I've another concern about this draft on another point of
detail, this time about the SCTP_DEFAULT_SEND_PARAM in 1-to-many
style.

I understand that this options affects subsequent sendto()s to
the association specified in sinfo_assoc_id, or if
sinfo_assoc_id is 0 to any newly created association from now
on. Now, what about the SCTP_SENDALL flag?

When that flag is set in the sndrcv structure in the ancillary
data of a sendmsg(), then the destination address or the
sinfo_assoc_id is ignored, the message is sent to every
association on the socket (and at the same time override the
default send param of each association).

But when it's set in the default send param of a specific
association, does that mean that anytime we do a sendto() to
that association, the message will be automatically forwarded to
every other association in the socket?

After a setsockopt with SCTP_DEFAULT_SEND_PARAM with
sinfo_assoc_id == 0 and sinfo_flags == SCTP_SENDALL, should
every sendto() go to every association, or only those sendto()s
sent to addresses for which there is no association yet?

[...]
>   establish and then close an association?

TIA and best regards,
Stephane

---

From: Vlad Yasevich <[email-masked]>
Date: Fri, 20 Jul 2007 09:33:20 -0400

>   is described as "scatter/gather array", not "data".

Would the following be better?

    A user may optionally terminate an association non-gracefully by sending with
    the SCTP_ABORT flag and possibly providing a user specified abort code as
    data.

>   DATA chunks to fit in the MTU. All those DATA chunks would have the

Yes, should be a single message.

>   > can use SCTP_INIT type sendmsg() to initiate an association without

Appears to be a slight one.

>   But what about the other possible usages of SCTP_SNDRCV and SCTP_INIT?

Those would be invalid.

>   should it automatically start an association without sending

Not that I can see...

>   establish and then close an association?

No.

-vlad

---

From: Stephane Chazelas <[email-masked]>
Date: Mon, 23 Jul 2007 17:55:49 +0100

On Fri, Jul 20, 2007 at 10:51:49AM +0100, Stephane Chazelas wrote:
[...]
[...]

Hi list,

I'm afraid I have some more questions about this document :).

about sctp_assoc_t.

At first sight, sctp_assoc_t seems to be an opaque type with no
indication of it being numerical or not, then there are some
inconsistencies in the document about its type:

Sometimes, we talk of an "sctp_assoc_t structure" (is it a C
struct?), sometimes it can take a value of 0 or zero (is it a
numerical type?), sometimes a value of '0' (is it a char?).

So my understanding is that the intent was to have a sort of
integer type assoc id, and that the value 0 is reserved and
shouldn't be assigned to any association.

Would it be possible to have it worded a bit more clearly in the
document?

Also, if 0 is a reserved value, it would be nice if it was
specified how that value should be handled for every call that
involves a sctp_assoc_t.

Especially, what about the SCTP_SNDRCV data option in sendmsg()?

It's not very clear what the sinfo_associd field is for. There
are several statements that a user should set that field to the
assoc id of the association he wants to shutdown/abort along
with the SCTP_EOF and SCTP_ABORT flags. Other than that, for
normal operation, it's said that the field should contain the
assoc_id returned in an ASSOC_CHANGE notification without really
explaining what for. But what if a user (in 1-to-many) wants to
send a msg to a host we are not associated to yet and for
instance using stream id 2?  Does he have to do a connect()
first? Or a setsockopt(SCTP_DEFAULT_SEND_PARAM) with
sinfo_associd == 0 and do a sendmsg() without SCTP_SNDRCV?

If both a destination address and an assoc_id (in a sctp_sndrcv
structure) are provided, how should a sctp stack look up the
association? What takes precedence?

In the description of the msghdr structure:
  1187     In the msghdr structure, the usage of msg_name has been discussed in
  1188     previous sections (see Section 3.1.3 and Section 4.1.8).

I can see nothing about msg_name in section 3.1.3. There's a
similar wrong link in section 4.1.8. I suspect 3.1.4 was meant
instead.

Section 3.1.4 says what to do when there is no association
already for the given address, but doesn't say what to do if
there is one or if there are several. For instance, if one does
a sendmsg with msg_name containing address X, with a SCTP_SNDRCV
with a sinfo_associd being zero, and a SCTP_EOF in the
sinfo_flags, should we shutdown every association to address X,
or just the first, or just the first one that is not in the
ESTABLISHED state. Same for just sending data. And what if a
non-zero assoc_id is provided...

Also, why doesn't sctp_sendmsg() take an assoc_id argument?

Also, could anyone please help me understand this statement in
section 7:

>  All options that support specific settings on an association by
>  filling in either an association id variable or a sockaddr_storage
>  SHOULD also support setting of the same value for the entire endpoint
>  (i.e. future associations).  To accomplish this the following logic
>  is used when setting one of these options:
>
>  a) If an address is specified via a sockaddr_storage that is included
>     in the structure, the address is used to lookup the association
>     and the settings are applied to the specific address (if
>     appropriate) or to the entire association.
>  b) If an association identification is filled in but not a
>     sockaddr_storage (if present), the association is found using the
>     association identification and the settings should be applied to
>     the entire association (since a specific address is not
>     specified).  Note this also applies to options that hold an
>     association identification in their structure but do not have a
>     sockaddr_storage field.
>  c) If neither the sockaddr_storage or association identification is
>     set, i.e. the sockaddr_storage is set to all 0's (INADDR_ANY) and
>     the association identification is 0, the settings are a default
>     and to be applied to the endpoint (all future associations).

I can't think of any option to which it applies. Does anyone
have an example?

I've spotted a few typos in the document:

   353	   setup an association implicitly.  It cannot be used to send data to
   354	   an established association as the association ID cannot be specified.
   355	
   356	   Once as association ID is assigned to an SCTP association, that ID

typo: "once as"

  2468	7.  Socket Options
  2469	
  2470	   The following sub-section describes various SCTP level socket options
  2471	   that are common to both styles.  SCTP associations can be multi-
  2472	   homed.  Therefore, certain option parameters include a
  2473	   sockaddr_storage structure to select which peer address the option
  2474	   should be applied to.
  2475	
  2476	   For the one-to-many style sockets, an sctp_assoc_t structure
  2477	   (association ID) is used to identify the the association instance

typo: "the the"

  2650	   This information may be examined for either the endpoint or a
  2651	   specific association.  To examine a endpoints default parameters the
  2652	   association id (sasoc_assoc_id) should must be set to the value '0'.

typo: "should must"

Best regards,
Stephane

---

From: Stephane Chazelas <[email-masked]>
Date: Tue, 24 Jul 2007 10:47:54 +0100

On Fri, Jul 20, 2007 at 09:33:20AM -0400, Vlad Yasevich wrote:
[...]
>     the SCTP_ABORT flag and possibly providing a user specified abort code as

Hi Vlad,

thank you for taking the time to respond.

In this occurrence, given that it mentions sendmsg()
explicitely, I would rather say "in the msgiov field".

[...]
> >   But what about the other possible usages of SCTP_SNDRCV and SCTP_INIT?

That's arguable. As the draft is currently worded, it is valid
as only no-control *and* no-data is invalid.

It's true that a user can use a setsockopt followed by a connect
to initiate an association with specific init parameters, but if
he wants to use those parameters only for a specific address,
allowing to establish an association with an empty sendmsg()
with control data would be useful (otherwise, he'd need to do
another setsockopt to revert to the previous parameters).

Also given that we can close an association with a sendmsg(), it
would make sense to be able to initiate it with a sendmsg() as
well.

But if we allow a sendmsg with no-data to initiate an
association with specific init parameters, I don't think it
makes sense to forbid a sendmsg() without control-data to allow
to establish an association with the default init parameters.

[...]
[...]

I'd agree with you. But then, the draft would need to be
updated. As it's worded today, it's not clear.

There's also the case of SCTP_EOF *with* user data that is not
clearly covered. One may want to use that to send datagrams and
make sure a new association is created for every send message.
It's not clear whether the draft allows that at the moment.

Best regards,
Stephane