Re: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT)

[Michael Tuexen <[e-mail]>]

> On 26. Aug 2017, at 21:21, Eric Rescorla <[e-mail]> wrote:
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-tsvwg-sctp-ndata-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
Hi Eric,

thanks for the review. See my responses in-line.

Best regards
Michael
> TECHNICAL
> I'm not sure I am following the rules about interleaving multiple
> messages in the same flight.
> 
>   The sender MUST NOT fragment 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.
> 
> So, say I have one stream and the application sends M1 and M2 and both
> need to be fragmented, so I have M1a, M1b and M2a and M2b. Does this
> mean that I can't send M2a until M1{a,b} has been acknowledged?
No, that is not what is meant.

Assume M1 is sent before M2 and you end up in M1a (first fragment),
M1b (second fragment), M2a (first fragment) and M2b (second fragment).
You would assign the TSNs in a way that they are increasing for
M1a, M1b, M2a, and M2b. So you are not interleaving messages on
the same stream. That is the point. So you would not send them as
M1a, M2a, M2b, M1b. You should also not send M1a, M2, M1b (assuming
that M2 doesn't need to be fragmented).

I agree, the above text is not as clear as possible. So what about stating
it as:

  The sender MUST NOT assign TSNs to more than one user message in any given
  stream at any time.  At any time, a sender MAY assign TSNs to multiple user
  messages, each of them on different streams.

> If so what's the need for that requirement? It seems like you could
The reason for this limitation is:
* It is enough to make streams independent of each other as for
  example required for WebRTC
* If you would allow interleaving of messages on the same stream
  you would also need to allow this in the upper layer API of
  SCTP. We did not want to make this API more complex for the user
  as it is already specified in RFC 6458.
  When keeping the API as specified in RFC 6458 but allowing
  the interleaving of user messages within a stream you are
  allowing deadlocks.

During the work on the extension we considered removing this restriction,
but decided it is not worth it. We even considered to allow the interleaving
of an ordered and unordered message. However, that you have required to
add a new interleaving level in
https://tools.ietf.org/html/rfc6458#section-8.1.20
and we decided that it is simpler and cleaner to stick to the interleaving
of messages from different streams.

I just double checked the document and the is a left over in the security
considerations:

   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.

this needs to be changed to:

   When doing so, an application has to provide
   a reassembly buffer for each incoming stream.

> use MID to reassemble correctly. And given this requirement, why do
> you need MID?
You need some id to know which fragments belong to the same
user message. You can't derive that from the TSN.
> 
> 
> Because fragementation is indicated by index, not range,
> what happens if you have to reduce MTU? So, say I have a message of
> size 2K which I fragment into 1K/1K and then I have to decrease
> my MTU to 512 bytes?
SCTP can't adopt, so IP fragmentation will be used.

The reason is that once you sent a DATA chunk or an I-DATA chunk
you assigned a TSN will is used for reliable transfer. So you
have to retransmit it and you can't change the user data contained
in it. This has not changed from the base spec.

Changing the information from index to range for handling reassembly
would not really help, since you still do reliable transfer by using the
TSN assigned to the DATA or I-DATA chunk and you need to retransmit it.
> 
> 
> EDITORIAL
> I think it would be helpful to indicate that B has to be
> set for the first chunk in S 2.1. Or perhaps move the overview of
> how the sender behaves in S 2.2.2 up in the document?
Considering this comment and the ones I got from other people
it seems like referring to RFC 4960 and RFC 7053 for the fields
which haven't changed and only describing the new fields doesn't
seem to work well.

I'll add text describing the "old fields".
> 
>