Subject: RE: [Tsvwg] sctpsocket: Returning unsent messages

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 25 Jun 2001 02:52:49 -0700

Jonathan,

I just want to make sure that this feature discussion is being argued
independently of the graceful shutdown() discussion we were having last
week. Retrieval of unsent messages is an SCTP extension to the Socket API
where the former is trying to provide a similar behavior to the existing TCP
Socket API behavior.

Robert.

-----Original Message-----
From:	Jonathan Wood [mailto:[email-masked]]
Sent:	Saturday, June 23, 2001 1:14 AM
To:	[email-masked]
Cc:	[email-masked]
Subject:	Re: [Tsvwg] sctpsocket: Returning unsent messages

OK, I see.

So my next question is: do we only want to return
1. unsent messages only
2. unsent and sent-but-not-ack'd messages
3. unsent and sent-but-not-ack'd and sent-and-SACK'd messages

3 will get you everything in the transmit queue.

It seems to me that since the problem to be solved is to
optimize changeover, 3 would be the best. Thoughts?

In any case, no matter what we choose, I need to add
some text to the draft explaining that there is no
guarantee that the returned messages comprise the set of
all messages not received by the peer application. If
apps need this, they need to add their own mechanisms.

Jonathan

> 
> 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.
> 
> Jonathan Wood wrote:
> > 
> > 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: Jonathan Wood <[email-masked]>
Date: Mon, 25 Jun 2001 15:46:17 -0700 (PDT)

>where the former is trying to provide a similar behavior to the existing TCP

Robert,

Yes, it is independant of the graceful shutdown() discussion.
It is related, however, to the issue of non-graceful shutdowns.
If unsent retrieval was not necessary, I was going to make
the argument that close(linger = 0) would suffice for non-
graceful shutdowns.

However, it looks like it may be useful to retrieve unsent
messages after aborting an association, so we still need
a mechanism for this. I'll continue this conversation in
the shutdown() thread.

Jonathan

---

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

Jonathan,

I will eagerly await the new draft.

--brian

Jonathan Wood wrote:                          (Mon, 25 Jun 2001 22:29:35)
> 
> Actually, unsent retrieval is no longer via ancillary data. The
> latest TSVWG draft has the right semantics and is considerably
> better WRT to the problems you've pointed out (although there
> is still room for tightening it up, I'll admit).
> 
> There are still a few places that we missed in the cleanup, and
> it's still referred to as ancillary data, but these should be
> all fixed in the -01 version, to appear soon. Mike Bartlett
> pointed out a number of these.
> 
> > 
> > Well, that would indicate the three situations; however, I don't totally
> > agree with section 5.3.1.4 anyway.  There isn't much point for an
> > ssf_type when there is a type in the cmsg structure.  There isn't much
> > point for a ssf_length field when there is already a length in the
> > cmsg structure which spans the entire ancillary data.  No point for
> > an ssf_error field (which has no defined values).  UNIX error codes
> > should suffice.  The ssf_data field is heavily underdefined.  Does this
> > contain the data sent by the user?  What part of it?  The part that
> > was sent in a fragment and absorbed in the sendmsg call?  The part
> > that was sent and acknowledged after SCTP fragmented it?  The part
> > that was sent by SCTP after SCTP unfragmented it?  An entire MTU
> > of data?  The entire data (TSDU)? (could be big).  What about truncation
> > of cmsg data on recvmsg?
> > 
> > I agree with the principle, but the syntax and semantics needs a lot
> > of work.
> > 
> 

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

---

From: [email-masked]
Date: Wed, 27 Jun 2001 12:55:54 +0300

> > > I see no reason NOT to add the SACKED as well. The information is
> > > there, you are already passing up chunk status.. why not
> > > have it passed up as well.
> > 
> > The main reason I think is that it is a good idea not to 
> expose protocol
> > details to apps if possible.  And as I pointed out 
> previously, something
> > sack'ed really does not mean much.  Data can be discarded or data
> > may not be able to be delivered to the app because of 
> ordering issue.
> > So this is kind of ambiguous.  Brian and other have pointed out that
> > there is an app level control to deal with this ambiguity if an app 
> > chooses to do this retrieval.  I don't see why we need to complicate
> > the API for the little ambiguous info.
> 
> Well its a little late to start stopping the exposing 
> protocol details.
> 
> It may, unfortunately, be necessary for some application to know which
> messages may have been delivered to the user on the other side.  With
> multiple streams the only way to determine this at present is to check
> which sacked messages contain contiguous SSNs for the streams 
> in question.
> Also, an application may want to do retrieval for some streams but not
> for others.  I don't know how to provide this information across a
> socket API without exposing some SCTP protocol details.

	I think that's the main difference... First of all, you only keep
the acknowledged chunks that have been SACKED (the others have been erased
already). But I guess that it could be a better (and somewhat more
complicated) information to give not just if the TSN has been SACKED, or
not, but if it has been delivered to the peer (unless the peer specifically
refused it), as Brian says, depending on its SSN.

	For me there isn't that big difference between not acknowledged TSNs
and acknowledged TSNs that are ordered but couldn't be passed to the peer's
upper user because not all the TSNs of its SSN arrived, or any other
previous SSN wasn't delivered for this same reason... of course, on a per
stream basis.

	BR Iván Arias Rodríguez