Subject: [Tsvwg] struct sctp_status

From: Michael Tuexen <[email-masked]>
Date: Sun, 16 Nov 2008 16:52:56 -0600

Dear all,

the current version of the Socket API says:

    struct sctp_status {
      sctp_assoc_t sstat_assoc_id;
      int32_t sstat_state;
      uint32_t sstat_rwnd;
      uint16_t sstat_unackdata;
      uint16_t sstat_penddata;
      uint16_t sstat_instrms;
      uint16_t sstat_outstrms;
      uint32_t sstat_fragmentation_point;
      struct sctp_paddrinfo sstat_primary;
    };

    sstat_unackdata:  This is the number of unacked data chunks.
    sstat_penddata:  This is the number of data chunks pending receipt.

This is not clear to be, what the returned values mean. As a  
clarification
I'm suggesting to replace it by

<t hangText="sstat_unackdata:">
This is a flag indicating if there is data in the send buffer
which is not yet acknowledged by the peer.</t>

<t hangText="sstat_penddata:">
This is the number of messages which can be read without blocking.</t>

Any comments?

Best regards
Michael

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 17 Nov 2008 08:29:57 -0500

Michael Tuexen wrote:
> This is not clear to be, what the returned values mean. As a clarification

That's not how this was interpreted in lksctp, which I means that
clarification is really needed.

The way lksctp implementers interpreted 'sstat_penddata' is more along
the lines of number of data missing chunks.  This has been useful to some
adaptation layer implementations.

I don't have an issue with clarifying the definitions though.

-vlad

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 17 Nov 2008 08:33:12 -0600

Hi Kacheong,

keeping the others in the discussion...

Comments in-line.

Best regards
Michael

On Nov 17, 2008, at 7:44 AM, Kacheong Poon wrote:

> Michael Tuexen wrote:
>
>> The problem is that the user only deals with user messages, not
>> DATA chunks.
>> The BSD stack can have 3 user messages queued and 3 DATA chunks
>> which are the last ones from one user message being fragmented
>> into 6 chunks. So, what would you report? 3,5?
>> Currently the text is not clear (to me) at all, so as a user
>> I can not use this field...
>
>
> The current text is about "data chunks."  So in the example
> above, it will report 2 + 6.  If you want it to be message,
> I guess it can be changed to that too.  A message fragmented
> into multiple data chunks is only considered as ack'ed if
> all those chunks are ack'ed.
I would prefer messages, because that is what the user sees.
So you are suggesting:
sstat_unackdata:  This is the number of complete messages not being  
completely acked.
>
>
>
>
>> The <t  > stuff comes from the .xml file I use to write the ID...
>> Yes I change from chunks to messages, since the user only see user
>> messages, not how many chunks were used to transport the message.
>> But it comes now up: What if I can only get the first part of a
>> user message?
>
>
> I guess we can limit it to complete messages.
>
>
>> Do you have an idea what to write?
>> Or should be leave out these field at all?
>
>
> They are already there.  So I'd prefer not to leave them out.
> I guess we can use something like
>
>
> sstat_unackdata:  This is the number of sent but unacked messages.
See my above suggestion.
>
> sstat_penddata:  This is the number of complete messages which can
>                 be read without blocking.
OK.

Any comments? Peter? Vlad? Randy?
> -- 
> 						K. Poon.
> 						[email-masked]

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 17 Nov 2008 10:10:02 -0500

>> sstat_unackdata:  This is the number of sent but unacked messages.

It's not the messages that are acknowledged, but the chunks.  I would
prefer keeping it in terms of chunks and I've already seen usages of
this in terms of chunks.

>>                 be read without blocking.

This one is still weird.  What happens to this statistic of partial
reads?  Do notifications count against this statistics (they are
messages after all)?

-vlad

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 17 Nov 2008 23:18:37 +0800

> prefer keeping it in terms of chunks and I've already seen usages of

What is the usage you referred to?  Michael suggested that
chunk is not a useful unit to an app since it does not
really need to understand how SCTP may fragment a message.

> reads?  Do notifications count against this statistics (they are

I guess it should be "data message," not any message.  And
it does not count partially read data message since the
remaining part cannot a complete data message.

-- 

						K. Poon.
						[email-masked]

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 17 Nov 2008 11:00:59 -0500

Kacheong Poon wrote:
> What is the usage you referred to?

The usage was for the app to see how many data chunks were in considered
outstanding.  The application was checking on the state of the association
to see how well behaved it was.  It was interested in chunk.

>  Michael suggested that

I don't think it valid to suggest the the application is only interested
in messages.  I've see evidence of it in multiple deployments.

-vlad