From nobody Mon Oct 5 11:42:46 2015 Return-Path: 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 4A9C91B3322 for ; Mon, 5 Oct 2015 11:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 6WVNZCI1Ejd8 for ; Mon, 5 Oct 2015 11:42:41 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (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 2F0221B331E for ; Mon, 5 Oct 2015 11:42:41 -0700 (PDT) Received: by ykft14 with SMTP id t14so180421922ykf.0 for ; Mon, 05 Oct 2015 11:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HIu2+lHqrCsQ/A+oyN6KQ8njDf5/XLbF4KM9WFYvOIk=; b=CqTuCB95ma7rCPUdJy73MDB6PYm6SCCinIrDT/J2kxffZOlqbe9yM5Ig9ToU/FI9la kFJtPXF/plyLF3+Ig67x46yYmGtRczK2wrpjn/9QYojUf500by+HZL0fB7Gnl08kfu9F f7p+f84qslHCWMVoxD4GxTMXfz2b2yq2dJfG1cLAE1FqjldwLh61q5MLcMAfWkuNjHo+ Vu37k3O7fw3ThJSbZMBlh4uRA7AW6MYZZuS1y6fIqgui2RcMKAW8ZIgwAd6QIPOufinw b+VMSQoAqaA9UP2sOmbClXKBIIC6SoQC3rvpWJwoPtRyQRGyTbZ87tGX/fFx/k1ynpvV TdxQ== MIME-Version: 1.0 X-Received: by 10.170.57.80 with SMTP id 77mr25436648ykz.59.1444070560426; Mon, 05 Oct 2015 11:42:40 -0700 (PDT) Received: by 10.37.35.78 with HTTP; Mon, 5 Oct 2015 11:42:40 -0700 (PDT) In-Reply-To: References: <20150921083533.19273.62189.idtracker@ietfa.amsl.com> <1D77A9B2-C37B-4ACF-A90D-DB485BC79B28@mjmontpetit.com> <92f091c456879303283af39e26ea14d5.squirrel@erg.abdn.ac.uk> <435C039A-5B01-450B-9223-883194F0B94D@mjmontpetit.com> Date: Mon, 5 Oct 2015 14:42:40 -0400 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=001a11393feec8f54305215fe039 Archived-At: Cc: " Fairhurst" , Marie-Jose Montpetit , Michael Welzl Subject: Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 18:42:44 -0000 --001a11393feec8f54305215fe039 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Have others read this draft yet? It is clearly aimed at addressing charter deliverable #1. Do other folks have an opinion on how well it helps the group achieve the goals in our charter? Should we use this document in some way? I'm looking for more input from the working group on how we should proceed. My opinion: I am very mindful (& appreciative) of the significant effort by Mirja and Brian and the other contributors on draft-ietf-taps-transports. The discussion around this doc has been very useful for clarifying (to me) how difficult it can be to pull useful common abstractions out of the 30+ years of transport technologies. Having been down this path for over a year, I appreciate the fairly narrow approach draft-welzl-taps-transports and think it may be the best chance for TAPS to succeed. Please share your views. --aaron On Sat, Sep 26, 2015 at 10:50 AM, Michael Welzl wrote: > +1 > > > On 26. sep. 2015, at 13.28, Marie-Jose Montpetit > wrote: > > > > Makes sense. > > > >> On Sep 26, 2015, at 3:17 AM, gorry@erg.abdn.ac.uk wrote: > >> > >> We seem to have two documents in a space where we started with one. > These > >> are different, to me this is OK. Both seem close to charter milestone > 1. I > >> don't see much overlap between the contents of the descriptive languag= e > >> and the API-focussed analysis, and any overlap could be eliminated. > >> > >> To me, doc 1 (current chartered item) can evolve to provide background > and > >> missing documentation for anyone in the IETF, and should compare > >> transports in a broad way and draw out the idea that they provide > >> services. This appears to be harder to get right than I for one had > hoped, > >> and still has a wide scope. Not a bad thing. I suggest it will provide= a > >> reference to stop us rat-holing when people ask what is "this" and > explain > >> how all these transports stack-up against one another (good pun?). We > can > >> (I suggest) finish this doc in this way. > >> > >> I do like the idea of a second document focussed ONLY on the Transport > API > >> (I'd call this 1a). In this we can avoid this"discussion of what are > >> transports" and move to a more focussed process in doc 1b, Most o= f > >> that troublesome descriptive text can go into 1, and ensure we keep > that > >> one readable to anyone in the IETF. > >> > >> Could I suggest the two docs against the first milestone will help us > >> make progress towards the next milestone faster. (Assuming we can kee= p > >> the two aligned, which seems quite doable). I can see also how the do= cs > >> are useful to different people. I'd like to see both mature and provid= e > >> inputs to move forward. > >> > >> Gorry > >> > >> > >>> Interesting and inline to getting transport API(s) > >>> > >>> Marie-Jos=C3=83=C2=A9 Montpetit > >>> marie@mjmontpetit.com > >>> mariejo@mit.edu > >>> > >>>> On Sep 21, 2015, at 04:44, Michael Welzl wrote: > >>>> > >>>> Dear all, > >>>> > >>>> In my presentation in Prague, I proposed an approach to identify the > >>>> services that transport protocols provide. At the end of the ensuing > >>>> discussion, I said that I (with co-authors) would write a draft that > >>>> explains the proposal by applying the proposed method to TCP and SCT= P. > >>>> > >>>> We just submitted this document - see below; I hope that this will > lead > >>>> to some discussion on the list... > >>>> > >>>> Cheers, > >>>> Michael > >>>> > >>>> > >>>>> Begin forwarded message: > >>>>> > >>>>> From: > >>>>> Subject: New Version Notification for > >>>>> draft-welzl-taps-transports-00.txt > >>>>> Date: 21 Sep 2015 10:35:33 CEST > >>>>> To: Michael Welzl , Michael Welzl > >>>>> , Michael Tuexen , Naeem > >>>>> Khademi , Michael Tuexen = , > >>>>> Naeem Khademi > >>>>> Resent-From: > >>>>> > >>>>> > >>>>> A new version of I-D, draft-welzl-taps-transports-00.txt > >>>>> has been successfully submitted by Michael Welzl and posted to the > >>>>> IETF repository. > >>>>> > >>>>> Name: draft-welzl-taps-transports > >>>>> Revision: 00 > >>>>> Title: An Approach to Identify Services Provided by IETF > >>>>> Transport Protocols and Congestion Control Mechanisms > >>>>> Document date: 2015-09-21 > >>>>> Group: Individual Submission > >>>>> Pages: 23 > >>>>> URL: > >>>>> > https://www.ietf.org/internet-drafts/draft-welzl-taps-transports-00.txt > >>>>> Status: > >>>>> https://datatracker.ietf.org/doc/draft-welzl-taps-transports/ > >>>>> Htmlized: > >>>>> https://tools.ietf.org/html/draft-welzl-taps-transports-00 > >>>>> > >>>>> > >>>>> Abstract: > >>>>> This document describes a method to identify services in transport > >>>>> protocols and congestion control mechanisms. It shows the approach > >>>>> using TCP and SCTP (base protocol) as examples. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Please note that it may take a couple of minutes from the time of > >>>>> submission > >>>>> until the htmlized version and diff are available at tools.ietf.org= . > >>>>> > >>>>> The IETF Secretariat > >>>> > >>>> _______________________________________________ > >>>> 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 > >>> > >> > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --001a11393feec8f54305215fe039 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Have others read this draft yet? =C2=A0 It is clearly aime= d at addressing charter deliverable #1.=C2=A0 Do other folks have an opinio= n on how well it helps the group achieve the goals in our charter?=C2=A0 Sh= ould we use this document in some way? I'm looking for more input from = the working group on how we should proceed.=C2=A0

My opi= nion:=C2=A0I am very mindful (& appreciative) of the significant effort= by Mirja and Brian and the other contributors on draft-ietf-taps-transport= s. =C2=A0 =C2=A0The discussion around this doc has been very useful for cla= rifying (to me) how difficult it can be to pull useful common abstractions = out of the 30+ years of transport technologies.=C2=A0 Having been down this= path for over a year, I appreciate the fairly narrow approach draft-welzl-= taps-transports and think it may be the best chance for TAPS to succeed. = =C2=A0

Please share your views.

=
--aaron

On Sat, Sep 26, 2015 at 10:50 AM, Michael Welzl= <michawe@ifi.uio.no> wrote:
+1

> On 26. sep. 2015, at 13.28, Marie-Jose Montpetit <marie@mjmontpetit.com> wrote:
>
> Makes sense.
>
>> On Sep 26, 2015, at 3:17 AM, gorry@erg.abdn.ac.uk wrote:
>>
>> We seem to have two documents in a space where we started with one= . These
>> are different, to me this is OK. Both seem close to charter milest= one 1. I
>> don't see much overlap between the contents of the descriptive= language
>> and the API-focussed analysis, and any overlap could be eliminated= .
>>
>> To me, doc 1 (current chartered item) can evolve to provide backgr= ound and
>> missing documentation for anyone in the IETF, and should compare >> transports in a broad way and draw out the idea that they provide<= br> >> services. This appears to be harder to get right than I for one ha= d hoped,
>> and still has a wide scope. Not a bad thing. I suggest it will pro= vide a
>> reference to stop us rat-holing when people ask what is "this= " and explain
>> how all these transports stack-up against one another (good pun?).= We can
>> (I suggest) finish this doc in this way.
>>
>> I do like the idea of a second document focussed ONLY on the Trans= port API
>> (I'd call this 1a). In this we can avoid this"discussion = of what are
>> transports"=C2=A0 and move to=C2=A0 a=C2=A0 more focussed=C2= =A0 process in doc 1b,=C2=A0 Most of
>> that troublesome descriptive=C2=A0 text can go into 1, and ensure = we keep that
>> one readable to anyone in the=C2=A0 IETF.
>>
>> Could=C2=A0 I suggest the two docs against the first milestone wil= l help us
>> make=C2=A0 progress towards the next milestone faster. (Assuming w= e can keep
>> the two aligned, which seems quite doable). I can see also how the= =C2=A0 docs
>> are useful to different people. I'd like to see both mature an= d provide
>> inputs to move forward.
>>
>> Gorry
>>
>>
>>> Interesting and inline to getting transport API(s)
>>>
>>> Marie-Jos=C3=83=C2=A9 Montpetit
>>> marie@mjmontpetit.com=
>>> mariejo@mit.edu
>>>
>>>> On Sep 21, 2015, at 04:44, Michael Welzl <michawe@ifi.uio.no> wrote:
>>>>
>>>> Dear all,
>>>>
>>>> In my presentation in Prague, I proposed an approach to id= entify the
>>>> services that transport protocols provide. At the end of t= he ensuing
>>>> discussion, I said that I (with co-authors) would write a = draft that
>>>> explains the proposal by applying the proposed method to T= CP and SCTP.
>>>>
>>>> We just submitted this document - see below;=C2=A0 I hope = that this will lead
>>>> to some discussion on the list...
>>>>
>>>> Cheers,
>>>> Michael
>>>>
>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>> From: <= internet-drafts@ietf.org>
>>>>> Subject: New Version Notification for
>>>>> draft-welzl-taps-transports-00.txt
>>>>> Date: 21 Sep 2015 10:35:33 CEST
>>>>> To: Michael Welzl <michawe@ifi.uio.no>, Michael Welzl
>>>>> <michawe@ifi.= uio.no>, Michael Tuexen <tuexen@fh-muenster.de>, Naeem
>>>>> Khademi <naeem= k@ifi.uio.no>, Michael Tuexen <tuexen@fh-muenster.de>,
>>>>> Naeem Khademi <naeemk@ifi.uio.no>
>>>>> Resent-From: <michawe@ifi.uio.no>
>>>>>
>>>>>
>>>>> A new version of I-D, draft-welzl-taps-transports-00.t= xt
>>>>> has been successfully submitted by Michael Welzl and p= osted to the
>>>>> IETF repository.
>>>>>
>>>>> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-welzl-taps-tran= sports
>>>>> Revision:=C2=A0 =C2=A0 00
>>>>> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 An Approach to Ident= ify Services Provided by IETF
>>>>> Transport Protocols and Congestion Control Mechanisms<= br> >>>>> Document date:=C2=A0 =C2=A0 2015-09-21
>>>>> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submissio= n
>>>>> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 23
>>>>> URL:
>>>>> https://= www.ietf.org/internet-drafts/draft-welzl-taps-transports-00.txt
>>>>> Status:
>>>>> https://datatracke= r.ietf.org/doc/draft-welzl-taps-transports/
>>>>> Htmlized:
>>>>> https://tools.ietf.or= g/html/draft-welzl-taps-transports-00
>>>>>
>>>>>
>>>>> Abstract:
>>>>> This document describes a method to identify services = in transport
>>>>> protocols and congestion control mechanisms.=C2=A0 It = shows the approach
>>>>> using TCP and SCTP (base protocol) as examples.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Please note that it may take a couple of minutes from = the time of
>>>>> submission
>>>>> until the htmlized version and diff are available at <= a href=3D"http://tools.ietf.org" rel=3D"noreferrer" target=3D"_blank">tools= .ietf.org.
>>>>>
>>>>> The IETF Secretariat
>>>>
>>>> _______________________________________________
>>>> Taps mailing list
>>>> Taps@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tap= s
>>>
>>> _______________________________________________
>>> 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

--001a11393feec8f54305215fe039-- From nobody Mon Oct 5 12:49:52 2015 Return-Path: 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 B9D9C1B4F41 for ; Mon, 5 Oct 2015 12:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Eb7fCaR1Go03 for ; Mon, 5 Oct 2015 12:49:48 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id BC6BF1B4F47 for ; Mon, 5 Oct 2015 12:49:47 -0700 (PDT) Received: from [192.168.0.8] (c-67-160-226-53.hsd1.ca.comcast.net [67.160.226.53]) by trammell.ch (Postfix) with ESMTPSA id 7B0C61A0387; Mon, 5 Oct 2015 21:49:13 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-664893E5-2651-4E4B-926F-424DB0661248 Mime-Version: 1.0 (1.0) From: Brian Trammell X-Mailer: iPhone Mail (12H321) In-Reply-To: Date: Mon, 5 Oct 2015 12:49:06 -0700 Content-Transfer-Encoding: 7bit Message-Id: <0FB76D15-3904-4D10-8FFD-F0E445E2564C@trammell.ch> References: <20150921083533.19273.62189.idtracker@ietfa.amsl.com> <1D77A9B2-C37B-4ACF-A90D-DB485BC79B28@mjmontpetit.com> <92f091c456879303283af39e26ea14d5.squirrel@erg.abdn.ac.uk> <435C039A-5B01-450B-9223-883194F0B94D@mjmontpetit.com> To: Aaron Falk Archived-At: Cc: " Fairhurst" , Marie-Jose Montpetit , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 19:49:51 -0000 --Apple-Mail-664893E5-2651-4E4B-926F-424DB0661248 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In transit, please excuse the brevity. Broadly I appreciate the effort to do the decomposition in a less arbitrary w= ay. I'm not convinced it's actually less arbitrary, but this is largely irre= levant: it's a *different* way to do the decomposition, so points of agreeme= nt (of which, at least on TCP and SCTP, there are many) reinforce confidence= that we're doing this right. I tend to agree with Gorry's suggestion on the= way forward. Cheers, Brian Sent from my iPhone > On 05 Oct 2015, at 11:42, Aaron Falk wrote: >=20 > Have others read this draft yet? It is clearly aimed at addressing chart= er deliverable #1. Do other folks have an opinion on how well it helps the g= roup achieve the goals in our charter? Should we use this document in some w= ay? I'm looking for more input from the working group on how we should proce= ed.=20 >=20 > My opinion: I am very mindful (& appreciative) of the significant effort b= y Mirja and Brian and the other contributors on draft-ietf-taps-transports. = The discussion around this doc has been very useful for clarifying (to me= ) how difficult it can be to pull useful common abstractions out of the 30+ y= ears of transport technologies. Having been down this path for over a year,= I appreciate the fairly narrow approach draft-welzl-taps-transports and thi= nk it may be the best chance for TAPS to succeed. =20 >=20 > Please share your views. >=20 > --aaron >=20 >=20 >> On Sat, Sep 26, 2015 at 10:50 AM, Michael Welzl wrot= e: >> +1 >>=20 >> > On 26. sep. 2015, at 13.28, Marie-Jose Montpetit wrote: >> > >> > Makes sense. >> > >> >> On Sep 26, 2015, at 3:17 AM, gorry@erg.abdn.ac.uk wrote: >> >> >> >> We seem to have two documents in a space where we started with one. Th= ese >> >> are different, to me this is OK. Both seem close to charter milestone 1= . I >> >> don't see much overlap between the contents of the descriptive languag= e >> >> and the API-focussed analysis, and any overlap could be eliminated. >> >> >> >> To me, doc 1 (current chartered item) can evolve to provide background= and >> >> missing documentation for anyone in the IETF, and should compare >> >> transports in a broad way and draw out the idea that they provide >> >> services. This appears to be harder to get right than I for one had ho= ped, >> >> and still has a wide scope. Not a bad thing. I suggest it will provide= a >> >> reference to stop us rat-holing when people ask what is "this" and exp= lain >> >> how all these transports stack-up against one another (good pun?). We c= an >> >> (I suggest) finish this doc in this way. >> >> >> >> I do like the idea of a second document focussed ONLY on the Transport= API >> >> (I'd call this 1a). In this we can avoid this"discussion of what are >> >> transports" and move to a more focussed process in doc 1b, Most o= f >> >> that troublesome descriptive text can go into 1, and ensure we keep t= hat >> >> one readable to anyone in the IETF. >> >> >> >> Could I suggest the two docs against the first milestone will help us= >> >> make progress towards the next milestone faster. (Assuming we can kee= p >> >> the two aligned, which seems quite doable). I can see also how the do= cs >> >> are useful to different people. I'd like to see both mature and provid= e >> >> inputs to move forward. >> >> >> >> Gorry >> >> >> >> >> >>> Interesting and inline to getting transport API(s) >> >>> >> >>> Marie-Jos=C3=83=C2=A9 Montpetit >> >>> marie@mjmontpetit.com >> >>> mariejo@mit.edu >> >>> >> >>>> On Sep 21, 2015, at 04:44, Michael Welzl wrote:= >> >>>> >> >>>> Dear all, >> >>>> >> >>>> In my presentation in Prague, I proposed an approach to identify the= >> >>>> services that transport protocols provide. At the end of the ensuing= >> >>>> discussion, I said that I (with co-authors) would write a draft that= >> >>>> explains the proposal by applying the proposed method to TCP and SCT= P. >> >>>> >> >>>> We just submitted this document - see below; I hope that this will l= ead >> >>>> to some discussion on the list... >> >>>> >> >>>> Cheers, >> >>>> Michael >> >>>> >> >>>> >> >>>>> Begin forwarded message: >> >>>>> >> >>>>> From: >> >>>>> Subject: New Version Notification for >> >>>>> draft-welzl-taps-transports-00.txt >> >>>>> Date: 21 Sep 2015 10:35:33 CEST >> >>>>> To: Michael Welzl , Michael Welzl >> >>>>> , Michael Tuexen , Naeem= >> >>>>> Khademi , Michael Tuexen = , >> >>>>> Naeem Khademi >> >>>>> Resent-From: >> >>>>> >> >>>>> >> >>>>> A new version of I-D, draft-welzl-taps-transports-00.txt >> >>>>> has been successfully submitted by Michael Welzl and posted to the >> >>>>> IETF repository. >> >>>>> >> >>>>> Name: draft-welzl-taps-transports >> >>>>> Revision: 00 >> >>>>> Title: An Approach to Identify Services Provided by IETF >> >>>>> Transport Protocols and Congestion Control Mechanisms >> >>>>> Document date: 2015-09-21 >> >>>>> Group: Individual Submission >> >>>>> Pages: 23 >> >>>>> URL: >> >>>>> https://www.ietf.org/internet-drafts/draft-welzl-taps-transports-00= .txt >> >>>>> Status: >> >>>>> https://datatracker.ietf.org/doc/draft-welzl-taps-transports/ >> >>>>> Htmlized: >> >>>>> https://tools.ietf.org/html/draft-welzl-taps-transports-00 >> >>>>> >> >>>>> >> >>>>> Abstract: >> >>>>> This document describes a method to identify services in transport >> >>>>> protocols and congestion control mechanisms. It shows the approach= >> >>>>> using TCP and SCTP (base protocol) as examples. >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Please note that it may take a couple of minutes from the time of >> >>>>> submission >> >>>>> until the htmlized version and diff are available at tools.ietf.org= . >> >>>>> >> >>>>> The IETF Secretariat >> >>>> >> >>>> _______________________________________________ >> >>>> 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 >> >>> >> >> >> > >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail-664893E5-2651-4E4B-926F-424DB0661248 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
In transit, please excuse the brevity.=

Broadly I appreciate the effort to do the decompos= ition in a less arbitrary way. I'm not convinced it's actually less arbitrar= y, but this is largely irrelevant: it's a *different* way to do the decompos= ition, so points of agreement (of which, at least on TCP and SCTP, there are= many) reinforce confidence that we're doing this right. I tend to agree wit= h Gorry's suggestion on the way forward.

Cheers, Brian

Sent fr= om my iPhone

On 05 Oct 2015, at 11:42, Aaron Falk <aaron.falk@gmail.com> wrote:

Have others read this dra= ft yet?   It is clearly aimed at addressing charter deliverable #1.&nbs= p; Do other folks have an opinion on how well it helps the group achieve the= goals in our charter?  Should we use this document in some way? I'm lo= oking for more input from the working group on how we should proceed. <= div>
My opinion: I am very mindful (& appreciative) o= f the significant effort by Mirja and Brian and the other contributors on dr= aft-ietf-taps-transports.    The discussion around this doc has be= en very useful for clarifying (to me) how difficult it can be to pull useful= common abstractions out of the 30+ years of transport technologies.  H= aving been down this path for over a year, I appreciate the fairly narrow ap= proach draft-welzl-taps-transports and think it may be the best chance for T= APS to succeed.  

Please share your views.
=

--aaron


On Sat, Sep 26, 2015 at 10:50 AM, M= ichael Welzl <michawe@ifi.uio.no> wrote:
+1

> On 26. sep. 2015, at 13.28, Marie-Jose Montpetit <marie@mjmontpetit.com> wrote:
>
> Makes sense.
>
>> On Sep 26, 2015, at 3:17 AM, gorry@erg.abdn.ac.uk wrote:
>>
>> We seem to have two documents in a space where we started with one.= These
>> are different, to me this is OK. Both seem close to charter milesto= ne 1. I
>> don't see much overlap between the contents of the descriptive lang= uage
>> and the API-focussed analysis, and any overlap could be eliminated.=
>>
>> To me, doc 1 (current chartered item) can evolve to provide backgro= und and
>> missing documentation for anyone in the IETF, and should compare >> transports in a broad way and draw out the idea that they provide >> services. This appears to be harder to get right than I for one had= hoped,
>> and still has a wide scope. Not a bad thing. I suggest it will prov= ide a
>> reference to stop us rat-holing when people ask what is "this" and e= xplain
>> how all these transports stack-up against one another (good pun?). W= e can
>> (I suggest) finish this doc in this way.
>>
>> I do like the idea of a second document focussed ONLY on the Transp= ort API
>> (I'd call this 1a). In this we can avoid this"discussion of what ar= e
>> transports"  and move to  a  more focussed  pro= cess in doc 1b,  Most of
>> that troublesome descriptive  text can go into 1, and ensure w= e keep that
>> one readable to anyone in the  IETF.
>>
>> Could  I suggest the two docs against the first milestone will= help us
>> make  progress towards the next milestone faster. (Assuming we= can keep
>> the two aligned, which seems quite doable). I can see also how the&= nbsp; docs
>> are useful to different people. I'd like to see both mature and pro= vide
>> inputs to move forward.
>>
>> Gorry
>>
>>
>>> Interesting and inline to getting transport API(s)
>>>
>>> Marie-Jos=C3=83=C2=A9 Montpetit
>>> marie@mjmontpetit.com<= /a>
>>> mariejo@mit.edu
>>>
>>>> On Sep 21, 2015, at 04:44, Michael Welzl <michawe@ifi.uio.no> wrote:
>>>>
>>>> Dear all,
>>>>
>>>> In my presentation in Prague, I proposed an approach to ide= ntify the
>>>> services that transport protocols provide. At the end of th= e ensuing
>>>> discussion, I said that I (with co-authors) would write a d= raft that
>>>> explains the proposal by applying the proposed method to TC= P and SCTP.
>>>>
>>>> We just submitted this document - see below;  I hope t= hat this will lead
>>>> to some discussion on the list...
>>>>
>>>> Cheers,
>>>> Michael
>>>>
>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>> From: <i= nternet-drafts@ietf.org>
>>>>> Subject: New Version Notification for
>>>>> draft-welzl-taps-transports-00.txt
>>>>> Date: 21 Sep 2015 10:35:33 CEST
>>>>> To: Michael Welzl <michawe@ifi.uio.no>, Michael Welzl
>>>>> <michawe@ifi.u= io.no>, Michael Tuexen <t= uexen@fh-muenster.de>, Naeem
>>>>> Khademi <naeemk= @ifi.uio.no>, Michael Tuexen <tuexen@fh-muenster.de>,
>>>>> Naeem Khademi <= naeemk@ifi.uio.no>
>>>>> Resent-From: <= michawe@ifi.uio.no>
>>>>>
>>>>>
>>>>> A new version of I-D, draft-welzl-taps-transports-00.tx= t
>>>>> has been successfully submitted by Michael Welzl and po= sted to the
>>>>> IETF repository.
>>>>>
>>>>> Name:        draft-welzl-taps-trans= ports
>>>>> Revision:    00
>>>>> Title:        An Approach to Identi= fy Services Provided by IETF
>>>>> Transport Protocols and Congestion Control Mechanisms >>>>> Document date:    2015-09-21
>>>>> Group:        Individual Submission=
>>>>> Pages:        23
>>>>> URL:
>>>>> https://ww= w.ietf.org/internet-drafts/draft-welzl-taps-transports-00.txt
>>>>> Status:
>>>>> https://datatracker.= ietf.org/doc/draft-welzl-taps-transports/
>>>>> Htmlized:
>>>>> https://tools.ietf.org/= html/draft-welzl-taps-transports-00
>>>>>
>>>>>
>>>>> Abstract:
>>>>> This document describes a method to identify services i= n transport
>>>>> protocols and congestion control mechanisms.  It s= hows the approach
>>>>> using TCP and SCTP (base protocol) as examples.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Please note that it may take a couple of minutes from t= he time of
>>>>> submission
>>>>> until the htmlized version and diff are available at tools.i= etf.org.
>>>>>
>>>>> The IETF Secretariat
>>>>
>>>> _______________________________________________
>>>> 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<= br> >>>
>>
>

_______________________________________________
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
= --Apple-Mail-664893E5-2651-4E4B-926F-424DB0661248-- From nobody Wed Oct 7 00:17:57 2015 Return-Path: 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 DDACC1A0367 for ; Wed, 7 Oct 2015 00:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 gQKt7eOood-i for ; Wed, 7 Oct 2015 00:17:54 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 BC53E1A0363 for ; Wed, 7 Oct 2015 00:17:53 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Zjiz1-0007Ph-AQ; Wed, 07 Oct 2015 09:17:51 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Zjiz0-0005Td-Rt; Wed, 07 Oct 2015 09:17:51 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Wed, 7 Oct 2015 09:17:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4656A4F1-8A56-424C-95A7-506D5FEE3FC3@ifi.uio.no> References: <20150921083533.19273.62189.idtracker@ietfa.amsl.com> <1D77A9B2-C37B-4ACF-A90D-DB485BC79B28@mjmontpetit.com> <92f091c456879303283af39e26ea14d5.squirrel@erg.abdn.ac.uk> <435C039A-5B01-450B-9223-883194F0B94D@mjmontpetit.com> To: Aaron Falk X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 3 sum rcpts/h 9 sum msgs/h 3 total rcpts 33809 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FF51902886D6D13FD6DB08DFD5C1D307081B8094 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 8102 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: " Fairhurst" , Marie-Jose Montpetit , "taps@ietf.org" Subject: Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 07:17:56 -0000 Hi, > On 05 Oct 2015, at 20:42, Aaron Falk wrote: >=20 > Have others read this draft yet? It is clearly aimed at addressing = charter deliverable #1. Do other folks have an opinion on how well it = helps the group achieve the goals in our charter? Should we use this = document in some way? I'm looking for more input from the working group = on how we should proceed.=20 >=20 > My opinion: I am very mindful (& appreciative) of the significant = effort by Mirja and Brian and the other contributors on = draft-ietf-taps-transports. +1 > The discussion around this doc has been very useful for clarifying = (to me) how difficult it can be to pull useful common abstractions out = of the 30+ years of transport technologies. Having been down this path = for over a year, I appreciate the fairly narrow approach = draft-welzl-taps-transports and think it may be the best chance for TAPS = to succeed. =20 >=20 > Please share your views. You say you appreciate the "fairly narrow" approach of = draft-welzl-taps-transports. This makes me wonder - maybe = draft-welzl-taps-transports should only cover a subset of the transports = in draft-ietf-taps-transports, based on what we can see in = draft-ietf-taps-transports? (e.g. the eventual text on RTP in = draft-ietf-taps-transports will probably not be a short list of = features, which may indicate that RTP should not be included in = draft-welzl-taps-transports). Cheers, Michael From nobody Wed Oct 7 02:18:24 2015 Return-Path: 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 832EB1A906E for ; Wed, 7 Oct 2015 02:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ErhDUdRghSVu for ; Wed, 7 Oct 2015 02:18:21 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 63E861B2C90 for ; Wed, 7 Oct 2015 02:18:21 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id C891A1A02FB; Wed, 7 Oct 2015 11:17:49 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_99883EEB-F8B3-4C4F-B6A7-3EE6D4EEFE6E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Brian Trammell In-Reply-To: <4656A4F1-8A56-424C-95A7-506D5FEE3FC3@ifi.uio.no> Date: Wed, 7 Oct 2015 11:17:49 +0200 Message-Id: <3D3C1025-32D9-4E60-B31D-35D15CC3D163@trammell.ch> References: <20150921083533.19273.62189.idtracker@ietfa.amsl.com> <1D77A9B2-C37B-4ACF-A90D-DB485BC79B28@mjmontpetit.com> <92f091c456879303283af39e26ea14d5.squirrel@erg.abdn.ac.uk> <435C039A-5B01-450B-9223-883194F0B94D@mjmontpetit.com> <4656A4F1-8A56-424C-95A7-506D5FEE3FC3@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Aaron Falk , Gorry Fairhurst , Marie-Jose Montpetit , "taps@ietf.org" Subject: Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 09:18:23 -0000 --Apple-Mail=_99883EEB-F8B3-4C4F-B6A7-3EE6D4EEFE6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 07 Oct 2015, at 09:17, Michael Welzl wrote: >=20 > Hi, >=20 >=20 >> On 05 Oct 2015, at 20:42, Aaron Falk wrote: >>=20 >> Have others read this draft yet? It is clearly aimed at addressing = charter deliverable #1. Do other folks have an opinion on how well it = helps the group achieve the goals in our charter? Should we use this = document in some way? I'm looking for more input from the working group = on how we should proceed. >>=20 >> My opinion: I am very mindful (& appreciative) of the significant = effort by Mirja and Brian and the other contributors on = draft-ietf-taps-transports. >=20 > +1 >=20 >=20 >> The discussion around this doc has been very useful for clarifying = (to me) how difficult it can be to pull useful common abstractions out = of the 30+ years of transport technologies. Having been down this path = for over a year, I appreciate the fairly narrow approach = draft-welzl-taps-transports and think it may be the best chance for TAPS = to succeed. >>=20 >> Please share your views. >=20 > You say you appreciate the "fairly narrow" approach of = draft-welzl-taps-transports. This makes me wonder - maybe = draft-welzl-taps-transports should only cover a subset of the transports = in draft-ietf-taps-transports, based on what we can see in = draft-ietf-taps-transports? Definitely. I think the "narrow" approach can work here -- the scope is = already narrowed by only considering unicast services, which simplifies = things quite a bit. The question is how and whether to narrow further. = TCP (and MPTCP), UDP (and UTP-lite), and SCTP clearly make the cut, as = they are widely deployed and/or there is active work on top of them for = which we expect wide deployment. Others I'm less sure of. Cheers, Brian > (e.g. the eventual text on RTP in draft-ietf-taps-transports will = probably not be a short list of features, which may indicate that RTP = should not be included in draft-welzl-taps-transports). >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_99883EEB-F8B3-4C4F-B6A7-3EE6D4EEFE6E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWFOM+AAoJEIoSt78L6kajfmMQAJc6Ha+WTtbiV3vb0aueeK0K UuV0JNVzCI7dgzQYgt62Fkr588EeAxTgBdbunTaj577IegbKFuiUK02YrKQkrOY1 a2aF6GAcXQhciK1oYtMme4E6lHboF8hxWd5M5zrjOFqUhPWhBdCLJWvIXBwjC44H gLJao16xWox85UjgRCSlQDomZfB8EJjwTMIOmqBqxwgigVP2ANg8SPJ/xV+nozdg eGSbQ9PcqIajquxMqhhmcXzbRQ2omaBpHSS3uIkKEqmuwwZQrweCmPveQlrD1O6/ R8BLbbgg4fizU0CTyVym5l3ehd8HH9h+rZ24B66DPdUYImpFTjhiIjWc3iB3VPy5 sQzL0QdeN7yW2LGYDxWOGLYSF9L7Lz1ufjBJrRTEMQVEEQ9MjFUGI0PPExpzNH/l WOyUmY4VTTWsSjiAW14WRBV8xRY6s/T9C0dQGmdTFKBMxrPmzEw28LMOXiV5gu5O mifKWTvmXJf1RZaEcQhatt00K4/X94/kkBRsAtnYER5XB5zAoFRHANK8LKKuY+HR bxw4i1TCpa+3xvmgL/CRuvlQHOZPV7O7SgaX66AGnBmrj1o8QQGVniirSnPeSMPE xqI7LPL7YuIFFCGVQdbHuVzCxg7F8t1ClO/9vP6Fy1wwlmQ9i2auQdcXPq9C/OZb ymZjvEosmc7vtdIsyRep =Qi7b -----END PGP SIGNATURE----- --Apple-Mail=_99883EEB-F8B3-4C4F-B6A7-3EE6D4EEFE6E-- From nobody Wed Oct 7 03:43:17 2015 Return-Path: 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 7162F1B2CA8; Wed, 7 Oct 2015 03:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 e1Q7B-KWJUwO; Wed, 7 Oct 2015 03:43:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1351B2DB6; Wed, 7 Oct 2015 03:43:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151007104314.19878.21283.idtracker@ietfa.amsl.com> Date: Wed, 07 Oct 2015 03:43:14 -0700 Archived-At: Cc: taps@ietf.org Subject: [Taps] I-D Action: draft-ietf-taps-transports-07.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 10:43:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services Working Group of the IETF. Title : Services provided by IETF transport protocols and congestion control mechanisms Authors : Godred Fairhurst Brian Trammell Mirja Kuehlewind Filename : draft-ietf-taps-transports-07.txt Pages : 53 Date : 2015-10-07 Abstract: This document describes services provided by existing IETF protocols and congestion control mechanisms. It is designed to help application and network stack programmers and to inform the work of the IETF TAPS Working Group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-taps-transports-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 9 19:56:39 2015 Return-Path: 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 7CA9F1B53D2 for ; Fri, 9 Oct 2015 19:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 TVsmgAzucwJO for ; Fri, 9 Oct 2015 19:56:36 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (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 145101B53D1 for ; Fri, 9 Oct 2015 19:56:36 -0700 (PDT) Received: by ykba192 with SMTP id a192so91348983ykb.3 for ; Fri, 09 Oct 2015 19:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rGj5xy1bk9OHBgkMsuIPS7XNyXXfvTSc9nNJGIQ9VBk=; b=t+FG/bZtHNNGDUqPAGX5eh6RO8sSECga/+Evnvb47//TsHtSYSRaMtLDv1iECKsSyG C66MPxMFNHMtMh+ngQoeSx/cHA6KtF9tBDNm3d1rhoJ/L/zM6IfzehvsdLDBSftwSWWc wPDwALrakISkvqOXFC17YHNFyh2oIbr/TaUyzegzXXE+QjFycq9Gl1c1sI4RDbtLOKfm k04YKXUAPkB0yEldK5MwXQTdXZNH8+TtvYqVdgTBqhEtQAp2E8WpM97LuEzlwTXIUXsm w/ql4Z4QZBSIvz1z5JfxWG30PtozZqCd8veOXweMJLj7689gSFYZ23LFv+NYTpxKcwh7 pfFQ== MIME-Version: 1.0 X-Received: by 10.129.129.199 with SMTP id r190mr11661069ywf.254.1444445795237; Fri, 09 Oct 2015 19:56:35 -0700 (PDT) Received: by 10.37.35.78 with HTTP; Fri, 9 Oct 2015 19:56:35 -0700 (PDT) In-Reply-To: <20151010012848.29540.63279.idtracker@ietfa.amsl.com> References: <20151010012848.29540.63279.idtracker@ietfa.amsl.com> Date: Fri, 9 Oct 2015 22:56:35 -0400 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c07efe685c3850521b73e2d Archived-At: Subject: [Taps] Fwd: taps - Requested session has been scheduled for IETF 94 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2015 02:56:37 -0000 --94eb2c07efe685c3850521b73e2d Content-Type: text/plain; charset=UTF-8 ---------- Forwarded message ---------- From: *"IETF Secretariat"* Date: Friday, October 9, 2015 Subject: taps - Requested session has been scheduled for IETF 94 To: aaron.falk@gmail.com Cc: taps-ads@ietf.org, aaron.falk@gmail.com Dear Aaron, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. taps Session 1 (1:30:00) Tuesday, Afternoon Session II 1520-1650 Room Name: Room 304 size: 200 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Aaron Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: apparea appsawg tsvarea aqm rmcat ippm tsvwg iccrg tcpm Second Priority: webpush tcpinc ppsp nvo3 mptcp icnrg httpbis irtfopen Third Priority: mmusic tram Special Requests: --------------------------------------------------------- -- -- aaron Sent from Gmail Mobile --94eb2c07efe685c3850521b73e2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ----------
From: "IETF Secr= etariat" <agenda@ietf.org>
Date: Friday, October 9, 2015
Subject: taps - Requested session= has been scheduled for IETF 94
To: aaron.falk@gmail.com
Cc: ta= ps-ads@ietf.org, aaron.falk@gma= il.com


Dear Aaron,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.

taps Session 1 (1:30:00)
=C2=A0 =C2=A0 Tuesday, Afternoon Session II 1520-1650
=C2=A0 =C2=A0 Room Name: Room 304 size: 200
=C2=A0 =C2=A0 ---------------------------------------------



Request Information:


---------------------------------------------------------
Working Group Name: Transport Services
Area Name: Transport Area
Session Requester: Aaron

Number of Sessions: 1
Length of Session(s):=C2=A0 1.5 Hours
Number of Attendees: 80
Conflicts to Avoid:
=C2=A0First Priority: apparea appsawg tsvarea aqm rmcat ippm tsvwg iccrg tc= pm
=C2=A0Second Priority: webpush tcpinc ppsp nvo3 mptcp icnrg httpbis irtfope= n
=C2=A0Third Priority: mmusic tram


Special Requests:

---------------------------------------------------------




--
-- aaron

Sent from Gmail Mobile

--94eb2c07efe685c3850521b73e2d-- From nobody Mon Oct 19 11:44:46 2015 Return-Path: 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 D132B1B2A94 for ; Mon, 19 Oct 2015 11:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham 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 LPJOS1wsHyTy for ; Mon, 19 Oct 2015 11:44:43 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (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 2FA5E1B2BB1 for ; Mon, 19 Oct 2015 11:44:42 -0700 (PDT) Received: by qgad10 with SMTP id d10so72671542qga.3 for ; Mon, 19 Oct 2015 11:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type; bh=y1XTpRBVCDMx3XSn426mTP7vjoFMBATT3BTTAuchpQY=; b=kWOuA34v0rAcqugMjopjTGpP830Sezx07eryH5zyUYorl37lspYikTilnY0nDwf7tO r8f94z+gbKw7XkXoiyJxT8OUw74ThT4oAUMiNtwtyc19U8xqYCvHxl/9woVFwBEJ7ryM 8VXdojtZA0IW37vwzhQl9DGKCU2UauuGvmmmwMdMY+6WV0A9Yka1fR4gP8vlzl3PiilO lz4lVdnQBCBvVuifxVCLiJsPCVob96VIkUy/OsO1Zy+YyaTiRXqUyWUZKVPJzzPPysi+ khnKfC4gxCZQW3OwJVnNDsNyXxhNGMOPFrO9qnhoiQDGUG0ts7vIids7im4Toz7ua7Cs WMdw== X-Received: by 10.140.146.66 with SMTP id 63mr10964757qhs.100.1445280281394; Mon, 19 Oct 2015 11:44:41 -0700 (PDT) Received: from [172.30.19.28] ([72.246.0.14]) by smtp.gmail.com with ESMTPSA id u89sm14907245qkl.27.2015.10.19.11.44.40 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Oct 2015 11:44:40 -0700 (PDT) User-Agent: Microsoft-MacOutlook/0.0.0.151008 Date: Mon, 19 Oct 2015 14:44:39 -0400 From: Aaron Falk To: Message-ID: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> Thread-Topic: IETF planning Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3528110680_1288394918" Archived-At: Subject: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 18:44:46 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3528110680_1288394918 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Folks- So, we have these two docs and a rough agreement that they are complimentar= y. Gorry suggests that they both progress as responsive to milestone 1: I suggest the two docs against the first milestone will help us make progress towards the next milestone faster. (Assuming we can keep the two aligned, which seems quite doable). I can see also how the docs are useful to different people. I'd like to see both mature and provide inputs to move forward. Is there agreement on this? I=E2=80=99ve heard no objections. Assuming so, we s= hould move on. First, I would ask that the authors summarize the work remaining on each do= c to the list and call out any topics requiring discussion at the Yokohama m= eeting. Second, let=E2=80=99s hear some proposals for addressing the second milestone. =20 2) Specify the subset of those Transport Services, as identified=20 in item 1, that end systems supporting TAPS will provide, and=20 give guidance on choosing among available mechanisms and=20 protocols. Note that not all the capabilities of IETF Transport=20 protocols need to be exposed as Transport Services. --B_3528110680_1288394918 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Hi Folks-

So, we have these two docs and a rough agreement that = they are complimentary.  Gorry suggests that they both progress as resp= onsive to milestone 1:

 I suggest the two docs against the fir= st milestone will help us
the two aligned, whic= h seems quite doable). I can see also how the  docs
are useful to different people. I'd like to= see both mature and provide
inputs to move forward.

I= s there agreement on this?  I’ve heard no objections.  Assum= ing so, we should move on.

First, I would a= sk that the authors summarize the work remaining on each doc to the list and= call out any topics requiring discussion at the Yokohama meeting.

Second, let’s hear some proposals for addressi= ng the second milestone.  

2) Sp=
ecify the subset of those Transport Services, as identified 
   in item 1, that end systems supporting TAPS will provide, and 
   give guidance on choosing among available mechanisms and 
   protocols.  Note that not all the capabilities of IETF Transpo=
rt 
   protocols need to be exposed as Transport Services.
--B_3528110680_1288394918-- From nobody Thu Oct 22 01:32:17 2015 Return-Path: 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 8975B1A19F8 for ; Thu, 22 Oct 2015 01:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 szSr3_uYVF53 for ; Thu, 22 Oct 2015 01:32:13 -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 E4AFC1A1B2A for ; Thu, 22 Oct 2015 01:32:12 -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 ) id 1ZpBI9-0000ah-OQ; Thu, 22 Oct 2015 10:32:09 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZpBI9-00086a-2q; Thu, 22 Oct 2015 10:32:09 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_85276A9D-6346-4F8E-B93C-C87132E3F050" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> Date: Thu, 22 Oct 2015 10:32:07 +0200 Message-Id: References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> To: Aaron Falk X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 4 sum rcpts/h 9 sum msgs/h 6 total rcpts 34216 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C7A7FEA7A582E5951FAD32D856132AC7DE4994D5 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 1885 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 08:32:16 -0000 --Apple-Mail=_85276A9D-6346-4F8E-B93C-C87132E3F050 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 19. okt. 2015, at 20.44, Aaron Falk wrote: >=20 > Hi Folks- >=20 > So, we have these two docs and a rough agreement that they are = complimentary. Gorry suggests that they both progress as responsive to = milestone 1: >=20 >> I suggest the two docs against the first milestone will help us >> make progress towards the next milestone faster. (Assuming we can = keep >> the two aligned, which seems quite doable). I can see also how the = docs >> are useful to different people. I'd like to see both mature and = provide >> inputs to move forward. >=20 > Is there agreement on this? I=E2=80=99ve heard no objections. = Assuming so, we should move on. >=20 > First, I would ask that the authors summarize the work remaining on = each doc to the list and call out any topics requiring discussion at the = Yokohama meeting. draft-welzl-taps-transports currently only covers TCP and SCTP. But = then: how many other protocols? It seems people agree that the protocols covered in = draft-welzl-taps-transports should be a subset of the protocols covered = in draft-ietf-taps-transports. My question is, then: how to choose the = subset? It seems obvious to include protocols that are seeing some deployment, = i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP=E2=80=A6 However: if that is the only decision ground, we probably wouldn=E2=80=99t= include DCCP. Are we then making a significant mistake, missing a = lesson to be learned? That, to me, is a discussion I=E2=80=99d like to have in Yokohama. > Second, let=E2=80=99s hear some proposals for addressing the second = milestone. =20 >=20 > 2) Specify the subset of those Transport Services, as identified > in item 1, that end systems supporting TAPS will provide, and > give guidance on choosing among available mechanisms and > protocols. Note that not all the capabilities of IETF Transport > protocols need to be exposed as Transport Services. It may not be much, but fwiw, draft-gjessing-taps-minset exists. It = contains some ideas on how services could be narrowed down, and these = could be applied to draft-welzl-taps-transports just as well as to = draft-ietf-taps-transports (which it=E2=80=99s currently written = around). Cheers, Michael --Apple-Mail=_85276A9D-6346-4F8E-B93C-C87132E3F050 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 19. okt. 2015, at 20.44, Aaron Falk <aaron.falk@gmail.com> wrote:

