Re: [Taps] Comments on draft-gjessing-taps-minset-00.txt

Michael Welzl <michawe@ifi.uio.no> Fri, 17 July 2015 14:33 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 3EC461B3469 for <taps@ietfa.amsl.com>; Fri, 17 Jul 2015 07:33:40 -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 ZmA0_t520t-x for <taps@ietfa.amsl.com>; Fri, 17 Jul 2015 07:33:38 -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 31F981B3466 for <taps@ietf.org>; Fri, 17 Jul 2015 07:33:38 -0700 (PDT)
Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1ZG6hj-0001D2-B1; Fri, 17 Jul 2015 16:33:35 +0200
Received: from [88.208.109.142] (helo=[192.168.11.63]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1ZG6hi-0003aM-KN; Fri, 17 Jul 2015 16:33:35 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <032C97CD-A8D3-4553-9DD1-B17E2295AC43@trammell.ch>
Date: Fri, 17 Jul 2015 16:33:32 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5BD04B53-35D1-4D95-A305-B3EF794D1ECE@ifi.uio.no>
References: <5b2e19f286a3eaf18d2ccf7da39abbbf@mail.gmail.com> <A6A77B18-C8F4-4C87-8493-8FF11AC98AA1@ifi.uio.no> <032C97CD-A8D3-4553-9DD1-B17E2295AC43@trammell.ch>
To: Brian Trammell <ietf@trammell.ch>
X-Mailer: Apple Mail (2.2070.6)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 14 msgs/h 4 sum rcpts/h 17 sum msgs/h 4 total rcpts 31073 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: D0AC4EACDF2A222EDEA844B8973371BBA5E5C212
X-UiO-SPAM-Test: remote_host: 88.208.109.142 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 4 total 21 max/h 4 blacklist 0 greylist 0 ratelimit 0
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/xW-d8oyszEiCg7Cek3oE3HtYEP4>
Cc: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>, "taps@ietf.org" <taps@ietf.org>, Stein Gjessing <steing@ifi.uio.no>
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: Fri, 17 Jul 2015 14:33:40 -0000

> On 16. jul. 2015, at 15.04, Brian Trammell <ietf@trammell.ch> wrote:
> 
> hi Michael,
> 
> ...inline...
> 
>> On 16 Jul 2015, at 13:23, Michael Welzl <michawe@ifi.uio.no> wrote:
> 
> <snip>
> 
>>> 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.
> 
> hm, so perhaps we should have coordinated here. That list, in that version, wasn't quite complete.

That doesn't matter - the point of the doc was to introduce the possible categorization and fill the "functional / non-functional" part with some examples so it's more understandable. If this list of examples is complete really doesn't matter.


> In the current version it's still not quite complete, as we're still trying to nail down how to partition the space of features (and how to divide things that are actually features from things that are just accidental effects of the way protocols have evolved). There are also aspects of the interfaces (coming from the interface discussion) we'd like to capture, on which we'd like to discuss f2f next Thursday.

ACK, indeed...


> Perhaps another way to approach this would be to start with a list of features we think we want in doc 2, and to use the background from doc 1 to fill in the gaps...

Bad idea I think. It raises horrible memories of TAPS creation. See, I started this off by saying that we have to do it bottom-up, by beginning with what protocols can do, not what services apps could want. This has disadvantages and is a compromise but it comes from looking at a history of well above a decade of people proposing these kinds of things and nothing coming out of it. That's because there are so many degrees of freedom and it's practically impossible to end up agreeing on anything.

My take-away from TAPS creation was that people had to share this experience together with me: let's do it top-down - oh, really, we can't agree - and now we're back at what I started with: bottom up.

Please please please let's not do another round on this ride with doc 2!   :-)

Cheers,
Michael