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

Michael Tuexen <tuexen@fh-muenster.de> Mon, 28 August 2017 22:39 UTC

Return-Path: <tuexen@fh-muenster.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A244A13213D; Mon, 28 Aug 2017 15:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXIg7xqnysUJ; Mon, 28 Aug 2017 15:39:56 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2EF51320CF; Mon, 28 Aug 2017 15:39:55 -0700 (PDT)
Received: from [192.168.1.204] (p57BB4D21.dip0.t-ipconnect.de [87.187.77.33]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 0BBF372106C12; Tue, 29 Aug 2017 00:39:40 +0200 (CEST)
From: Michael Tuexen <tuexen@fh-muenster.de>
Message-Id: <7C366691-31F9-44B3-AF7A-F877B13EF27A@fh-muenster.de>
Content-Type: multipart/signed; boundary="Apple-Mail=_62AE38DC-0487-4CB1-8DFC-48D252F45CDA"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 29 Aug 2017 00:39:40 +0200
In-Reply-To: <CABcZeBM+-vkO_-Q4NZp7g8tKG6SfS4KLqaf2SHWmLxkDHYcTOg@mail.gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg-chairs@ietf.org, "tsvwg@ietf.org" <tsvwg@ietf.org>
To: Eric Rescorla <ekr@rtfm.com>
References: <150377526319.25828.13085691478621902018.idtracker@ietfa.amsl.com> <6B8221AA-0A42-4409-BDA9-63215B0789F2@fh-muenster.de> <CABcZeBM+-vkO_-Q4NZp7g8tKG6SfS4KLqaf2SHWmLxkDHYcTOg@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ueMh3XLLe0IfncSx2P2iHmKQe9k>
Subject: Re: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Aug 2017 22:39:58 -0000

> On 28. Aug 2017, at 22:56, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> 
> On Mon, Aug 28, 2017 at 1:42 PM, Michael Tuexen <tuexen@fh-muenster.de> wrote:
> > On 26. Aug 2017, at 21:21, Eric Rescorla <ekr@rtfm.com> 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. 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...

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