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

[Magnus Westerlund <[e-mail]>]

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

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.

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.

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.

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.

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?

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 packet, 
independently how many bytes of message data that fits?


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?

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?

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?

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?

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.

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