Subject: Re: [Fwd: Re: [[email-masked]: [Tsvwg] SCTP Sockets API Question]]

From: Chuck Winters <[email-masked]>
Date: Fri, 1 Nov 2002 09:22:36 -0500

Hey again,

On Thu, Oct 31, 2002 at 01:50:43PM -0600, Jon Grimm wrote:
 
<snip>
> > Correct me if I'm wrong, bug if message boundaries are preserved, the semantics
> > should be that a read on the socket should return one message, or part of a
> > message(if the buffer it is being read into is too small).  If the message is
> > smaller than the buffer, still only 1 message is read into the buffer.  Now,
> > if message boundaries are preserved, and the previously stated semantics are
> > correct, then why is SOCK_STREAM used as a service type?  
> > Wouldn't SOCK_DGRAM be a better fit?
> >
> 
> Well its a little hard to call it a bug if its not specified. 
Sorry, should be "but" not "bug".
> 
> I just call'em like I read'em.   The recvmsg behavior needs to be there
> for applications that want to bite off a little bit of SCTP knowledge. 
> I prefer not to have differing behaviors for read vs recvmsg.   Due to
> layering, it may even be quite difficult to force two different
> behaviors at the read vs recvmsg interface.  In the linux case,
> read/recv/recvfrom all wrapper recvmsg before entry into the transport
> specific layer.   
I agree, recvmsg must be there, and it must be able to get info from SCTP.
> 
> Its a little weird to put SCTP under SOCK_STREAM anyway.  IMO, 1-1
> should have been SOCK_SEQPACKET and 1-many something new entirely..
> SOCK_SCTP.   I'm guessing the original thoughts on the I-D were a
> tradeoff in application porting vs semantics vs getting at all the kewl
> bits in SCTP.
It is probably better to fit SCTP to current service types rather than
make new ones.
> 
> For impementation reasons I need it to be specified either as:
> a) TCP-style recvmsg MUST preserve message boundaries read/recv MAY
> preserve boundaries.
> b) TCP-style read/recv MUST preserve stream semantics, recvmsg MAY
> preserve message semantics
> 
> The current I-D allows (a) (though possibly by oversight), but I could
> tolerate (b) too  
> The third option, which require differing behaviors, will not always be
> possible, so... the app will need to be ready for this situation
> anyway.   
IMO recv/read/readv/recvmsg should have the same semantics for the same service type.

> Best Regards,
> Jon

Later,
Chuck
-- 
Chuck Winters                            | Email:  [email-masked]
Distributed Processing Laboratory        | Phone:  856-338-3987
Lockheed Martin Advanced Technology Labs |
1 Federal St - A&E-3W                    |
Camden, NJ 08102                         |

---

From: Chuck Winters <[email-masked]>
Date: Fri, 1 Nov 2002 09:30:31 -0500

Hi again,

On Thu, Oct 31, 2002 at 03:03:05PM -0600, Randall Stewart (cisco) wrote:
> Jon:
> 
> Some answers to both of you:
> 
> 1) First and formost.. YOU MUST preserve message boundaries no matter
>     which you open UDP or TCP style
> 
> 2) There will  be no MUST/MUST NOT wording in the current ID.. there 
> cannot be since it
>     will in the end be an informational RFC.
> 
> 3) What ties the MUST into number 1 is RFC2960.. since it emphasis 
> message boundary
>      preservation...
> 
> So basically you should either get a FULL message or a part of a 
> message.. but NEVER
> the end of one message and the beginning of the other... otherwise you 
> end up with NO
> message boundaries and break the SCTP symantics.
Then why use SOCK_STREAM?  IMO, the service type defines how the data is 
presented to the upper layer.  There is no indication(in my mind) that 
SOCK_STREAM means "connected socket" other than the historical fact that 
TCP uses SOCK_STREAM.  I believe that SOCK_DGRAM would be a much better
fit to the way data is structured in SCTP.
> 
> Now as to why we made the choices we did.. I think your (Jon's) guesses 
> are about
> right on.. and we wanted to avoid defining new types i.e. SOCK_SCTP etc..
Agreed, not a good idea.  I think that one would be hard to get by a standards
commitee
> R
<snip>

Later,
Chuck

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 01 Nov 2002 09:32:32 -0600

>fit to the way data is structured in SCTP.

The reason I believe we selectecd SOCK_STREAM is that we DID want a
mode that looked like TCP. Making it be SOCK_DGRAM would imply
it looked like UDP not TCP.

And we have been quite sucessful simulating TCP's interface. Take a look
at the www.sctp.org web page and you can find a mozilla and an apache that
use the TCP style and don't even know that they are using SCTP. We have
also somewhere in our backlog of things to put on the web site a
ftp/ftpd and openssh.. all with simple changes to the socket() call to make
SCTP be used..

I think SOCK_DGRAM just plain implies that one would open it and read.. much
like our UDP style. Tradition in the network coding world dicatates that
SOCK_STREAM is connection oriented with the accept()/connect()/listen() 
calls.

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 01 Nov 2002 09:34:40 -0600

>IMO recv/read/readv/recvmsg should have the same semantics for the same service type.

If you look closely at a TCP service style.. the same service is being 
offered by
the SCTP model as well... TCP NEVER returns a two seperate messages... 
there is
always either the whole message read or some number of parts.. of course 
there is
always only one message :-)

