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

From: Jonathan Wood <[email-masked]>
Date: Mon, 25 Jun 2001 22:24:12 -0700 (PDT)

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.
> > 
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 26 Jun 2001 01:15:45 -0500

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

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Jacob Heitz <[email-masked]>
Date: Tue, 26 Jun 2001 08:15:18 -0700

Please allow retrieval after abort.

---

From: Randall Stewart <[email-masked]>
Date: Tue, 26 Jun 2001 11:27:49 -0500

Jacob:

I feel we WILL put this in (if it is not already there).. I
think if you allow data retrieval you MUST have a complete
implementation of it...

R

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 26 Jun 2001 11:31:30 -0500

Jacob,

Why?

-- 
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 ¦

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 26 Jun 2001 11:55:04 -0500

Randall,

Then retrieval *during* abort or shutdown should
also be added to complete the implementation. 
This would permit operation at least equivalent to 
SSCOP.  I can hardly wait to see how that is
shoe-horned into the sockets API.  I don't believe
that the sockets API even provides a mechanism for
reseting a TCP connection under user whim.

--Brian

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 26 Jun 2001 11:47:00 -0700 (PDT)

> reseting a TCP connection under user whim.

Brian, can you explain what you meant by "during" abort or
shutdown?  After the app uses sendmsg() to abort the association,
it is considered done in the local host.  SCTP stack will send
the ABORT immediately.  The proposed change is to allow the
app to retrieve unsent data.  Suppose the app uses shutdown(SHUT_WR)
to shutdown an association.  The proposed change is to allow the
app to continue to receive data.  Is your "during" related to the
app level protocol?

BTW, to reset a TCP connection, just set SO_LINGER value to 0
and then do a close().  The connection will be reset immediately.

							K. Poon.
							[email-masked]

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 26 Jun 2001 16:41:30 -0500

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 26 Jun 2001 19:29:28 -0500

Hmmm,

I was thinking on the case where you receive
the abort.. but I guess it is really the case you
illustrate..  which is already covered..

R

---

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

Kacheong,

> and then do a close().  The connection will be reset immediately.

Well, SSCOP (which is used for MTP3b) which has retrieval built into
the protocol and an orderly shutdown, allows retrieval after sending
a disconnect command (END) but before receiving a disconnect
acknowledgement (ENDAK).  This is roughly equivalent to allowing
retrieval after SCTP sends SHUTDOWN but before it receives SHUTDOWN
ACK.

I think that it could make sense to allow the app to request the
delivery of messages after shutdown(fd, SHUT_WR), but not actually
deliver them up until after SCTP has sent SHUTDOWN or SHUTDOWN-ACK.
Then there may be no need to try to do this ABORT thing to retrieve
messages quickly.

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 27 Jun 2001 21:53:20 -0700 (PDT)

> retrieval after SCTP sends SHUTDOWN but before it receives SHUTDOWN

Brian, can you explain more?  What is the semantics of retrieval of
data after a disconnect command?  Does it mean that if there are unsent
messages, they are returned to the app and will not be sent?  In the
case of SCTP, if SHUTDOWN is sent, all messages must have been sent.
It seems to me that the equivalent is after shutdown(SHUT_WR) is 
called, the app wants to stop sending the unsent data and retrieve
them back if the SHUTDOWN has not been sent yet.  Is this correct?  
But I don't know how it can be done in the current API...  And I don't
see the need for this.  So maybe Brian can explain more about the 
rationale for SSCOP doing that.  And if the API does not support it, is 
there a problem?  This interaction sounds really strange to me...

On the side line, does our phone system really do this kind of thing now?

> Then there may be no need to try to do this ABORT thing to retrieve

The reason for the abort is that the socket API (not just our extension)
does not have a notion of taking back what has been sent.  The best
we can extend that is if there is a failure, return the data in the
queue.  I think we really need to be careful to understand the real
need of this interaction before we come up with a solution...

							K. Poon.
							[email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 Jun 2001 01:24:43 -0500

Kacheong,

> there a problem?  This interaction sounds really strange to me...

I might be dragging you a little off topic...  SSCOP, like ISO transport
and network protocols does not have a distinction between orderly and
abortive release.  Release stops sending messages (abortive), but expects
an confirmation if possible (orderly).

> On the side line, does our phone system really do this kind of thing now?

Yes.  See, for example, Q.2140.

> need of this interaction before we come up with a solution...

Well, the API is being extended to "take back" what was sent after
the ABORT.  What is the difference in doing it as the SHUTDOWN is
sent, or as a precondition to sending a SHUTDOWN?

A more fundamental difference here is that SCTP's ACK's are for
its own use only and SCTP provides no support for application level
acknowledgements.  SSCOP does.  ISO/NSD does.  SS7 does.  Therefore,
I believe it should be the application's responsibility to provide
its own protocol for acknowledgements and perform its own buffering.
This is what normal TCP applications do today.

Drop retrieval from the API altogether.  It is something that the
API was never intended to perform because of the lack of support
for acknolwedged data transfer (where in the ISO sense, acknowledged
data transfer is user-to-user acknolwedgement).  The XTI supported
this, but sockets does not.

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 28 Jun 2001 11:52:44 -0500

Kacheong Poon wrote:
...
> need of this interaction before we come up with a solution...

I tend to agree with you. To me, the only sensible scenarios for doing
data retrieval are: 

1) when there is an unexpected communication failure, i.e., the sender
gets a COMUUNICATION_LOST notification while doing data transfer; and 

