Re: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT)
Eric Rescorla <ekr@rtfm.com> Mon, 28 August 2017 20:56 UTC
Return-Path: <ekr@rtfm.com>
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 6E1A01329A8 for <tsvwg@ietfa.amsl.com>; Mon, 28 Aug 2017 13:56:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 G5Q3prkp7K1x for <tsvwg@ietfa.amsl.com>; Mon, 28 Aug 2017 13:56:54 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F65132974 for <tsvwg@ietf.org>; Mon, 28 Aug 2017 13:56:53 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id s187so8377496ywf.2 for <tsvwg@ietf.org>; Mon, 28 Aug 2017 13:56:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r1IP6StRi88C+8fbi4ZWCQLyX5T3fwpjJ5hLS/7uKB4=; b=Vowvfo+eNxmK0i6WiolFwjXXvqNmoG80PAr90OZOYch7HNMvqWDIFayrae0cVZ9NeA hyt227lvPUlBso8nLxmhsfqg3OuNI/poCH4OakCmM08nKCI7JdD2YZZwebp4fRMazRDO bczHivGo2bjhOOlrHXyQ1sTlPWVO9CppsSWJxiLAyNwX0ltGIr0ntiO3+ZTubgZ+q1Au TSKVpGmcIjushYROqT86+oVpF4orGjzCDYdq3/SVGBCjqEvIgWGlfRfBb2ECdMy/PEol Pn+HujwW5ppvi1Havm7/rFuJZXVoPOxk+ySKoprgF1/IW7RlhHaxzmVlv4YvuSzK5wFi eLDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r1IP6StRi88C+8fbi4ZWCQLyX5T3fwpjJ5hLS/7uKB4=; b=IlBUzIMVOEtozqYfsUrKCmfXXK+zeWLmEWwr2ryJvQ3z4yqNY7HbOQTFuf4IIfPI7a yjgg9E6IeX7Ag6GeME5xIKWRZayhFxW2vuFdK3gsAf5BrM5nWTWRI4SAygQDmsRUsGwF JzTtcxoqMJ7a+JNGsqx5tLWoX8AC53NWw/wydldP4/docC9yoLEylsZan4phhtJ/hbre zGwjUApc4x7NzHo0vWWH18CiLTyl5yhlHX/DC5Q+JiZWMYy4dcJEt/yZc6e5nQXg3HtP h38PDKWWa+2HpEoucZQ2YfMcRm8BkiotyM6cRYXxih6b7TQplhsBB1llqxPWoBQWESnM HQxA==
X-Gm-Message-State: AHYfb5gceExV6YwXQ+ThzyimNCh5KBE632W6vQcbPmDX0Ve5lLW6P9jD lRg3P8/4aGYjnckDp2BuC800LAvu5ByM
X-Received: by 10.129.87.79 with SMTP id l76mr1756497ywb.222.1503953813069; Mon, 28 Aug 2017 13:56:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.218.130 with HTTP; Mon, 28 Aug 2017 13:56:12 -0700 (PDT)
In-Reply-To: <6B8221AA-0A42-4409-BDA9-63215B0789F2@fh-muenster.de>
References: <150377526319.25828.13085691478621902018.idtracker@ietfa.amsl.com> <6B8221AA-0A42-4409-BDA9-63215B0789F2@fh-muenster.de>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 28 Aug 2017 13:56:12 -0700
Message-ID: <CABcZeBM+-vkO_-Q4NZp7g8tKG6SfS4KLqaf2SHWmLxkDHYcTOg@mail.gmail.com>
To: Michael Tuexen <tuexen@fh-muenster.de>
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>
Content-Type: multipart/alternative; boundary="001a1149d326c97a1c0557d68869"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/CC3YrJwaxdlLtTJsxTygn_Jf5c0>
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 20:56:57 -0000
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 > 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". > > > > > >
- [tsvwg] Eric Rescorla's No Objection on draft-iet… Eric Rescorla
- Re: [tsvwg] Eric Rescorla's No Objection on draft… Michael Tuexen
- Re: [tsvwg] Eric Rescorla's No Objection on draft… Eric Rescorla
- Re: [tsvwg] Eric Rescorla's No Objection on draft… Michael Tuexen
- Re: [tsvwg] Eric Rescorla's No Objection on draft… Eric Rescorla
- Re: [tsvwg] Eric Rescorla's No Objection on draft… Michael Tuexen
- Re: [tsvwg] Eric Rescorla's No Objection on draft… Eric Rescorla
- Re: [tsvwg] Eric Rescorla's No Objection on draft… Michael Tuexen
- Re: [tsvwg] Eric Rescorla's No Objection on draft… Michael Tuexen
- Re: [tsvwg] Eric Rescorla's No Objection on draft… Spencer Dawkins at IETF
- Re: [tsvwg] Eric Rescorla's No Objection on draft… Eric Rescorla