This IS consistent with what SCTP is doing :->

R

---

From: Chuck Winters <[email-masked]>
Date: Fri, 1 Nov 2002 13:11:02 -0500

On Fri, Nov 01, 2002 at 09:34:40AM -0600, Randall Stewart (cisco) wrote:
<snip>
> This IS consistent with what SCTP is doing :->

Nice point :)
That's like following the letter of the law instead of the spirit of the law.

Chuck

---

From: Chuck Winters <[email-masked]>
Date: Fri, 1 Nov 2002 13:57:52 -0500

Hello All,
  So, I decided to take lunch and think about my position a little more.  I 
looked at this page:
  http://www.opengroup.org/onlinepubs/007904975/functions/socket.html
to get a little guidance on the subject, and this is what I found:

    The type argument specifies the socket type, which determines the 
    semantics of communication over the socket. The following socket 
    types are defined; implementations may specify additional socket types:

    SOCK_STREAM
      Provides sequenced, reliable, bidirectional, connection-mode byte streams, 
      and may provide a transmission mechanism for out-of-band data.
    SOCK_DGRAM
      Provides datagrams, which are connectionless-mode, unreliable messages of 
      fixed maximum length.
    SOCK_SEQPACKET
      Provides sequenced, reliable, bidirectional, connection-mode transmission 
      paths for records. A record can be sent using one or more output operations 
      and received using one or more input operations, but a single operation never 
      transfers part of more than one record. Record boundaries are visible to the 
      receiver via the MSG_EOR flag.

  So it seems that SCTP fits best into the SOCK_SEQPACKET category.  Being that that
is already in use, it is a choice between SOCK_DGRAM and SOCK_STREAM.  Then I began
trying to decide how I liked my words prepared(that way they tasted good when I ate
them).  I had seen on a few pages that ATM had the idea of adding SOCK_CONN_DGRAM to
the sockets api.  That seems like that would be a better match than both SOCK_DGRAM 
and SOCK_STREAM.

Later,
Chuck

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 01 Nov 2002 14:18:19 -0600

....
> the sockets api.  That seems like that would be a better match than both SOCK_DGRAM

Considering that SCTP provides a new type of service that did not exist
in the traditional IP transport protocols, I'd expect that some new
definitions in sockets will be created and people will pick them up
gradually. I.e., we do not need to be constrained by what is there.

-Qiaobing

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 01 Nov 2002 14:54:27 -0600

Chuck:

With the idea that we did NOT want to define a new type.. you can see
our delima

SOCK_SEQPACKET fits one of our styles no problem.. we elected to
use it with UDP.

But where do you place the tcp style? The concept behind it was definetly
compatability with TCP... we wanted things to work seamlessly when
you used this model with an existing TCP app.. change the one field in
the socket() call and presto.. you are using SCTP.. So the SOCK_DGRAM
did NOT seem like the right choice... i.e. connectionless...

I will admit if we had really wanted to define a new type then probably 
moving
the tcp style to sock_seqpacket would be ok to do... but I am still happy
with our current choices... since SCTP CAN be used whereever TCP is used
and so you have one tweak to do to the app socket() call.. and it fits with
what the user expects.

If one turns on autoclose() and does a listen() then this also makes 
things look
very non-connection oriented in its own right.. aka. like a SOCK_DGRAM...

R