Re: [Taps] IETF planning

Marie-Jose Montpetit <marie@mjmontpetit.com> Tue, 27 October 2015 14:08 UTC

Return-Path: <marie@mjmontpetit.com>
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 268DE1A8A0B for <taps@ietfa.amsl.com>; Tue, 27 Oct 2015 07:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level:
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3] 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 NdIE_H1rwoMr for <taps@ietfa.amsl.com>; Tue, 27 Oct 2015 07:08:18 -0700 (PDT)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (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 643601A8A01 for <taps@ietf.org>; Tue, 27 Oct 2015 07:08:18 -0700 (PDT)
Received: by qgem9 with SMTP id m9so145807874qge.1 for <taps@ietf.org>; Tue, 27 Oct 2015 07:08:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit_com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nSgGyum/LvrGF/mBkW8NUFzqr9MP4pNFcj6UtZZM85E=; b=RXLoyhKS8th/G2tcW5yL+aktFbSde3iG4WB3JpQ8Buxs6WYti53V40j/Kfa9crJBy8 e8pBXAx+nWgDFPcJ/+Y40HN87DCH9kSyJB22kqYbd+Oj1sY8ybQwdChAjbcsDZLVRoKc 4ubZczeDOhwuXWpJGBe2de2JjokBuhvaUJSLGnukW30X6QwuQ8YO1LlhalrN7Vj9x7II r7pi9VUHV2E4CxG8G0VKpWSO1LojyC1Py3XFzlzFI8BTO0n7u/5iIboU/Q9uzkY8oe+g nDPoiXekOGRhuNf6VHhQtjHuuwZfIPXQyZ/FBv+D786ICRUHkQxLGMH6p0GvHr5p8PV5 ggTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=nSgGyum/LvrGF/mBkW8NUFzqr9MP4pNFcj6UtZZM85E=; b=FkRY2UXLUm87BxantXNkAeVvvRlzvVmSPz/36TGbvPpAi7JYhh2hIVlThBmNDETF6q Uajkkz/LfNTPecDL8lswqJSanlbb0/YYZL0TgLvRhN8/Z3vIbJ3RpsNQHVaa6nmvKode STBcdLNadPu3Hp4amfkc0P/t2FhnjVdF14QmCFUt3n0XoyLvPno7xz8WDPhGHIURc/gB XZaPW1Ln8Efd3T2mU1iK2nHWwH5C5EF14SvKQ+s4dQbx/YW26SuSaTpHOy6SDukFyIWz Ft/pcB+v1syU1FC9WTicnBvfkFhWXUdCuu7kYUDEpkDc9elvR7aAp4bkuBHhp8dBtu+B qPKg==
X-Gm-Message-State: ALoCoQmfVMmEsfGVK8WLEXZPJSyd37aq5PUzjuCLzrT3qEndG6ZRf/rH3hVlLR57A8fZyee/cGtk
X-Received: by 10.140.42.16 with SMTP id b16mr42589033qga.78.1445954897464; Tue, 27 Oct 2015 07:08:17 -0700 (PDT)
Received: from [10.0.1.21] (c-76-118-234-192.hsd1.ma.comcast.net. [76.118.234.192]) by smtp.gmail.com with ESMTPSA id 12sm15049525qhx.38.2015.10.27.07.08.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Oct 2015 07:08:16 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Marie-Jose Montpetit <marie@mjmontpetit.com>
In-Reply-To: <6F9FB87C-D0FF-46B3-A634-8A2E1234F9B7@tik.ee.ethz.ch>
Date: Tue, 27 Oct 2015 10:08:15 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <9C828361-EA04-4FB2-89D6-49678B60245C@mjmontpetit.com>
References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <B36B9E5E-0EB5-418A-A6A1-E103C8ECF500@ifi.uio.no> <CCC80AEF-66CD-4497-A374-2ED89DF4FA17@trammell.ch> <CAD62q9XQMSyuG_=HYjXKe12iE=-F3HasXqrmJs+RAQeBZbddCQ@mail.gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <CAD62q9XjebXmRHUebJLrd35=PnrLPGCZFv4LBO5omYBh2J+72Q@mail.gmail.com> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> <CAD62q9WAaHZ_OrueAa5u0rMuZGssC0mR+3gVWEBQ7DmDMm0cAQ@mail.gmail.com> <27697ADF-7AE6-4E99-8288-FF19A68F1411@ifi.uio.no> <6F9FB87C-D0FF-46B3-A634-8A2E1234F9B7@tik.ee.ethz.ch>
To: =?utf-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/hJ3JN4efiXt_m1h0NxAJLbTZPVw>
Cc: Aaron Falk <aaron.falk@gmail.com>, "<gorry@erg.abdn.ac.uk> Fairhurst" <gorry@erg.abdn.ac.uk>, Michael Welzl <michawe@ifi.uio.no>, Brian Trammell <ietf@trammell.ch>, "taps@ietf.org" <taps@ietf.org>, Stein Gjessing <steing@ifi.uio.no>
Subject: Re: [Taps] IETF planning
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: Tue, 27 Oct 2015 14:08:25 -0000

I agree with Mirja. We have done a lot of “background” work up to now and I don’t mind long documents as long as they are useful references which I think the current document is. I am ok with keeping the work on draft-welzl-taps-transports. But I would also want to move to the next steps - not that I want a science experiment but my interest from the beginning was to define how applications can use transports more efficiently both for existing transports and potential future ones - APIs, discovery etc. I don’t think we need detailed lists of features as all these transports are documented elsewhere but better means to advertise them and use them.

Marie-José
> On Oct 27, 2015, at 10:00 AM, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
> 
> Hi all,
> 
> I didn’t say anything so far because I don’t mind to have a second protocol here, but I personally don’t see this doc as really needed. Effectively we will have two docs that have the same results (a list of features) at the end. I personally find the approach taken in the new doc even more arbitrary and reading this discussion of what should be in and out just underlines this point.
> 
> From my point of view the taps-transports is ready now. Btw. we did not leave out (hopefully) any features of RTP, we just decided to keep the description very short and only focus in the description on those parts that are actually transport related. 
> 
> I agree that the taps-transport doc is quite long, but for the wg I don’t the the purpose of this doc in having it but in getting it. I mean the process we had so far to get this doc in the right shape was very helpful and I believe we are ready to move on. The only think that is interesting now for the wg is the final list of feature, which is there and ready to use. 
> 
> As a side note, I also believe that other people might be interesting in reading the doc for other reasons than participating in taps because it’s actually a quite nice overview doc now.
> 
> That’s just my 2c. I don’t want to hold the wg from any further steps regarding draft-well-taps-transports; I just had the feeling I should also express a different opinion here.
> 
> Mirja
> 
> 
>> Am 27.10.2015 um 14:47 schrieb Michael Welzl <michawe@ifi.uio.no>no>:
>> 
>> 
>>> On 26. okt. 2015, at 17.35, Aaron Falk <aaron.falk@gmail.com> wrote:
>>> 
>>> On Mon, Oct 26, 2015 at 9:46 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
>>> 
>>> Working towards a realistic end-goal of a deployable system.
>>> 
>>> So we’re i) describing services; ii) narrowing them down somehow; iii) describing how to build this thing.
>>> My concern is with iii) being something feasible and useful, not an obscure sci-fi document.
>>> 
>>> Uh, yeah.  That's our charter.  Narrowing down is in doc 2.  Are you making the case we should do it in doc 1?  
>> 
>> Well, just because we narrow down in doc 2 doesn’t mean that doc 1 has to contain everything under the sun as a starting point. Consider the discussion around RTP in draft-ietf-taps-transports - I think the consensus was to have only very short text on RTP in there, not a list of all the protocol features. The starting point for draft-welzl-taps-transports should probably be limited in a similar way, but I’d suggest limiting it more than draft-ietf-taps-transports - partially because draft-ietf-taps-transports can already show that certain protocols are not adding new transport features to the mix that don’t yet exist.
>> 
>> Of course, the main reason behind my argument is to keep draft-welzl-taps-transports within a reasonable length. Look at its length now, with only two protocols!  I think the length is inevitable, but if we have good reasons not to cover certain protocols, I think we should keep them out. At least it’s a valuable discussion to have!
>> 
>> 
>>> Say we include DCCP. It’ll add some services that aren’t in the other protocols listed so far in this mail - e.g. drop notification (see section 3.6.3 in draft-ietf-taps-transports). Say, in step ii), we find no good arguments to remove drop notification. Then, in step iii), we’ll have to say how a TAPS system can support drop notification. So, to build a working TAPS system, one has to either:
>>> - include DCCP in the code base
>>> - extend other protocols to provide this functionality
>>> 
>>> None of these two options are very helpful if we want to TAPS to be real thing one day.
>>> 
>>> a: TAPS is not chartered to do anything normative.  Doc 3 is about experimenting.
>> 
>> Sure! But it’s still about stuff that someone should be able to build - I just don’t want doc 3 to become a sci-fi literature piece  :-)
>> 
>> 
>>> b: You are having the discussion that we planned to have for Doc 2.  Make your case to drop those protocols then.  Or, if no one wants to write sections for the additional protocols for Doc 1a (an extended version of draft-welzl-taps-transports), then folks are voting with their feet on the utility of keeping them.
>> 
>> See my arguments above; about getting sections done for draft-welzl-taps-transports, I don’t worry too much: this is only the very first version, we haven’t asked anyone for inputs yet (and I can volunteer to cover a few more protocols myself).
>> 
>> 
>>> c: One of the goals of TAPS is to enable deployment of transport protocols such as DCCP where networks permit it without forcing application (or library) authors to handle probe and fallback.  If we don't include protocols that aren't seeing deployment, what is the value of this activity?
>> 
>> This is a very good point. I’m not sure - do we really need to cover absolutely all protocols that are in draft-ietf-transports in draft-welzl-taps-transports, then? I am concerned about the implementability of the final beast…
>> 
>> Cheers,
>> Michael
>> 
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps