Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-sctp-ndata-03

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Mon, 18 May 2015 15:38:08 +0200

Hi,

I could not find any follow up to this message.
Have I missed it ?

>
>2. Section 2.3.2:
>   When an association resets the SSN using the SCTP extension defined
>   in [RFC6525], the two counters (one for the ordered messages, one for
>   the unordered messages) used for the MID MUST be reset to 0
>   correspondingly.
>
>What happens to messages that are fragmented and partially delivered when
>the reset is requested? Is the reset happening after the message, or is it
>discarded. What about an interleaved set of in flight messages?
>
[Karen ] I suppose that the SCTP receiver will enter "deferred reset
processing" as of RFC6525 and
will complete whatever partial delivery processes that it has ongoing,
releasing all such once the last assigned TSN number
of sender is reached cumulatively.

I wonder if RFC6525 and/or this draft need to clarify what shall happen
when SCTP(*) progresses  a  request for reset of outgoing SSN/MID on a
stream
 and there is outgoing data on the stream which has not had a TSN assigned
yet ?

(* SCTP sender has received request from UL -OR - SCTP receiver has received
request from peer for Incoming SSN/MID reset)

If TSNs are assigned (on the stream in question) in SCTP sender prior to
sending the reset of outgoing SSN/MID request (on the stream in question),
then _I think_ that there would be no issues with interleaving or partial
delivery at receiver side as such would complete prior to that the
last assigned TSN has been cumulative received.

>3. Section 3:
>
>The whole section is a To Be Done.
>
>4. Section 6.
>
>Is the risks discussed in the thread that Mo started really fully
>mitigated. Can't
>a malious sender deadlock the thread with any of the schedulers? Also, what
>possibilities to starve some messages exists by playing with others? Please
>consider a bit more what the implication of this extension is.
>
[Karen ]  Could you elaborate on what the perceived problem is ?
If a malicious sender deadlock himself - I am probably not so very
concerned - or ? - but are you referring to
that when multiple users uses the one and the same SCTP association, then it
should require a special privilege to
define the stream scheduler as this may impact all users and may unfairly
favor some streams ?

One thing which I would have liked for was that the scream priority
scheduler, i.e.,  SCTP_SS_PRIORITY, would be coupled (at
least by default) to the  Priority Policy of RFC7496. I.e., meaning that a
message written on a particular stream, when  SCTP_SS_PRIORITY
was set, by default would inherit the stream priority as RFC7496 Priority
(when RFC7496 Priority was invoked also).
But this anyway is only an optimization - (an optimization which some then
may consider a sub-optimization).

Thanks Karen

>Cheers
>
>Magnus Westerlund
>
>----------------------------------------------------------------------
>Services, Media and Network features, Ericsson Research EAB/TXM
>----------------------------------------------------------------------
>Ericsson AB                 | Phone  +46 10 7148287
>Färögatan 6                 | Mobile +46 73 0949079
>SE-164 80 Stockholm, Sweden | mailto: [email-masked]
>----------------------------------------------------------------------