2) a message with limited lifetime expired at the sender (btw, I cann't
find this message TTL support in the latest socket API draft. what
happened?).

I am still not convinced we need to support data retrieval following a
controlled shutdown or abort call.

-Qiaobing

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 Jun 2001 12:15:34 -0500

Qiaobing,

SS7 (and SSCOP) shuts down links under user control and still
performs retrieval.  This is because the application may detect
peer application errors and deem the connection unusable, but
still wants to retrieve undelivered messages and send them to
another server.  Can you provide an example of an application
other than SIGTRAN UAs which would want this mechanism?

--Brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Jacob Heitz <[email-masked]>
Date: Thu, 28 Jun 2001 10:19:01 -0700

The scenario I want to cover is when the SCTP user decides
"this association has become unsuitable for whatever reason
and some of the remaining transmit buffer should be put
on an avian carrier". When that occurs, this SCTP user wants
to shut that association down or abort it and retrieve as
quickly as possible.

-- 
// Jacob Heitz Tel:510-747-2917 Ext:72917 Home:510-888-9429

---

From: Randall Stewart at work <[email-masked]>
Date: Thu, 28 Jun 2001 12:11:30 -0500

Qiaobing:

Comments below..

> find this message TTL support in the latest socket API draft. what

Hmm... I thought we had this one in there as well.. but it looks
like we missed it :-0

> controlled shutdown or abort call.

I agree with the above.. i.e. data retrieval makes no sense to the
guy that initiated a shutdown.. or for that matter got all his
data through during a graceful shutdown from the other end.

Where it does make sense is when I get a Comm lost...

And in these situations it IS valuable to know if the data
chunk was ever sent or NOT sent at all... 

R

---

From: Randall Stewart at work <[email-masked]>
Date: Thu, 28 Jun 2001 13:53:40 -0500

Jacob:

It seems to me that once you put in the mechanism, it SHOULD
report after a COMM-Failure any packets still inqueue.

It should not matter if you caused the abort or the peer
died and caused the abort... 

If you have subscribed to the "retriveal" type mechanism
you get up the data in queue.

As I noted earlier, for ASAP, this is an important feature
that is very usefull... we need to keep all those pigeons
happy :)

R

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 28 Jun 2001 13:21:35 -0700 (PDT)

> to shut that association down or abort it and retrieve as

Jacob, correct me if I misunderstood the above.  You are asking to
end an association while SCTP still thinks that it is OK.  It
sounds to me like an abort.  And then you want to retrieve the 
data in the queue (sent and unsent).  The main difference from
the current proposed API is that it is an user induced failure,
not a failure in SCTP.  Thus it is not covered.

Before we think about how to add this to the API, can other 
people comment on this use?  I think we need more input.  Please
let us know if you know of an app or you have an app, or you plan
to have app which needs exactly this behavior, an user induced 
failure and retrieval of data.

							K. Poon.
							[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 28 Jun 2001 13:26:07 -0700 (PDT)

> died and caused the abort... 

Randy, actually there is a difference.  An user abort has the
added semantics of flushing data in the queue.  Why does an
app abort an association while SCTP still thinks it is fine?
Here comes the flush semantics as the app gives up...  So I
think we should ask people if this is needed and why.  Maybe
Jacob can fill us in about the background and an example.

							K. Poon.
							[email-masked]

---

From: Jacob Heitz <[email-masked]>
Date: Thu, 28 Jun 2001 17:15:30 -0700

M2PA requires it.
MTP3 can send M2PA a "Stop" request followed by
a "Retrieve BSNT" request and then a "Retrieve"
request.

When M2PA gets "Stop", it aborts the SCTP association.
Then MTP3 will ask it to retrieve.

MTP3 will do this sequence if it receives a changeover
order for the M2PA link from an alternate link.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 29 Jun 2001 00:46:49 -0500

Jacob,

I don't believe that the next version of the M2PA
draft will require it.

-Brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/