Subject: Re: [Tsvwg] SCTP Sockets Mapping - Closure of TCP-style SCTP sock ets

From: Jonathan Wood <[email-masked]>
Date: Tue, 26 Jun 2001 15:16:04 -0700 (PDT)

It's always hard to predict how apps will use a general
API, so answering this question is hard.

The only scenario I can think of now is if you don't
want to wait for a graceful shutdown attempt to time
out before trying another server. Remember that if the
peer is not responding, it could take minutes before
a shutdown attempt finally times out.

The main reason I proposed this was for completeness.
We can gracefully shutdown a connection with either close()
or shutdown(), and retrieve data after the latter. We can
abort an association with close(linger = 0), but there is
no matching interface to retrieve data.

Jonathan

> 
> Jacob and Jonathan,
> 
> Yes, why you want to do this?
> 
> I can see the usefulness of data retrieval in the case that the peer
> **unexpected** goes away (either crashed or becoming unreachable). In
> such a case, the local endpoint will first see a COMMUNICATION-LOST
> notification from the stack and then will do a data retrieval. This
> makes a lot of sense.
> 
> But it becomes less clear to me why you want to do an Abort primitive
> call down to the the stack and then retrieve the data. This situation is
> totally under your control and thus completely avoidable. This is like
> you regret what you have pushed down the stack and want to get it back
> (like recalling an email). Should we make the API to support this kind
> of "regrettable" behavior?
> 
> -Qiaobing
> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Jacob,
> > 
> > Why?
> > 
> > On Tue, 26 Jun 2001, Jacob Heitz wrote:
> > 
> > > Please allow retrieval after abort.
> > >
> > > "Brian F. G. Bidulock" wrote:
> > > >
> > > > Jonathan,
> > > >
> > > > Why not do an orderly shutdown to retrieve unsent
> > > > data?  I don't see where abort is more useful than
> > > > orderly shutdown before retrieval.  SSCOP even allows
> > > > retrieval *while* shutting down.
> > > >
> > > > --Brian
> > > >
> > > > On Mon, 25 Jun 2001, Jonathan Wood wrote:
> > > >
> > > > >
> > > > > Retrieving unsent data.
> > > > >
> > > > > It seems to me that we need this to make unsent retrieval
> > > > > complete.
> > > > >
> > > > > I'm not crazy about it, however, so if you could convince
> > > > > me that it really isn't useful, I'd be happy...
> > > > >
> > > > > > Jonathan,
> > > > > >
> > > > > > What is the need for this?  I just can't think of why
> > > > > > an application would want to abort an association and
> > > > > > leave a the socket open...
> > > > > >
> > > > > > --Brian
> > > > > >
> > > > > > On Mon, 25 Jun 2001, Jonathan Wood wrote:
> > > > > > >
> > > > > > > In addition, we need a way to abort an association and still
> > > > > > > leave an open socket descriptor. shutdown() cannot be twisted
> > > > > > > to fill this requirement, so I propose including a MSG_ABORT
> > > > > > > flag in sendmsg(), just as UDP-style sockets do now.
> > >
> > > _______________________________________________
> > > tsvwg mailing list
> > > [email-masked]
> > > http://www1.ietf.org/mailman/listinfo/tsvwg
> > 
> > --
> > Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> > [email-masked]    ¦ world; the unreasonable one persists in  ¦
> > http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
> >                         ¦ Therefore  all  progress  depends on the ¦
> >                         ¦ unreasonable man. -- George Bernard Shaw ¦
> > 
> > _______________________________________________
> > tsvwg mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/tsvwg
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 26 Jun 2001 22:58:42 -0500

Jonathan,

I would make sense to permit retrieval once SCTP has sent
SHUTDOWN or even once shutdown(fd, SHUT_WR) has been
performed and not wait until shutdown completes.  ABORTing
an association under user control is fairly brutal and
may expose too much protocol specific behavior to the
application.  close() with linger=0 is fairly specific
app behavior: it says "I'm going away now and don't wait
around".

Because retrieval is so SS7 related, I can't imagine what
other application other than SIGTRAN UAs would want to
use retrieval.  Within SS7, (as evidenced by SSCOP), there
is no case where the SSCF aborts a connection and then
performs retrieval.  The connection can only abort due
to an error detected by SSCOP or on receipt of an error
PDU from the peer.  Otherwise, the SSCF performs an
orderly shutdown and then goes about retrieving messages.

Would you say that SSCOP is not complete?

--Brian