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

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 1 Sep 2017 15:22:51 -0500

Hi, Eric,

On Wed, Aug 30, 2017 at 8:11 AM, Michael Tuexen <[email-masked]>
wrote:

>
> > On 29. Aug 2017, at 15:09, Eric Rescorla <[email-masked]> wrote:
> >
> >
> >
> > On Tue, Aug 29, 2017 at 12:24 AM, Michael Tuexen <[email-masked]>
> wrote:
> > > On 29. Aug 2017, at 01:04, Eric Rescorla <[email-masked]> wrote:
> > >
> > >
> > >
> > > On Mon, Aug 28, 2017 at 3:39 PM, Michael Tuexen <[email-masked]>
> wrote:
> > > > On 28. Aug 2017, at 22:56, Eric Rescorla <[email-masked]> wrote:
> > > >
> > > >
> > > >
> > > > On Mon, Aug 28, 2017 at 1:42 PM, Michael Tuexen <
> [email-masked]> wrote:
> > > > > On 26. Aug 2017, at 21:21, Eric Rescorla <[email-masked]> 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.
> > > >
> > > > Perhaps you might instead say:
> > > >
> > > > The user messages within a given stream must have strictly
> increasing TSNs
> > > Not sure what you are suggesting, since TSN are assigned to chunks, not
> > > user messages.
> > >
> > > The problem here is that  your text focuses on TSN *assignment* which
> is not
> > > really the relevant property (it's an implementation artifact) rather
> what appears
> > > on the wire is. So, the requirement here seems to be that you allocate
> TSNs
> > > to fragments of user messages in order.
> > The next sentence in the document states:
> >
> > The sender MUST assign TSNs in a way that the receiver can make progress.
> > One way to achieve this is to assign a higher TSN to the later fragments
> of
> > a user message and send out the TSNs in sequence.
> >
> > The reason not to mandate this is that you might you more complex schemes
> > in case of load-sharing between multiple paths.
> >
> > That's fine, but I don't find the current text clear and this doesn't
> help. Why don't
> > you try listing the requirements on what appears on the wire from the
> receiver's
> > perspective in response to this message, and then we can discuss how to
> > write it in the doc.
> Let me make another suggestion:
>
> OLD TEXT:
>
>    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.
>
>    The sender MUST assign TSNs in a way that the receiver can make
>    progress.  One way to achieve this is to assign a higher TSN to the
>    later fragments of a user message and send out the TSNs in sequence.
>
>
> NEW TEXT:
>
>    The sender MUST NOT process (move user data into I-DATA chunks and
> assign
>    a TSN to it) for more than one user message in any given stream at any
> time.
>    At any time, a sender MAY process multiple user messages, each of them
> on
>    different streams.
>
>    The sender MUST assign TSNs to I-DATA chunks in a way that the receiver
>    can make progress.  One way to achieve this is to assign a higher TSN
> to the
>    later fragments of a user message and send out the I-DATA chunks such
> that
>    the TSNs are in sequence.
>
> Does that address your issue?
>

Michael has submitted -13 which includes this text. Diff is at
https://tools.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-ndata-13.txt.

I'm planning to send an Approved notice for -13. If you see a problem,
please let me know.

Thanks,

Spencer

>
> Best regards
> Michael
> >
> > -Ekr
> >
> > >
> > >
> > > Just considering the simple case of non-fragmented user
> > > messages, you can't guarantee that user messages of a particular stream
> > > have increasing TSNs, since there can be wrap arounds due to chunks
> > > belonging to other streams. The TSN are 32-bit numbers with serial
> arithmetic...
> > >
> > > Hmm... You don't think of these as being infinite precision but taken
> mod 2^32?
> > In most cases, yes. But I need to take into account that the numbers can
> wrap
> > and how this is handled by receivers. That is why the document states
> some
> > limitations you the number of outstanding MIDs and FSNs.
> >
> > Best regards
> > Michael
> > >
> > > -Ekr
> > >
> > >
> > >
> > >
> > > Best regards
> > > Michael
> > > >
> > > >
> > > >
> > > > > 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.
> > > >
> > > > Yeah, I thought you could but after some thought I see you cannot.
> > > >
> > > >
> > > > -Ekr
> > > >
> > > > > 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".
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 2 Sep 2017 07:24:24 -0600

LGTM

On Fri, Sep 1, 2017 at 2:22 PM, Spencer Dawkins at IETF <
[email-masked]> wrote:

>> > > On Mon, Aug 28, 2017 at 3:39 PM, Michael Tuexen <
>> > > > > email addresses included in the To and CC lines. (Feel free to
>> cut this
>> > > > > Please refer to https://www.ietf.org/iesg/stat
>> ement/discuss-criteria.html
>> > > on the wire is. So, the requirement here seems to be that you
>> allocate TSNs
>> progress.
>> > One way to achieve this is to assign a higher TSN to the later
>> fragments of
>> > In most cases, yes. But I need to take into account that the numbers
>> can wrap
>> > > > would not really help, since you still do reliable transfer by
>> using the