Hi= Folks-

So, we have these two = docs and a rough agreement that they are complimentary.  Gorry = suggests that they both progress as responsive to milestone 1:

 I suggest the two docs against the first milestone will = help us
make  progress = towards the next milestone faster. (Assuming we can keep
the two aligned, which seems quite doable). I can = see also how the  docs
are useful = to different people. I'd like to see both mature and provide
inputs to move = forward.

Is there agreement on this?  I=E2=80=99v= e heard no objections.  Assuming so, we should move on.

First, I would ask that the = authors summarize the work remaining on each doc to the list and call = out any topics requiring discussion at the Yokohama = meeting.

draft-welzl-taps-transports currently only covers = TCP and SCTP. But then: how many other protocols?
It seems = people agree that the protocols covered in draft-welzl-taps-transports = should be a subset of the protocols covered in = draft-ietf-taps-transports. My question is, then: how to choose the = subset?

It seems obvious to include = protocols that are seeing some deployment, i.e. of course UDP, maybe = UDP-Lite (?), but also MPTCP=E2=80=A6
However: if that is the = only decision ground, we probably wouldn=E2=80=99t include DCCP. Are we = then making a significant mistake, missing a lesson to be = learned?

That, to me, is a discussion = I=E2=80=99d like to have in Yokohama.


Second, let=E2=80=99s hear some proposals for = addressing the second milestone.  

2) Specify the subset of those Transport =
Services, as identified
   in item 1, that end systems supporting TAPS will provide, and
   give guidance on choosing among available mechanisms and
   protocols.  Note that not all the capabilities of IETF =
Transport
   protocols need to be exposed as Transport Services.

It = may not be much, but fwiw, draft-gjessing-taps-minset exists. It = contains some ideas on how services could be narrowed down, and these = could be applied to draft-welzl-taps-transports just as well as = to draft-ietf-taps-transports  (which it=E2=80=99s currently = written around).

Cheers,
Michael

= --Apple-Mail=_85276A9D-6346-4F8E-B93C-C87132E3F050-- From nobody Thu Oct 22 02:40:19 2015 Return-Path: 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 3225D1B3566 for ; Thu, 22 Oct 2015 02:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 DyFDhcgCemWa for ; Thu, 22 Oct 2015 02:40:16 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id D068F1B3249 for ; Thu, 22 Oct 2015 02:40:15 -0700 (PDT) Received: from public-docking-cx-0533.ethz.ch (public-docking-pat-cx-mapped-0023.ethz.ch [195.176.111.24]) by trammell.ch (Postfix) with ESMTPSA id A83C51A05D6; Thu, 22 Oct 2015 11:40:14 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C1ABF344-2A9B-4D0F-958E-FB2E29B6170E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Brian Trammell In-Reply-To: Date: Thu, 22 Oct 2015 11:40:13 +0200 Message-Id: References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> To: Michael Welzl X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Aaron Falk , "taps@ietf.org" Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 09:40:18 -0000 --Apple-Mail=_C1ABF344-2A9B-4D0F-958E-FB2E29B6170E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 Oct 2015, at 10:32, Michael Welzl wrote: >=20 >=20 >> On 19. okt. 2015, at 20.44, Aaron Falk wrote: >>=20 >> Hi Folks- >>=20 >> So, we have these two docs and a rough agreement that they are = complimentary. Gorry suggests that they both progress as responsive to = milestone 1: >>=20 >>> I suggest the two docs against the first milestone will help us >>> make progress towards the next milestone faster. (Assuming we can = keep >>> the two aligned, which seems quite doable). I can see also how the = docs >>> are useful to different people. I'd like to see both mature and = provide >>> inputs to move forward. >>=20 >> Is there agreement on this? I=E2=80=99ve heard no objections. = Assuming so, we should move on. >>=20 >> First, I would ask that the authors summarize the work remaining on = each doc to the list and call out any topics requiring discussion at the = Yokohama meeting. >=20 > draft-welzl-taps-transports currently only covers TCP and SCTP. But = then: how many other protocols? > It seems people agree that the protocols covered in = draft-welzl-taps-transports should be a subset of the protocols covered = in draft-ietf-taps-transports. My question is, then: how to choose the = subset? >=20 > It seems obvious to include protocols that are seeing some deployment, = i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP=E2=80=A6 > However: if that is the only decision ground, we probably wouldn=E2=80=99= t include DCCP. Are we then making a significant mistake, missing a = lesson to be learned? >=20 > That, to me, is a discussion I=E2=80=99d like to have in Yokohama. +1, and FWIW that's exactly the same starting point I got to on my own. >> Second, let=E2=80=99s hear some proposals for addressing the second = milestone. >>=20 >> 2) Specify the subset of those Transport Services, as identified >> in item 1, that end systems supporting TAPS will provide, and >> give guidance on choosing among available mechanisms and >> protocols. Note that not all the capabilities of IETF Transport >> protocols need to be exposed as Transport Services. >>=20 >=20 > It may not be much, but fwiw, draft-gjessing-taps-minset exists. It = contains some ideas on how services could be narrowed down, and these = could be applied to draft-welzl-taps-transports just as well as to = draft-ietf-taps-transports (which it=E2=80=99s currently written = around). There's probably quibbling to be done about the details, but I believe = draft-gjessing is a good starting point for charter item 2. Cheers, Brian > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_C1ABF344-2A9B-4D0F-958E-FB2E29B6170E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWKK7+AAoJEIoSt78L6kajv+UP/ids/no4WkvfM8W9km+QG+mV 9Zg9v0SjxbPG2tArm1cAcoEJRP13PBZz6tI6/dq4wamPp4WGgvrLNcCC22U1s6iz tGAxf4O7Q8kKNMXT4X4K2itNE2EmyK/EqHqT44eIXvvNDuibm82fc1Pyng5ARlTU ELBtFa6JphvZwNV0bQZf/2tV28dygXKGE8Ayt4eOCY19Ge5kT2xWOwxqwn4z6evV HmiB6Ix+d1eCIWBOhZO0k7a9PRq3BzFcVmZ9fZ1IJH2Bu1xgbZ9gDBFdV+/GXUkt CqX/IDLld3ZR6/AahfyBMFH5fiLtA1CO7qOPU4a0Eb/J5Qql0RmSacB2maLdat6+ rtna86t2y2NAJrhX0fRwwZZJMxTDvOpFdOg7t3IiS/P9Qso5qVs+daXGRv1NrZLM F59NFONehWns5bz5boWbyBQfKyxX+0aPv3eLbdIO2E7INzbDSIzdEmzARpG6tKMo G24kuuOvJCpGcZ5dO+lEnI1VA7ihoddLLhLooPJ2OgrlPFpmCjhS9pbALHpdX577 hqakGDj1DV1scoRwIz8g6dRRul4Ld2OTSoUjTb7EtK5JL80Z9CEr2r+EoE1bqV42 FjHY4q8ELmHqMO/XnH7GCTv/Z40sW6ipONT+sLTibrLErxbxD1nGshIkhkKhRi3p Ks8hwW6lwHgXA7ZcradO =Apxc -----END PGP SIGNATURE----- --Apple-Mail=_C1ABF344-2A9B-4D0F-958E-FB2E29B6170E-- From nobody Thu Oct 22 07:14:31 2015 Return-Path: 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 1BB4E1ACF03 for ; Thu, 22 Oct 2015 07:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 A7QlnPA9YSKL for ; Thu, 22 Oct 2015 07:14:29 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (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 BB0B51ACEFB for ; Thu, 22 Oct 2015 07:14:29 -0700 (PDT) Received: by ykdr3 with SMTP id r3so83507383ykd.1 for ; Thu, 22 Oct 2015 07:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CKf8BgxBCyBFy6Ugkc49x2m5BaQ43VrPhWWXm53N8fE=; b=h9Oj9Z0czJaq4a8reaXa+lUzhZ/lGNBdy5hh4+PaCeg6R+UCcL+/zIFCYe/Q1z6oic CeiVLR5hyRCTwgFrSW2kprVVStNEANa5be9cmQIHc46cIGf4espGr5/zshIZdcO+iuZk U1fFaXcGEVPCtSRLXpOIBEj7mUXj+xoFc5bOP+B3teCZ/irRm5DaWjEvWRqeU1aB0TWw jmU3eSnRQzAm/g9RwJcLTXsuc0k8R6qW0wfNk4YEtJfwtr3zHxuVXppFZdBbCUvjnbCu kAYjRSnI/PzzVQCmrR8JEcoifAjQZnZHXCogYrYzf0mDFtvYTqZeRV04QL0ptRopGjN7 S+SA== MIME-Version: 1.0 X-Received: by 10.13.201.68 with SMTP id l65mr11276492ywd.340.1445523269045; Thu, 22 Oct 2015 07:14:29 -0700 (PDT) Received: by 10.37.95.2 with HTTP; Thu, 22 Oct 2015 07:14:28 -0700 (PDT) In-Reply-To: References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> Date: Thu, 22 Oct 2015 10:14:28 -0400 Message-ID: From: Aaron Falk To: Stein Gjessing Content-Type: multipart/alternative; boundary=001a114e870af756f80522b21ca9 Archived-At: Cc: Brian Trammell , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 14:14:31 -0000 --001a114e870af756f80522b21ca9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > > > draft-welzl-taps-transports currently only covers TCP and SCTP. But > then: how many other protocols? > > It seems people agree that the protocols covered in > draft-welzl-taps-transports should be a subset of the protocols covered i= n > draft-ietf-taps-transports. My question is, then: how to choose the subse= t? > > > > It seems obvious to include protocols that are seeing some deployment, > i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP=E2=80=A6 > > However: if that is the only decision ground, we probably wouldn=E2=80= =99t > include DCCP. Are we then making a significant mistake, missing a lesson = to > be learned? > > > > That, to me, is a discussion I=E2=80=99d like to have in Yokohama. > > +1, and FWIW that's exactly the same starting point I got to on my own. > > Any volunteers to kick off the lead the discussion? > > It may not be much, but fwiw, draft-gjessing-taps-minset exists. It > contains some ideas on how services could be narrowed down, and these cou= ld > be applied to draft-welzl-taps-transports just as well as to > draft-ietf-taps-transports (which it=E2=80=99s currently written around)= . > > There's probably quibbling to be done about the details, but I believe > draft-gjessing is a good starting point for charter item 2. > > Stein, will you be in Yokohama and interested in leading a discussion on this draft? --aaron --001a114e870af756f80522b21ca9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> draft-welzl-taps-transports currently only covers TCP and SCTP. But th= en: how many other protocols?
> It seems people agree that the protocols covered in draft-welzl-taps-t= ransports should be a subset of the protocols covered in draft-ietf-taps-tr= ansports. My question is, then: how to choose the subset?
>
> It seems obvious to include protocols that are seeing some deployment,= i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP=E2=80=A6
> However: if that is the only decision ground, we probably wouldn=E2=80= =99t include DCCP. Are we then making a significant mistake, missing a less= on to be learned?
>
> That, to me, is a discussion I=E2=80=99d like to have in Yokohama.

