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

[Michael Tuexen <[e-mail]>]

> On 29. Aug 2017, at 15:09, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
> On Tue, Aug 29, 2017 at 12:24 AM, Michael Tuexen <[e-mail]> wrote:
> > On 29. Aug 2017, at 01:04, Eric Rescorla <[e-mail]> wrote:
> >
> >
> >
> > 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.
> 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?

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