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

From: Jonathan Wood <[email-masked]>
Date: Mon, 25 Jun 2001 15:55:05 -0700 (PDT)

>
>With all that said, I think it is a fair statement to warn the user
>of the SCTP retrieval mechanism in the draft that some messages
>retrieved may have already been accepted by the peer app.  It also
>makes sense that, if retrieved messages are passed as ancillary data
>in recvmsg, that the retrieved data be marked with the assigned SSN
>(if any) and whether the DATA chunks was from your categories (1),
>(2) and (3) with an attribute in the ancillary data.  Retrieval

Brian,

I like this idea. Since I've just snipped lots of text,
I'll recap:

When an association closes (gracefully or non-gracefully),
and the caller has enabled SCTP_SEND_FAILED events, the contents
of the SCTP transmit queue will be returned to the caller. Section
5.3.1.4 defines the following flags for each returned message:

    SCTP_DATA_INQUEUE - When this flag is indicated the
                        data was never attempted to be
                        sent. I.e. it was never assigned
                        a TSN and sent onto the wire.

    SCTP_DATA_INTMIT  - When this flag is indicated the
                        data WAS assigned a TSN and sent
                        at least once but never acknowleged.

[ what does INTMIT stand for? ]

We should also add a third flag:

    SCTP_DATA_SACKED  - When this flag is indicated the
                        data WAS assigned a TSN and sent
                        at least once and was acknowleged
                        in a gap report, but the cumulative
                        TSN never passed it.

Sound OK?

Jonathan

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

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 25 Jun 2001 20:14:06 -0700 (PDT)

>                         a TSN and sent onto the wire.

Now looking at it, it seems that it is simpler to just say "the data
has never been sent."  "Attempted to be sent" can be confusing.  And
SCTP_DATA_INQUEUE may be confusing as data should be in the transmit 
queue whether it has been sent or not.  Maybe we should change it
to SCTP_DATA_UNSENT?

> [ what does INTMIT stand for? ]

We proabably want to avoid using TSN in the API draft because apps
do not need to care about TSN.  In section 7.3, TSN is also mentioned.
I think we should remove that.

>                         in a gap report, but the cumulative

Maybe Brian or other people familiar with the sigtran protocols
can comment on this.  Do we really need to separate the sack'ed
but not cumulatively ack'ed case?  The reason I ask is that the
receiver is free to discard sack'ed but not cumulatively ack'ed
data chunks.  And I believe it is better not talk about TSN in
the API draft.  It seems to me that making this distinction is
not that useful.  I maybe wrong.  I suggest we should include them
both as SCTP_DATA_SENT?  This has a easier to understand semantics 
for app programmers without the need to understand SCTP fully.

							K. Poon.
							[email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 26 Jun 2001 00:03:25 -0500

Jonathan,

>                         in a gap report, but the cumulative

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: Randall Stewart <[email-masked]>
Date: Tue, 26 Jun 2001 09:00:45 -0500

> [ what does INTMIT stand for? ]

I did not invent the term, La Monte was it you? But I would
guess it is IN TMIT or "in the process of being transmitted" 

At least that was my guess when I read it :-)

>                         in a gap report, but the cumulative

I like it!

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