Subject: [Tsvwg] sctpsocket: Returning unsent messages

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

I am unsure as to whether or not returning unsent messages
after a shutdown/abort is actually useful, mostly because I
am unclear on exactly what problem this is trying to solve.

The only problem I think of that this might try to solve
is to enable the sender to know which messages never "made
it", so it could, for example, try to resend them to a
different server.

However, this problem is not solved by returning unsent
messages, since messages that may have been sent may not
have been delivered, and even messages that the peer
has acknowleged may not have been delivered to or accepted
by the application at the other end. In other words, the
set of all unsent messages does not necessarily comprise
the set of all messages that were not delivered to the peer
application.

I would like some more information from the WG on exactly
what problem(s) returning unsent messages is trying to
solve, and how it is expected to solve them. If it turns out
that this functionality is indeed not useful, I propose we
drop it from the SCTP sockets extensions draft.

(I am not suggesting, however, that we remove the SCTP_SEND_FAILED
 notification for errors like bad stream ID, etc.)

Jonathan

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

---

From: Jacob Heitz <[email-masked]>
Date: Fri, 22 Jun 2001 16:26:35 -0700

Some implementations of M2UA on the MGC will want to
retrieve the unsent messages from a failed SCTP association
and resend them on an alternate link when doing changeover.

Of course, some messages will be dropped when doing this,
but not as many as if retrieval of unsent messages was
not available.

MTP requires that the number of dropped messages be as 
low as possible, not that it be zero.

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 22 Jun 2001 17:38:36 -0700 (PDT)

> low as possible, not that it be zero.

Note that it is not just drop, there can be duplicate too.  The
other end may have received the message but the ack never gets
back.  So I believe the app must have some form of duplicate
detection mechanism.  Does it also mean that when the changeover
happens, the app can tell the other end exactly what to resend 
instead of relying on SCTP?  If some messages are not available,
it still knows exactly how many are missing.

I think the issue here is if we want to do the extra effort to
provide an unreliable error reporting mechanism to the apps.

							K. Poon.
							[email-masked]