+1, and FWIW that's exactly the same starting point I got to on = my own.


Any volunteers= to kick off the lead the discussion?

=C2=A0
=
> It may not be much, but fwiw, draft-gjessing-taps-minset exists. It co= ntains some ideas on how services could be narrowed down, and these could b= e applied to draft-welzl-taps-transports just as well as to draft-ietf-taps= -transports=C2=A0 (which it=E2=80=99s currently written around).

There's probably quibbling to be done about the details, but I b= elieve draft-gjessing is a good starting point for charter item 2.



Stein, will you be in Y= okohama and interested in leading a discussion on this draft?
--aaron
--001a114e870af756f80522b21ca9-- From nobody Thu Oct 22 09:20:03 2015 Return-Path: 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 3460B1A6F7A for ; Thu, 22 Oct 2015 09:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 b3OfY-TebTzp for ; Thu, 22 Oct 2015 09:19:59 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 677F41A3BA6 for ; Thu, 22 Oct 2015 09:19:59 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZpIar-0001uR-60; Thu, 22 Oct 2015 18:19:57 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZpIaq-0007yg-IP; Thu, 22 Oct 2015 18:19:57 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_ACE9F393-BE77-4E5E-BFC5-E6320EA81F3B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Thu, 22 Oct 2015 18:19:55 +0200 Message-Id: References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> To: Aaron Falk X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 9 sum msgs/h 5 total rcpts 34235 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1F403125B7359AF6123BF29DDB117FBC30833DF4 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 2 total 1900 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , "taps@ietf.org" , Stein Gjessing Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 16:20:02 -0000 --Apple-Mail=_ACE9F393-BE77-4E5E-BFC5-E6320EA81F3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22. okt. 2015, at 16.14, Aaron Falk wrote: >=20 >=20 > > draft-welzl-taps-transports currently only covers TCP and SCTP. But = then: how many other protocols? > > It seems people agree that the protocols covered in = draft-welzl-taps-transports should be a subset of the protocols covered = in draft-ietf-taps-transports. My question is, then: how to choose the = subset? > > > > It seems obvious to include protocols that are seeing some = deployment, i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP=E2=80=A6= > > However: if that is the only decision ground, we probably wouldn=E2=80= =99t include DCCP. Are we then making a significant mistake, missing a = lesson to be learned? > > > > That, to me, is a discussion I=E2=80=99d like to have in Yokohama. >=20 > +1, and FWIW that's exactly the same starting point I got to on my = own. >=20 >=20 > Any volunteers to kick off the lead the discussion? Let me try to roll this some more on the list, because I gave it some = thought: The goal is to have something buildable. So if we allow protocols that = are hardly deployed into draft-welzl-taps-transports, then this gives us = a list that may include services that one can never implement unless = hardly-deployed protocol X is used, or other protocols are extended to = all of a sudden provide this functionality. Thus, boring as it may seem, =E2=80=9Cwidely deployed protocols=E2=80=9D = can be the only reasonable criterion to allow adding protocols in = draft-welzl-taps-transports Thoughts? Cheers, Michael --Apple-Mail=_ACE9F393-BE77-4E5E-BFC5-E6320EA81F3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 22. okt. 2015, at 16.14, Aaron Falk <aaron.falk@gmail.com> wrote:


> draft-welzl-taps-transports currently only covers TCP and SCTP. But = then: how many other protocols?
> It seems people agree that the protocols covered in = draft-welzl-taps-transports should be a subset of the protocols covered = in draft-ietf-taps-transports. My question is, then: how to choose the = subset?
>
> It seems obvious to include protocols that are seeing some = deployment, i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP=E2=80=A6=
> However: if that is the only decision ground, we probably = wouldn=E2=80=99t include DCCP. Are we then making a significant mistake, = missing a lesson to be learned?
>
> That, to me, is a discussion I=E2=80=99d like to have in = Yokohama.

+1, and FWIW that's exactly the same starting point I got to on = my own.


Any volunteers to kick off the lead the = discussion?

Let me try to roll this some more on the list, because = I gave it some thought:

The goal is = to have something buildable. So if we allow protocols that are hardly = deployed into draft-welzl-taps-transports, then this gives us a = list that may include services that one can never implement unless = hardly-deployed protocol X is used, or other protocols are extended to = all of a sudden provide this functionality.

Thus, boring as it may seem, =E2=80=9Cwidely = deployed protocols=E2=80=9D can be the only reasonable criterion to = allow adding protocols in draft-welzl-taps-transports

Thoughts?

Cheers,
Michael

= --Apple-Mail=_ACE9F393-BE77-4E5E-BFC5-E6320EA81F3B-- From nobody Thu Oct 22 11:46:59 2015 Return-Path: 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 61E461B3B1A for ; Thu, 22 Oct 2015 11:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 439TefDeDY01 for ; Thu, 22 Oct 2015 11:46:56 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 5D4E91B3B17 for ; Thu, 22 Oct 2015 11:46:55 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZpKt3-0001qM-MM; Thu, 22 Oct 2015 20:46:53 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZpKt3-0003VF-6D; Thu, 22 Oct 2015 20:46:53 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_44C7A2B1-D0EF-4175-9F05-0DEF7CF51FDE" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> Date: Thu, 22 Oct 2015 20:46:52 +0200 Message-Id: <3AD6FE1A-7E9E-4A30-89DA-6D4870623C24@ifi.uio.no> References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> To: Aaron Falk X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 7 sum msgs/h 4 total rcpts 34239 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 535002BA4D448274272A9A4D9A9565C3B584FAB7 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1903 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 18:46:58 -0000 --Apple-Mail=_44C7A2B1-D0EF-4175-9F05-0DEF7CF51FDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 19. okt. 2015, at 20.44, Aaron Falk wrote: >=20 > Hi Folks- >=20 > So, we have these two docs and a rough agreement that they are = complimentary. Gorry suggests that they both progress as responsive to = milestone 1: >=20 >> I suggest the two docs against the first milestone will help us >> make progress towards the next milestone faster. (Assuming we can = keep >> the two aligned, which seems quite doable). I can see also how the = docs >> are useful to different people. I'd like to see both mature and = provide >> inputs to move forward. >=20 > Is there agreement on this? I=E2=80=99ve heard no objections. = Assuming so, we should move on. =3D> So, I=E2=80=99d like to ask for WG adoption of = draft-welzl-taps-transports Cheers, Michael --Apple-Mail=_44C7A2B1-D0EF-4175-9F05-0DEF7CF51FDE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 19. okt. 2015, at 20.44, Aaron Falk <aaron.falk@gmail.com> wrote:

Hi= Folks-

So, we have these two = docs and a rough agreement that they are complimentary.  Gorry = suggests that they both progress as responsive to milestone 1:

 I suggest the two docs against the first milestone will = help us
make  progress = towards the next milestone faster. (Assuming we can keep
the two aligned, which seems quite doable). I can = see also how the  docs
are useful = to different people. I'd like to see both mature and provide
inputs to move = forward.

Is there agreement on this?  I=E2=80=99v= e heard no objections.  Assuming so, we should move = on.

=3D> So, I=E2=80=99d like to ask for WG adoption = of draft-welzl-taps-transports

Cheers,
Michael

= --Apple-Mail=_44C7A2B1-D0EF-4175-9F05-0DEF7CF51FDE-- From nobody Thu Oct 22 13:23:37 2015 Return-Path: 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 AC2D91B40A9 for ; Thu, 22 Oct 2015 13:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 tyrg4wVBU6Go for ; Thu, 22 Oct 2015 13:23:34 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id B4A5E1B40A7 for ; Thu, 22 Oct 2015 13:23:34 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2:8c88:436c:e6dd:5a22] (unknown [IPv6:2001:470:26:9c2:8c88:436c:e6dd:5a22]) by trammell.ch (Postfix) with ESMTPSA id 8A7D21A0023; Thu, 22 Oct 2015 22:23:33 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Brian Trammell In-Reply-To: Date: Thu, 22 Oct 2015 22:23:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> To: Michael Welzl X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Aaron Falk , Stein Gjessing , "taps@ietf.org" Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 20:23:36 -0000 hi Michael, > On 22 Oct 2015, at 18:19, Michael Welzl wrote: >=20 >=20 >> On 22. okt. 2015, at 16.14, Aaron Falk wrote: >>=20 >>=20 >> > draft-welzl-taps-transports currently only covers TCP and SCTP. But = then: how many other protocols? >> > It seems people agree that the protocols covered in = draft-welzl-taps-transports should be a subset of the protocols covered = in draft-ietf-taps-transports. My question is, then: how to choose the = subset? >> > >> > It seems obvious to include protocols that are seeing some = deployment, i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP=E2=80=A6= >> > However: if that is the only decision ground, we probably = wouldn=E2=80=99t include DCCP. Are we then making a significant mistake, = missing a lesson to be learned? >> > >> > That, to me, is a discussion I=E2=80=99d like to have in Yokohama. >>=20 >> +1, and FWIW that's exactly the same starting point I got to on my = own. >>=20 >>=20 >> Any volunteers to kick off the lead the discussion? >=20 > Let me try to roll this some more on the list, because I gave it some = thought: >=20 > The goal is to have something buildable. So if we allow protocols that = are hardly deployed into draft-welzl-taps-transports, then this gives us = a list that may include services that one can never implement unless = hardly-deployed protocol X is used, or other protocols are extended to = all of a sudden provide this functionality. >=20 > Thus, boring as it may seem, =E2=80=9Cwidely deployed protocols=E2=80=9D= can be the only reasonable criterion to allow adding protocols in = draft-welzl-taps-transports s/widely deployed/widely implemented/g, but yes. Another thought: draft-gjessing (as it currently is) looks at the = minimal set of services. If there are services we believe are useful to = support that are not presently widely implemented or deployed, we can = certainly add them as optional, no? The only services that could not be = handled in such a way would be those that have an impact on the API = other than just adding knobs and meters, no? Cheers, Brian > Thoughts? >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Oct 23 00:13:22 2015 Return-Path: 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 4FE881ACCDF for ; Fri, 23 Oct 2015 00:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 AoyYi-H9XQMn for ; Fri, 23 Oct 2015 00:13:20 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 196511B2E03 for ; Fri, 23 Oct 2015 00:13:19 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZpWXM-0004SP-MO; Fri, 23 Oct 2015 09:13:16 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZpWXL-0000t2-Ty; Fri, 23 Oct 2015 09:13:16 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Fri, 23 Oct 2015 09:13:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> To: Brian Trammell X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 9 sum msgs/h 4 total rcpts 34254 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 43FABF687368A835B1EFEED408CF96C691304297 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 1 total 1910 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , Stein Gjessing , "taps@ietf.org" Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 07:13:22 -0000 > On 22. okt. 2015, at 22.23, Brian Trammell wrote: >=20 > hi Michael, >=20 >> On 22 Oct 2015, at 18:19, Michael Welzl wrote: >>=20 >>=20 >>> On 22. okt. 2015, at 16.14, Aaron Falk wrote: >>>=20 >>>=20 >>>> draft-welzl-taps-transports currently only covers TCP and SCTP. But = then: how many other protocols? >>>> It seems people agree that the protocols covered in = draft-welzl-taps-transports should be a subset of the protocols covered = in draft-ietf-taps-transports. My question is, then: how to choose the = subset? >>>>=20 >>>> It seems obvious to include protocols that are seeing some = deployment, i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP=E2=80=A6= >>>> However: if that is the only decision ground, we probably = wouldn=E2=80=99t include DCCP. Are we then making a significant mistake, = missing a lesson to be learned? >>>>=20 >>>> That, to me, is a discussion I=E2=80=99d like to have in Yokohama. >>>=20 >>> +1, and FWIW that's exactly the same starting point I got to on my = own. >>>=20 >>>=20 >>> Any volunteers to kick off the lead the discussion? >>=20 >> Let me try to roll this some more on the list, because I gave it some = thought: >>=20 >> The goal is to have something buildable. So if we allow protocols = that are hardly deployed into draft-welzl-taps-transports, then this = gives us a list that may include services that one can never implement = unless hardly-deployed protocol X is used, or other protocols are = extended to all of a sudden provide this functionality. >>=20 >> Thus, boring as it may seem, =E2=80=9Cwidely deployed protocols=E2=80=9D= can be the only reasonable criterion to allow adding protocols in = draft-welzl-taps-transports >=20 > s/widely deployed/widely implemented/g, but yes. Agreed > Another thought: draft-gjessing (as it currently is) looks at the = minimal set of services. If there are services we believe are useful to = support that are not presently widely implemented or deployed, we can = certainly add them as optional, no? The only services that could not be = handled in such a way would be those that have an impact on the API = other than just adding knobs and meters, no? Sorry, you lose me here - in particular I don=E2=80=99t get the part = about =E2=80=9Chave an impact on the API=E2=80=A6=E2=80=9D. Could you = maybe give a toy example? Cheers, Michael From nobody Fri Oct 23 00:22:46 2015 Return-Path: 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 364611B2E4A for ; Fri, 23 Oct 2015 00:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1nhSTYBtx9aP for ; Fri, 23 Oct 2015 00:22:44 -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 5329A1B2E05 for ; Fri, 23 Oct 2015 00:22:44 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZpWgU-0004oy-9e; Fri, 23 Oct 2015 09:22:42 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZpWgT-0004An-QN; Fri, 23 Oct 2015 09:22:42 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_52B3EE5B-10CD-4502-AA60-B946B49A50C6" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> Date: Fri, 23 Oct 2015 09:22:41 +0200 Message-Id: References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> To: Aaron Falk X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 3 sum rcpts/h 12 sum msgs/h 6 total rcpts 34257 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C126594B74C4A584EDD203A883609E0604154D52 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 1912 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 07:22:46 -0000 --Apple-Mail=_52B3EE5B-10CD-4502-AA60-B946B49A50C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, About this: > Second, let=E2=80=99s hear some proposals for addressing the second = milestone. =20 >=20 > 2) Specify the subset of those Transport Services, as identified > in item 1, that end systems supporting TAPS will provide, and > give guidance on choosing among available mechanisms and > protocols. Note that not all the capabilities of IETF Transport > protocols need to be exposed as Transport Services. I think this should be based on the services in = draft-welzl-taps-transports. Then, isn=E2=80=99t it a bit premature to = worry about this second item? Yes I think we can progress fast with = draft-welzl-taps-transports, but still it=E2=80=99s only the first = version now. I think this item should therefore wait a bit. Cheers, Michael --Apple-Mail=_52B3EE5B-10CD-4502-AA60-B946B49A50C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

About = this:

Second, let=E2=80=99s hear some proposals for addressing the = second milestone.  

2) Specify the =
subset of those Transport Services, as identified
   in item 1, that end systems supporting TAPS will provide, and
   give guidance on choosing among available mechanisms and
   protocols.  Note that not all the capabilities of IETF =
Transport
   protocols need to be exposed as Transport Services.

I think this should be = based on the services in draft-welzl-taps-transports. Then, isn=E2=80= =99t it a bit premature to worry about this second item? Yes I think we = can progress fast with draft-welzl-taps-transports, but still it=E2=80=99s= only the first version now. I think this item should therefore wait a = bit.

Cheers,
Michael

= --Apple-Mail=_52B3EE5B-10CD-4502-AA60-B946B49A50C6-- From nobody Fri Oct 23 18:15:45 2015 Return-Path: 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 33AE51B2C86 for ; Fri, 23 Oct 2015 18:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 D12yi7vqpB5u for ; Fri, 23 Oct 2015 18:15:42 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4ABF1B2C75 for ; Fri, 23 Oct 2015 18:15:41 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t9O1F49u012746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 23 Oct 2015 18:15:08 -0700 (PDT) To: Brian Trammell , Aaron Falk References: <20150921083533.19273.62189.idtracker@ietfa.amsl.com> <1D77A9B2-C37B-4ACF-A90D-DB485BC79B28@mjmontpetit.com> <92f091c456879303283af39e26ea14d5.squirrel@erg.abdn.ac.uk> <435C039A-5B01-450B-9223-883194F0B94D@mjmontpetit.com> <0FB76D15-3904-4D10-8FFD-F0E445E2564C@trammell.ch> From: Joe Touch Message-ID: <562ADB98.6070306@isi.edu> Date: Fri, 23 Oct 2015 18:15:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <0FB76D15-3904-4D10-8FFD-F0E445E2564C@trammell.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: " Fairhurst" , "taps@ietf.org" , Marie-Jose Montpetit , Michael Welzl , touch@isi.edu Subject: Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2015 01:15:44 -0000 +1 I have read this version in detail (and provided feedback), and think it is a useful document. Joe On 10/5/2015 12:49 PM, Brian Trammell wrote: > In transit, please excuse the brevity. > > Broadly I appreciate the effort to do the decomposition in a less > arbitrary way. I'm not convinced it's actually less arbitrary, but this > is largely irrelevant: it's a *different* way to do the decomposition, > so points of agreement (of which, at least on TCP and SCTP, there are > many) reinforce confidence that we're doing this right. I tend to agree > with Gorry's suggestion on the way forward. > > Cheers, Brian > > Sent from my iPhone > > On 05 Oct 2015, at 11:42, Aaron Falk > wrote: > >> Have others read this draft yet? It is clearly aimed at addressing >> charter deliverable #1. Do other folks have an opinion on how well it >> helps the group achieve the goals in our charter? Should we use this >> document in some way? I'm looking for more input from the working >> group on how we should proceed. >> >> My opinion: I am very mindful (& appreciative) of the significant >> effort by Mirja and Brian and the other contributors on >> draft-ietf-taps-transports. The discussion around this doc has been >> very useful for clarifying (to me) how difficult it can be to pull >> useful common abstractions out of the 30+ years of transport >> technologies. Having been down this path for over a year, I >> appreciate the fairly narrow approach draft-welzl-taps-transports and >> think it may be the best chance for TAPS to succeed. >> >> Please share your views. >> >> --aaron >> >> >> On Sat, Sep 26, 2015 at 10:50 AM, Michael Welzl > > wrote: >> >> +1 >> >> > On 26. sep. 2015, at 13.28, Marie-Jose Montpetit >> > wrote: >> > >> > Makes sense. >> > >> >> On Sep 26, 2015, at 3:17 AM, gorry@erg.abdn.ac.uk >> wrote: >> >> >> >> We seem to have two documents in a space where we started with >> one. These >> >> are different, to me this is OK. Both seem close to charter >> milestone 1. I >> >> don't see much overlap between the contents of the descriptive >> language >> >> and the API-focussed analysis, and any overlap could be eliminated. >> >> >> >> To me, doc 1 (current chartered item) can evolve to provide >> background and >> >> missing documentation for anyone in the IETF, and should compare >> >> transports in a broad way and draw out the idea that they provide >> >> services. This appears to be harder to get right than I for one >> had hoped, >> >> and still has a wide scope. Not a bad thing. I suggest it will >> provide a >> >> reference to stop us rat-holing when people ask what is "this" >> and explain >> >> how all these transports stack-up against one another (good >> pun?). We can >> >> (I suggest) finish this doc in this way. >> >> >> >> I do like the idea of a second document focussed ONLY on the >> Transport API >> >> (I'd call this 1a). In this we can avoid this"discussion of >> what are >> >> transports" and move to a more focussed process in doc 1b, >> Most of >> >> that troublesome descriptive text can go into 1, and ensure we >> keep that >> >> one readable to anyone in the IETF. >> >> >> >> Could I suggest the two docs against the first milestone will >> help us >> >> make progress towards the next milestone faster. (Assuming we >> can keep >> >> the two aligned, which seems quite doable). I can see also how >> the docs >> >> are useful to different people. I'd like to see both mature and >> provide >> >> inputs to move forward. >> >> >> >> Gorry >> >> >> >> >> >>> Interesting and inline to getting transport API(s) >> >>> >> >>> Marie-José Montpetit >> >>> marie@mjmontpetit.com >> >>> mariejo@mit.edu >> >>> >> >>>> On Sep 21, 2015, at 04:44, Michael Welzl > > wrote: >> >>>> >> >>>> Dear all, >> >>>> >> >>>> In my presentation in Prague, I proposed an approach to >> identify the >> >>>> services that transport protocols provide. At the end of the >> ensuing >> >>>> discussion, I said that I (with co-authors) would write a >> draft that >> >>>> explains the proposal by applying the proposed method to TCP >> and SCTP. >> >>>> >> >>>> We just submitted this document - see below; I hope that >> this will lead >> >>>> to some discussion on the list... >> >>>> >> >>>> Cheers, >> >>>> Michael >> >>>> >> >>>> >> >>>>> Begin forwarded message: >> >>>>> >> >>>>> From: > > >> >>>>> Subject: New Version Notification for >> >>>>> draft-welzl-taps-transports-00.txt >> >>>>> Date: 21 Sep 2015 10:35:33 CEST >> >>>>> To: Michael Welzl > >, Michael Welzl >> >>>>> >, Michael >> Tuexen >, Naeem >> >>>>> Khademi >, >> Michael Tuexen >, >> >>>>> Naeem Khademi > >> >>>>> Resent-From: > >> >>>>> >> >>>>> >> >>>>> A new version of I-D, draft-welzl-taps-transports-00.txt >> >>>>> has been successfully submitted by Michael Welzl and posted >> to the >> >>>>> IETF repository. >> >>>>> >> >>>>> Name: draft-welzl-taps-transports >> >>>>> Revision: 00 >> >>>>> Title: An Approach to Identify Services Provided by IETF >> >>>>> Transport Protocols and Congestion Control Mechanisms >> >>>>> Document date: 2015-09-21 >> >>>>> Group: Individual Submission >> >>>>> Pages: 23 >> >>>>> URL: >> >>>>> >> https://www.ietf.org/internet-drafts/draft-welzl-taps-transports-00.txt >> >>>>> Status: >> >>>>> https://datatracker.ietf.org/doc/draft-welzl-taps-transports/ >> >>>>> Htmlized: >> >>>>> https://tools.ietf.org/html/draft-welzl-taps-transports-00 >> >>>>> >> >>>>> >> >>>>> Abstract: >> >>>>> This document describes a method to identify services in >> transport >> >>>>> protocols and congestion control mechanisms. It shows the >> approach >> >>>>> using TCP and SCTP (base protocol) as examples. >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Please note that it may take a couple of minutes from the >> time of >> >>>>> submission >> >>>>> until the htmlized version and diff are available at >> tools.ietf.org . >> >>>>> >> >>>>> The IETF Secretariat >> >>>> >> >>>> _______________________________________________ >> >>>> 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 >> >>> >> >> >> > >> >> _______________________________________________ >> 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 > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Mon Oct 26 02:55:40 2015 Return-Path: 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 DA4431B396B for ; Mon, 26 Oct 2015 02:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Pg4mOsiy1MSK for ; Mon, 26 Oct 2015 02:55:35 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 50A701B3A59 for ; Mon, 26 Oct 2015 02:55:35 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id BDC811B001B9; Mon, 26 Oct 2015 10:02:50 +0000 (GMT) References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> To: Aaron Falk , Stein Gjessing From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <562DF846.7090901@erg.abdn.ac.uk> Date: Mon, 26 Oct 2015 09:54:14 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Brian Trammell , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 09:55:38 -0000 On 22/10/2015 15:14, Aaron Falk wrote: > > > draft-welzl-taps-transports currently only covers TCP and SCTP. But then: how many other protocols? > > It seems people agree that the protocols covered in draft-welzl-taps-transports should be a subset of the protocols covered in draft-ietf-taps-transports. My question is, then: how to choose the subset? > > > > It seems obvious to include protocols that are seeing some deployment, i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP… > > However: if that is the only decision ground, we probably wouldn’t include DCCP. Are we then making a significant mistake, missing a lesson to be learned? > > > > That, to me, is a discussion I’d like to have in Yokohama. > > +1, and FWIW that's exactly the same starting point I got to on my own. > > > Any volunteers to kick off the lead the discussion? > > So, I think UDP, and UDP-Lite *NEED* to be included. MPTCOP also. On DCCP, this has many services being re-invented above. I think we have an interesting dilemma about whether to describe this, I suggest one of the reason for the minimal use of DCCP (DCCP/UDP) could well be the lack of a framework that allows this to be done without recoding an app. So, if we had such a framework *WHEN* DCCP/UDP was done, we may now have seen more usage. > > --aaron > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > Gorry From nobody Mon Oct 26 06:17:21 2015 Return-Path: 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 81BC41B3E09 for ; Mon, 26 Oct 2015 06:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 OUP-IWCxq79W for ; Mon, 26 Oct 2015 06:17:18 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 8F9761B3E08 for ; Mon, 26 Oct 2015 06:17:18 -0700 (PDT) Received: by ykek133 with SMTP id k133so510264yke.2 for ; Mon, 26 Oct 2015 06:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HYv5SQsvHiPZaVYZnWb11dxRlSxn/9LixH8HgBm0GDg=; b=RIyPg9X1+02UYOgrhcj0DeLPtIRwX/TP55ip6oHkKk08Y48dfQQb0uj9/7OenBrBTX HnrCn6ZbzSr3MaCHjrv8aKJBmfKuVXhV+pzWqIH6u7ELqgVGvm9+7oKbDw0wIcC/ZNj3 2zYFrcHnla//EvomNKmqnYSRdstlW1kkvwtKEJz4JAuTbbZyuJTt6C1gCQ8xduvqGWqm fBz3L2mKNUtdVp4WKwG4euiGWiiNO6Ry7gbAjxIt11vtpTHWiBiT0HDniuQq9tGHvIrL 8U+ob2dBgB2DXPAJJT8i7k/LlAl3vw9d0Jln/NTT3VqrKESAA1aowC/Z4u6Eo1OKAdKl LQhw== MIME-Version: 1.0 X-Received: by 10.13.245.134 with SMTP id e128mr25513913ywf.24.1445865437859; Mon, 26 Oct 2015 06:17:17 -0700 (PDT) Received: by 10.37.95.2 with HTTP; Mon, 26 Oct 2015 06:17:17 -0700 (PDT) In-Reply-To: <562DF846.7090901@erg.abdn.ac.uk> References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <562DF846.7090901@erg.abdn.ac.uk> Date: Mon, 26 Oct 2015 09:17:17 -0400 Message-ID: From: Aaron Falk To: Gorry Fairhurst Content-Type: multipart/alternative; boundary=94eb2c034df0d13086052301c757 Archived-At: Cc: Brian Trammell , "taps@ietf.org" , Michael Welzl , Stein Gjessing Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 13:17:20 -0000 --94eb2c034df0d13086052301c757 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Oct 26, 2015 at 5:54 AM, Gorry Fairhurst wrote: > On 22/10/2015 15:14, Aaron Falk wrote: > >> >> > draft-welzl-taps-transports currently only covers TCP and SCTP. Bu= t >> then: how many other protocols? >> > It seems people agree that the protocols covered in >> draft-welzl-taps-transports should be a subset of the protocols covered = in >> draft-ietf-taps-transports. My question is, then: how to choose the subs= et? >> > >> > It seems obvious to include protocols that are seeing some >> deployment, i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP=E2=80= =A6 >> > However: if that is the only decision ground, we probably wouldn= =E2=80=99t >> include DCCP. Are we then making a significant mistake, missing a lesson= to >> be learned? >> > >> > That, to me, is a discussion I=E2=80=99d like to have in Yokohama. >> >> +1, and FWIW that's exactly the same starting point I got to on my >> own. >> >> >> Any volunteers to kick off the lead the discussion? >> >> >> > > > So, I think UDP, and UDP-Lite *NEED* to be included. MPTCOP also. > > On DCCP, this has many services being re-invented above. I think we have > an interesting dilemma about whether to describe this, I suggest one of t= he > reason for the minimal use of DCCP (DCCP/UDP) could well be the lack of a > framework that allows this to be done without recoding an app. So, if we > had such a framework *WHEN* DCCP/UDP was done, we may now have seen more > usage. I don't understand. Why leave out any of the protocols included in draft-ietf-taps-transports? Is there an argument other than for expedience= ? --aaron --94eb2c034df0d13086052301c757 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Oct 26, 2015 at 5:54 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk= > wrote:
On 22= /10/2015 15:14, Aaron Falk wrote:

=C2=A0 =C2=A0 > draft-welzl-taps-transports currently only covers TCP an= d SCTP. But then: how many other protocols?
=C2=A0 =C2=A0 > It seems people agree that the protocols covered in draf= t-welzl-taps-transports should be a subset of the protocols covered in draf= t-ietf-taps-transports. My question is, then: how to choose the subset?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > It seems obvious to include protocols that are seeing so= me deployment, i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP=E2=80= =A6
=C2=A0 =C2=A0 > However: if that is the only decision ground, we probabl= y wouldn=E2=80=99t include DCCP. Are we then making a significant mistake, = missing a lesson to be learned?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > That, to me, is a discussion I=E2=80=99d like to have in= Yokohama.

