Re: [Taps] Comments on draft-gjessing-taps-minset-00.txt
Michael Welzl <michawe@ifi.uio.no> Thu, 16 July 2015 11:23 UTC
Return-Path: <michawe@ifi.uio.no>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0325B1B39E6 for <taps@ietfa.amsl.com>; Thu, 16 Jul 2015 04:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level:
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 yIxHYZXMPfsn for <taps@ietfa.amsl.com>; Thu, 16 Jul 2015 04:23:20 -0700 (PDT)
Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378891B39E3 for <taps@ietf.org>; Thu, 16 Jul 2015 04:23:20 -0700 (PDT)
Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1ZFhG2-0002Wj-F5; Thu, 16 Jul 2015 13:23:18 +0200
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1ZFhG1-0008JG-UQ; Thu, 16 Jul 2015 13:23:18 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <5b2e19f286a3eaf18d2ccf7da39abbbf@mail.gmail.com>
Date: Thu, 16 Jul 2015 13:23:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A6A77B18-C8F4-4C87-8493-8FF11AC98AA1@ifi.uio.no>
References: <5b2e19f286a3eaf18d2ccf7da39abbbf@mail.gmail.com>
To: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>
X-Mailer: Apple Mail (2.2098)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 7 sum msgs/h 4 total rcpts 31027 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 11B2768CEF6352C2C43818B37E2C8BA1F6E2DD17
X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 99990 minaction 1 bait 0 mail/h: 3 total 7430 max/h 17 blacklist 0 greylist 0 ratelimit 0
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/ErUpsEqv6dybaTqlZ_Ke7I_G3c0>
Cc: Stein Gjessing <steing@ifi.uio.no>, "taps@ietf.org" <taps@ietf.org>
Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-00.txt
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jul 2015 11:23:22 -0000
Hi, thanks! Below: > On 16 Jul 2015, at 11:22, Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com> wrote: > > HI, > > A few initial comments the definition of the transport service features as > they appear from section 3 (and TAPS1): > > Unidirectional/bidirectional: I am not sure what this means exactly: > Does it refer to that data transfer is negotiated for both directions > perhaps ? But then it only applies to connection oriented transport. > Does it refer to that control info is going back ? > Does it refer to that messages (which ever form) are going back on the > reverse network path ? Then it does not necessarily apply to SCTP MH. Sorry for not being clear enough: it means that it's a feature that can be used just on one side, without requiring the other side to be involved (e.g. Nagle is just a sender-side mechanism). > o non-reliable delivery: > add SCTP > > o reliable delivery: > add SCTP > > Suggest to rephrase > > o reliable and partially reliable delivery > --> > o partially reliable delivery: > SCTP > > o drop notification : > add SCTP > > o ordered delivery: > add SCTP > > o unordered delivery: > add SCTP ACK, thanks > Ideally, I think, then one would use a common term for Nagle(-like) > bundling for TCP and SCTP. Agreed, we actually did that in Michael Welzl, Stefan Jörer, Stein Gjessing: "Towards a Protocol-Independent Internet Transport API", FutureNet IV workshop in conjunction with of IEEE ICC 2011, 5-9 June 2011, Kyoto, Japan, using app PDU bundling because it's more meaningful than Nagle. But here the idea was just to copy+paste the list from doc 1 (version 4) and put things under the correct headings, as a way to show how we *could* apply categorization methods. Cheers, Michael
- Re: [Taps] Comments on draft-gjessing-taps-minset… Karen Elisabeth Egede Nielsen
- Re: [Taps] Comments on draft-gjessing-taps-minset… Michael Welzl
- Re: [Taps] Comments on draft-gjessing-taps-minset… Karen Elisabeth Egede Nielsen
- Re: [Taps] Comments on draft-gjessing-taps-minset… Brian Trammell
- Re: [Taps] Comments on draft-gjessing-taps-minset… Michael Welzl