Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016

[Michael Tuexen <[e-mail]>]

> On 20 Dec 2016, at 16:05, Magnus Westerlund <[e-mail]> wrote:
Hi Magnus,

thank you very much for the review. Please find my comments in-line.

Best regards
Michael
> 
> Hi,
> 
> I have reviewed -08 in this WG last call and have the following comments.
> 
> 1. Section 2.1: "Therefore a sender MUST NOT have more than
>      2**31 - 1 fragments of a single user message in flight."
> 
> This document uses in "in flight" at three places. I fail to find a definition of this in this document nor in RFC 4960, that also use it in a couple of places. I think the right way forward here is probably to include this issue as one that should be clear in the updated 
I added a clarification for in flight for messages:
A message is considered in flight, if at least on of its I-DATA chunks is not
acknowledged in a non-renegable way.
And for fragments:
A fragment is considered in flight, if it is not
acknowledged in a non-renegable way.
> version of RFC 4960. I do consider this a clarity issue if not addressed. Even if I wonder if it is at all possible to violate it, as the TSN is not larger field than the FSN.
You could have TSN wrap arounds.
> 
> 2. Section 2.2.2:
> 
>   The sender MUST NOT be fragmenting more than one user message in any
>   given stream at any time.  At any time, a sender MAY fragment
>   multiple user messages, each of them on different streams.
> 
> If I have read this document correctly, the above implies something that maybe should be made more clear. If one has unordered messages, one could in fact have a transmission schedule for a single stream that looks like this (MID/FSN):
> 
> 0/0
> 1/0
> 0/1
> 2/0
> 0/3
> 
> In other words on the same stream have one large fragmented messages, and multiple non-fragemented messessages overtaking the large fragmented one?
> 
> I wonder if this should be clarified as being allowed.
It is not intended to interleave messages of the same stream. The intention is to allow interleaving of messages from
different streams. So the example you are giving is not allowed.
Section 2.2.2 says:
This way messages from other streams may be interleaved with the fragmented message.
Please note that this is the only form of interleaving support. For example, it is not possible
to interleave multiple ordered or unordered user messages from the same stream.

