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

[Michael Tuexen <[e-mail]>]

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

> 
> Hi Michael,
> 
> On Wed, Jul 10, 2013 at 3:42 AM, Michael Tuexen <[e-mail]> wrote:
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> 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