Subject: [tsvwg] comments draft-tuexen-tsvwg-sctp-prpolicies-01

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 9 Jul 2013 21:22:32 -0400

Hi,

Looks good.
I have an unrelated question since a mention occurs in the
sprstat_abandoned_sent stats):
does it make sense to abandon a message that is partially sent? At the
receiver, I am
assuming if such a  partial message was to make it, partial delivery will
be made to
the socket user?

cheers,
jamal

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 10 Jul 2013 09:42:19 +0200

On Jul 10, 2013, at 3:22 AM, Jamal Hadi Salim <[email-masked]> wrote:

> 
> Hi,
> 
> Looks good. 
> I have an unrelated question since a mention occurs in the sprstat_abandoned_sent stats): 
> does it make sense to abandon a message that is partially sent? At the receiver, I am
> assuming if such a  partial message was to make it, partial delivery will be made to
> the socket user?
Ji Jamal,

you have to distinguish between the sender and receiver side.

Assume the sender sends a user message which is approximately of size 3*MTU.
So SCTP will fragment it into 3 DATA chunk and send them. If the user
has specified that the number of retransmissions is limited to 0 and
the last fragment gets lost in the network, the sender will increment
sprstat_abandoned_sent.

What will happen at the receiver side if you assume that the first two
fragments have been received. If partial delivery was started, you will
get a SCTP_PARTIAL_DELIVERY_EVENT event indicating SCTP_PARTIAL_DELIVERY_ABORTED.
Without partial delivery being started, the receiver could also drop the
first part of the message.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 10 Jul 2013 12:42:52 +0200

On Jul 10, 2013, at 11:48 AM, Jamal Hadi Salim <[email-masked]> wrote:

> 
> Hi Michael,
> 
> On Wed, Jul 10, 2013 at 3:42 AM, Michael Tuexen <[email-masked]> wrote:
> 
> Ok,  so the last fragment essentially doesnt get acknowledged before we 
> abandon ship. And the other stat indicates we abandoned while we still had some
> sitting locally. Is the intersection of the two (some are sent but not acked and
> some are still sitting locally) implying both stats will be incremented?
I think there is no intersection:
Either a fragment has been sent or no fragment has been sent. Depending
on this, the corresponding counter has incremented.
> 
> Other than the perceived ambiguity -  why do i care to know about the
> two types of abandoned messages in a user app? I  will have to sum
> those two, so why not just give me one stat?
Differentiating between unsent and sent makes sense. For unsent you
know for sure that the message has not been received by the peer.
For sent messages, you don't know (for example, the SACK could have
been lost).
I'm not giving you one stat because:
* if you want only one, adding them is not too hard.
* the SCTP_SEND_FAILED_EVENT event gives you also an indication
  whether the user message was sent or not. This stats is something
  like a summary.
>  
> BTW: the doc will benefit from such a small description as you gave me
> above.
OK. I'll add some text.
> You answered the essence of my question.
> Silly follow up: I am assuming that event will come with an EOR?
Events should have the MSG_EOR flag set if the buffer provided was
large enough.

Best regards
Michael
> To use your example (at receiver):
> EPOLLIN, recvmsg chunk1, chunk2, EAGAIN
> EPOLLIN, recvmsg SCTP_PARTIAL_DELIVERY_EVENT, EOR
> 
> cheers,
> jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 10 Jul 2013 05:48:37 -0400

Hi Michael,

Ok,  so the last fragment essentially doesnt get acknowledged before we
abandon ship. And the other stat indicates we abandoned while we still had
some
sitting locally. Is the intersection of the two (some are sent but not
acked and
some are still sitting locally) implying both stats will be incremented?

cheers,
jamal

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 12 Jul 2013 17:21:57 +0200

> BTW: the doc will benefit from such a small description as you gave me
The new revision contains some clarification:
http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-prpolicies-02

Best regards
Michael

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 12 Jul 2013 14:14:57 -0400

Hi Michael,
I think this addresses my earlier comments (and thanks for the responses on
the other questions earlier).

cheers,
jamal