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

From: Michael Tuexen <[email-masked]>
Date: Mon, 6 Jul 2015 20:53:31 +0200

> On 31 Mar 2015, at 17:18, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> 
> I have reviewed draft-ietf-tsvwg-sctp-ndata-03 and have the following
> comments:
Hi Magnus,

thank you very much for your review. Please see my comments in-line.

Best regards
Michael
> 
> 1. Section 2.1:
> 
>   Reserved: 16 bits (unsigned integer)
>      This field is reserved.  It SHOULD be set to 0 by the sender and
>      ignored by the receiver.
> 
> 
> I think this really needs to be written as:
> 
>   Reserved: 16 bits (unsigned integer)
>      This field is reserved.  It MUST be set to 0 by the sender and
>      MUST be ignored by the receiver.
Text taken.
> 
> The reason is that unless you can guarantee pre-extended senders is not
> sending a set bit, you can't use a set bit to have semantics. In
> addition the ignore part is important. Possbily the reason for this,
> i.e. for future extension should be included in text
We use the "set to 0 on the sender side and ignore at the receiver side"
in several other RFCs without explanation. So I would prefer to keep
it consistent. 
> 
> 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?
No sure if you are referring to the incoming or outgoing stream.
If the user requests an outgoing stream to be reset, all messages
already given to the stack will be delivered before the reset operation
happens. That is described in RFC 6525.
> 
> 3. Section 3:
> 
> The whole section is a To Be Done.
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.
I need to go through the email conversation. If I remember it correctly,
his point wasn't clear to me. I gig through the archive...
> 
> 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]
> ----------------------------------------------------------------------
> 
>

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 6 Jul 2015 20:56:56 +0200

> On 18 May 2015, at 15:38, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> Hi,
> 
> I could not find any follow up to this message.
> Have I missed it ?
> 
>> 
>> 2. Section 2.3.2:
>> 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)
My understanding is that the sequence of the user interactions (send calls/
trigger stream reset operation) is important, not the time the TSN is assigned,
since this is not observable by the user. Let me dig through RFC 6525, this
might be related to an upcoming code change in the stream reset handling in
FreeBSD I'm going to work on at the Hackathon...
> 
> 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:
>> 
>> 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 ?
I also need to figure out what his issue actually was.

Best regards
Michael
> 
> 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
>>

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Mon, 13 Jul 2015 14:29:47 +0200

HI Michael,

>>> 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?
>>>
>> 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)
[Karen ] So I think that we are both saying that the stream reset need to
happen only after
the last prior send message on the stream has been transmitted or at least
have been assigned with a TSN
and the new situation with the scheduling (anything but FIFO) is that to
obey the scheduling principle defined (whatever it is)
then this means that the TSN assignment may need to be pending and thus also
the stream reset may need to be pending. Correct ?

BR, Karen

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

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 13 Jul 2015 15:02:50 +0200

> On 13 Jul 2015, at 14:29, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> HI Michael,
> 
>>>> 
>>>> 2. Section 2.3.2:
Correct.
> the stream reset may need to be pending. Correct ?
Correct.
RFC 6525 is very vague on this...

Best regards
Michael