To make things clearer, I have added to section 2:
<t>The protocol mechanisms described in this document allow the interleaving
of user messages sent on different streams. They do not support the interleaving
of multiple messages (ordered or unordered) sent on the same stream.</t>
> 3. Section 2.2.3:
> 
>   Upon reception of an SCTP packet containing an I-DATA chunk if the
>   message needs to be reassembled, then the receiver MUST use the FSN
>   for reassembly of the message and not the TSN.
> 
> This above assumes that one has identified first the stream based on SID, and then using the MID of the I-DATA to determine the message the chunk actually contains. It might be a point to clarify these assumptions going into the above sentence.
OK. Done. Text changed to:
<t>Upon reception of an SCTP packet containing an I-DATA chunk whose
user message needs to be reassembled, the receiver MUST first use the SID to
identify the stream, consider the U bit to determine if it is part of an ordered
or unordered message, find the user message identified by the MID and finally
use the FSN for reassembly of the message and not the TSN.
> 
> 4. Section 3:
> 
> There appear to be an assumption here that isn't made clear. Namely that the sender side implementation and the application using the SCTP implementation instance is the one that selects which stream scheduler to use. There is no negotiation, not even protocol level indication to the receiver for what is being used. That means that for applications that has dependency on what stream scheduling behaviors the far sender has, needs to communicate that out-of-band or on top of the established association between the instances.
You are right. The receiver doesn't know what scheduler is used by the peer. It can even change during the lifetime of
the association. In the WebRTC use case it is simple. The specification tells both sides which scheduler to use.
> 
> To be clear I don't have a pressing case where this would be a problem, but I think it should be made explicit these assumptions.
I added the following clarification:
<t>The selection of the stream scheduler is done at the sender side. There
is no mechanism provided for signalling the stream scheduler being used
to the receiver side or even let the receiver side influence the selection
of the stream scheduler used at the sender side.</t>
> 
> 5. Section 3.2:
> 
>   When not using user message interleaving, this scheduler provides a
>   fair scheduling based on the number of user messages by cycling
>   around non-empty stream queues.  When using user message
>   interleaving, this scheduler provides a fair scheduling based on the
>   number of I-DATA chunks by cycling around non-empty stream queues.
> 
> I think this description is insufficient to produce a behaviour that is consistent between implementors. I find it lacking in explanation on a couple of different aspects.
> 
> A. Ordering of the stream specific queues. When a message is added to a stream that had nothing queued, is that stream handled in stream ID order, or is the stream added as the last in the list/ cyclic queue of the current streams having data to send?
I think you can do either. It results in the same overall behaviour. So it is left implementation specific.
> 
> B. The behaviour when adding chunks to a packet. For non interleaved, I assume this one will add a DATA chunk from the next stream, assuming it will fit within in MTU boundaries, else send. For I-DATA should one fill up the packet to the MTU boundary and then send the 
If you have space in the packet you can even put a DATA chunk in the packet, which contains the beginning of the next user message.
It doesn't have to be a complete user message.
> packet, independently how many bytes of message data that fits?
When using I-DATA, you just select the next stream after sending each I-DATA chunk.
> 
> 
> 6. Section 3.3:
> 
>   This is a round-robin scheduler but bundles only DATA or I-DATA
>   chunks referring to the same stream in a packet.  This minimizes
>   head-of-line blocking when a packet is lost because only a single
>   stream is affected.
> 
> In this case, for non-interleaved, am I allowed to fit the next message into the SCTP packet, if it can fit in the remaining size before MTU, or does this scheduler result in under utilized packets?
As long as the next message belongs to the same stream, you can put it in.
> 
> For fragmented, I will assume that I am allowed to fill one packet worth of chunks from this stream, independent of how many messages that implies?
Yes.
> 
> 7. Section 3.5:
> 
>   This
>   scheduler considers the lengths of the messages of each stream and
>   schedules them in a certain way to maintain an equal bandwidth for
>   all streams.
> 
> Is the above taking only the scheduled for transmission into account, or is also past transmissions relevant in the scheduling decision between streams?
That is left implementation dependent. The goal is that all streams get an equal bandwidth within some time
constraints.
> 
> 8. Section 4.3.1:
> 
> Some implementations might
>   therefore put some restrictions on setting combinations of these
>   values.
> 
> This doesn't appear to be sound API definitions. Wouldn't it be clearer to actually either require to option to be set prior, or alternatively, setting this, causing the other to also be set to avoid issues?
Implementations might do this differently or have different principles of protecting the user.
In FreeBSD, for example, we fail the enabling of the user message interleaving if the interleaving
level is not set to 2. The automatic change of other variables is something I'm not preferring.
I have added a sentence which describes a save way to enable it:

Setting the interleaving level to at least 2 before enabling the negotiation of
user message interleaving should work on all platforms.
> 
> 9. Section 6:
> 
>   This document does not add any additional security considerations in
>   addition to the ones given in [RFC4960] and [RFC6458].
> 
>   It should be noted that the application has to consent that it is
>   willing to do the more complex reassembly support required for user
>   message interleaving.
> 
> I think this is an insufficient security consideration section. It hints at a receiver resource exhaustion attack. I think that should be made clear what this attacks entail, and what mitigations that can be considered.
OK. I changed the text to:
<t>It should be noted that the application has to consent that it is willing
to do the more complex reassembly support required for user message
interleaving. When doing so, an application has to provide up to two reassembly
buffers (one for ordered messages, one for unordered messages) for each incoming
stream. It has to protect itself against these buffers taking too many resources.
If user message interleaving is not used, only a single reassembly buffer needs
to be provided. But the application has to protect itself for excessive resource
usages there too.</t>
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>