=C2=A0 =C2=A0 +1, and FWIW that's exactly the same starting point I got= to on my own.


Any volunteers to kick off the lead the discussion?



 <snip test on another draft>

So, I think UDP, and UDP-Lite *NEED* to be included. MPTCOP also.

On DCCP, this has many services being re-invented above. I think we have an= interesting dilemma about whether to describe this, I suggest one of the r= eason for the minimal use of DCCP (DCCP/UDP) could well be the lack of a fr= amework that allows this to be done without recoding an app. So, if we had = such a framework *WHEN* DCCP/UDP was done, we may now have seen more usage.=

I don't understand.=C2=A0 Why leave ou= t any of the protocols included in draft-ietf-taps-transports?=C2=A0 Is the= re an argument other than for expedience?

--aaron<= /div>
--94eb2c034df0d13086052301c757-- From nobody Mon Oct 26 06:50:07 2015 Return-Path: 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 357BE1B3E62 for ; Mon, 26 Oct 2015 06:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 w3k8uJ-Tf_qA for ; Mon, 26 Oct 2015 06:50:03 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 B3B631B3E96 for ; Mon, 26 Oct 2015 06:50:02 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Zqi6r-0007nX-Vm; Mon, 26 Oct 2015 14:46:49 +0100 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Zqi6r-0005Ui-79; Mon, 26 Oct 2015 14:46:49 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_CBEA31F0-4686-4EF1-9ACF-C32BF964F302" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Mon, 26 Oct 2015 14:46:47 +0100 Message-Id: <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <562DF846.7090901@erg.abdn.ac.uk> To: Aaron Falk X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 12 sum msgs/h 3 total rcpts 34363 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 20867889C86842604033C2A6A9ADEA7613190367 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 2 total 1958 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: " Fairhurst" , Brian Trammell , "taps@ietf.org" , Stein Gjessing Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 13:50:06 -0000 --Apple-Mail=_CBEA31F0-4686-4EF1-9ACF-C32BF964F302 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26. okt. 2015, at 14.17, Aaron Falk wrote: >=20 > On Mon, Oct 26, 2015 at 5:54 AM, Gorry Fairhurst > wrote: > On 22/10/2015 15:14, Aaron Falk wrote: >=20 > > draft-welzl-taps-transports currently only covers TCP and SCTP. = But then: how many other protocols? > > It seems people agree that the protocols covered in = draft-welzl-taps-transports should be a subset of the protocols covered = in draft-ietf-taps-transports. My question is, then: how to choose the = subset? > > > > It seems obvious to include protocols that are seeing some = deployment, i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP=E2=80=A6= > > However: if that is the only decision ground, we probably = wouldn=E2=80=99t include DCCP. Are we then making a significant mistake, = missing a lesson to be learned? > > > > That, to me, is a discussion I=E2=80=99d like to have in = Yokohama. >=20 > +1, and FWIW that's exactly the same starting point I got to on my = own. >=20 >=20 > Any volunteers to kick off the lead the discussion? >=20 >=20 >=20 > >=20 > So, I think UDP, and UDP-Lite *NEED* to be included. MPTCOP also. Assuming this is a typo and you mean MPTCP, I agree. > On DCCP, this has many services being re-invented above. I think we = have an interesting dilemma about whether to describe this, I suggest = one of the reason for the minimal use of DCCP (DCCP/UDP) could well be = the lack of a framework that allows this to be done without recoding an = app. So, if we had such a framework *WHEN* DCCP/UDP was done, we may now = have seen more usage. I understand and agree, but that doesn=E2=80=99t help us now=E2=80=A6 > I don't understand. Why leave out any of the protocols included in = draft-ietf-taps-transports? Is there an argument other than for = expedience? Working towards a realistic end-goal of a deployable system. So we=E2=80=99re 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. Say we include DCCP. It=E2=80=99ll add some services that aren=E2=80=99t = 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=E2=80=99ll 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. I understand that we can see these as optional, and end up with a = document iii) that has a small mandatory base and lots of optional = things - but this will then be a huge document, of which only a small = subset will ever be implemented. Personally I think that=E2=80=99s a = possibility but not really what we should aim at. Cheers, Michael --Apple-Mail=_CBEA31F0-4686-4EF1-9ACF-C32BF964F302 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 26. okt. 2015, at 14.17, Aaron Falk <aaron.falk@gmail.com> wrote:

On Mon, = Oct 26, 2015 at 5:54 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
On = 22/10/2015 15:14, Aaron Falk wrote:

    > draft-welzl-taps-transports currently only covers TCP = and SCTP. But then: how many other protocols?
    > It seems people agree that the protocols covered in = draft-welzl-taps-transports should be a subset of the protocols covered = in draft-ietf-taps-transports. My question is, then: how to choose the = subset?
    >
    > It seems obvious to include protocols that are seeing = some deployment, i.e. of course UDP, maybe UDP-Lite (?), but also = MPTCP=E2=80=A6
    > However: if that is the only decision ground, we = probably wouldn=E2=80=99t include DCCP. Are we then making a significant = mistake, missing a lesson to be learned?
    >
    > That, to me, is a discussion I=E2=80=99d like to have = in Yokohama.

    +1, and FWIW that's exactly the same starting point I got = to on my own.


Any volunteers to kick off the lead the discussion?



 <snip test on another draft>

So, I think UDP, and UDP-Lite *NEED* to be included. MPTCOP also.

Assuming this is a typo and you mean MPTCP, I = agree.


On DCCP, this has many services being re-invented above. I think we have = an interesting dilemma about whether to describe this, I suggest one of = the reason for the minimal use of DCCP (DCCP/UDP) could well be the lack = of a framework that allows this to be done without recoding an app. So, = if we had such a framework *WHEN* DCCP/UDP was done, we may now have = seen more = usage.

I understand and agree, but that doesn=E2=80=99t help = us now=E2=80=A6



I don't = understand.  Why leave out any of the protocols included in = draft-ietf-taps-transports?  Is there an argument other than for = expedience?

Working towards a realistic end-goal of a = deployable system.

So = we=E2=80=99re 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.

Say = we include DCCP. It=E2=80=99ll add some services that aren=E2=80=99t 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=E2=80=99ll 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.

I understand that we can see these as optional, and end up = with a document iii) that has a small mandatory base and lots of = optional things - but this will then be a huge document, of which only a = small subset will ever be implemented. Personally I think that=E2=80=99s = a possibility but not really what we should aim at.

Cheers,
Michael

= --Apple-Mail=_CBEA31F0-4686-4EF1-9ACF-C32BF964F302-- From nobody Mon Oct 26 07:46:33 2015 Return-Path: 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 6F3B31B4681 for ; Mon, 26 Oct 2015 07:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ZT4I-p0uSJI2 for ; Mon, 26 Oct 2015 07:46:28 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id E3C151B4680 for ; Mon, 26 Oct 2015 07:46:27 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id CA6B51B00253; Mon, 26 Oct 2015 14:53:43 +0000 (GMT) References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> To: Michael Welzl , Aaron Falk From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <562E3CC2.1010008@erg.abdn.ac.uk> Date: Mon, 26 Oct 2015 14:46:26 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Brian Trammell , "taps@ietf.org" , Stein Gjessing Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 14:46:30 -0000 On 26/10/2015 13:46, Michael Welzl wrote: > >> On 26. okt. 2015, at 14.17, Aaron Falk > > wrote: >> >> On Mon, Oct 26, 2015 at 5:54 AM, Gorry Fairhurst > > wrote: >> >> On 22/10/2015 15:14, Aaron Falk wrote: >> >> >> > draft-welzl-taps-transports currently only covers TCP >> and SCTP. But then: how many other protocols? >> > It seems people agree that the protocols covered in >> draft-welzl-taps-transports should be a subset of the >> protocols covered in draft-ietf-taps-transports. My question >> is, then: how to choose the subset? >> > >> > It seems obvious to include protocols that are seeing >> some deployment, i.e. of course UDP, maybe UDP-Lite (?), but >> also MPTCP… >> > However: if that is the only decision ground, we >> probably wouldn’t include DCCP. Are we then making a >> significant mistake, missing a lesson to be learned? >> > >> > That, to me, is a discussion I’d like to have in Yokohama. >> >> +1, and FWIW that's exactly the same starting point I got >> to on my own. >> >> >> Any volunteers to kick off the lead the discussion? >> >> >> >> >> >> So, I think UDP, and UDP-Lite *NEED* to be included. MPTCOP also. > > Assuming this is a typo and you mean MPTCP, I agree. > Then we agree on this. > >> On DCCP, this has many services being re-invented above. I think >> we have an interesting dilemma about whether to describe this, I >> suggest one of the reason for the minimal use of DCCP (DCCP/UDP) >> could well be the lack of a framework that allows this to be done >> without recoding an app. So, if we had such a framework *WHEN* >> DCCP/UDP was done, we may now have seen more usage. > > I understand and agree, but that doesn’t help us now… > > >> I don't understand. Why leave out any of the protocols included in >> draft-ietf-taps-transports? Is there an argument other than for >> expedience? > > 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. > > 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. > > I understand that we can see these as optional, and end up with a > document iii) that has a small mandatory base and lots of optional > things - but this will then be a huge document, of which only a small > subset will ever be implemented. Personally I think that’s a possibility > but not really what we should aim at. > > Cheers, > Michael > Yes, that discussion is probably consistent with my thinking - If we want to focus on what can be made right now, we can't include DCCP - not because it can't be done - a lot of code has been written, and we understand the spec - but because it's one step further-on than we currently can achieve easily in the first pass. (If that's the motivation for excluding it, I would understand at this stage.) I think one could say the same for other protocols that could/have been layered over UDP. Does that also therefore mean we don't currently include such other protocols? Gorry From nobody Mon Oct 26 08:35:52 2015 Return-Path: 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 720E41B4B37 for ; Mon, 26 Oct 2015 08:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TcEoXmRuea9l for ; Mon, 26 Oct 2015 08:35:46 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 78C831B4B36 for ; Mon, 26 Oct 2015 08:35:37 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Zqjo6-0003e9-Fp; Mon, 26 Oct 2015 16:35:34 +0100 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Zqjo5-0001Wz-R7; Mon, 26 Oct 2015 16:35:34 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <562E3CC2.1010008@erg.abdn.ac.uk> Date: Mon, 26 Oct 2015 16:35:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9FB253A2-5947-4BA7-B73F-86C099371691@ifi.uio.no> References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> <562E3CC2.1010008@erg.abdn.ac.uk> To: " Fairhurst" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 3 sum rcpts/h 12 sum msgs/h 4 total rcpts 34376 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F6A8217BC5649F6E78E981E6B61C6833F050E416 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 3 total 1963 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , Brian Trammell , "taps@ietf.org" , Stein Gjessing Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 15:35:49 -0000 > On 26. okt. 2015, at 15.46, Gorry Fairhurst = wrote: >=20 > On 26/10/2015 13:46, Michael Welzl wrote: >>=20 >>> On 26. okt. 2015, at 14.17, Aaron Falk >> > wrote: >>>=20 >>> On Mon, Oct 26, 2015 at 5:54 AM, Gorry Fairhurst = >> > wrote: >>>=20 >>> On 22/10/2015 15:14, Aaron Falk wrote: >>>=20 >>>=20 >>> > draft-welzl-taps-transports currently only covers TCP >>> and SCTP. But then: how many other protocols? >>> > It seems people agree that the protocols covered in >>> draft-welzl-taps-transports should be a subset of the >>> protocols covered in draft-ietf-taps-transports. My question >>> is, then: how to choose the subset? >>> > >>> > It seems obvious to include protocols that are seeing >>> some deployment, i.e. of course UDP, maybe UDP-Lite (?), but >>> also MPTCP=E2=80=A6 >>> > However: if that is the only decision ground, we >>> probably wouldn=E2=80=99t include DCCP. Are we then making a >>> significant mistake, missing a lesson to be learned? >>> > >>> > That, to me, is a discussion I=E2=80=99d like to have = in Yokohama. >>>=20 >>> +1, and FWIW that's exactly the same starting point I got >>> to on my own. >>>=20 >>>=20 >>> Any volunteers to kick off the lead the discussion? >>>=20 >>>=20 >>>=20 >>> >>>=20 >>> So, I think UDP, and UDP-Lite *NEED* to be included. MPTCOP also. >>=20 >> Assuming this is a typo and you mean MPTCP, I agree. >>=20 > Then we agree on this. =E2=80=A6 and I guess we should add TLS, DTLS to that list. >>> On DCCP, this has many services being re-invented above. I think >>> we have an interesting dilemma about whether to describe this, I >>> suggest one of the reason for the minimal use of DCCP (DCCP/UDP) >>> could well be the lack of a framework that allows this to be done >>> without recoding an app. So, if we had such a framework *WHEN* >>> DCCP/UDP was done, we may now have seen more usage. >>=20 >> I understand and agree, but that doesn=E2=80=99t help us now=E2=80=A6 >>=20 >>=20 >>> I don't understand. Why leave out any of the protocols included in >>> draft-ietf-taps-transports? Is there an argument other than for >>> expedience? >>=20 >> Working towards a realistic end-goal of a deployable system. >>=20 >> So we=E2=80=99re 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. >>=20 >> Say we include DCCP. It=E2=80=99ll add some services that aren=E2=80=99= 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=E2=80=99ll >> 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 >>=20 >> None of these two options are very helpful if we want to TAPS to be = real >> thing one day. >>=20 >> I understand that we can see these as optional, and end up with a >> document iii) that has a small mandatory base and lots of optional >> things - but this will then be a huge document, of which only a small >> subset will ever be implemented. Personally I think that=E2=80=99s a = possibility >> but not really what we should aim at. >>=20 >> Cheers, >> Michael >>=20 > Yes, that discussion is probably consistent with my thinking - If we = want to focus on what can be made right now, we can't include DCCP - not = because it can't be done - a lot of code has been written, and we = understand the spec - but because it's one step further-on than we = currently can achieve easily in the first pass. (If that's the = motivation for excluding it, I would understand at this stage.) >=20 > I think one could say the same for other protocols that could/have = been layered over UDP. Does that also therefore mean we don't currently = include such other protocols? Which protocols are you thinking of? I think the argument about = widespread implementation and use, not whether it=E2=80=99s run over UDP = or not=E2=80=A6 Cheers, Michael From nobody Mon Oct 26 09:35:57 2015 Return-Path: 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 7FE981B4F40 for ; Mon, 26 Oct 2015 09:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 vZ0Cfl_VxCAH for ; Mon, 26 Oct 2015 09:35:55 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (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 CA46E1B4F3F for ; Mon, 26 Oct 2015 09:35:54 -0700 (PDT) Received: by ykft191 with SMTP id t191so7135069ykf.0 for ; Mon, 26 Oct 2015 09:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CXOvJz/F4XpIPN+UpJE3wwzkE1N+XiMwsubtQ3k3CiM=; b=otX3xj/zBxE7wz/nXAs0JDeIBwd8Lmh7uoMfMzQGeZBodEy3G+XwpwUW39crSFT2Oy aAxlY/QwxcVPvWKVgf7CGkU+A9BKOdvUIDOVtAmTfqzqZ0rsVBtRa5B8e0pjgmFgowik KDVk/RSRf6HfQPWDTecsckgS80tkksiC1g1a+HuFxjWmV8xikD6h5AkXv6ONfcNobQE8 LS/E1FRXodBa4hRXBL3pQnwvw/pZscD51yFsJW6rDXikWiAUgZlunW6LIjCb1snv4P+l 8zZIueB7tqdjttTDYAm1KK8LlaxuyKo+fGGkVoRmw2V4qnalI2fSPa1ULNIzcU1asvTB DXEA== MIME-Version: 1.0 X-Received: by 10.13.240.66 with SMTP id z63mr26149629ywe.261.1445877354055; Mon, 26 Oct 2015 09:35:54 -0700 (PDT) Received: by 10.37.95.2 with HTTP; Mon, 26 Oct 2015 09:35:53 -0700 (PDT) In-Reply-To: <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> Date: Mon, 26 Oct 2015 12:35:53 -0400 Message-ID: From: Aaron Falk To: Michael Welzl Content-Type: multipart/alternative; boundary=94eb2c035ec813d0b30523048e7a Archived-At: Cc: " Fairhurst" , Brian Trammell , "taps@ietf.org" , Stein Gjessing Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 16:35:56 -0000 --94eb2c035ec813d0b30523048e7a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Oct 26, 2015 at 9:46 AM, Michael Welzl wrote: > > Working towards a realistic end-goal of a deployable system. > > So we=E2=80=99re 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? > > Say we include DCCP. It=E2=80=99ll add some services that aren=E2=80=99t = in the other > protocols listed so far in this mail - e.g. drop notification (see sectio= n > 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=E2=80=99ll = have to > say how a TAPS system can support drop notification. So, to build a worki= ng > 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. 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. 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= ? > > I understand that we can see these as optional, and end up with a documen= t > iii) that has a small mandatory base and lots of optional things - but th= is > will then be a huge document, of which only a small subset will ever be > implemented. Personally I think that=E2=80=99s a possibility but not real= ly what we > should aim at. > --94eb2c035ec813d0b30523048e7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, 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=E2=80= =99re i) describing services; ii) narrowing them down somehow; iii) describ= ing how to build this thing.
My concern is with iii) being someth= ing feasible and useful, not an obscure sci-fi document.

Uh, yeah.=C2=A0 That's our charter.=C2=A0 Nar= rowing down is in doc 2.=C2=A0 Are you making the case we should do it in d= oc 1? =C2=A0

=C2=A0

Say we includ= e DCCP. It=E2=80=99ll add some services that aren=E2=80=99t in the other pr= otocols 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 argum= ents to remove drop notification. Then, in step iii), we=E2=80=99ll have to= say how a TAPS system can support drop notification. So, to build a workin= g 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 TA= PS to be real thing one day.

a:= TAPS is not chartered to do anything normative.=C2=A0 Doc 3 is about exper= imenting.

b: You are having the discussion that we= planned to have for Doc 2.=C2=A0 Make your case to drop those protocols th= en.=C2=A0 Or, if no one wants to write sections for the additional protocol= s for Doc 1a (an extended version of draft-welzl-taps-transports), then fol= ks are voting with their feet on the utility of keeping them.
c: One of the goals of TAPS is to enable deployment of transpor= t protocols such as DCCP where networks permit it without forcing applicati= on (or library) authors to handle probe and fallback.=C2=A0 If we don't= include protocols that aren't seeing deployment, what is the value of = this activity?
=C2=A0

