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

[Eric Rescorla <[e-mail]>]

LGTM

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

> Hi, Eric,
>
> On Wed, Aug 30, 2017 at 8:11 AM, Michael Tuexen <[e-mail]>
> wrote:
>
>>
>> > 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/stat
>> ement/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".
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>