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

[Eric Rescorla <[e-mail]>]

On Mon, Aug 28, 2017 at 3:39 PM, Michael Tuexen <[e-mail]>
wrote:

> > On 28. Aug 2017, at 22:56, Eric Rescorla <[e-mail]> wrote:
> >
> >
> >
> > On Mon, Aug 28, 2017 at 1:42 PM, Michael Tuexen <[e-mail]>
> wrote:
> > > 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.
> >
> > 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.


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?

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