I understand that we can s= ee these as optional, and end up with a document iii) that has a small mand= atory base and lots of optional things - but this will then be a huge docum= ent, of which only a small subset will ever be implemented. Personally I th= ink that=E2=80=99s a possibility but not really what we should aim at.
--94eb2c035ec813d0b30523048e7a-- From nobody Tue Oct 27 02:44:55 2015 Return-Path: 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 C76361A6F2B for ; Tue, 27 Oct 2015 02:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] 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 p-S5iOgRRwpr for ; Tue, 27 Oct 2015 02:44:52 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 5B9FC1A6EED for ; Tue, 27 Oct 2015 02:44:52 -0700 (PDT) Received: by iofz202 with SMTP id z202so214339721iof.2 for ; Tue, 27 Oct 2015 02:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Z4XrJtrIbM0vK085jZ5Zl/rnXcJsFqnBQorVuq71tQo=; b=Knsi7bO+CijM+SPJwWUktPKj22nBjhyYQw3IC+hTSEZsAJ/3ci7zOcZoLG2MpRQBm9 agWhaIqQX8cnXEMyX4fAORiQRVk669QfZlQKfgCg8wySSaEBNzSMTKE+ffI8kKdwl7QL U5jQs/Gcfz6KAMFYk1tg39NnExhWUXOM6LaFw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Z4XrJtrIbM0vK085jZ5Zl/rnXcJsFqnBQorVuq71tQo=; b=SVG0zLALgHPBITdhrjgjw50RBIo5VaMlsL0KN7vjpWCajk4H9xO7GOvIZJCcsGPz3p VZUquv+uSRkjvkPq6OL5i6cETfmlthDouQy995O4E4s2NX1KjXjUIG4C2Q/BTpYA6lhw n2zQt1kkebQM0EqZzb63n/qulFakxrgoImHib/LMvYVSz4xWzyZWVt/hSGNsFfNqBetA pQKFrDxeNx17EumLm8w51wpRZzkJgz/jcXVkR88IIYzXxbgGOEm7L8CLHxxoBfKzazve ChJtw4Z6Iudo9wmBctmuOOTKns299knjOetIfQ3hCHsaZg3bS9U56JvZIBMT6iD2XZ7E AgKw== X-Gm-Message-State: ALoCoQlizRFhnBNPDxBjYz4qAhM1PpZ2oLeZ39ivV6kSojyErkoLvi9d/lkNiPl1G4JGE4w+vlLs/rCTNAT4ZdljIZ7UFVISjM7mpwDN4QY5VOV8Qdl8RxI= X-Received: by 10.107.10.217 with SMTP id 86mr21642652iok.145.1445939091820; Tue, 27 Oct 2015 02:44:51 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> <562E3CC2.1010008@erg.abdn.ac.uk> In-Reply-To: <562E3CC2.1010008@erg.abdn.ac.uk> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 thread-index: AQLnIZNWolJn6oOSV5yTes39Ry1l7wE3EKfUAj1+V1oBGpplrwKU7z00AeovEUkCuc7VVwL9pdiBm9zGfVA= Date: Tue, 27 Oct 2015 10:44:50 +0100 Message-ID: To: gorry@erg.abdn.ac.uk, Michael Welzl , Aaron Falk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Cc: Brian Trammell , Stein Gjessing , taps@ietf.org Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 09:44:55 -0000 HI, Just a note. Not necessarily relevant for the overall argument however. > > > > So we=E2=80=99re i) describing services; ii) narrowing them down someho= w; iii) > > describing how to build this thing. > > My concern is with iii) being something feasible and useful, not an > > obscure sci-fi document. > > > > Say we include DCCP. It=E2=80=99ll add some services that aren=E2=80=99= 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=E2=80=99ll 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 > > SCTP also provides drop notification (SEND_FAILURE). BR, Karen From nobody Tue Oct 27 06:36:06 2015 Return-Path: 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 456131A8953 for ; Tue, 27 Oct 2015 06:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 tAeW7IRWeORY for ; Tue, 27 Oct 2015 06:35:53 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 6B7681A8948 for ; Tue, 27 Oct 2015 06:35:39 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Zr4PX-0008EY-MV; Tue, 27 Oct 2015 14:35:35 +0100 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Zr4PX-0005WE-5b; Tue, 27 Oct 2015 14:35:35 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Tue, 27 Oct 2015 14:35:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4E10F74F-7A3E-4A08-A631-33C76B3D457F@ifi.uio.no> References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> <562E3CC2.1010008@erg.abdn.ac.uk> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 8 sum msgs/h 3 total rcpts 34388 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 4FA42EF3E792FD3A4D03B477DCE9C08B0A60F3D0 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 2 total 1970 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: " Fairhurst" , Aaron Falk , "taps@ietf.org" , Stein Gjessing , Brian Trammell Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 13:36:00 -0000 > On 27. okt. 2015, at 10.44, Karen Elisabeth Egede Nielsen = wrote: >=20 > HI, >=20 > Just a note. Not necessarily relevant for the overall argument = however. >=20 >>>=20 >>> So we=E2=80=99re 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. >>>=20 >>> Say we include DCCP. It=E2=80=99ll add some services that aren=E2=80=99= 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=E2=80=99ll 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 >>>=20 >=20 > SCTP also provides drop notification (SEND_FAILURE). =E2=80=A6 and it=E2=80=99s actually covered in = draft-welzl-taps-transports, on page 16 ( = https://tools.ietf.org/html/draft-welzl-taps-transports-00#section-4.2 = ). Silly me! It=E2=80=99s an interesting example, though: forgetting that drop = notification (with a cause code) exists in SCTP, I picked =E2=80=9Cdrop = notification=E2=80=9D as an example service of DCCP because I remembered = it as an interesting functionality when the protocol was made, and (more = importantly) because it kind of stood out in the list in = draft-ietf-transports. Maybe the right thing to do is to use the list of =E2=80=9Ctransport = features" in draft-ietf-transports to see if a protocol adds anything = new to the mix or is really just essentially duplicating services that = already exist in the other protocols in draft-welzl-taps-transports, and = use that to decide whether to include a protocol or not? Cheers, Michael From nobody Tue Oct 27 06:47:28 2015 Return-Path: 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 26D5D1A8984 for ; Tue, 27 Oct 2015 06:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 doJUGKxLOv4q for ; Tue, 27 Oct 2015 06:47:21 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 BEB8F1A8982 for ; Tue, 27 Oct 2015 06:47:20 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Zr4as-0002cf-0O; Tue, 27 Oct 2015 14:47:18 +0100 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Zr4aq-0004ta-Kt; Tue, 27 Oct 2015 14:47:17 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_D53BF641-0861-4789-849C-8592E4193FB1" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Tue, 27 Oct 2015 14:47:15 +0100 Message-Id: <27697ADF-7AE6-4E99-8288-FF19A68F1411@ifi.uio.no> References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> To: Aaron Falk X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 12 msgs/h 3 sum rcpts/h 13 sum msgs/h 4 total rcpts 34393 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0360A29E4FBB2BC469EFC35323DBF9FD5552EE18 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 3 total 1971 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: " Fairhurst" , Brian Trammell , "taps@ietf.org" , Stein Gjessing Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 13:47:27 -0000 --Apple-Mail=_D53BF641-0861-4789-849C-8592E4193FB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26. okt. 2015, at 17.35, Aaron Falk wrote: >=20 > On Mon, Oct 26, 2015 at 9:46 AM, Michael Welzl > wrote: >=20 > Working towards a realistic end-goal of a deployable system. >=20 > So we=E2=80=99re 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. >=20 > Uh, yeah. That's our charter. Narrowing down is in doc 2. Are you = making the case we should do it in doc 1? =20 Well, just because we narrow down in doc 2 doesn=E2=80=99t 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=E2=80=99d 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=E2=80=99t 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=E2=80=99s a valuable discussion to = have! > Say we include DCCP. It=E2=80=99ll add some services that aren=E2=80=99t= 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=E2=80=99ll 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 >=20 > None of these two options are very helpful if we want to TAPS to be = real thing one day. >=20 > a: TAPS is not chartered to do anything normative. Doc 3 is about = experimenting. Sure! But it=E2=80=99s still about stuff that someone should be able to = build - I just don=E2=80=99t 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=E2=80=99t worry too much: this is = only the very first version, we haven=E2=80=99t 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=E2=80=99m 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=E2=80=A6 Cheers, Michael --Apple-Mail=_D53BF641-0861-4789-849C-8592E4193FB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=E2=80=99re 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=E2=80=99t 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=E2=80=99d 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=E2=80=99t 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=E2=80=99s a valuable discussion to have!


Say we include = DCCP. It=E2=80=99ll add some services that aren=E2=80=99t 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=E2=80=99ll 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=E2=80=99s still about stuff that = someone should be able to build - I just don=E2=80=99t 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=E2=80=99t worry too much: this is = only the very first version, we haven=E2=80=99t 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=E2=80=99m 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=E2=80=A6

Cheers,
Michael

= --Apple-Mail=_D53BF641-0861-4789-849C-8592E4193FB1-- From nobody Tue Oct 27 06:58:58 2015 Return-Path: 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 272451A89B0 for ; Tue, 27 Oct 2015 06:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] 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 l6RSIhk-gzkl for ; Tue, 27 Oct 2015 06:58:54 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 A69801A89A6 for ; Tue, 27 Oct 2015 06:58:54 -0700 (PDT) Received: by igbkq10 with SMTP id kq10so83030563igb.0 for ; Tue, 27 Oct 2015 06:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-type; bh=iuFPBUzHYMuHXuki8h0RPy25lTsvRyrpLjBqOOHxoro=; b=VIbQhl+qdZZ6M3uYi4lq0+WnXAGp+rZ95EfYJ1xeS+P6q/fpN6uLik8kbcPvt7OA3l Y7oaKgR8ptm/EtWTuVMqTV8v/oUlHxK3RgIsfITAPqT3UQXKhzu6WqFPDdN/Iw70gnz1 o4ELlSwqYj9z5MI9qPjdw5qiXbFg4KT2nISpk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=iuFPBUzHYMuHXuki8h0RPy25lTsvRyrpLjBqOOHxoro=; b=iLNpEefpYyZyT5BhHlrKlosa0bnfOvOnYyYQGQKcTSav1HvRYr3lyFU0kcrpu/L955 /Y4m/x2JgJpoIeUhdtd0kGEPbLWqrTYROYnbKN3pf7w2tAeKpW4ig99joNlS9KLfMYM7 FLeCeWGjJCBj676D5kAYUtmh9lx/lOCivIMTchaEqET4PLreZJcZRnCFNu0VGmRoojB9 K/UGfCg6EyW4EGzb3JP2bz59E5VSqYHHqaFQgnbhgW9OGDpBmOrUYxKSPSd7J9Fg9ZDw /AhJjSByVcgevh1mq/rkZqruiLsVAIlFUG3Qf/PF3n22JxrW587r+h1HlnMWwPXjpI60 MC/Q== X-Gm-Message-State: ALoCoQle0p2jXvajrIOIKfpt+5gjEtZquDJTTBdT8FHhTQiN2Nce/mpHCpJQWRfVxmR+Hkn0F3Ac63idNuayu+urd2tbWZ39nKjXbKH0WlaDQln9+HjxtJA= X-Received: by 10.50.87.69 with SMTP id v5mr25685758igz.2.1445954334013; Tue, 27 Oct 2015 06:58:54 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20150921083533.19273.62189.idtracker@ietfa.amsl.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 thread-index: AQKdK9Xuvg/e8qMO2/7tp8zJAaxQOQC0KKL7nOF2XUA= Date: Tue, 27 Oct 2015 14:58:52 +0100 Message-ID: <9ac4441c10c70ae76c7bb75dc3613494@mail.gmail.com> To: Michael Welzl , taps WG Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Subject: Re: [Taps] Fwd: New Version Notification for draft-welzl-taps-transports-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 13:58:57 -0000 HI, FWIIW please accept the following comments to the document: Section 3.1: "Passive open with fully specified foreign socket" Is that a typical function provided to ULP by TCP ? Our POSIX socket api implementation does not really provide this. Or it does by set of special filters on the listening socket, but I wasn't aware that this was a feature generally available in TCP. "Passive open with fully specified foreign socket" on a unspecified passive open socket ? I assume we speak listening socket. Again is this something typically provided as an option to ULP by TCP ? "Send: and PUSH flag description": The PUSH flag is typically set inside the TCP implementation and the ULP typically has no direct influence on the setting of it. I think that it is strange that this function is chosen to be described as if it is controlled directly by ULP when it is indeed not. There is some text later in section 3.1.1 motivating the choice. Yes it is correct that TCP implementations implement set of PUSH flag causing a behavior (i.e., a set of PUSH) that matches that the PUSH flag is set in the end of a communication, but again it is not controlled by ULP. As the intend of this document is to expose services that the ULP can invoke, I think that it is problematic that it is described as if the ULP can control PUSH directly, when it indeed (often) cannot. Section 3.2: General comment: The multi-stream capability and stream prioritization/scheduling possibilities of SCTP is a feature differentiating SCTP from TCP. The same is the fact that SCTP (SCTP-PR) also provide unreliable (no retransmissions) and partial reliable transport service (timeout). I think that these service features are important for certain SCTP deployment scenarios and that it would be desirable for these to be exposed here. (The timeout is described) It not included here in the first pass it will never even get considered for TAPS as a potential service, would it ? (It might end up being excluding, but then this should be a conscious (visible) choice, I think). Detailed comments: "Initialize needs be called only once per set of local addresses": This is the case when supporting one-to-many style sockets. Perhaps one might add "but ULP may also initialize each association endpoint instance individually". "Associate": I think that it is relevant to clarify that the remote SCTP instance in the association primitive is identified by one or multiple destination addresses thus allowing also the association handshake to proceed using multiple paths. "Send": "Another advisory flag indicates the ULP's preference to avoid bundling user data .." This is specified as an optional attribute in RFC4960. This is not specified in the RFC6458 socket API. ((Yes it might be similar to the TCP PUSH flag in that it is not generally implemented as directly controllable by ULP on a message basis - Or?)) Section 4.2: SCTP implements NO_delay (Nagle) option on a per association basis (as TCP on a per connection basis) but not typically on a per message basis as described here. There are some additional bundling control related to stream scheduling - some are described in sctp-ndata draft. Section 5.1: "Disable Nagle algorithm:" Not specified in RFC4960, but in RFC6458 for SCTP. Is it really valid to use RFC4960 as a reference for the socket API when the approach of SCTP IETF community has been to use RFC6458 for this ? *** BR, Karen > -----Original Message----- > From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Michael Welzl > Sent: 21. september 2015 10:45 > To: taps WG > Subject: [Taps] Fwd: New Version Notification for draft-welzl-taps- > transports-00.txt > > Dear all, > > In my presentation in Prague, I proposed an approach to identify the services > that transport protocols provide. At the end of the ensuing discussion, I said > that I (with co-authors) would write a draft that explains the proposal by > applying the proposed method to TCP and SCTP. > > We just submitted this document - see below; I hope that this will lead to > some discussion on the list... > > Cheers, > Michael > > > > Begin forwarded message: > > > > From: > > Subject: New Version Notification for > > draft-welzl-taps-transports-00.txt > > Date: 21 Sep 2015 10:35:33 CEST > > To: Michael Welzl , Michael Welzl > > , Michael Tuexen , > Naeem > > Khademi , Michael Tuexen muenster.de>, > > Naeem Khademi > > Resent-From: > > > > > > A new version of I-D, draft-welzl-taps-transports-00.txt > > has been successfully submitted by Michael Welzl and posted to the > > IETF repository. > > > > Name: draft-welzl-taps-transports > > Revision: 00 > > Title: An Approach to Identify Services Provided by > IETF Transport Protocols and Congestion Control Mechanisms > > Document date: 2015-09-21 > > Group: Individual Submission > > Pages: 23 > > URL: https://www.ietf.org/internet-drafts/draft-welzl-taps- > transports-00.txt > > Status: https://datatracker.ietf.org/doc/draft-welzl-taps-transports/ > > Htmlized: https://tools.ietf.org/html/draft-welzl-taps-transports-00 > > > > > > Abstract: > > This document describes a method to identify services in transport > > protocols and congestion control mechanisms. It shows the approach > > using TCP and SCTP (base protocol) as examples. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Oct 27 07:00:27 2015 Return-Path: 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 6EF9D1A89AA for ; Tue, 27 Oct 2015 07:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 xlluYXFyl19N for ; Tue, 27 Oct 2015 07:00:23 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2741A89A6 for ; Tue, 27 Oct 2015 07:00:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 29E4FD930E; Tue, 27 Oct 2015 15:00:22 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MkADKhvJgrRB; Tue, 27 Oct 2015 15:00:21 +0100 (MET) Received: from [192.168.178.33] (x5f717ab6.dyn.telefonica.de [95.113.122.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 61432D930C; Tue, 27 Oct 2015 15:00:21 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <27697ADF-7AE6-4E99-8288-FF19A68F1411@ifi.uio.no> Date: Tue, 27 Oct 2015 15:00:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6F9FB87C-D0FF-46B3-A634-8A2E1234F9B7@tik.ee.ethz.ch> References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> <27697ADF-7AE6-4E99-8288-FF19A68F1411@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Aaron Falk , " Fairhurst" , "taps@ietf.org" , Stein Gjessing , Brian Trammell Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 14:00:26 -0000 Hi all, I didn=E2=80=99t say anything so far because I don=E2=80=99t mind to = have a second protocol here, but I personally don=E2=80=99t 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. =46rom 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.=20 I agree that the taps-transport doc is quite long, but for the wg I = don=E2=80=99t 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.=20 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=E2=80=99s actually a quite nice overview doc now. That=E2=80=99s just my 2c. I don=E2=80=99t 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 : >=20 >=20 >> On 26. okt. 2015, at 17.35, Aaron Falk wrote: >>=20 >> On Mon, Oct 26, 2015 at 9:46 AM, Michael Welzl = wrote: >>=20 >> Working towards a realistic end-goal of a deployable system. >>=20 >> So we=E2=80=99re 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. >>=20 >> Uh, yeah. That's our charter. Narrowing down is in doc 2. Are you = making the case we should do it in doc 1? =20 >=20 > Well, just because we narrow down in doc 2 doesn=E2=80=99t 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=E2=80=99d 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=E2=80=99t yet exist. >=20 > 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=E2=80=99s a valuable discussion to = have! >=20 >=20 >> Say we include DCCP. It=E2=80=99ll add some services that aren=E2=80=99= 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=E2=80=99ll 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 >>=20 >> None of these two options are very helpful if we want to TAPS to be = real thing one day. >>=20 >> a: TAPS is not chartered to do anything normative. Doc 3 is about = experimenting. >=20 > Sure! But it=E2=80=99s still about stuff that someone should be able = to build - I just don=E2=80=99t want doc 3 to become a sci-fi literature = piece :-) >=20 >=20 >> 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. >=20 > See my arguments above; about getting sections done for = draft-welzl-taps-transports, I don=E2=80=99t worry too much: this is = only the very first version, we haven=E2=80=99t asked anyone for inputs = yet (and I can volunteer to cover a few more protocols myself). >=20 >=20 >> 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? >=20 > This is a very good point. I=E2=80=99m 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=E2=80=A6 >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Oct 27 07:07:29 2015 Return-Path: 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 DBC2D1A89EB for ; Tue, 27 Oct 2015 07:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 jvihDIFlEwEK for ; Tue, 27 Oct 2015 07:07:26 -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 79DE51A8A1E for ; Tue, 27 Oct 2015 07:07:24 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Zr4uI-00038A-8T; Tue, 27 Oct 2015 15:07:22 +0100 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Zr4uH-0000qW-Ik; Tue, 27 Oct 2015 15:07:22 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <9ac4441c10c70ae76c7bb75dc3613494@mail.gmail.com> Date: Tue, 27 Oct 2015 15:07:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150921083533.19273.62189.idtracker@ietfa.amsl.com> <9ac4441c10c70ae76c7bb75dc3613494@mail.gmail.com> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 10 sum msgs/h 3 total rcpts 34397 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E1A74B6596579B07C81FA63236254CEEA1402469 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1973 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 14:07:29 -0000 Dear Karen, Thanks a lot for your comments! This was only meant as a starting point - e.g. the decision to only use = RFC4960 but not RFC6458 is definitely not set in stone. We=E2=80=99ll incorporate them in the next revision (and then maybe get = back to you in case we need discussion) - thanks again! Cheers, Michael > On 27. okt. 2015, at 14.58, Karen Elisabeth Egede Nielsen = wrote: >=20 > HI, >=20 > FWIIW please accept the following comments to the document: >=20 > Section 3.1: >=20 > "Passive open with fully specified foreign socket" >=20 > Is that a typical function provided to ULP by TCP ? > Our POSIX socket api implementation does not really provide this. Or = it > does by set of special filters on the > listening socket, but I wasn't aware that this was a feature generally > available in TCP. >=20 > "Passive open with fully specified foreign socket" on a unspecified > passive open socket ? >=20 > I assume we speak listening socket. Again is this something typically > provided as an option to ULP by TCP ? >=20 > "Send: and PUSH flag description": >=20 > The PUSH flag is typically set inside the TCP implementation and the = ULP > typically has no direct influence on the setting of it. I think that = it is > strange that this function > is chosen to be described as if it is controlled directly by ULP when = it > is indeed not. >=20 > There is some text later in section 3.1.1 motivating the choice. Yes = it is > correct that TCP implementations implement > set of PUSH flag causing a behavior (i.e., a set of PUSH) that matches > that the PUSH flag is set in the end of a communication, > but again it is not controlled by ULP. As the intend of this document = is > to expose services that the ULP > can invoke, I think that it is problematic that it is described as if = the > ULP can control PUSH directly, when it indeed (often) cannot. >=20 > Section 3.2: >=20 > General comment: >=20 > The multi-stream capability and stream prioritization/scheduling > possibilities of SCTP is a feature > differentiating SCTP from TCP. The same is the fact that SCTP = (SCTP-PR) > also provide unreliable (no retransmissions) and partial reliable > transport service (timeout). >=20 > I think that these service features are important for certain SCTP > deployment scenarios > and that it would be desirable for these to be exposed here. (The = timeout > is described) > It not included here in the first pass it will never even get = considered > for TAPS as a potential service, would it ? > (It might end up being excluding, but then this should be a > conscious (visible) choice, I think). >=20 > Detailed comments: >=20 > "Initialize needs be called only once per set of local addresses": >=20 > This is the case when supporting one-to-many style sockets. Perhaps = one > might add > "but ULP may also initialize each association endpoint instance > individually". >=20 > "Associate": >=20 > I think that it is relevant to clarify that the remote SCTP instance = in > the association primitive is > identified by one or multiple destination addresses thus allowing also = the > association handshake > to proceed using multiple paths. >=20 > "Send": >=20 > "Another advisory flag indicates the ULP's preference to avoid = bundling > user data .." >=20 > This is specified as an optional attribute in RFC4960. This is not > specified in the RFC6458 socket API. > ((Yes it might be similar to the TCP PUSH flag in that it is not = generally > implemented as directly controllable by ULP on a message basis - Or?)) >=20 > Section 4.2: >=20 > SCTP implements NO_delay (Nagle) option on a per association basis (as = TCP > on a per connection basis) but not typically > on a per message basis as described here. There are some additional > bundling control related to stream scheduling - some are described in > sctp-ndata draft. >=20 > Section 5.1: >=20 > "Disable Nagle algorithm:" >=20 > Not specified in RFC4960, but in RFC6458 for SCTP. > Is it really valid to use RFC4960 as a reference for the socket API = when > the approach of > SCTP IETF community has been to use RFC6458 for this ? >=20 > *** >=20 > BR, Karen >=20 >=20 >=20 >> -----Original Message----- >> From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Michael Welzl >> Sent: 21. september 2015 10:45 >> To: taps WG >> Subject: [Taps] Fwd: New Version Notification for draft-welzl-taps- >> transports-00.txt >>=20 >> Dear all, >>=20 >> In my presentation in Prague, I proposed an approach to identify the > services >> that transport protocols provide. At the end of the ensuing = discussion, > I said >> that I (with co-authors) would write a draft that explains the = proposal > by >> applying the proposed method to TCP and SCTP. >>=20 >> We just submitted this document - see below; I hope that this will = lead > to >> some discussion on the list... >>=20 >> Cheers, >> Michael >>=20 >>=20 >>> Begin forwarded message: >>>=20 >>> From: >>> Subject: New Version Notification for >>> draft-welzl-taps-transports-00.txt >>> Date: 21 Sep 2015 10:35:33 CEST >>> To: Michael Welzl , Michael Welzl >>> , Michael Tuexen , >> Naeem >>> Khademi , Michael Tuexen > muenster.de>, >>> Naeem Khademi >>> Resent-From: >>>=20 >>>=20 >>> A new version of I-D, draft-welzl-taps-transports-00.txt >>> has been successfully submitted by Michael Welzl and posted to the >>> IETF repository. >>>=20 >>> Name: draft-welzl-taps-transports >>> Revision: 00 >>> Title: An Approach to Identify Services Provided by >> IETF Transport Protocols and Congestion Control Mechanisms >>> Document date: 2015-09-21 >>> Group: Individual Submission >>> Pages: 23 >>> URL: = https://www.ietf.org/internet-drafts/draft-welzl-taps- >> transports-00.txt >>> Status: > https://datatracker.ietf.org/doc/draft-welzl-taps-transports/ >>> Htmlized: > https://tools.ietf.org/html/draft-welzl-taps-transports-00 >>>=20 >>>=20 >>> Abstract: >>> This document describes a method to identify services in transport >>> protocols and congestion control mechanisms. It shows the approach >>> using TCP and SCTP (base protocol) as examples. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at > tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps From nobody Tue Oct 27 07:08:26 2015 Return-Path: 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 ; 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 ; 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 ; Tue, 27 Oct 2015 07:08:18 -0700 (PDT) Received: by qgem9 with SMTP id m9so145807874qge.1 for ; 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 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> <562DF846.7090901@erg.abdn.ac.uk> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> <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?= X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Aaron Falk , " Fairhurst" , Michael Welzl , Brian Trammell , "taps@ietf.org" , Stein Gjessing Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 14:08:25 -0000 I agree with Mirja. We have done a lot of =E2=80=9Cbackground=E2=80=9D = work up to now and I don=E2=80=99t 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=E2=80=99t 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=C3=A9 > On Oct 27, 2015, at 10:00 AM, Mirja K=C3=BChlewind = wrote: >=20 > Hi all, >=20 > I didn=E2=80=99t say anything so far because I don=E2=80=99t mind to = have a second protocol here, but I personally don=E2=80=99t 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. >=20 > =46rom 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.=20 >=20 > I agree that the taps-transport doc is quite long, but for the wg I = don=E2=80=99t 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.=20 >=20 > 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=E2=80=99s actually a quite nice overview doc now. >=20 > That=E2=80=99s just my 2c. I don=E2=80=99t 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. >=20 > Mirja >=20 >=20 >> Am 27.10.2015 um 14:47 schrieb Michael Welzl : >>=20 >>=20 >>> On 26. okt. 2015, at 17.35, Aaron Falk wrote: >>>=20 >>> On Mon, Oct 26, 2015 at 9:46 AM, Michael Welzl = wrote: >>>=20 >>> Working towards a realistic end-goal of a deployable system. >>>=20 >>> So we=E2=80=99re 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. >>>=20 >>> Uh, yeah. That's our charter. Narrowing down is in doc 2. Are you = making the case we should do it in doc 1? =20 >>=20 >> Well, just because we narrow down in doc 2 doesn=E2=80=99t 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=E2=80=99d 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=E2=80=99t yet exist. >>=20 >> 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=E2=80=99s a valuable discussion to = have! >>=20 >>=20 >>> Say we include DCCP. It=E2=80=99ll add some services that aren=E2=80=99= 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=E2=80=99ll 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 >>>=20 >>> None of these two options are very helpful if we want to TAPS to be = real thing one day. >>>=20 >>> a: TAPS is not chartered to do anything normative. Doc 3 is about = experimenting. >>=20 >> Sure! But it=E2=80=99s still about stuff that someone should be able = to build - I just don=E2=80=99t want doc 3 to become a sci-fi literature = piece :-) >>=20 >>=20 >>> 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. >>=20 >> See my arguments above; about getting sections done for = draft-welzl-taps-transports, I don=E2=80=99t worry too much: this is = only the very first version, we haven=E2=80=99t asked anyone for inputs = yet (and I can volunteer to cover a few more protocols myself). >>=20 >>=20 >>> 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? >>=20 >> This is a very good point. I=E2=80=99m 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=E2=80=A6 >>=20 >> Cheers, >> Michael >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Oct 27 07:27:30 2015 Return-Path: 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 EE6771A8A68 for ; Tue, 27 Oct 2015 07:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 OSSsB_n4T-hy for ; Tue, 27 Oct 2015 07:27:27 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 3F5A61A8A66 for ; Tue, 27 Oct 2015 07:27:25 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Zr5Dd-0006Xu-6k; Tue, 27 Oct 2015 15:27:21 +0100 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Zr5Dc-0001BG-8O; Tue, 27 Oct 2015 15:27:21 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <6F9FB87C-D0FF-46B3-A634-8A2E1234F9B7@tik.ee.ethz.ch> Date: Tue, 27 Oct 2015 15:27:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2DC75956-A94E-40DE-8A40-B8A6BABE8ED8@ifi.uio.no> References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> <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?= X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 10 msgs/h 3 sum rcpts/h 16 sum msgs/h 4 total rcpts 34403 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 90F298C6433DEB516C3EB1219E65F2E83B9D5CCB X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 3 total 1974 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , " Fairhurst" , "taps@ietf.org" , Stein Gjessing , Brian Trammell Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 14:27:29 -0000 > On 27. okt. 2015, at 15.00, Mirja K=C3=BChlewind = wrote: >=20 > Hi all, >=20 > I didn=E2=80=99t say anything so far because I don=E2=80=99t mind to = have a second protocol here, but I personally don=E2=80=99t 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 think draft-welzl-taps-transports highlights how many services (or = transport features or whatever we want to call them) are lost when we = just compile a list as in draft-ietf-taps-transports. To give a few examples: SCTP: "ordered and unordered delivery within a = stream=E2=80=9D does not make it clear that you can in fact specify = per-message whether ordering matters or not. In TCP, during the lifetime of a connection, you can change the DSCP = value. In TCP, you can open a connection to listen at one local interface or = any; in SCTP, you can specify a list of local interfaces We can debate whether these things are unnecessary details, but they are = things that appear in draft-welzl-taps-transports as a result of the = systematic approach I=E2=80=99ve taken. =20 > 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. Even more arbitrary =3D> could you please explain? I think the discussion of what should be in and out has absolutely = nothing to do with the arbitrariness of the approach taken in the doc. > =46rom 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.=20 >=20 > I agree that the taps-transport doc is quite long, but for the wg I = don=E2=80=99t 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.=20 >=20 > 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=E2=80=99s actually a quite nice overview doc now. I agree that it=E2=80=99s a nice document and ready. As for =E2=80=9CThe = only thing interesting for the wg is he final list of features, which is = there and ready to use=E2=80=9D, see the discussion above: the = draft-ietf-taps-transports is a nice and useful survey, but I do not = think it is a good basis for an implementable TAPS system, which we = eventually want (doc 3). Cheers, Michael >=20 > That=E2=80=99s just my 2c. I don=E2=80=99t 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. >=20 > Mirja >=20 >=20 >> Am 27.10.2015 um 14:47 schrieb Michael Welzl : >>=20 >>=20 >>> On 26. okt. 2015, at 17.35, Aaron Falk wrote: >>>=20 >>> On Mon, Oct 26, 2015 at 9:46 AM, Michael Welzl = wrote: >>>=20 >>> Working towards a realistic end-goal of a deployable system. >>>=20 >>> So we=E2=80=99re 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. >>>=20 >>> Uh, yeah. That's our charter. Narrowing down is in doc 2. Are you = making the case we should do it in doc 1? =20 >>=20 >> Well, just because we narrow down in doc 2 doesn=E2=80=99t 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=E2=80=99d 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=E2=80=99t yet exist. >>=20 >> 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=E2=80=99s a valuable discussion to = have! >>=20 >>=20 >>> Say we include DCCP. It=E2=80=99ll add some services that aren=E2=80=99= 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=E2=80=99ll 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 >>>=20 >>> None of these two options are very helpful if we want to TAPS to be = real thing one day. >>>=20 >>> a: TAPS is not chartered to do anything normative. Doc 3 is about = experimenting. >>=20 >> Sure! But it=E2=80=99s still about stuff that someone should be able = to build - I just don=E2=80=99t want doc 3 to become a sci-fi literature = piece :-) >>=20 >>=20 >>> 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. >>=20 >> See my arguments above; about getting sections done for = draft-welzl-taps-transports, I don=E2=80=99t worry too much: this is = only the very first version, we haven=E2=80=99t asked anyone for inputs = yet (and I can volunteer to cover a few more protocols myself). >>=20 >>=20 >>> 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? >>=20 >> This is a very good point. I=E2=80=99m 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=E2=80=A6 >>=20 >> Cheers, >> Michael >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 From nobody Tue Oct 27 07:30:56 2015 Return-Path: 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 8CE861A8A75 for ; Tue, 27 Oct 2015 07:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 epDCExFRgCKU for ; Tue, 27 Oct 2015 07:30:53 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 597601A8A71 for ; Tue, 27 Oct 2015 07:30:53 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Zr5H0-0007g3-Mx; Tue, 27 Oct 2015 15:30:50 +0100 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Zr5H0-0005I2-4s; Tue, 27 Oct 2015 15:30:50 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <9C828361-EA04-4FB2-89D6-49678B60245C@mjmontpetit.com> Date: Tue, 27 Oct 2015 15:30:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8032F291-F984-40D0-A599-0BA7AE8DE5E0@ifi.uio.no> References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> <27697ADF-7AE6-4E99-8288-FF19A68F1411@ifi.uio.no> <6F9FB87C-D0FF-46B3-A634-8A2E1234F9B7@tik.ee.ethz.ch> <9C828361-EA04-4FB2-89D6-49678B60245C@mjmontpetit.com> To: Marie-Jose Montpetit X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 17 msgs/h 4 sum rcpts/h 23 sum msgs/h 5 total rcpts 34410 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: BCA84EFA8A8A1991893C2E31D483E3DE50CF08EA X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 4 total 1975 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , " Fairhurst" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Brian Trammell , "taps@ietf.org" , Stein Gjessing Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 14:30:54 -0000 > On 27. okt. 2015, at 15.08, Marie-Jose Montpetit = wrote: >=20 > I agree with Mirja. We have done a lot of =E2=80=9Cbackground=E2=80=9D = work up to now and I don=E2=80=99t 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=E2=80=99t think we = need detailed lists of features as all these transports are documented = elsewhere but better means to advertise them and use them. How are you going to do this when you don=E2=80=99t know what applies to = connection opening, connection maintenance, data transfer? What kinds of = error messages are available? I think it=E2=80=99s a much more obvious step from = draft-welzl-taps-transports to a generic TAPS API than from = draft-ietf-taps-transports, and that=E2=80=99s the whole point. = draft-ietf-taps-transports is a nice survey but it doesn=E2=80=99t = really help you much for creating an API, I think. Cheers, Michael From nobody Tue Oct 27 07:33:40 2015 Return-Path: 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 34A171A8A94 for ; Tue, 27 Oct 2015 07:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 SLgTy1yLAHZL for ; Tue, 27 Oct 2015 07:33:38 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (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 1B4991A8A91 for ; Tue, 27 Oct 2015 07:33:38 -0700 (PDT) Received: by qgad10 with SMTP id d10so146502016qga.3 for ; Tue, 27 Oct 2015 07:33:37 -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=0awEJPfoUzWlbNRD/ajmDOoJ6X0P7qaQW6CtH/WXTco=; b=db/ldMrRMx9rGTkKPXZKSJ+kiWL1gSbZZmR/aeKbqjIowox67EiWaEyPbz27fypazp bnoQP1dgkcZHjtaqcFuH295MG/AQefyzHk+IMH3wmHF2qARWHggaYKMWsyXv6yJ+jCwt IRtY7l6VhwODHniG1xCd2zrQL4x3nsDVRt4bYuWv/g0xrbdxbU3HqBh/XqjbzidzS4YX CMLEm6nTS2GImY+a4ATfSA7K+OAnLq87Y4gzYrjjBCP0LC8oDjnKaqgsYl9zYIIwKDz/ 1NzearNFLZ+wzo6wnftzQlZi1Ue9Nyirj5mZTNOrtQgSDxLvq+PHEmLrXUt2ryCvEoym 7Tvg== 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=0awEJPfoUzWlbNRD/ajmDOoJ6X0P7qaQW6CtH/WXTco=; b=T/fnl0pi+F9Gc4LqLBxBxUbTJDqYluVQRvDBEfeY+t6+SWi+rACirMjXFXJwmfqrUw gDsoxepkrg8QrtCr+x3G0jLO+4Gkj77FeqMIMXOy1dMBqVxpMN4yhevW38psgCLv7FCl WwLm3bVy51CtO8K2OyLsVKnGgLeccANsAQA+TwEW7/Z/40bDgrYgeVdSsXOtCMc3tJhl NLDB8lC+bM3dSnK0iABO8wr+IFVWrMWHqsDcToltTBonqcVlb9TR5E3hDNG6KdYKYOIf /8cEy6SmsOjvZBuqLYr66MGxzo5FQO9uIwd65ifuz/5Fq+lmAj4ne1MHUyrcLa58AI2i rT3Q== X-Gm-Message-State: ALoCoQmBS7z3XyesQCds/nF9+gzda13VQ79GuHkLaSaUM5ZJPN9vnM4SmHqzH3/xkOBISYaXlCL9 X-Received: by 10.140.17.105 with SMTP id 96mr9874091qgc.34.1445956417132; Tue, 27 Oct 2015 07:33:37 -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 p90sm15216924qgd.10.2015.10.27.07.33.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Oct 2015 07:33:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Marie-Jose Montpetit In-Reply-To: <8032F291-F984-40D0-A599-0BA7AE8DE5E0@ifi.uio.no> Date: Tue, 27 Oct 2015 10:33:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> <27697ADF-7AE6-4E99-8288-FF19A68F1411@ifi.uio.no> <6F9FB87C-D0FF-46B3-A634-8A2E1234F9B7@tik.ee.ethz.ch> <9C828361-EA04-4FB2-89D6-49678B60245C@mjmontpetit.com> <8032F291-F984-40D0-A599-0BA7AE8DE5E0@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Aaron Falk , " Fairhurst" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Brian Trammell , "taps@ietf.org" , Stein Gjessing Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 14:33:39 -0000 >=20 > How are you going to do this when you don=E2=80=99t know what applies = to connection opening, connection maintenance, data transfer? What kinds = of error messages are available? We need that of course but I don=E2=80=99t see now any list of what are = the common features between all transports (to start with) and then how = to discover the rest :-) > I think it=E2=80=99s a much more obvious step from = draft-welzl-taps-transports to a generic TAPS API than from = draft-ietf-taps-transports, and that=E2=80=99s the whole point. = draft-ietf-taps-transports is a nice survey but it doesn=E2=80=99t = really help you much for creating an API, I think. I did not suggest abandoning it. Just making sure it does focus on what = is needed. >=20 > Cheers, > Michael >=20 From nobody Tue Oct 27 07:47:04 2015 Return-Path: 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 B7CFF1A8ABE for ; Tue, 27 Oct 2015 07:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 XrHp8jBJvtgQ for ; Tue, 27 Oct 2015 07:46:59 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F23B1A8AC8 for ; Tue, 27 Oct 2015 07:46:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1EFFBD930C; Tue, 27 Oct 2015 15:46:58 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id paLswoPrE3mY; Tue, 27 Oct 2015 15:46:57 +0100 (MET) Received: from [192.168.178.33] (x5f717ab6.dyn.telefonica.de [95.113.122.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 4F3F3D9304; Tue, 27 Oct 2015 15:46:57 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <2DC75956-A94E-40DE-8A40-B8A6BABE8ED8@ifi.uio.no> Date: Tue, 27 Oct 2015 15:46:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <782D504B-656F-4C98-9790-A2B2FFC36473@tik.ee.ethz.ch> References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> <27697ADF-7AE6-4E99-8288-FF19A68F1411@ifi.uio.no> <6F9FB87C-D0FF-46B3-A634-8A2E1234F9B7@tik.ee.ethz.ch> <2DC75956-A94E-40DE-8A40-B8A6BABE8ED8@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Aaron Falk , " Fairhurst" , "taps@ietf.org" , Stein Gjessing , Brian Trammell Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 14:47:02 -0000 Hi Michael, for me, when I was reading the following, that was when I found it quite = arbitrary again: "In the list resulting from the second pass, some services are missing because they are implicit in some protocols, and they only become explicit when we consider the superset of all services offered by all protocols. =E2=80=9E So how do we know that we actually caught everything? Further see below. > Am 27.10.2015 um 15:27 schrieb Michael Welzl : >=20 >=20 >> On 27. okt. 2015, at 15.00, Mirja K=C3=BChlewind = wrote: >>=20 >> Hi all, >>=20 >> I didn=E2=80=99t say anything so far because I don=E2=80=99t mind to = have a second protocol here, but I personally don=E2=80=99t see this doc = as really needed. Effectively we will have two docs that have the same = results (a list of features) at the end. >=20 > I think draft-welzl-taps-transports highlights how many services (or = transport features or whatever we want to call them) are lost when we = just compile a list as in draft-ietf-taps-transports. > To give a few examples: SCTP: "ordered and unordered delivery within a = stream=E2=80=9D does not make it clear that you can in fact specify = per-message whether ordering matters or not. > In TCP, during the lifetime of a connection, you can change the DSCP = value. > In TCP, you can open a connection to listen at one local interface or = any; in SCTP, you can specify a list of local interfaces >=20 > We can debate whether these things are unnecessary details, but they = are things that appear in draft-welzl-taps-transports as a result of the = systematic approach I=E2=80=99ve taken. >=20 For me that would be good feedback for taps-transport, to include these = things. We have for each protocol a section on interface(s). We could = even include more background text there if needed. However, for the things you=E2=80=99ve mentioned that=E2=80=99s for me = rather a question on the level of detail of certain features. We=E2=80=99v= e already discussed that we might need something like =E2=80=9Aaspects=E2=80= =98 for each feature. I believe we decided to not provide more details = in this doc because we wanted to move on. However, I also believe that = people in this group understand well that in some cases we=E2=80=99ll = need more detailed information on the feature. And for me even if we = submit and publish the taps-transport as it is, this is not written in = stone and we can still say later on, that we rename a feature or split = it up or whatever. For me that would even be part of the second doc in = the charter. Again, I=E2=80=99m okay to have two docs here. I don=E2=80=99t think a = second doc is absolutely necessary. An alternative would be to merge = both docs=E2=80=A6 just as a side note. But I=E2=80=99m okay with both, = two or one docs. >=20 >> 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. >=20 > Even more arbitrary =3D> could you please explain? > I think the discussion of what should be in and out has absolutely = nothing to do with the arbitrariness of the approach taken in the doc. See above. For me the only question is, how can we make sure we cover = the right things and don=E2=80=99t forget important stuff. And in both = cases the answer is we can=E2=80=99t. For me analyzing (only) the interfaces, is the more arbitrary approach = because the current interfaces are already arbitrary to some extend and = that=E2=80=99s exactly what we want to change. But that=E2=80=99s my = personal view and there might not be an objective conclusion here. >=20 >=20 >> =46rom 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.=20 >>=20 >> I agree that the taps-transport doc is quite long, but for the wg I = don=E2=80=99t 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.=20 >>=20 >> 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=E2=80=99s actually a quite nice overview doc now. >=20 > I agree that it=E2=80=99s a nice document and ready. As for =E2=80=9CThe= only thing interesting for the wg is he final list of features, which = is there and ready to use=E2=80=9D, see the discussion above: the = draft-ietf-taps-transports is a nice and useful survey, but I do not = think it is a good basis for an implementable TAPS system, which we = eventually want (doc 3). I don=E2=80=99t have the feeling that the new doc is much better. = Important is that the wg knows that these features are not written in = stone and we still have to think about the right choices here for any = future work. I believe that=E2=80=99s true for both docs. Mirja >=20 > Cheers, > Michael >=20 >=20 >=20 >>=20 >> That=E2=80=99s just my 2c. I don=E2=80=99t 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. >>=20 >> Mirja >>=20 >>=20 >>> Am 27.10.2015 um 14:47 schrieb Michael Welzl : >>>=20 >>>=20 >>>> On 26. okt. 2015, at 17.35, Aaron Falk = wrote: >>>>=20 >>>> On Mon, Oct 26, 2015 at 9:46 AM, Michael Welzl = wrote: >>>>=20 >>>> Working towards a realistic end-goal of a deployable system. >>>>=20 >>>> So we=E2=80=99re 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. >>>>=20 >>>> Uh, yeah. That's our charter. Narrowing down is in doc 2. Are = you making the case we should do it in doc 1? =20 >>>=20 >>> Well, just because we narrow down in doc 2 doesn=E2=80=99t 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=E2=80=99d 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=E2=80=99t yet exist. >>>=20 >>> 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=E2=80=99s a valuable discussion to = have! >>>=20 >>>=20 >>>> Say we include DCCP. It=E2=80=99ll add some services that aren=E2=80=99= 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=E2=80=99ll 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 >>>>=20 >>>> None of these two options are very helpful if we want to TAPS to be = real thing one day. >>>>=20 >>>> a: TAPS is not chartered to do anything normative. Doc 3 is about = experimenting. >>>=20 >>> Sure! But it=E2=80=99s still about stuff that someone should be able = to build - I just don=E2=80=99t want doc 3 to become a sci-fi literature = piece :-) >>>=20 >>>=20 >>>> 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. >>>=20 >>> See my arguments above; about getting sections done for = draft-welzl-taps-transports, I don=E2=80=99t worry too much: this is = only the very first version, we haven=E2=80=99t asked anyone for inputs = yet (and I can volunteer to cover a few more protocols myself). >>>=20 >>>=20 >>>> 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? >>>=20 >>> This is a very good point. I=E2=80=99m 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=E2=80=A6 >>>=20 >>> Cheers, >>> Michael >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 From nobody Tue Oct 27 11:59:40 2015 Return-Path: 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 68FF71ACDF8 for ; Tue, 27 Oct 2015 11:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 a54fC4M9geiU for ; Tue, 27 Oct 2015 11:59:35 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 7CE451ACDF7 for ; Tue, 27 Oct 2015 11:59:35 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Zr9Py-0008Ky-RN; Tue, 27 Oct 2015 19:56:22 +0100 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Zr9Px-0007K6-PS; Tue, 27 Oct 2015 19:56:22 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <782D504B-656F-4C98-9790-A2B2FFC36473@tik.ee.ethz.ch> Date: Tue, 27 Oct 2015 19:56:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3C8D178C-CEF2-4395-B4B7-2FB80F39F733@ifi.uio.no> References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> <27697ADF-7AE6-4E99-8288-FF19A68F1411@ifi.uio.no> <6F9FB87C-D0FF-46B3-A634-8A2E1234F9B7@tik.ee.ethz.ch> <2DC75956-A94E-40DE-8A40-B8A6BABE8ED8@ifi.uio.no> <782D504B-656F-4C98-9790-A2B2FFC36473@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 2 sum rcpts/h 20 sum msgs/h 4 total rcpts 34419 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DC24456694BC7ACF5F268B5CBDB83027F8C80FB6 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 2 total 1978 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , " Fairhurst" , "taps@ietf.org" , Stein Gjessing , Brian Trammell Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 18:59:38 -0000 > On 27. okt. 2015, at 15.46, Mirja K=C3=BChlewind = wrote: >=20 > Hi Michael, >=20 > for me, when I was reading the following, that was when I found it = quite arbitrary again: >=20 > "In the list resulting from the second pass, some services are missing > because they are implicit in some protocols, and they only become > explicit when we consider the superset of all services offered by = all > protocols. =E2=80=9E >=20 > So how do we know that we actually caught everything? Everything here is based on text parts of the RFCs that focus on what a = protocol provides to the upper layer and how it is used. This should be everything that=E2=80=99s relevant as a service. Now, when you have all these bits covered, for all the protocols you = want to cover, this should give you *exactly* the services of relevance = - that=E2=80=99s the idea of this procedure. For example, now the document contains only TCP and SCTP. There is no = mention of congestion control, because, to choose between these two, = congestion control is not a relevant service: they both have it, in the = same way. If the document would only cover TCP and SCTP, I think = that=E2=80=99s exactly how it should be. When we add UDP, the obvious RFC to cover is the one on usage guidelines = (RFC5405). It will tell us that UDP does not have congestion control, = which means that the application has to take care of it. Thus, =E2=80=9Cno= congestion control=E2=80=9D becomes a part of the services. Because = =E2=80=9Clack of XY=E2=80=9D is a bit strange as a service, it=E2=80=99d = be obvious to write =E2=80=9Ccongestion control=E2=80=9D as a service = for the other protocols instead. Consider another example. Assume, for a second, that all protocols had = the same checksum, and no option to turn it off or configure it. This is = not true, but just imagine it for the example. In this case, there would never be text in any of the RFCs talking about = the relevance of the checksum to the application - and it would never = appear as a service, which is exactly the right decision, it would be an = integral part of communication that is the same everywhere. Anyway, in = reality, as soon as we add UDP-Lite and/or DCCP, we have configurable = checksums as a service in the list. But if these protocols are not = covered, what=E2=80=99s the point of describing a =E2=80=9Cconfigurable = checksum=E2=80=9D service? (I=E2=80=99m ignoring the fact that the checksum can be disabled in UDP = now, for simplicity) > Further see below. >=20 >> Am 27.10.2015 um 15:27 schrieb Michael Welzl : >>=20 >>=20 >>> On 27. okt. 2015, at 15.00, Mirja K=C3=BChlewind = wrote: >>>=20 >>> Hi all, >>>=20 >>> I didn=E2=80=99t say anything so far because I don=E2=80=99t mind to = have a second protocol here, but I personally don=E2=80=99t see this doc = as really needed. Effectively we will have two docs that have the same = results (a list of features) at the end. >>=20 >> I think draft-welzl-taps-transports highlights how many services (or = transport features or whatever we want to call them) are lost when we = just compile a list as in draft-ietf-taps-transports. >> To give a few examples: SCTP: "ordered and unordered delivery within = a stream=E2=80=9D does not make it clear that you can in fact specify = per-message whether ordering matters or not. >> In TCP, during the lifetime of a connection, you can change the DSCP = value. >> In TCP, you can open a connection to listen at one local interface or = any; in SCTP, you can specify a list of local interfaces >>=20 >> We can debate whether these things are unnecessary details, but they = are things that appear in draft-welzl-taps-transports as a result of the = systematic approach I=E2=80=99ve taken. >>=20 >=20 > For me that would be good feedback for taps-transport, to include = these things. We have for each protocol a section on interface(s). We = could even include more background text there if needed. >=20 > However, for the things you=E2=80=99ve mentioned that=E2=80=99s for me = rather a question on the level of detail of certain features. We=E2=80=99v= e already discussed that we might need something like =E2=80=9Aaspects=E2=80= =98 for each feature. I believe we decided to not provide more details = in this doc because we wanted to move on. However, I also believe that = people in this group understand well that in some cases we=E2=80=99ll = need more detailed information on the feature. And for me even if we = submit and publish the taps-transport as it is, this is not written in = stone and we can still say later on, that we rename a feature or split = it up or whatever. Indeed, taps-transport is just at a slightly higher abstraction layer = than draft-welzl-taps-transports. > For me that would even be part of the second doc in the charter. Here I disagree. I think we need more detail to end up with an = implementable system, as in draft-welzl-taps-transports. The second doc = in the charter is about narrowing down the services, not adding more = detail. > Again, I=E2=80=99m okay to have two docs here. I don=E2=80=99t think a = second doc is absolutely necessary. An alternative would be to merge = both docs=E2=80=A6 just as a side note. But I=E2=80=99m okay with both, = two or one docs. I think merging them would get messy. >>> 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. >>=20 >> Even more arbitrary =3D> could you please explain? >> I think the discussion of what should be in and out has absolutely = nothing to do with the arbitrariness of the approach taken in the doc. >=20 > See above. For me the only question is, how can we make sure we cover = the right things and don=E2=80=99t forget important stuff. And in both = cases the answer is we can=E2=80=99t. Given the RFC text describes well what a protocol offers to the upper = layer and how it=E2=80=99s used, my procedure (above) should give you = exactly what=E2=80=99s needed. > For me analyzing (only) the interfaces, is the more arbitrary approach = because the current interfaces are already arbitrary to some extend and = that=E2=80=99s exactly what we want to change. But that=E2=80=99s my = personal view and there might not be an objective conclusion here. This document is not about analyzing only the interfaces: it=E2=80=99s = about analyzing RFC text that describes what a protocol offers to the = upper layer and how it=E2=80=99s used. Because TCP and SCTP have = abstract API descriptions, that makes up more than 90% of this text in = case of these two protocols. When you say that the current interfaces (which, for the context of = draft-welzl-taps-transports, are the abstract interfaces in the RFCs) = are "already arbitrary to some extent=E2=80=9D, you really criticize the = text in the RFC that describes how to use a protocol; then, I think you = should be specific and explain what you think is wrong per protocol, and = maybe suggest an update or errata. I do think that a lot of thinking has = gone into these text bits=E2=80=A6 even though real-life implementations = may diverge from these abstract APIs. I also don=E2=80=99t think we want to *change* these interfaces, but = describe how to create a generic one that is built upon them. >>> =46rom 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.=20 >>>=20 >>> I agree that the taps-transport doc is quite long, but for the wg I = don=E2=80=99t 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.=20 >>>=20 >>> 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=E2=80=99s actually a quite nice overview doc now. >>=20 >> I agree that it=E2=80=99s a nice document and ready. As for =E2=80=9CTh= e only thing interesting for the wg is he final list of features, which = is there and ready to use=E2=80=9D, see the discussion above: the = draft-ietf-taps-transports is a nice and useful survey, but I do not = think it is a good basis for an implementable TAPS system, which we = eventually want (doc 3). >=20 > I don=E2=80=99t have the feeling that the new doc is much better. = Important is that the wg knows that these features are not written in = stone and we still have to think about the right choices here for any = future work. I believe that=E2=80=99s true for both docs. I don=E2=80=99t get that; can you give an example? Cheers, Michael From nobody Tue Oct 27 12:30:24 2015 Return-Path: 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 4AEE41ACE80 for ; Tue, 27 Oct 2015 12:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 s9V4UIPLMozk for ; Tue, 27 Oct 2015 12:30:18 -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 170441ACE8B for ; Tue, 27 Oct 2015 12:30:18 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Zr9wm-0007aX-D2; Tue, 27 Oct 2015 20:30:16 +0100 Received: from 16.79-161-30.customer.lyse.net ([79.161.30.16] helo=[10.0.1.3]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user steing (Exim 4.80) (envelope-from ) id 1Zr9wl-00082Q-MG; Tue, 27 Oct 2015 20:30:16 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_ACC68171-0A00-42E0-BC52-6F0AEC5A052A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stein Gjessing In-Reply-To: Date: Tue, 27 Oct 2015 20:31:21 +0100 Message-Id: <0505F6AF-F999-478D-8598-6F259D43AC4F@ifi.uio.no> References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> To: Aaron Falk X-Mailer: Apple Mail (2.1878.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 15940 max rcpts/h 43 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6F8C3DDEA79C3411FD540664B7D7ACAC0E11D4FF X-UiO-SPAM-Test: UIO-GREYLIST remote_host: 79.161.30.16 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 1 total 1731 max/h 32 blacklist 0 greylist 1 ratelimit 0 Archived-At: Cc: Brian Trammell , "taps@ietf.org" , Michael Welzl , Stein Gjessing Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 19:30:20 -0000 --Apple-Mail=_ACC68171-0A00-42E0-BC52-6F0AEC5A052A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Sorry for the long silence. I have been on vacation with almost no = internet connection. I will attend IETF 94, but I don=B4t feel ready to lead a discussion = about charter item 2. However, I will take part in the discussion and gladly contribute to the = draft we eventually have to make to fulfill the charter, possibly by = revising draft-gjessing-taps-minset. Stein On 22 Oct 2015, at 16:14, Aaron Falk wrote: >=20 > > draft-welzl-taps-transports currently only covers TCP and SCTP. But = then: how many other protocols? > > It seems people agree that the protocols covered in = draft-welzl-taps-transports should be a subset of the protocols covered = in draft-ietf-taps-transports. My question is, then: how to choose the = subset? > > > > It seems obvious to include protocols that are seeing some = deployment, i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP=85 > > However: if that is the only decision ground, we probably wouldn=92t = include DCCP. Are we then making a significant mistake, missing a lesson = to be learned? > > > > That, to me, is a discussion I=92d like to have in Yokohama. >=20 > +1, and FWIW that's exactly the same starting point I got to on my = own. >=20 >=20 > Any volunteers to kick off the lead the discussion? >=20 > =20 > > It may not be much, but fwiw, draft-gjessing-taps-minset exists. It = contains some ideas on how services could be narrowed down, and these = could be applied to draft-welzl-taps-transports just as well as to = draft-ietf-taps-transports (which it=92s currently written around). >=20 > There's probably quibbling to be done about the details, but I believe = draft-gjessing is a good starting point for charter item 2. >=20 >=20 >=20 > Stein, will you be in Yokohama and interested in leading a discussion = on this draft? >=20 > --aaron --Apple-Mail=_ACC68171-0A00-42E0-BC52-6F0AEC5A052A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi,

Sorry for the long silence. =  I have been on vacation with  almost no internet = connection.
I will attend IETF 94, but I don=B4t feel ready to = lead a discussion about charter item 2.
However, I will take = part in the discussion and gladly contribute to the draft we eventually = have to make to fulfill the charter, possibly by revising = draft-gjessing-taps-minset.

Stein

<= div>
On 22 Oct 2015, at 16:14, Aaron Falk <aaron.falk@gmail.com> = wrote:


> draft-welzl-taps-transports currently only covers TCP and SCTP. But = then: how many other protocols?
> It seems people agree that the protocols covered in = draft-welzl-taps-transports should be a subset of the protocols covered = in draft-ietf-taps-transports. My question is, then: how to choose the = subset?
>
> It seems obvious to include protocols that are seeing some = deployment, i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP=85
> However: if that is the only decision ground, we probably wouldn=92t = include DCCP. Are we then making a significant mistake, missing a lesson = to be learned?
>
> That, to me, is a discussion I=92d like to have in Yokohama.

+1, and FWIW that's exactly the same starting point I got to on = my own.


Any = volunteers to kick off the lead the = discussion?

 
> It may not be much, but fwiw, draft-gjessing-taps-minset exists. It = contains some ideas on how services could be narrowed down, and these = could be applied to draft-welzl-taps-transports just as well as to = draft-ietf-taps-transports  (which it=92s currently written = around).

There's probably quibbling to be done about the details, but I = believe draft-gjessing is a good starting point for charter item 2.



Stein, will you be = in Yokohama and interested in leading a discussion on this = draft?

--aaron

= --Apple-Mail=_ACC68171-0A00-42E0-BC52-6F0AEC5A052A-- From nobody Tue Oct 27 14:02:57 2015 Return-Path: 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 CE3181AD0B8 for ; Tue, 27 Oct 2015 14:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 52VaxO5M7V8F for ; Tue, 27 Oct 2015 14:02:53 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CDF1AD06F for ; Tue, 27 Oct 2015 14:02:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 16CBFD9304; Tue, 27 Oct 2015 22:02:51 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LTKWszw3UEDx; Tue, 27 Oct 2015 22:02:50 +0100 (MET) Received: from [192.168.178.33] (x5f717ab6.dyn.telefonica.de [95.113.122.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 47A8CD9305; Tue, 27 Oct 2015 22:02:50 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <3C8D178C-CEF2-4395-B4B7-2FB80F39F733@ifi.uio.no> Date: Tue, 27 Oct 2015 22:02:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6507117D-40F1-48FF-ADB0-F624C33731FD@tik.ee.ethz.ch> References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> <27697ADF-7AE6-4E99-8288-FF19A68F1411@ifi.uio.no> <6F9FB87C-D0FF-46B3-A634-8A2E1234F9B7@tik.ee.ethz.ch> <2DC75956-A94E-40DE-8A40-B8A6BABE8ED8@ifi.uio.no> <782D504B-656F-4C98-9790-A2B2FFC36473@tik.ee.ethz.ch> <3C8D178C-CEF2-4395-B4B7-2FB80F39F733@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Aaron Falk , " Fairhurst" , "taps@ietf.org" , Stein Gjessing , Brian Trammell Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 21:02:57 -0000 Hi, see inline. > Am 27.10.2015 um 19:56 schrieb Michael Welzl : >=20 >=20 >> On 27. okt. 2015, at 15.46, Mirja K=C3=BChlewind = wrote: >>=20 >> Hi Michael, >>=20 >> for me, when I was reading the following, that was when I found it = quite arbitrary again: >>=20 >> "In the list resulting from the second pass, some services are = missing >> because they are implicit in some protocols, and they only become >> explicit when we consider the superset of all services offered by = all >> protocols. =E2=80=9E >>=20 >> So how do we know that we actually caught everything? >=20 > Everything here is based on text parts of the RFCs that focus on what = a protocol provides to the upper layer and how it is used. > This should be everything that=E2=80=99s relevant as a service. I disagree. > Now, when you have all these bits covered, for all the protocols you = want to cover, this should give you *exactly* the services of relevance = - that=E2=80=99s the idea of this procedure. >=20 > For example, now the document contains only TCP and SCTP. There is no = mention of congestion control, because, to choose between these two, = congestion control is not a relevant service: they both have it, in the = same way. If the document would only cover TCP and SCTP, I think = that=E2=80=99s exactly how it should be. I disagree. >=20 > When we add UDP, the obvious RFC to cover is the one on usage = guidelines (RFC5405). It will tell us that UDP does not have congestion = control, which means that the application has to take care of it. Thus, = =E2=80=9Cno congestion control=E2=80=9D becomes a part of the services. = Because =E2=80=9Clack of XY=E2=80=9D is a bit strange as a service, = it=E2=80=99d be obvious to write =E2=80=9Ccongestion control=E2=80=9D as = a service for the other protocols instead. I don=E2=80=99t think =E2=80=9Eno congestion control=E2=80=9C is a = service. That=E2=80=99s not a logic I understand; sorry. I don=E2=80=99t think that the point we want to capture is if there is = congestion control or not; it=E2=80=99s rather with choices you have = about congestion control. And today you might pick one congestion = control by name, where the name is a random pick and does not say = anything about the mechanism that is used. I=E2=80=99d hope that taps = could actually provide an interface that=E2=80=99s actual useful and = understandable such that the transport layer can pick the right = congestion control for you. I thought that one of the main points! >=20 > Consider another example. Assume, for a second, that all protocols had = the same checksum, and no option to turn it off or configure it. This is = not true, but just imagine it for the example. > In this case, there would never be text in any of the RFCs talking = about the relevance of the checksum to the application - and it would = never appear as a service, which is exactly the right decision, it would = be an integral part of communication that is the same everywhere. = Anyway, in reality, as soon as we add UDP-Lite and/or DCCP, we have = configurable checksums as a service in the list. But if these protocols = are not covered, what=E2=80=99s the point of describing a = =E2=80=9Cconfigurable checksum=E2=80=9D service? > (I=E2=80=99m ignoring the fact that the checksum can be disabled in = UDP now, for simplicity) >=20 Okay, even if extending existing protocols not in the charter, just = because every protocol would use the same checksum, that does not mean = that it would not be useful to maybe disable it. And if that would be = detected by taps which would mean a small protocol change, we could go = to the respective wg (e.g. tsvwg or tcpm) and figure out if they would = consider such an extension useful. I=E2=80=99m absolutely not convinced = here that we don=E2=80=99t want to do that. Further, back to your example above. To call =E2=80=9Eno congestion = control=E2=80=9C a service you have to analyze the protocol itself. = =E2=80=9Eno congestion control=E2=80=9C is not exposed in any = interface!!! And analyzing the protocol is what we do in the = taps-transport doc! When I was reading draft-well-taps-transports I=E2=80=99d had the = feeding you=E2=80=99ve started with the interfaces but then detected = that obvious things are missing, so you basically also started analyzing = the protocols itself but very selectively and from my point of view even = more arbitrary. The true might be somewhere in between here and we might need to do both = to get an as complete as possible picture. As I said in my previous = mail, we could even even merge both docs and or have two separate ones. = Again as I said before to me the approach you take is less logical and I = don=E2=80=99t think it will led to a complete or =E2=80=9Aright=E2=80=98 = solution either. =46rom my point of view, let's keep in mind all the discussion we had = and what we learned to far, and let=E2=80=99s move on! Mirja >=20 >=20 >> Further see below. >>=20 >>> Am 27.10.2015 um 15:27 schrieb Michael Welzl : >>>=20 >>>=20 >>>> On 27. okt. 2015, at 15.00, Mirja K=C3=BChlewind = wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> I didn=E2=80=99t say anything so far because I don=E2=80=99t mind = to have a second protocol here, but I personally don=E2=80=99t see this = doc as really needed. Effectively we will have two docs that have the = same results (a list of features) at the end. >>>=20 >>> I think draft-welzl-taps-transports highlights how many services (or = transport features or whatever we want to call them) are lost when we = just compile a list as in draft-ietf-taps-transports. >>> To give a few examples: SCTP: "ordered and unordered delivery within = a stream=E2=80=9D does not make it clear that you can in fact specify = per-message whether ordering matters or not. >>> In TCP, during the lifetime of a connection, you can change the DSCP = value. >>> In TCP, you can open a connection to listen at one local interface = or any; in SCTP, you can specify a list of local interfaces >>>=20 >>> We can debate whether these things are unnecessary details, but they = are things that appear in draft-welzl-taps-transports as a result of the = systematic approach I=E2=80=99ve taken. >>>=20 >>=20 >> For me that would be good feedback for taps-transport, to include = these things. We have for each protocol a section on interface(s). We = could even include more background text there if needed. >>=20 >> However, for the things you=E2=80=99ve mentioned that=E2=80=99s for = me rather a question on the level of detail of certain features. We=E2=80=99= ve already discussed that we might need something like =E2=80=9Aaspects=E2= =80=98 for each feature. I believe we decided to not provide more = details in this doc because we wanted to move on. However, I also = believe that people in this group understand well that in some cases = we=E2=80=99ll need more detailed information on the feature. And for me = even if we submit and publish the taps-transport as it is, this is not = written in stone and we can still say later on, that we rename a feature = or split it up or whatever. >=20 > Indeed, taps-transport is just at a slightly higher abstraction layer = than draft-welzl-taps-transports. >=20 >=20 >> For me that would even be part of the second doc in the charter. >=20 > Here I disagree. I think we need more detail to end up with an = implementable system, as in draft-welzl-taps-transports. The second doc = in the charter is about narrowing down the services, not adding more = detail. >=20 >=20 >> Again, I=E2=80=99m okay to have two docs here. I don=E2=80=99t think = a second doc is absolutely necessary. An alternative would be to merge = both docs=E2=80=A6 just as a side note. But I=E2=80=99m okay with both, = two or one docs. >=20 > I think merging them would get messy. >=20 >=20 >>>> 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. >>>=20 >>> Even more arbitrary =3D> could you please explain? >>> I think the discussion of what should be in and out has absolutely = nothing to do with the arbitrariness of the approach taken in the doc. >>=20 >> See above. For me the only question is, how can we make sure we cover = the right things and don=E2=80=99t forget important stuff. And in both = cases the answer is we can=E2=80=99t. >=20 > Given the RFC text describes well what a protocol offers to the upper = layer and how it=E2=80=99s used, my procedure (above) should give you = exactly what=E2=80=99s needed. >=20 >=20 >> For me analyzing (only) the interfaces, is the more arbitrary = approach because the current interfaces are already arbitrary to some = extend and that=E2=80=99s exactly what we want to change. But that=E2=80=99= s my personal view and there might not be an objective conclusion here. >=20 > This document is not about analyzing only the interfaces: it=E2=80=99s = about analyzing RFC text that describes what a protocol offers to the = upper layer and how it=E2=80=99s used. Because TCP and SCTP have = abstract API descriptions, that makes up more than 90% of this text in = case of these two protocols. >=20 > When you say that the current interfaces (which, for the context of = draft-welzl-taps-transports, are the abstract interfaces in the RFCs) = are "already arbitrary to some extent=E2=80=9D, you really criticize the = text in the RFC that describes how to use a protocol; then, I think you = should be specific and explain what you think is wrong per protocol, and = maybe suggest an update or errata. I do think that a lot of thinking has = gone into these text bits=E2=80=A6 even though real-life implementations = may diverge from these abstract APIs. >=20 > I also don=E2=80=99t think we want to *change* these interfaces, but = describe how to create a generic one that is built upon them. >=20 >=20 >>>> =46rom 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.=20 >>>>=20 >>>> I agree that the taps-transport doc is quite long, but for the wg I = don=E2=80=99t 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.=20 >>>>=20 >>>> 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=E2=80=99s actually a quite nice overview doc now. >>>=20 >>> I agree that it=E2=80=99s a nice document and ready. As for =E2=80=9CT= he only thing interesting for the wg is he final list of features, which = is there and ready to use=E2=80=9D, see the discussion above: the = draft-ietf-taps-transports is a nice and useful survey, but I do not = think it is a good basis for an implementable TAPS system, which we = eventually want (doc 3). >>=20 >> I don=E2=80=99t have the feeling that the new doc is much better. = Important is that the wg knows that these features are not written in = stone and we still have to think about the right choices here for any = future work. I believe that=E2=80=99s true for both docs. >=20 > I don=E2=80=99t get that; can you give an example? >=20 > Cheers, > Michael From nobody Wed Oct 28 01:05:25 2015 Return-Path: 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 F2C4E1ACE9F for ; Wed, 28 Oct 2015 01:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 jGrlX71rwsyV for ; Wed, 28 Oct 2015 01:05:22 -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 D41FC1B3709 for ; Wed, 28 Oct 2015 01:05:21 -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 ) id 1ZrLjR-0004Pa-9A; Wed, 28 Oct 2015 09:05:17 +0100 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZrLjQ-0004ex-P9; Wed, 28 Oct 2015 09:05:17 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <6507117D-40F1-48FF-ADB0-F624C33731FD@tik.ee.ethz.ch> Date: Wed, 28 Oct 2015 09:05:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <029C74BE-7B33-4DC2-B449-07BACCCBDD2A@ifi.uio.no> References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> <27697ADF-7AE6-4E99-8288-FF19A68F1411@ifi.uio.no> <6F9FB87C-D0FF-46B3-A634-8A2E1234F9B7@tik.ee.ethz.ch> <2DC75956-A94E-40DE-8A40-B8A6BABE8ED8@ifi.uio.no> <782D504B-656F-4C98-9790-A2B2FFC36473@tik.ee.ethz.ch> <3C8D178C-CEF2-4395-B4B7-2FB80F39F733@ifi.uio.no> <6507117D-40F1-48FF-ADB0-F624C33731FD@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 34438 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A523ABB0D170B1E83B41259904F3710D291F14FE X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 1 total 1988 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , " Fairhurst" , "taps@ietf.org" , Stein Gjessing , Brian Trammell Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 08:05:24 -0000 Hi Mirja, I=E2=80=99m not sure where this discussion is leading us: twice you just = say you disagree without giving a reason; then you seem to get kind of = hung up on the =E2=80=9Cno congestion control=E2=80=9D bit immediately = after quoting my statement: ** Thus, =E2=80=9Cno congestion control=E2=80=9D becomes a part of the = services. Because =E2=80=9Clack of XY=E2=80=9D is a bit strange as a = service, it=E2=80=99d be obvious to write =E2=80=9Ccongestion control=E2=80= =9D as a service for the other protocols instead. ** i.e. the service would be "congestion control=E2=80=9D, not =E2=80=9Cno = congestion control=E2=80=9D. The latter is just what you'd get in the = first iteration when working through the UDP usage guidelines. I=E2=80=99ll cut most of the text here to try to wrap this up, then = answer a particular point, and then get to your conclusion: > Further, back to your example above. To call =E2=80=9Eno congestion = control=E2=80=9C a service you have to analyze the protocol itself. = =E2=80=9Eno congestion control=E2=80=9C is not exposed in any = interface!!! And analyzing the protocol is what we do in the = taps-transport doc! No, you do *not* have to analyze the protocol, as this is not only about = interfaces, it=E2=80=99s based on any text in the RFCs that describes = what a protocol provides to the upper layer and how it is used. RFC = 5405, as an obvious source of text on how to use UDP and what it = provides to the layer above, tells us: "It is important to stress that an application SHOULD perform congestion control over all UDP traffic it sends to a destination, independently from how it generates this traffic." So, once we include UDP, we get congestion control as a service for TCP = and SCTP, from this text. > When I was reading draft-well-taps-transports I=E2=80=99d had the = feeding you=E2=80=99ve started with the interfaces but then detected = that obvious things are missing, so you basically also started analyzing = the protocols itself but very selectively and from my point of view even = more arbitrary. That=E2=80=99s not what I did. I strictly used only text that talks = about what a protocol provides to the upper layer and how it is used. > =46rom my point of view, let's keep in mind all the discussion we had = and what we learned to far, and let=E2=80=99s move on! Noting your statement from a previous email: "Again, I=E2=80=99m okay to = have two docs here. I don=E2=80=99t think a second doc is absolutely = necessary. An alternative would be to merge both docs=E2=80=A6 just as a = side note. But I=E2=80=99m okay with both, two or one docs.=E2=80=9D, I = agree and think we should just move on. Cheers, Michael From nobody Wed Oct 28 01:34:41 2015 Return-Path: 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 3D8681B3658 for ; Wed, 28 Oct 2015 01:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] 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 0GDODFksmpnZ for ; Wed, 28 Oct 2015 01:34:38 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::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 840921B3656 for ; Wed, 28 Oct 2015 01:34:38 -0700 (PDT) Received: by igdg1 with SMTP id g1so101684233igd.1 for ; Wed, 28 Oct 2015 01:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=YT3vsRp1rXhjMMkuAaH8G4mka1rfqZUT6razsAJNXL0=; b=t5WmxmrTO1SRL8lE0mcincZmRwpIZwiUZcaEA65BxaRyHDkr3hpJ2BNBx3iVPI9hO4 uT37RikjKUzjmHjZMj5pOgzpeFWbfA1IZVJ00DKjmBie7qZBOoJb27r55/0bH0QF+XYv JxR2ci0EnKZ+IuIOFKFGngrWN28T7P9rJzgcw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=YT3vsRp1rXhjMMkuAaH8G4mka1rfqZUT6razsAJNXL0=; b=au3xFRSkm7N66TkZlyiP2+/0de27J+mz+Iwb8gRlIIU5QergiaZYGW01NwIeQFc5YR a+W3vylS8leMEOBCLMiOWhOiFxFGVpP9MTtTgHVqfg+3WAmCxjGvvRcN51m4gK5EjgYR 8ZqgeTtPxjq2B7mDGEmLA009jmMvinq2N4iSsFFc9iGPSbmIfSZQjzX8wRL5BltHFGqU YX8WF1kafpfUFoelbEddjIJ7Hg93kmhws2UmH2TtfvidWxYX2r2II0SYjGodocuKarWa A+1LSPrMDpmla9YCJwR8Hh9f/jPRPVW4MNCSMuTXLv24sK73TnWDiEFCuuHgSvN/8NQ6 lCLQ== X-Gm-Message-State: ALoCoQkkoWnW4Md6uJ+qvtUTwXWf87eD4VCb67wvx+UyV6W9iSfMOL3AXhkTwZXi2UQGBOgVlud7zcaz2y9JAot7j7pAEOX/a0O1WI5iSL/D3ZxDg8clGWs= X-Received: by 10.50.20.74 with SMTP id l10mr1642185ige.2.1446021277918; Wed, 28 Oct 2015 01:34:37 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20150921083533.19273.62189.idtracker@ietfa.amsl.com> <9ac4441c10c70ae76c7bb75dc3613494@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKdK9Xuvg/e8qMO2/7tp8zJAaxQOQC0KKL7ApUxzZACUuj4nJy7fK5w Date: Wed, 28 Oct 2015 09:34:36 +0100 Message-ID: <2599cdcec9a767ff3d40695faa645836@mail.gmail.com> To: Michael Welzl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Cc: taps@ietf.org Subject: Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 08:34:41 -0000 Hi, Thanks. If this was not clear, then I should emphasize that I think this document is an excellent starting point ! BR, Karen > -----Original Message----- > From: Michael Welzl [mailto:michawe@ifi.uio.no] > Sent: 27. oktober 2015 15:07 > To: Karen Elisabeth Egede Nielsen > Cc: taps@ietf.org > Subject: Re: [Taps] New Version Notification for > draft-welzl-taps-transports- > 00.txt > > Dear Karen, > > Thanks a lot for your comments! > This was only meant as a starting point - e.g. the decision to only use > RFC4960 > but not RFC6458 is definitely not set in stone. > > We=E2=80=99ll incorporate them in the next revision (and then maybe get b= ack to > you > in case we need discussion) - thanks again! > > Cheers, > Michael > > > > On 27. okt. 2015, at 14.58, Karen Elisabeth Egede Nielsen > wrote: > > > > HI, > > > > FWIIW please accept the following comments to the document: > > > > Section 3.1: > > > > "Passive open with fully specified foreign socket" > > > > Is that a typical function provided to ULP by TCP ? > > Our POSIX socket api implementation does not really provide this. Or it > > does by set of special filters on the > > listening socket, but I wasn't aware that this was a feature generally > > available in TCP. > > > > "Passive open with fully specified foreign socket" on a unspecified > > passive open socket ? > > > > I assume we speak listening socket. Again is this something typically > > provided as an option to ULP by TCP ? > > > > "Send: and PUSH flag description": > > > > The PUSH flag is typically set inside the TCP implementation and the UL= P > > typically has no direct influence on the setting of it. I think that it > > is > > strange that this function > > is chosen to be described as if it is controlled directly by ULP when i= t > > is indeed not. > > > > There is some text later in section 3.1.1 motivating the choice. Yes it > > is > > correct that TCP implementations implement > > set of PUSH flag causing a behavior (i.e., a set of PUSH) that matches > > that the PUSH flag is set in the end of a communication, > > but again it is not controlled by ULP. As the intend of this document i= s > > to expose services that the ULP > > can invoke, I think that it is problematic that it is described as if > > the > > ULP can control PUSH directly, when it indeed (often) cannot. > > > > Section 3.2: > > > > General comment: > > > > The multi-stream capability and stream prioritization/scheduling > > possibilities of SCTP is a feature > > differentiating SCTP from TCP. The same is the fact that SCTP (SCTP-PR) > > also provide unreliable (no retransmissions) and partial reliable > > transport service (timeout). > > > > I think that these service features are important for certain SCTP > > deployment scenarios > > and that it would be desirable for these to be exposed here. (The > > timeout > > is described) > > It not included here in the first pass it will never even get considere= d > > for TAPS as a potential service, would it ? > > (It might end up being excluding, but then this should be a > > conscious (visible) choice, I think). > > > > Detailed comments: > > > > "Initialize needs be called only once per set of local addresses": > > > > This is the case when supporting one-to-many style sockets. Perhaps one > > might add > > "but ULP may also initialize each association endpoint instance > > individually". > > > > "Associate": > > > > I think that it is relevant to clarify that the remote SCTP instance in > > the association primitive is > > identified by one or multiple destination addresses thus allowing also > > the > > association handshake > > to proceed using multiple paths. > > > > "Send": > > > > "Another advisory flag indicates the ULP's preference to avoid bundling > > user data .." > > > > This is specified as an optional attribute in RFC4960. This is not > > specified in the RFC6458 socket API. > > ((Yes it might be similar to the TCP PUSH flag in that it is not > > generally > > implemented as directly controllable by ULP on a message basis - Or?)) > > > > Section 4.2: > > > > SCTP implements NO_delay (Nagle) option on a per association basis (as > TCP > > on a per connection basis) but not typically > > on a per message basis as described here. There are some additional > > bundling control related to stream scheduling - some are described in > > sctp-ndata draft. > > > > Section 5.1: > > > > "Disable Nagle algorithm:" > > > > Not specified in RFC4960, but in RFC6458 for SCTP. > > Is it really valid to use RFC4960 as a reference for the socket API whe= n > > the approach of > > SCTP IETF community has been to use RFC6458 for this ? > > > > *** > > > > BR, Karen > > > > > > > >> -----Original Message----- > >> From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Michael Welzl > >> Sent: 21. september 2015 10:45 > >> To: taps WG > >> Subject: [Taps] Fwd: New Version Notification for draft-welzl-taps- > >> transports-00.txt > >> > >> Dear all, > >> > >> In my presentation in Prague, I proposed an approach to identify the > > services > >> that transport protocols provide. At the end of the ensuing discussion= , > > I said > >> that I (with co-authors) would write a draft that explains the proposa= l > > by > >> applying the proposed method to TCP and SCTP. > >> > >> We just submitted this document - see below; I hope that this will > >> lead > > to > >> some discussion on the list... > >> > >> Cheers, > >> Michael > >> > >> > >>> Begin forwarded message: > >>> > >>> From: > >>> Subject: New Version Notification for > >>> draft-welzl-taps-transports-00.txt > >>> Date: 21 Sep 2015 10:35:33 CEST > >>> To: Michael Welzl , Michael Welzl > >>> , Michael Tuexen , > >> Naeem > >>> Khademi , Michael Tuexen >> muenster.de>, > >>> Naeem Khademi > >>> Resent-From: > >>> > >>> > >>> A new version of I-D, draft-welzl-taps-transports-00.txt > >>> has been successfully submitted by Michael Welzl and posted to the > >>> IETF repository. > >>> > >>> Name: draft-welzl-taps-transports > >>> Revision: 00 > >>> Title: An Approach to Identify Services Provided by > >> IETF Transport Protocols and Congestion Control Mechanisms > >>> Document date: 2015-09-21 > >>> Group: Individual Submission > >>> Pages: 23 > >>> URL: https://www.ietf.org/internet-drafts/draft-welzl-taps= - > >> transports-00.txt > >>> Status: > > https://datatracker.ietf.org/doc/draft-welzl-taps-transports/ > >>> Htmlized: > > https://tools.ietf.org/html/draft-welzl-taps-transports-00 > >>> > >>> > >>> Abstract: > >>> This document describes a method to identify services in transport > >>> protocols and congestion control mechanisms. It shows the approach > >>> using TCP and SCTP (base protocol) as examples. > >>> > >>> > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of > >>> submission until the htmlized version and diff are available at > > tools.ietf.org. > >>> > >>> The IETF Secretariat > >>> > >> > >> _______________________________________________ > >> Taps mailing list > >> Taps@ietf.org > >> https://www.ietf.org/mailman/listinfo/taps From nobody Wed Oct 28 05:16:23 2015 Return-Path: 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 751481B540B for ; Wed, 28 Oct 2015 05:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 PRrTxEEYQyLF for ; Wed, 28 Oct 2015 05:16:18 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 CFFC91B5408 for ; Wed, 28 Oct 2015 05:16:17 -0700 (PDT) Received: by iody8 with SMTP id y8so7918213iod.1 for ; Wed, 28 Oct 2015 05:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-type:content-transfer-encoding; bh=qsJ1ixVXORyvQ6O9f9acJDo6ziJnO2lFjg+unt8Cllg=; b=HESHH6J6J5J6KrgO6YeTD2UHAQJlufvXf0PKOTuVANzU7DGApvTpmOotLv111hssoO G4TJIwvLgcATkmFC+qT+znNoKnZqqHpkQdhTrkNiI2yHxPkwoOLaCqVWbIyO4w7FSDGN 1dWTSfTYTT7q55r3/nCW1SbnVh0czlRpJ1fBk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type :content-transfer-encoding; bh=qsJ1ixVXORyvQ6O9f9acJDo6ziJnO2lFjg+unt8Cllg=; b=SeRusMg0J/P/LAGvkfGurekSovuNhI8+58DvVorcXXOuxXdnxgYn6n3SLgeoSx9G7k sO9mSGgkjAEMHvSK6QY6o1xT1TaFzRCJqIZWrwfPnMRoW3ga+6pGXIU034qz/KH6cTf2 gPwtEEdOw8ok2EV64vE7iXACzELqSY69zDKASUwfddTiK9aGZt0dob69QmHba+R1r9a4 Xfu9/mrFZttmitGpJUyyrFCWTh+nywZm6GwEsq7AXdrZhINKd1oYosvfcCrpdyPGKCE9 WPB0wxfoTy8fQW23OdT+ziTHhotcRhor2mGiIubWSlOiSIVZo0flnmKErB1AEennwCep FElg== X-Gm-Message-State: ALoCoQnbntLDkggzkBuVGGBgDFQE+WPbcCJeHaJen5Mq5t/6uP0AX/op0kadYO6X/CGLgmERgqFFy4J+DGj4BaWwbBaNneQ5+dzjJuym5wRqQRoSkrFN1xE= X-Received: by 10.107.155.16 with SMTP id d16mr34182492ioe.38.1446034577153; Wed, 28 Oct 2015 05:16:17 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20151007104314.19878.21283.idtracker@ietfa.amsl.com> In-Reply-To: <20151007104314.19878.21283.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFZLlo63tGRXuxbUdNMPdEANZ+3J59wbm6w Date: Wed, 28 Oct 2015 13:16:15 +0100 Message-ID: <172925b64087d68c0c9f4a1de58daec5@mail.gmail.com> To: taps@ietf.org, Brian Trammell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Michael Tuexen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-07.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 12:16:21 -0000 HI, Please accept the following comments. Use them as/if you see fit. (Given my wretched, non-twistable, arms you are allowed not to take them too seriously) Section 3.1.1: 6'th paragraph: " In addition, a congestion control mechanism may react to changes in delay as an early indication for congestion." I think one will need to give a reference to this as it is not covered by the reference to RFC5681. Possibly this statement is better given in the context of the next paragraph referring to extensions. [I am aware that I have given this comment before. The reason that this continues to be an issue for me is that delay based CC alg's also are applicable to, e.g., SCTP (and have been applied there, though I don't know much about real deployment of them for SCTP). I am not sure if the solution to this is to have a special common section about congestion control algorithms - referring possibly to that these special CC als mostly are in deployment for TCP]. 9'th paragraph: Reference to push flag: The sentence: "TCP provides a push and a urgent function to enable data to be directly accessed by the receiver without having to wait for in-order delivery of the data." Should be revised I think. It is not very clear what the push flag contribute with in this sentence. The PUSH flag helps to release a "tail" packet from a TSO/GRO function/temporary packet buffering function. This feature of TCP might be significantly enough to describe the PUSH flag function as an implicit and internal protocol implementation optimization making TCP "push" tails through intermediate buffering functions. But the PUSH function is not really a "function" that TCP stacks provide to the ULP today (even if this is described as an optional possibility in RFC1122) - Or is it ? The urgent flag is not recommended ... so does it belong here ? Section 3.3: 1'st Paragraph: I propose to remove the sentence: "It also optionally supports path failover to provide resilience to path failures." There is no optionality about it and I think it is covered in the sentence before on supporting MH to handle path failures. In sentence: "An SCTP association has multiple unidirectional streams in each direction and provides in- sequence delivery of user messages only within each stream." ^^^ I propose to remove the word "only". I suggest to add the following sentence: "SCTP supports multiple stream scheduling schemes controlling the multiplexing of the streams into the transmission channel. Including priority as well as fair weighting schemes." Section 3.3.1: I propose to add the following sentence in the end of the paragraph on multi-homing below the bulleted list: "[I-D.ietf-tsvwg-sctp-failover] specifies a quicker failover operation reducing the latency of the failover". Inserted before the last sentence as follows: "If a remote address becomes unreachable, the traffic is switched over to a reachable one, if one exists. [I-D.ietf-tsvwg-sctp-failover] specifies a quicker failover operation reducing he latency of the failover. Each SCTP end-point supervises continuously the reachability of all peer addresses using a heartbeat mechanism." Section 3.3.2: First bullet: "In case of send failures that application .. " --> propose to replace with "In case of send failures, including drop of messages sent unreliably, the application " Third last paragraph: snet --> sent Section 3.3.3. Suggest to replace: fully reliable or partially reliable delivery --> with --> fully reliable, partially reliable and unreliable delivery Section 4.1: I wonder if SCTP Reliability could be Full/Partial/None I wonder if unordered delivery should be added as a row. I am not sure if ECN for SCTP should be marked as TBD. Applicability of RFC3168 to SCTP is described in RFC4960. I personally don=E2=80=99t know of any deployment of this. BR, Karen > -----Original Message----- > From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 7. oktober 2015 12:43 > To: i-d-announce@ietf.org > Cc: taps@ietf.org > Subject: [Taps] I-D Action: draft-ietf-taps-transports-07.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Services Working Group of the IETF. > > Title : Services provided by IETF transport protocols and congestion > control mechanisms > Authors : Godred Fairhurst > Brian Trammell > Mirja Kuehlewind > Filename : draft-ietf-taps-transports-07.txt > Pages : 53 > Date : 2015-10-07 > > Abstract: > This document describes services provided by existing IETF protocols > and congestion control mechanisms. It is designed to help > application and network stack programmers and to inform the work of > the IETF TAPS Working Group. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-taps-transports-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Oct 28 05:23:43 2015 Return-Path: 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 1D2D91B5495 for ; Wed, 28 Oct 2015 05:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 g0gapzClN8kN for ; Wed, 28 Oct 2015 05:23:40 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C31171B5493 for ; Wed, 28 Oct 2015 05:23:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5D4AAD930E; Wed, 28 Oct 2015 13:23:38 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id l-31me78MUbr; Wed, 28 Oct 2015 13:23:38 +0100 (MET) Received: from vpn-global-121-dhcp.ethz.ch (vpn-global-121-dhcp.ethz.ch [129.132.211.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 77324D9304; Wed, 28 Oct 2015 13:23:37 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <029C74BE-7B33-4DC2-B449-07BACCCBDD2A@ifi.uio.no> Date: Wed, 28 Oct 2015 13:23:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <53698FCA-C315-4C30-A936-0C1D4036F377@tik.ee.ethz.ch> References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> <27697ADF-7AE6-4E99-8288-FF19A68F1411@ifi.uio.no> <6F9FB87C-D0FF-46B3-A634-8A2E1234F9B7@tik.ee.ethz.ch> <2DC75956-A94E-40DE-8A40-B8A6BABE8ED8@ifi.uio.no> <782D504B-656F-4C98-9790-A2B2FFC36473@tik.ee.ethz.ch> <3C8D178C-CEF2-4395-B4B7-2FB80F39F733@ifi.uio.no> <6507117D-40F1-48FF-ADB0-F624C33731FD@tik.ee.ethz.ch> <029C74BE-7B33-4DC2-B449-07BACCCBDD2A@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Aaron Falk , " Fairhurst" , "taps@ietf.org" , Stein Gjessing , Brian Trammell Subject: Re: [Taps] IETF planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 12:23:42 -0000 Hi Micheal, this is only a personal opinion and I do not object to work on this doc. Mija > Am 28.10.2015 um 09:05 schrieb Michael Welzl : >=20 > Hi Mirja, >=20 > I=E2=80=99m not sure where this discussion is leading us: twice you = just say you disagree without giving a reason; then you seem to get kind = of hung up on the =E2=80=9Cno congestion control=E2=80=9D bit = immediately after quoting my statement: >=20 > ** > Thus, =E2=80=9Cno congestion control=E2=80=9D becomes a part of the = services. Because =E2=80=9Clack of XY=E2=80=9D is a bit strange as a = service, it=E2=80=99d be obvious to write =E2=80=9Ccongestion control=E2=80= =9D as a service for the other protocols instead. > ** > i.e. the service would be "congestion control=E2=80=9D, not =E2=80=9Cno = congestion control=E2=80=9D. The latter is just what you'd get in the = first iteration when working through the UDP usage guidelines. >=20 >=20 > I=E2=80=99ll cut most of the text here to try to wrap this up, then = answer a particular point, and then get to your conclusion: >=20 >=20 >> Further, back to your example above. To call =E2=80=9Eno congestion = control=E2=80=9C a service you have to analyze the protocol itself. = =E2=80=9Eno congestion control=E2=80=9C is not exposed in any = interface!!! And analyzing the protocol is what we do in the = taps-transport doc! >=20 > No, you do *not* have to analyze the protocol, as this is not only = about interfaces, it=E2=80=99s based on any text in the RFCs that = describes what a protocol provides to the upper layer and how it is = used. RFC 5405, as an obvious source of text on how to use UDP and what = it provides to the layer above, tells us: > "It is important to stress > that an application SHOULD perform congestion control over all UDP > traffic it sends to a destination, independently from how it > generates this traffic." >=20 > So, once we include UDP, we get congestion control as a service for = TCP and SCTP, from this text. >=20 >=20 >> When I was reading draft-well-taps-transports I=E2=80=99d had the = feeding you=E2=80=99ve started with the interfaces but then detected = that obvious things are missing, so you basically also started analyzing = the protocols itself but very selectively and from my point of view even = more arbitrary. >=20 > That=E2=80=99s not what I did. I strictly used only text that talks = about what a protocol provides to the upper layer and how it is used. >=20 >=20 >> =46rom my point of view, let's keep in mind all the discussion we had = and what we learned to far, and let=E2=80=99s move on! >=20 > Noting your statement from a previous email: "Again, I=E2=80=99m okay = to have two docs here. I don=E2=80=99t think a second doc is absolutely = necessary. An alternative would be to merge both docs=E2=80=A6 just as a = side note. But I=E2=80=99m okay with both, two or one docs.=E2=80=9D, I = agree and think we should just move on. >=20 > Cheers, > Michael From nobody Wed Oct 28 05:40:30 2015 Return-Path: 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 4D26E1A876B for ; Wed, 28 Oct 2015 05:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 eJApKvFaFnnh for ; Wed, 28 Oct 2015 05:40:27 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 7CA931A8767 for ; Wed, 28 Oct 2015 05:40:27 -0700 (PDT) Received: by igbdj2 with SMTP id dj2so5841806igb.1 for ; Wed, 28 Oct 2015 05:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-type:content-transfer-encoding; bh=i1YhqeFqJfrKTwbH6/YInGi5iCVTYTbMjtyeAaPIoy4=; b=5wmM7DqM5fH04DJ8vjjTKZisK7uanQBauDmkS+KVkbM3KNBSSiyCeesw2/BAkU+okk /0LHDTM1dcY0QXZ6VxppEy0qKcJHfGEy7EaQ/0HIRQaIRHr/Qdn4RM5rsPEgZnl343Md H+Amexnk/VOlgjlFcZkEWnW33HYd/MCuYGEOU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type :content-transfer-encoding; bh=i1YhqeFqJfrKTwbH6/YInGi5iCVTYTbMjtyeAaPIoy4=; b=N/yAvJL2Jo7eopyZeEP4EuMBConGSAGxuiO0rv/axDdavj54F4z8TAthPnOWuBrCMW kwpAg8ulSmQFNRe1T6iH7BLbwz+flEZ5IS3RJY4FHxHmf47Nx9h7MYakn1riPXS1LHXD Nr5aML6jpGtE0S7+yTfIXsKuZFPOvzv1PlrW5xmXSG5JdBGaVbCzYzedZ4Uq4kyV6KxA 6z3rD7RFx76kIp4BH0v74CMbP1M7emkU2k4pbF4/jExpu36ukm2nKKcQ3wBNGSt0k/Z5 IA2uJqbHUG4Fy96RVEdoUx016Evvtis2xa1W3vIFNt+0l0rDM9JVbDLBHwouwQR+rtpd ZAwQ== X-Gm-Message-State: ALoCoQliN3sJHlx42tYSIyMenIEQlFo6zzAnW5ymVZ0Swflp80y9A8oj1uHpC2gxhlblDoTMxoAaFymY/brZ2NQkxG+nsHaZTnH0OLUvbmr6bhSiehwEO7Y= X-Received: by 10.50.43.129 with SMTP id w1mr2739030igl.96.1446036026842; Wed, 28 Oct 2015 05:40:26 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20151007104314.19878.21283.idtracker@ietfa.amsl.com> 172925b64087d68c0c9f4a1de58daec5@mail.gmail.com In-Reply-To: 172925b64087d68c0c9f4a1de58daec5@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFZLlo63tGRXuxbUdNMPdEANZ+3J59wbm6wgAAutoA= Date: Wed, 28 Oct 2015 13:40:25 +0100 Message-ID: <8d277b9e34b04d4f25758383e6f1429f@mail.gmail.com> To: taps@ietf.org, Brian Trammell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Michael Tuexen , Michael Welzl , gorry@erg.abdn.ac.uk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-07.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 12:40:29 -0000 BTW, My personal opinion is that this document, in this version, is very good and serves well the purpose of providing a comprehensive survey of the services provided with a number of the IETF transport protocols. I do note, however, that the title of the document puts bigger emphasis on congestion control than the document content as such. I further, personally, consider the document draft-welzl-taps-transport as a good, and necessary, supplement going more into the details of the existing transport service interface(s). Thanks. BR, Karen > -----Original Message----- > From: Karen Elisabeth Egede Nielsen [mailto:karen.nielsen@tieto.com] > Sent: 28. oktober 2015 13:16 > To: 'taps@ietf.org'; 'Brian Trammell'; 'Mirja K=C3=BChlewind'; Michael Tu= exen > (tuexen@fh-muenster.de) > Subject: RE: [Taps] I-D Action: draft-ietf-taps-transports-07.txt > > HI, > > Please accept the following comments. > Use them as/if you see fit. > (Given my wretched, non-twistable, arms you are allowed not to take them > too seriously) > > Section 3.1.1: > > 6'th paragraph: > > " In addition, a congestion control > mechanism may react to changes in delay as an early indication for > congestion." > > I think one will need to give a reference to this as it is not covered by the > reference to RFC5681. > Possibly this statement is better given in the context of the next paragraph > referring to extensions. > > [I am aware that I have given this comment before. The reason that this > continues to be an issue for me is that > delay based CC alg's also are applicable to, e.g., SCTP (and have been applied > there, though I don't know much > about real deployment of them for SCTP). > I am not sure if the solution to this is to have a special common section about > congestion control algorithms - referring possibly > to that these special CC als mostly are in deployment for TCP]. > > 9'th paragraph: > > Reference to push flag: > > The sentence: > > "TCP provides a push and a urgent function to enable data to be > directly accessed by the receiver without having to wait for in-order > delivery of the data." > > Should be revised I think. It is not very clear what the push flag contribute > with in this sentence. The PUSH flag helps to release a "tail" > packet from a TSO/GRO function/temporary packet buffering function. This > feature of TCP might be significantly enough to describe the > PUSH flag function as an implicit and internal protocol implementation > optimization making TCP "push" tails through > intermediate buffering functions. But the PUSH function is not really a > "function" that TCP stacks provide to the ULP today > (even if this is described as an optional possibility in RFC1122) - Or is it ? > > The urgent flag is not recommended ... so does it belong here ? > > Section 3.3: > > 1'st Paragraph: > > I propose to remove the sentence: > > "It also optionally supports path failover to > provide resilience to path failures." > > There is no optionality about it and I think it is covered in the sentence > before on supporting MH > to handle path failures. > > In sentence: > > "An SCTP association has > multiple unidirectional streams in each direction and provides in- > sequence delivery of user messages only within each stream." > ^^^ > I propose to remove the word "only". > > I suggest to add the following sentence: > > "SCTP supports multiple stream scheduling schemes controlling the > multiplexing of the streams > into the transmission channel. Including priority as well as fair weighting > schemes." > > Section 3.3.1: > > I propose to add the following sentence in the end of the paragraph on > multi-homing below the bulleted list: > > "[I-D.ietf-tsvwg-sctp-failover] specifies a quicker failover operation reducing > the latency of the failover". > > Inserted before the last sentence as follows: > > "If a remote > address becomes unreachable, the traffic is switched over to a > reachable one, if one exists. [I-D.ietf-tsvwg-sctp-failover] specifies a > quicker failover operation > reducing he latency of the failover. > Each SCTP end-point supervises > continuously the reachability of all peer addresses using a heartbeat > mechanism." > > Section 3.3.2: > > First bullet: > > "In case of send failures that application .. " --> propose to replace with > > "In case of send failures, including drop of messages sent unreliably, the > application " > > Third last paragraph: > > snet --> sent > > Section 3.3.3. > > Suggest to replace: > > fully reliable or partially reliable delivery --> with --> > > fully reliable, partially reliable and unreliable delivery > > Section 4.1: > > I wonder if SCTP Reliability could be Full/Partial/None > > I wonder if unordered delivery should be added as a row. > > I am not sure if ECN for SCTP should be marked as TBD. Applicability of > RFC3168 to SCTP is described in RFC4960. > I personally don=E2=80=99t know of any deployment of this. > > > BR, Karen > > > > > -----Original Message----- > > From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of internet- > > drafts@ietf.org > > Sent: 7. oktober 2015 12:43 > > To: i-d-announce@ietf.org > > Cc: taps@ietf.org > > Subject: [Taps] I-D Action: draft-ietf-taps-transports-07.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Transport Services Working Group of the > IETF. > > > > Title : Services provided by IETF transport protocols and > congestion > > control mechanisms > > Authors : Godred Fairhurst > > Brian Trammell > > Mirja Kuehlewind > > Filename : draft-ietf-taps-transports-07.txt > > Pages : 53 > > Date : 2015-10-07 > > > > Abstract: > > This document describes services provided by existing IETF protocols > > and congestion control mechanisms. It is designed to help > > application and network stack programmers and to inform the work of > > the IETF TAPS Working Group. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-taps-transports-07 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-07 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Taps mailing list > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Oct 28 07:08:21 2015 Return-Path: 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 C60F01A8978 for ; Wed, 28 Oct 2015 07:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 kYk3IDJbLCb6 for ; Wed, 28 Oct 2015 07:08:16 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (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 F25D51A897B for ; Wed, 28 Oct 2015 07:08:15 -0700 (PDT) Received: by ykek133 with SMTP id k133so8681379yke.2 for ; Wed, 28 Oct 2015 07:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=+OxnjHgWYL/dopo3GLzFQiUPTfL/lEPinOHs2xXZxjE=; b=IiXxJeQ409nXdfcEvrW+LjHt76UeMosEraqVVebA7KvyCUoJ0DS3X1NYSAhSSqTxmc pbylrD/r6VEO5GjTrUqdszUVMxspp3FRZ8jnpk6AOg8//GYvYHJK59QEEgmjCw469cKj X1VPUUhedoP1jTrF0q4FCf2Um2t0RphpEpag2Un3RgGtEBcub1/k8Ti7r9wIvXGlXP8Y DQzY2y08IzM1DZZ8Z9zSgOb4YGtqqSyNvN8bRiWirJr3480Sg7Sy+rtyeEwL6gS5kqf1 9O+bcppfgwoV8DjjWr5YFSnYE45Am1YyxKqY68uByChU9jhO7kdserYS0JeeqsFh29Ab 40gA== MIME-Version: 1.0 X-Received: by 10.129.41.15 with SMTP id p15mr34327368ywp.91.1446041295268; Wed, 28 Oct 2015 07:08:15 -0700 (PDT) Received: by 10.37.95.2 with HTTP; Wed, 28 Oct 2015 07:08:15 -0700 (PDT) Date: Wed, 28 Oct 2015 10:08:15 -0400 Message-ID: From: Aaron Falk To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Brian Trammell , Gorry Fairhurst Content-Type: multipart/alternative; boundary=001a11413698bc38d905232ab98b Archived-At: Cc: "taps@ietf.org" Subject: [Taps] is draft-ietf-taps-transports-07 ready for wg last call X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 14:08:20 -0000 --001a11413698bc38d905232ab98b Content-Type: text/plain; charset=UTF-8 Mirja, draft editor, has said the draft is 'done'. Do you other editors agree? We can make the Yokohama discussion part of the last call review. --aaron --001a11413698bc38d905232ab98b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mirja, draft editor, has said the draft is 'done'.= =C2=A0 Do you other editors agree?=C2=A0 We can make the Yokohama discussio= n part of the last call review.

--aaron
--001a11413698bc38d905232ab98b-- From nobody Wed Oct 28 07:10:37 2015 Return-Path: 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 E7DB51A8937 for ; Wed, 28 Oct 2015 07:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 4vMKguJBgCsI for ; Wed, 28 Oct 2015 07:10:34 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 3D8E81A8904 for ; Wed, 28 Oct 2015 07:10:34 -0700 (PDT) Received: by ykba4 with SMTP id a4so8652415ykb.3 for ; Wed, 28 Oct 2015 07:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=6FVC7CdWuUKDGaMskDP0d64JWATedgBqYxoeO6pDDHg=; b=iH1JqTDIJptWrhdnD/zORozcJ1/E5Zp6eqfy4rTBEpy1xF0xmXDZ9Y/1s4PaIjd9t2 dyYQRcepmLfELted/Iu+LK3xOSQep3EczUUc10vgFgs6eR6o0WpJblwrseKTDWMkVm3D sILESq1sHugiUTnRNqRzjSekLiuZ9xyWer2Sy8EjLBo3n5mOW8bJQxzLiq+/E3xWh1BV bN9oiqt5ijrNU+EMby73aNMEfQ1V9n4mgmXaA53m4JXfAvTI/y2lVVBFYNeVNVAMDC5L SQ1g33cUojQdUJ2G3/VYt51sbTmYbGgPQaXiHHgTRSY0unfjwgpFnzHTSLbW9rQGW2IN v5Hw== MIME-Version: 1.0 X-Received: by 10.13.201.68 with SMTP id l65mr34668029ywd.340.1446041433537; Wed, 28 Oct 2015 07:10:33 -0700 (PDT) Received: by 10.37.95.2 with HTTP; Wed, 28 Oct 2015 07:10:33 -0700 (PDT) Date: Wed, 28 Oct 2015 10:10:33 -0400 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=001a114e870afa1e9d05232ac16e Archived-At: Cc: Michael Tuexen , Naeem Khademi , Michael Welzl Subject: [Taps] adopting draft-welzl-taps-transports X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 14:10:36 -0000 --001a114e870afa1e9d05232ac16e Content-Type: text/plain; charset=UTF-8 I've not heard any objections to work on this document and several proposals for why it would help docs 2 & 3 (as well as the implementations based on 3). 1. Should TAPS adopt draft-welzl-taps-transports as a working group deliverable? 2. To some folks it sounds as though this doc is a pre-requisite to doc 2. Do folks agree? Can we start on doc 2 in parallel or should we wait? --aaron --001a114e870afa1e9d05232ac16e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've not heard any objections to work on this document= and several proposals for why it would help docs 2 & 3 (as well as the= implementations based on 3). =C2=A0

1. Should TAPS adop= t draft-welzl-taps-transports as a working group deliverable?=C2=A0

2. To some folks it sounds as though this doc is a pre-re= quisite to doc 2.=C2=A0 Do folks agree?=C2=A0 Can we start on doc 2 in para= llel or should we wait?

--aaron
--001a114e870afa1e9d05232ac16e-- From nobody Wed Oct 28 07:12:42 2015 Return-Path: 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 09D4E1A8960 for ; Wed, 28 Oct 2015 07:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 M-u4U7-k7AwR for ; Wed, 28 Oct 2015 07:12:39 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (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 BEE171A898F for ; Wed, 28 Oct 2015 07:12:39 -0700 (PDT) Received: by ykft191 with SMTP id t191so8834060ykf.0 for ; Wed, 28 Oct 2015 07:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+Cg72EbplCCKMXqWy3oI+J3Z+RMfPeTq7tQuR8ShSuQ=; b=YQofyl/7fjas91QyECPDNmx79LlBLc3vW5uuooFmyKHVzDjm78kcPxKOSdpVI6dbYo Sf8/35VrFee/HLdoESfqP60H89vSk+iLqrq9IipclTC+iHFWvx8XHftbPlwrCsUSlpNy CAqlj6CzQI8ZRts8IGVYfvaShhq8cKmZTCtDNl4gVwdRO2nTZQEx3UJfCegV2MdXlbAN dLQLbl8V1OMuix31QTl0UNo/W1lHyQiM3PZczY+TGtkC2VLA8FWNv68dqS2bfNrcVT15 NhFdkdjKWRKlTA4jiByZR0gsx9dBYh7bZi0e7EJ2SPxBpayOZz6ldMNor8LkvkI26r8f NZFQ== MIME-Version: 1.0 X-Received: by 10.129.43.214 with SMTP id r205mr1043914ywr.61.1446041559101; Wed, 28 Oct 2015 07:12:39 -0700 (PDT) Received: by 10.37.95.2 with HTTP; Wed, 28 Oct 2015 07:12:39 -0700 (PDT) Date: Wed, 28 Oct 2015 10:12:39 -0400 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=001a1141e45e75f9ad05232ac939 Archived-At: Subject: [Taps] implementors X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 14:12:41 -0000 --001a1141e45e75f9ad05232ac939 Content-Type: text/plain; charset=UTF-8 TAPS was started based on the assumption that there are folks who want to implement the API and supporting mechanism. Do we have folks on the list who plan to do this? --aaron --001a1141e45e75f9ad05232ac939 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
TAPS was started based on the assumption that there are fo= lks who want to implement the API and supporting mechanism.=C2=A0 Do we hav= e folks on the list who plan to do this?

--aaron
--001a1141e45e75f9ad05232ac939-- From nobody Wed Oct 28 07:17:47 2015 Return-Path: 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 0690F1B3322 for ; Wed, 28 Oct 2015 07:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 J41T0aU1vnSH for ; Wed, 28 Oct 2015 07:17:44 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (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 7449E1A8941 for ; Wed, 28 Oct 2015 07:17:44 -0700 (PDT) Received: by qgem9 with SMTP id m9so7306181qge.1 for ; Wed, 28 Oct 2015 07:17:43 -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=vnQsN4659PlVtsvmdvJ9ZsjsCYRJvZVuxxwC3r0shjg=; b=jBi+t/zApncpvSfRYa0jXgZ7LJ3vQhHbtnBub5oF6iJ2Ar9TaSyHhYXz80mlX1YMH+ Ztwrd0D9yRwx/CkDTqd3o/htZEp0VxZ6D+BNJEcn/040Y+elXLpmXfx+X3R0qrCbdhUu jBRmmIVMdyHA/JQtFcK6r8PWakXfyEgzlnbVagBPBl302LKhSAPRyg8YsZunoE9RaZWD 8JRSvK1uvAB4sjw+TnxB/hYGbqWj1S2K23afSaCDSsoZg1AzLmW8s7xc9vx7hxp/3OxQ 5v+hDQB3CqnlMJRr1pJu3K3aA2PS6ByGs0mGa4+sVfAp3WXoekNXAMI9YnrXMKfdOath 7+Sg== 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=vnQsN4659PlVtsvmdvJ9ZsjsCYRJvZVuxxwC3r0shjg=; b=c/SpfZMwgF2GgByR7x+CP+MErLnTq8kV8qZ4gaYbQfTyi4MxslGVRMBeG2eEmzj/CJ y2C7ZHisAnvJYUIPCujKeK2UfRtN3yJl54Soa1bQQcyVfLtYIZuiQbFXAwJu0J9IdHvN 0J/O9Oin1AuwJ/iieHqJQNs3s3aCZmcfe/94xb/mNFWt0b5MndkB1n+vCjotNS7mENXU HibVyB2IYbyy/XEvi4Lj5aThc84qgJxZb5TS3QHDcBYgdrn4dtMa0bnN/Le/fm4OeFpp Ey3rNbghsts8ZbfjMINd+NQbMQbVOGSvwmRc/eoyTLyicX5RS5XYOwjejFV1y97HPMgL rYmA== X-Gm-Message-State: ALoCoQmyiglvO1B1oiQtcSYP3D6tDrgiAQcnpC2CjbLQZWXfqVALgdMwnzX6qfCQj7q2Xzj3bErg X-Received: by 10.140.216.135 with SMTP id m129mr60535917qhb.90.1446041863619; Wed, 28 Oct 2015 07:17:43 -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 b35sm2316262qkb.16.2015.10.28.07.17.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Oct 2015 07:17:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Marie-Jose Montpetit In-Reply-To: Date: Wed, 28 Oct 2015 10:17:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Aaron Falk X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] implementors X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 14:17:46 -0000 I would love to help. At least on the protocol/architecture side. > On Oct 28, 2015, at 10:12 AM, Aaron Falk wrote: >=20 > TAPS was started based on the assumption that there are folks who want = to implement the API and supporting mechanism. Do we have folks on the = list who plan to do this? >=20 > --aaron > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Oct 28 07:29:30 2015 Return-Path: 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 6DF261B557A for ; Wed, 28 Oct 2015 07:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 preP-ikWaLaq for ; Wed, 28 Oct 2015 07:29:27 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id A748A1B5579 for ; Wed, 28 Oct 2015 07:29:27 -0700 (PDT) Received: from [10.0.3.52] (s39.BMT-e1.vectant.ne.jp [122.103.208.39]) by trammell.ch (Postfix) with ESMTPSA id A356F1A0209; Wed, 28 Oct 2015 15:28:52 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Brian Trammell In-Reply-To: Date: Wed, 28 Oct 2015 23:28:47 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <2DEC1386-B68C-495C-8A05-E19AD14D1D88@trammell.ch> References: To: Aaron Falk X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Gorry Fairhurst , =?utf-8?Q?Mirja_K=C3=BChlewind?= , "taps@ietf.org" Subject: Re: [Taps] is draft-ietf-taps-transports-07 ready for wg last call X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 14:29:29 -0000 hi Aaron, I concur. There are a few editorial changes to make but we can do these together = with LC comments: we had originally wanted to do a great big grid of = protocols and features, (section 4.1) but the present list (section 4) = is probably much more readable. We need to do one more pass on this to = make sure we got everything, and probably add names of protocols = supporting each feature. Cheers, Brian > On 28 Oct 2015, at 23:08, Aaron Falk wrote: >=20 > Mirja, draft editor, has said the draft is 'done'. Do you other = editors agree? We can make the Yokohama discussion part of the last = call review. >=20 > --aaron > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Oct 28 07:45:25 2015 Return-Path: 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 24D5F1A8A03 for ; Wed, 28 Oct 2015 07:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ScSinGAMy8bl for ; Wed, 28 Oct 2015 07:45:22 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3E91A89FF for ; Wed, 28 Oct 2015 07:45:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3D510D9304; Wed, 28 Oct 2015 15:45:20 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2imF1pQdXZNC; Wed, 28 Oct 2015 15:45:19 +0100 (MET) Received: from [192.168.178.33] (x5f702095.dyn.telefonica.de [95.112.32.149]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 8880AD9303; Wed, 28 Oct 2015 15:45:19 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <2DEC1386-B68C-495C-8A05-E19AD14D1D88@trammell.ch> Date: Wed, 28 Oct 2015 15:45:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2DEC1386-B68C-495C-8A05-E19AD14D1D88@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Aaron Falk , Gorry Fairhurst , "taps@ietf.org" Subject: Re: [Taps] is draft-ietf-taps-transports-07 ready for wg last call X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 14:45:24 -0000 Hi Aaron, what I meant was that we are done with the actual work for this doc. = However, there are few minor things on the todo list, as Brian said. = Further we were hoping to get some feedback from the list for a new = revision. Especially there was a question that Brian posted regarding = the feature section: Is it okay to only have the lists as we have them = right now, or would it be useful to add some text (1-3 sentences) for = each feature that describes how a feature is implemented in the specific = protocol=E2=80=A6? Mirja > Am 28.10.2015 um 15:28 schrieb Brian Trammell : >=20 > hi Aaron, >=20 > I concur. >=20 > There are a few editorial changes to make but we can do these together = with LC comments: we had originally wanted to do a great big grid of = protocols and features, (section 4.1) but the present list (section 4) = is probably much more readable. We need to do one more pass on this to = make sure we got everything, and probably add names of protocols = supporting each feature. >=20 > Cheers, >=20 > Brian >=20 >> On 28 Oct 2015, at 23:08, Aaron Falk wrote: >>=20 >> Mirja, draft editor, has said the draft is 'done'. Do you other = editors agree? We can make the Yokohama discussion part of the last = call review. >>=20 >> --aaron >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps From nobody Wed Oct 28 07:46:58 2015 Return-Path: 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 019BE1A8A03 for ; Wed, 28 Oct 2015 07:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 x6PiA3ycR3jg for ; Wed, 28 Oct 2015 07:46:55 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE03A1A89FC for ; Wed, 28 Oct 2015 07:46:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A05ADD930C; Wed, 28 Oct 2015 15:46:53 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id A49shIk24aTZ; Wed, 28 Oct 2015 15:46:53 +0100 (MET) Received: from [192.168.178.33] (x5f702095.dyn.telefonica.de [95.112.32.149]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 3DB1CD9303; Wed, 28 Oct 2015 15:46:53 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Wed, 28 Oct 2015 15:46:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <735ABD99-AF8E-4989-AA94-FB0F229C8121@tik.ee.ethz.ch> References: To: Aaron Falk X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] implementors X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 14:46:57 -0000 Hi Aaron, we would be interested and able to support implementation efforts, = however, it=E2=80=99s not clear to me now what exactly should be = implemented. Mirja > Am 28.10.2015 um 15:12 schrieb Aaron Falk : >=20 > TAPS was started based on the assumption that there are folks who want = to implement the API and supporting mechanism. Do we have folks on the = list who plan to do this? >=20 > --aaron > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Oct 28 07:51:17 2015 Return-Path: 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 54B111A8AB7 for ; Wed, 28 Oct 2015 07:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 eIt0oo4X1I1e for ; Wed, 28 Oct 2015 07:51:12 -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 CA40A1A879C for ; Wed, 28 Oct 2015 07:51:11 -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 ) id 1ZrS4E-00009w-4k; Wed, 28 Oct 2015 15:51:10 +0100 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZrS4D-0005ss-M6; Wed, 28 Oct 2015 15:51:10 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_1DA63E59-3ECA-4AA2-8CB4-AA30297F769E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Wed, 28 Oct 2015 15:51:09 +0100 Message-Id: References: To: Aaron Falk X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 10 msgs/h 7 sum rcpts/h 13 sum msgs/h 8 total rcpts 34470 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6485DA8B285C7ECACBEE22CB4AB15A07092CF1F0 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 7 total 2010 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] implementors X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 14:51:15 -0000 --Apple-Mail=_1DA63E59-3ECA-4AA2-8CB4-AA30297F769E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, There=E2=80=99s a European project dedicated to implementing a TAPS++ = type system: https://www.neat-project.org = All members of this project are naturally planning to do a TAPS = implementation. Cheers, Michael > On 28. okt. 2015, at 15.12, Aaron Falk wrote: >=20 > TAPS was started based on the assumption that there are folks who want = to implement the API and supporting mechanism. Do we have folks on the = list who plan to do this? >=20 > --aaron > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_1DA63E59-3ECA-4AA2-8CB4-AA30297F769E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

There=E2=80=99s a European project dedicated to implementing = a TAPS++ type system:  https://www.neat-project.org

All members of this project are = naturally planning to do a TAPS implementation.

Cheers,
Michael


On 28. okt. 2015, at 15.12, Aaron Falk <aaron.falk@gmail.com> wrote:

TAPS was started based on the assumption that there are folks = who want to implement the API and supporting mechanism.  Do we have = folks on the list who plan to do this?

--aaron
_______________________________________________
Taps = mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Apple-Mail=_1DA63E59-3ECA-4AA2-8CB4-AA30297F769E-- From nobody Thu Oct 29 00:40:21 2015 Return-Path: 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 818471A024C for ; Thu, 29 Oct 2015 00:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 q0VYSeSSQqbD for ; Thu, 29 Oct 2015 00:40:17 -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 6E3B61A8849 for ; Thu, 29 Oct 2015 00:40:17 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Zrhol-0007Sg-6m; Thu, 29 Oct 2015 08:40:15 +0100 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Zrhok-0006Tr-Km; Thu, 29 Oct 2015 08:40:15 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Thu, 29 Oct 2015 08:40:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Aaron Falk X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 16 msgs/h 6 sum rcpts/h 21 sum msgs/h 9 total rcpts 34486 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 3938B559D75A0E0363D16BA13C92B361F99BF2A4 X-UiO-SPAM-Test: UIO-GREYLIST remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 6 total 2016 max/h 14 blacklist 0 greylist 1 ratelimit 0 Archived-At: Cc: Michael Tuexen , " Khademi" , "taps@ietf.org" Subject: Re: [Taps] adopting draft-welzl-taps-transports X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 07:40:19 -0000 So I did say this before, but to get the ball rolling: > On 28. okt. 2015, at 15.10, Aaron Falk wrote: >=20 > I've not heard any objections to work on this document and several = proposals for why it would help docs 2 & 3 (as well as the = implementations based on 3). =20 >=20 > 1. Should TAPS adopt draft-welzl-taps-transports as a working group = deliverable?=20 >=20 > 2. To some folks it sounds as though this doc is a pre-requisite to = doc 2. Do folks agree? Can we start on doc 2 in parallel or should we = wait? I do think that doc 2 should be based on draft-welzl-taps-transports, = i.e. I think we should wait for a bit. We could get started before = draft-welzl-taps-transports is completely finished, but I think we = should give it at least 1-2 more iterations before starting to narrow it = down in doc 2.=20 Cheers, Michael From nobody Sat Oct 31 18:55:43 2015 Return-Path: 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 AAF0B1B4F1B for ; Sat, 31 Oct 2015 18:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 vQTc5saJ3H_j for ; Sat, 31 Oct 2015 18:55:40 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (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 7BBE61B4F19 for ; Sat, 31 Oct 2015 18:55:40 -0700 (PDT) Received: by ykek133 with SMTP id k133so110729767yke.2 for ; Sat, 31 Oct 2015 18:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=kMj/xf+lNNqX5J7DcdZTMqbAPCw2iqTWP5vInUWGhXo=; b=OjU8/206dUbIW6KN1geyv1jSWCV+b3rsPBrPwMKSoSNI38PQ2bFEGOrHgTgOgXaoag bl0fkKpFpT3bHxYaIA07RdSSzGAANkvAfVFA4zql2/t8fGmxJC7cErTyeTot2lKcwBxO 5/4jIlOlE5f51l5kLIDiO0y8nJo10w8Eoe/UvglLdWspkRCUP6zmYIur7hXZbk6xHMsE cIFGGnmD4Q2kY5mKogvqmnGwGGiOY3q39PBKwImHgBnvMcH1+EPhTGCubNY30uOymzcL wzwi8+wx4SFAFnolXofEmv6zoiZrKLsmXGF3ftYNwAQYFfcMHdOqoLJJXEYg5uc3FdHK ptGQ== MIME-Version: 1.0 X-Received: by 10.13.245.134 with SMTP id e128mr11619180ywf.24.1446342939839; Sat, 31 Oct 2015 18:55:39 -0700 (PDT) Received: by 10.37.95.2 with HTTP; Sat, 31 Oct 2015 18:55:39 -0700 (PDT) Date: Sat, 31 Oct 2015 21:55:39 -0400 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c034df027448e052370f547 Archived-At: Subject: [Taps] agenda for IETF-94 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 01:55:41 -0000 --94eb2c034df027448e052370f547 Content-Type: text/plain; charset=UTF-8 Apologies for taking so long to get this out. (My non-existent co-chair dropped the ball. :) Comments and critique are welcome. Please read the drafts. --aaron ==== 1. Agenda bash 2. WG Status 3. Updates on draft-ietf-taps-transports - Starting WGLC for this doc 4. Discussion of draft-welzl-taps-transports - Review of 'algorithm' - What additional protocols should be included? - Should the wg adopt this draft? 5. AOB --94eb2c034df027448e052370f547 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Apologies for taking so long to get this out. (My non-exis= tent co-chair dropped the ball. =C2=A0:) =C2=A0Comments and critique are we= lcome.=C2=A0 Please read the drafts.

--aaron
<= br>
=3D=3D=3D=3D


1. Agenda = bash

2. WG Status

3. Upda= tes on draft-ietf-taps-transports
=C2=A0 =C2=A0 - Starting WGLC f= or this doc

4. Discussion of draft-welzl-taps-tran= sports
=C2=A0 =C2=A0 - Review of 'algorithm'=C2=A0
<= div>=C2=A0 =C2=A0 - What additional protocols should be included?
=C2=A0 =C2=A0 - Should the wg adopt this draft?

5= . AOB
--94eb2c034df027448e052370f547--