Subject: Re: [Tsvwg] Comments on draft-ietf-tsvwg-sctpsocket-00.txt

From: Jonathan Wood <[email-masked]>
Date: Fri, 15 Jun 2001 13:22:08 -0700 (PDT)

Mike,

Thanks for the close read. You've saved us lots of tedious
work :)

1-7: good catches, thanks.

>
>8. Cross-reference in section 5.2: "See section 5.2.1 for more information".
>Should this be section 3.1.2?

Probably should be 5.3.1.1.

>
>9. Two points on the MSG_ADDR_OVER flag:
>a) The text for the MSG_ADDR_OVER flag in section 5.2.2 should presumably
>say TCP rather than UDP, because for UDP sockets the destination address is
>always critical.  Also the reference to sendto() seems incorrect because
>that call does not have ancillary data.  I suggest that the text should read
>as follows.
>"This flag, for TCP-style sockets, requests the SCTP stack to override the
>primary destination address with the address found with the sendmsg call." 
>b) In section 4.1.8  I suggest that the first sentence of point 1) should be
>modified to refer to the MSG_ADDR_OVER flag as follows.
>"When sending, the msg_name field in the msghdr is not used to specify the
>intended receiver.  However, if the MSG_ADDR_OVER flag is specified in the
>flags (see section 5.2.2) then the sender uses this field to indicate a
>different peer address if it does not want to send the message to the
>primary address of the receiver." 

Actually, I think the MSG_ADDR_OVER flag would be redundant for
TCP-style sockets. If the sender wants to send to the primary,
msg_name is NULL. If it wants to override the primary, it places
the alternate address in msg_name. This implies MSG_ADDR_OVER.

10-19: agree

>20. Section 8.1: The flags field on sctp_bindx() is formed from the bitwise
>OR of zero or more of the flags ADD and REMOVE.  Of course it only makes
>sense if exactly one of these flags is specified (the combination "don't ADD
>and don't REMOVE" makes no more sense than the combination "ADD and
>REMOVE").  I suggest that these should not be bitwise flags.  Please can you
>make them just two alternative values for the flag.

I believe the idea with making the flags a bitwise OR was to
make the call general enough that we could add interesting
functionality later. For example, let's say we wanted to allow
the caller a way around address scoping rules; we might add
SCTP_BINDX_BYPASS_SCOPING flag, which would act as a modifier
to the add functionality:

sctp_bindx(fd, addrs, naddrs, SCTP_BINDX_BYPASS_SCOPING | SCTP_BINDX_ADD_ADDR);

It makes the semantics much simpler if all flags are
formed with a bitwise-OR. Imagine the user confusion if
some flags were not OR'd, while others were...

Of course, you are right that it doesn't make sense to both
add and delete an address at the same time. Would you be
satisfied with some additional text saying that socket
implementations should catch and reject this?

21: ok.

>22. Section 8.5.  I don't understand what your new call provides that
>couldn't be achieved using setsockopt() and getsockopt().  None of the calls
>is simultaneously reading and writing.  You can set peer address parameters
>using setsockopt(SCTP_PEER_ADDR_PARAMS) or you can read them using
>getsockopt(SCTP_PEER_ADDR_PARAMS).  You can retrieve peer address
>information using getsockopt(SCTP_PEER_ADDR_INFO).  Why do we need a new

getsockopt() is read-only. In other words, you cannot pass an
address into getsockopt() and get back info on that address.
Of course, you could hack up getsockopt() to get it to work this
way, but I think it is much cleaner to provide a wrapper call
that allows implementors to do what works best on their platforms.

>call which can both set and get the same information set using different
>option identifiers?  Also the references to SCTP_SET_PRIMARY_ADDRS and
>SCTP_SET_PEER_PRIMARY_ADDRS as values for opt have no corresponding section
>later on.

Right - These two options can be set with setsockopt(), and
in fact last week I changed this in the upcoming -01 version of
the draft.

23: ok

>24. How about the option of specifying a message lifetime on outgoing data?
>(Section 5.2.2)  This would be analogous to the section 10.1 interface in
>RFC 2960.

If the WG agrees there is a need for this functionality, we can
add it in... I'd like to get some input on this.

25-26: ok

Jonathan

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

---

From: Mike Bartlett <[email-masked]>
Date: Mon, 18 Jun 2001 16:17:46 +0100

Hi Jonathan

Thanks for your reply.  I have some minor follow-up points, marked with
"MB>>".

Mike

-----Original Message-----
From: Jonathan Wood [mailto:[email-masked]]
Sent: 15 June 2001 21:22
To: [email-masked]; Mike Bartlett
Subject: Re: [Tsvwg] Comments on draft-ietf-tsvwg-sctpsocket-00.txt

Mike,

MB>> You're welcome :)

<snip>

MB>> OK, this makes sense now.  
MB>> I think some more explanation would help here, along the lines
suggested in Randall's email, and as I mentioned in (b) some
cross-references for sendmsg() for UDP (and TCP if applicable) would be good
too.  Also I believe my point in (a) about the sendto() reference in 5.2.2
is still valid.  

<snip>

sctp_bindx(fd, addrs, naddrs, SCTP_BINDX_BYPASS_SCOPING |
SCTP_BINDX_ADD_ADDR);

MB>> Yes, that would work for me.  Although to be honest I think that the
main problem is that ADD and REMOVE should be separate API calls.  I can't
imagine many of the flags you might want to add would apply to both ADD and
REMOVE, and I imagine you'll end up with two disjoint sets of options.  

<snip>

MB>> OK, I get it now.  Thanks.

<snip>