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

["Proshin, Maksim" <[e-mail]>]

Hi Magnus,


Just a clarification to the first comment:

"in flight" term is already covered in draft-ietf-tsvwg-rfc4960-errata-01


BR, Maxim



---------- Forwarded message ----------
From: Magnus Westerlund <[e-mail]<mailto:[e-mail]>>
Date: Tue, Dec 20, 2016 at 6:05 PM
Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016
To: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<tel:%2B46%2010%207148287>
Färögatan 6                 | Mobile [phone]<tel:%2B46%2073%200949079>
SE-164 80 Stockholm, Sweden | mailto: [e-mail]<mailto:[e-mail]>
----------------------------------------------------------------------