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

From: [email-masked]
Date: Thu, 8 Dec 2016 07:36:28 -0000

This mail announces a TSVWG Working Group Last Call (WGLC) on:

             Stream Schedulers and User Message Interleaving for SCTP
             draft-ietf-tsvwg-sctp-ndata
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata

This WGLC will last for 2 weeks weeks.

Comments should be sent to the [email-masked] list, although purely
editorial comments may be sent directly to the authors. Please cc: the
WG chairs at [email-masked]  if you would like the chairs to
track such editorial comments as part of the WGLC process.

No IPR disclosures have been submitted directly on
draft-ietf-tsvwg-sctp-ndata.

Thanks,
Gorry
(TSVWG Co-Chair)

---

From: Irene Rüngeler <[email-masked]>
Date: Wed, 14 Dec 2016 12:49:11 +0100

Hi,

I have worked with the draft before and took it to implement I-DATA chunks in wireshark. I also wrote some tests for I-DATA in packetdrill and tested the FreeBSD stack.
I have read the draft and do not have technical comments. I sent my editorial comments to Michael Tuexen.

Best regards,

Irene Ruengeler

> Am 08.12.2016 um 08:36 schrieb [email-masked]:
> 
>

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 15 Dec 2016 09:13:14 +0100

> On 14 Dec 2016, at 12:49, Irene Rüngeler <[email-masked]> wrote:
> 
> Hi,
> 
Hi Irene,

thanks a lot for your comments. They have been incorporated.

Best regards
Michael

---

From: Felix Weinrank <[email-masked]>
Date: Mon, 19 Dec 2016 13:22:14 +0100

Hi all,

I used the draft to implement the I-DATA extension in the INET Framework 
for the OMNeT++ simulation environment.
This includes both; the User Message Interleaving and the Stream Schedulers.
In addition to the usage within the simulation environment, we 
successfully tested our implementation with the FreeBSD kernel 
implementation.

Best regards
Felix

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 19 Dec 2016 19:09:52 +0100

> On 19 Dec 2016, at 13:22, Felix Weinrank <[email-masked]> wrote:
> 
> Hi all,
> 
> I used the draft to implement the I-DATA extension in the INET Framework for the OMNeT++ simulation environment.
> In addition to the usage within the simulation environment, we successfully tested our implementation with the FreeBSD kernel implementation.
Any comments?

Best regards
Michael

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 Dec 2016 16:05:44 +0100

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  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Proshin, Maksim" <[email-masked]>
Date: Tue, 20 Dec 2016 15:38:02 +0000

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 <[email-masked]<mailto:[email-masked]>>
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: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Hi,

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:

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?

3. Section 2.2.3:

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:

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:

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

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:

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:

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  +46 10 7148287<tel:%2B46%2010%207148287>
Färögatan 6                 | Mobile +46 73 0949079<tel:%2B46%2073%200949079>
SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>
----------------------------------------------------------------------

---

From: Felix Weinrank <[email-masked]>
Date: Wed, 21 Dec 2016 23:43:39 +0100

No additional comments, the previous comments already covered mine.
Especially Michael Welzl's comment to describe the WFQ more precisely is 
an important point for me.