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

From: Jonathan Wood <[email-masked]>
Date: Tue, 26 Jun 2001 14:38:42 -0700 (PDT)

> 
> > 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.
> 
> 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?

I find this clearer.

[snip]

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

I admit the difference is slim. The only reason I suggested it
was the maybe apps we haven't thought of yet might actually
find it useful.

Jonathan, easily swayed on this one.

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 26 Jun 2001 17:22:20 -0500

> > queue whether it has been sent or not.  Maybe we should change it

I too find this much crisper... 

> Jonathan, easily swayed on this one.

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.

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