From nobody Mon Nov 3 04:56:39 2014 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 79FCF1A0127 for ; Mon, 3 Nov 2014 04:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, HTML_MESSAGE=0.001, 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 tTD4mYFshDBi for ; Mon, 3 Nov 2014 04:56:35 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDA4D1A0120 for ; Mon, 3 Nov 2014 04:56:32 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id n3so6362728wiv.12 for ; Mon, 03 Nov 2014 04:56:31 -0800 (PST) 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; bh=xQom/tzQPpOhJf3Ze4XEd51WzKsHbPXYWu7wut6oqK8=; b=4C0xndmWj1+nuqFr5Eeze4O9uquPih73STTbdiGyBe9/oJjtJRMIuYG3JZTGN6Wfqr +XzAGwGuu3nJzBrsDm3o+pEvBLTTQciVremgAB2o0e8s1mh2WUo4Po6eVxcSL8E1FUCu UCYpRsN+EJNKF0Uwhja0gbgCskI/e30xJmEGE= 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; bh=xQom/tzQPpOhJf3Ze4XEd51WzKsHbPXYWu7wut6oqK8=; b=hKyLLLIdzrdumuiSM2ghbBLUDQG75Z1tKmIiwupx7tR+hKUjGNYwtseiH7rmATNVRL X22ccd286iXDsmjDJojezZUfMNdU4aDFc36eliYoBtjCFdYttyfVwW4rWuQOZh8sF1tR NXh42YLniWi9UPIl1FkwUy7l0yrPn15ooAMwoRIDHvBdBwAX3PGc4JPrlaJ8DM+8kFI0 a+7X9jVvY3zTBHdIlm8ugHaDVi3fOvnLbPFubB6LPaXB1R3zuqtv0j2jZm4kBziI41Pl Vre56YHsP5u4xifkM3iw8nHitK1dm/HpkSHO6Zr0PAo2Hs3hH3TIcdFnKCcHQVVAoXCA UlEA== X-Gm-Message-State: ALoCoQm/LpRR7j488USYzyyZnFQd/yBuQ5cttFqMB9C6WLEm036m3zbdct1xJRqab+dlgVFk99WNLe+TxwHxyPsO3JOrRYYEnOcwxRBegisCmkf5dE6Ia94= X-Received: by 10.180.98.233 with SMTP id el9mr6334902wib.3.1415019390978; Mon, 03 Nov 2014 04:56:30 -0800 (PST) From: Karen Elisabeth Egede Nielsen References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJzcNaud4vLvkK4lfGmWeqkkm4JwZsH5GVw Date: Mon, 3 Nov 2014 13:56:30 +0100 Message-ID: To: Aaron Falk , taps@ietf.org Content-Type: multipart/alternative; boundary=f46d044288962666450506f3e0c6 X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/taps/Qr2O_PYsjaluGJuBAEsDd2ty7-c Cc: Gorry Fairhurst , Brian Trammell Subject: Re: [Taps] new draft available: draft-fairhurst-taps-transports-00 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, 03 Nov 2014 12:56:37 -0000 --f46d044288962666450506f3e0c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Thanks a lot for a good start. I notice that MPTCP is quoted as a transport protocol but that CMT-SCTP isn=E2=80=99t. I assume that this is motivated by the fact that the taps work very clearly draws the line in between features that have made it through IETF standardisation (even as informational) and features that have not and only are specified in =E2=80=9Cseemingly dormant=E2=80=9D individual drafts= . Correct ? In terms of SCTP and the transport service that it provides, then I wonder if the priority feature that it embeds is something that afford special mentioning in this document. I.e., by usage of streams and priority settings on streams then it is possible to enforce that messages written on particular stream is able to outrace messages written on other non-prioritized streams at least from a sender transmittal perspective. The feature is actually started to be deployed for some applications in present signalling networks but it is only partially standardized in that the tsvwg documents (ndata, secondary SCTP-pr) that specifies the feature are not finished yet. Still the features are described in standards track documents. Thanks BR, Karen *From:* Taps [mailto:taps-bounces@ietf.org] *On Behalf Of *Aaron Falk *Sent:* Tuesday, October 28, 2014 5:04 PM *To:* taps@ietf.org *Cc:* Gorry Fairhurst; Brian Trammell *Subject:* [Taps] new draft available: draft-fairhurst-taps-transports-00 Hi Folks- Gorry & Brian have published an annotated framework for TAPS doc 1 on transport services here . We'll discuss whether to adopt it as a working group doc in Honolulu. I encourage you to send comments and offers to contribute text before then. --aaron --f46d044288962666450506f3e0c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi= ,

=C2=A0=

Thanks a lot for a go= od start.

=C2= =A0

I notice th= at MPTCP is quoted as a transport protocol but that CMT-SCTP isn=E2=80=99t.= I assume that this

is motivated by the fact that the taps work very clearly draws the li= ne in between

= features that have made it through IETF standardisation (even as informatio= nal) =C2=A0and features that have not and

= only are specified in =E2=80=9Cseemingly dormant= =E2=80=9D individual drafts. Correct ?

=C2=A0

In terms of SCTP and the transport service that it provides= , then I wonder if the priority feature that it embeds is something<= /p>

that afford special me= ntioning in this document. I.e., by usage of streams and priority settings = on streams then it is possible

to enforce that messages written on particular stream is ab= le to outrace messages written on other non-prioritized streams at least fr= om a

sender tr= ansmittal perspective.

The feature is actually started to be deployed for some application= s in present signalling networks but it is only partially standardized in t= hat the

tsvwg d= ocuments (ndata, secondary SCTP-pr) that specifies the feature are not fini= shed yet. Still the features are described in standards track documents.

=C2=A0

=

Thanks

=C2=A0

BR, Karen

=C2=A0

From: Taps [mailto:taps-bo= unces@ietf.org] On Behalf Of Aaron Falk
Sent: Tuesday,= October 28, 2014 5:04 PM
To: ta= ps@ietf.org
Cc: Gorry Fairhurst; Brian Trammell
Subject= : [Taps] new draft available: draft-fairhurst-taps-transports-00=

=C2=A0

Hi Folks-

=C2=A0

Gorry & Brian have published an annotated framework for TAP= S doc 1 on transport services here.=C2=A0 We'll discuss whether to a= dopt it as a working group doc in Honolulu.=C2=A0 I encourage you to send c= omments and offers to contribute text before then. =C2=A0

=C2=A0

--aaron

=
--f46d044288962666450506f3e0c6-- From nobody Mon Nov 3 06:10:18 2014 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 491FD1A0354 for ; Mon, 3 Nov 2014 06:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 4Eqrf4bCeKI5 for ; Mon, 3 Nov 2014 06:10:15 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id E44F21A033B for ; Mon, 3 Nov 2014 06:10:14 -0800 (PST) Received: from [IPv6:2001:67c:10ec:52c8:8000::5a9] (unknown [IPv6:2001:67c:10ec:52c8:8000::5a9]) by trammell.ch (Postfix) with ESMTPSA id E9E381A02C0; Mon, 3 Nov 2014 15:10:12 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Brian Trammell In-Reply-To: Date: Mon, 3 Nov 2014 15:10:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <07F9252C-C6D0-4D73-9F32-366C57C7A943@trammell.ch> References: To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/CMHGX0IrqBgvLNg_Z8chudljzjE Cc: Aaron Falk , Gorry Fairhurst , taps@ietf.org Subject: Re: [Taps] new draft available: draft-fairhurst-taps-transports-00 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, 03 Nov 2014 14:10:17 -0000 > On 03 Nov 2014, at 13:56, Karen Elisabeth Egede Nielsen = wrote: >=20 > Hi, > =20 > Thanks a lot for a good start. > =20 > I notice that MPTCP is quoted as a transport protocol but that = CMT-SCTP isn=E2=80=99t. I assume that this=20 > is motivated by the fact that the taps work very clearly draws the = line in between=20 > features that have made it through IETF standardisation (even as = informational) and features that have not and > only are specified in =E2=80=9Cseemingly dormant=E2=80=9D individual = drafts. Correct ? This is the intention (in keeping with item 1 on the charter). However, = _this_ revision is very -00 and as such has only the most obvious things = we could think of just before the deadline. My personal opinion is that = if we can illustrate an interesting transport service using a proposed = extension to an IETF protocol, then by all means let=E2=80=99s do so.=20 > In terms of SCTP and the transport service that it provides, then I = wonder if the priority feature that it embeds is something > that afford special mentioning in this document. I.e., by usage of = streams and priority settings on streams then it is possible > to enforce that messages written on particular stream is able to = outrace messages written on other non-prioritized streams at least from = a=20 > sender transmittal perspective. > The feature is actually started to be deployed for some applications = in present signalling networks but it is only partially standardized in = that the > tsvwg documents (ndata, secondary SCTP-pr) that specifies the feature = are not finished yet. Still the features are described in standards = track documents. This definitely seems to be a transport service of interest.=20 Cheers, Brian > From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Aaron Falk > Sent: Tuesday, October 28, 2014 5:04 PM > To: taps@ietf.org > Cc: Gorry Fairhurst; Brian Trammell > Subject: [Taps] new draft available: = draft-fairhurst-taps-transports-00 > =20 > Hi Folks- > =20 > Gorry & Brian have published an annotated framework for TAPS doc 1 on = transport services here. We'll discuss whether to adopt it as a working = group doc in Honolulu. I encourage you to send comments and offers to = contribute text before then. =20 > =20 > --aaron From nobody Mon Nov 3 10:02:43 2014 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 AB9C11A6F58 for ; Mon, 3 Nov 2014 10:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 ZaceBIIcMBed for ; Mon, 3 Nov 2014 10:02:39 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E511A6F57 for ; Mon, 3 Nov 2014 10:02:39 -0800 (PST) X-AuditID: 12074424-f79346d000004923-47-5457c33d8f34 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id E7.C1.18723.E33C7545; Mon, 3 Nov 2014 13:02:38 -0500 (EST) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id sA3I2at9030039; Mon, 3 Nov 2014 13:02:37 -0500 Received: from OC11EXEDGE4.EXCHANGE.MIT.EDU (oc11exedge4.exchange.mit.edu [18.9.3.27]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id sA3I2Uve012670; Mon, 3 Nov 2014 13:02:35 -0500 Received: from W92EXHUB14.exchange.mit.edu (18.7.73.25) by OC11EXEDGE4.EXCHANGE.MIT.EDU (18.9.3.27) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Nov 2014 13:01:54 -0500 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.121]) by W92EXHUB14.exchange.mit.edu ([18.7.73.25]) with mapi id 14.03.0158.001; Mon, 3 Nov 2014 13:02:31 -0500 From: Marie-Jose Montpetit To: Brian Trammell Thread-Topic: [Taps] new draft available: draft-fairhurst-taps-transports-00 Thread-Index: AQHP8snMWJ76k5SlV02iYtjeTH4d1JxPOWoAgAAUlwCAAEDpgA== Date: Mon, 3 Nov 2014 18:02:31 +0000 Message-ID: <12F1CF3F-F015-4785-884E-DFFA547E985D@mit.edu> References: <07F9252C-C6D0-4D73-9F32-366C57C7A943@trammell.ch> In-Reply-To: <07F9252C-C6D0-4D73-9F32-366C57C7A943@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [50.241.90.249] Content-Type: multipart/signed; boundary="Apple-Mail=_4F73EB85-206F-4AAA-AA17-BDA05E68D795"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA01TaUgUYRjum52dHcWxcTL30/SHixJaa0mKS4eVWCydYkthRDm5k7u0O8rO Kq6QGLodHiXm0a6FVmahYinY5Q9xtCj9kRalVlprdmmKkVBpZDOO17/n/Z6LF94Pl1FNmB9u ZK2MhaVNKswdpRTRq9XR7Yd06yeeYpoz02VyzeiZCqBpzB3HNLzdgWreHdkm1xb8/IpoHzoH FNrq6j+Ilv8Srx1udaBx8sPum/WMyZjOWNZFJ7obClq6sdSh0IznU5OKbPAxOA+44ZCMgP21 OTIJ+8DuwTtYHnDHKbICgY7Sz0AaWgFsPmeXS8MTABte8XPDPQDt0yOoNNQCeOHSN0QMw8i1 8JP9+mywNxkM80+/UIhYRnYA+LowQsQryN1w7Oa4oMcFzR7YUL9XksfArqFSIGKUDIL2x/xs JEFuhDkvJxVS10MAJ2YKUZFwI7fClu9/Zg1AWOJXZz0idSnhm+FKRFrOG7p6urD5Rf89cs3h QNg3kotK+hIA3/3dL5V5wWeOYbQIQOeSKOcSmXOJTHpfA2uujcokHAJb82/NvUfC0cc/gIQ3 wctTbZiEA2FJvktRBfBaEKA3Z6rNtNHEMUlqLolmWcaijgozG61hjD6tCcyeQ2zQA5DDq3hA 4kDlQcDmgzpKTqdzNjMPfHFEtZLIbDykozyPp+htBpozHLOkmRiOB0FC19Ddum7gh7IpLKPy JirrBB2hp22ZjCVlXrYKR1VKoum3p44ik2krc5JhUhnLPOuP4ypILOcFo5eFSWYyThhN1kUa wd14AHEPIXyfqCG4VNrMGZMlvhME+imJkjaBIEXCkMYueOdPfQQohbVWEP6i3UP4CAvuESEY EYK35+nEYCu9SPllAzQquyYyKe5BcfggddGqCzmWcLvqSlFUY1hvTjwZe67/Rm6L3tbesXby R6PjrZotR9o2LIvpC/BJPO979L2rl3K19w138UPTTiOVkeX6MNOXeXZX8dVTO8bLnHfy2PgD O0e3lE/f75YnZinl9gFNz+WajpP6sYne67Yb9oToSKsK5Qx0eKjMwtH/AS6p35bFAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/taps/fSBFUktUMMUpi2tPFd8DYaa2HRk Cc: Karen Elisabeth Egede Nielsen , Aaron Falk , Gorry Fairhurst , "taps@ietf.org" Subject: Re: [Taps] new draft available: draft-fairhurst-taps-transports-00 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, 03 Nov 2014 18:02:41 -0000 --Apple-Mail=_4F73EB85-206F-4AAA-AA17-BDA05E68D795 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I thin kwe are going to face a lot of "extensions". Maybe a secondary = goal could be to define a standard way to access both IETF and = "extension" transports? /mjm Marie-Jose Montpetit, Ph.D. mariejo@mit.edu @SocialTVMIT > On Nov 3, 2014, at 9:10 AM, Brian Trammell wrote: >=20 >=20 >> On 03 Nov 2014, at 13:56, Karen Elisabeth Egede Nielsen = wrote: >>=20 >> Hi, >>=20 >> Thanks a lot for a good start. >>=20 >> I notice that MPTCP is quoted as a transport protocol but that = CMT-SCTP isn=E2=80=99t. I assume that this=20 >> is motivated by the fact that the taps work very clearly draws the = line in between=20 >> features that have made it through IETF standardisation (even as = informational) and features that have not and >> only are specified in =E2=80=9Cseemingly dormant=E2=80=9D individual = drafts. Correct ? >=20 > This is the intention (in keeping with item 1 on the charter). = However, _this_ revision is very -00 and as such has only the most = obvious things we could think of just before the deadline. My personal = opinion is that if we can illustrate an interesting transport service = using a proposed extension to an IETF protocol, then by all means = let=E2=80=99s do so.=20 >=20 >> In terms of SCTP and the transport service that it provides, then I = wonder if the priority feature that it embeds is something >> that afford special mentioning in this document. I.e., by usage of = streams and priority settings on streams then it is possible >> to enforce that messages written on particular stream is able to = outrace messages written on other non-prioritized streams at least from = a=20 >> sender transmittal perspective. >> The feature is actually started to be deployed for some applications = in present signalling networks but it is only partially standardized in = that the >> tsvwg documents (ndata, secondary SCTP-pr) that specifies the feature = are not finished yet. Still the features are described in standards = track documents. >=20 > This definitely seems to be a transport service of interest.=20 >=20 > Cheers, >=20 > Brian >=20 >> From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Aaron Falk >> Sent: Tuesday, October 28, 2014 5:04 PM >> To: taps@ietf.org >> Cc: Gorry Fairhurst; Brian Trammell >> Subject: [Taps] new draft available: = draft-fairhurst-taps-transports-00 >>=20 >> Hi Folks- >>=20 >> Gorry & Brian have published an annotated framework for TAPS doc 1 on = transport services here. We'll discuss whether to adopt it as a working = group doc in Honolulu. I encourage you to send comments and offers to = contribute text before then. =20 >>=20 >> --aaron >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_4F73EB85-206F-4AAA-AA17-BDA05E68D795 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDRDCCA0Aw ggKpoAMCAQICEQDvxXGV9K8f4AQSxWSxJJPrMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0 ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQLEwxDbGllbnQgQ0EgdjEwHhcNMTQwNzAyMTM1MzUyWhcN MTUwNzMwMTM1MzUyWjCBqzELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAs BgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENs aWVudCBDQSB2MTEdMBsGA1UEAxMUTWFyaWUtSm9zZSBNb250cGV0aXQxHjAcBgkqhkiG9w0BCQEW D21hcmllam9ATUlULkVEVTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvMWfBmhCuS6ol1Q/ KWrhtk0nMP3xU6T6R7Q7y/VnbE6BtYxFaRQ09PzHiv9B58UDhbhNN5y59BVPWWfevOImFitx4PY0 c6wMYGxC6aR0l9VySQ0VNavkRRKujyPxxjz+GRb64mAWzP0xqutz6SaZ2Fi0lxgccRheH/d0OLTg agUCAwEAAaOBoTCBnjAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwCwYDVR0PBAQDAgXgMB0GA1UdDgQWBBRCoWStx3OeBP0pszhPjQgj z28cdDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY2EubWl0LmVkdS9jYS9taXRjbGllbnQuY3Js MA0GCSqGSIb3DQEBBQUAA4GBAHdNroykei2WKB4gO19mPUIyPMBFZrw5f87upM40csBB5HBBtZO4 op6JqoMxs93UrS+KO2+UK8c4zL/lRBRfbmQ7/r+gbJn0YqMb93eEHXR2u07xiRxHrI8oaC9RGhzc NMjbuAPbxlfY55CEPA2LLT/3nibZfvy+UPV/Xdkbg71gMYICtTCCArECAQEwgYEwbDELMAkGA1UE BhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5z dGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/FcZX0rx/gBBLF ZLEkk+swCQYFKw4DAhoFAKCCAYkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTQxMTAzMTgwMjMxWjAjBgkqhkiG9w0BCQQxFgQUdJJz/34tI/tHDpzGsxrZkn9hQYww gZIGCSsGAQQBgjcQBDGBhDCBgTBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UE CxMMQ2xpZW50IENBIHYxAhEA78VxlfSvH+AEEsVksSST6zCBlAYLKoZIhvcNAQkQAgsxgYSggYEw bDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1 c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/F cZX0rx/gBBLFZLEkk+swDQYJKoZIhvcNAQEBBQAEgYBlnsnbk7E9WVpafHy4XoIpms5P7ze9/jd+ 8bmc19GwSKnWJoGAUm50OARpLwoMfHCVVdD1uOv5SHLawOauNETWm0VuYSTQMuruPxGffMONqwsz l7loKSWVc95lu6BvUShmiaDxA24uoI+2nWqGjKSX2pDsgBqZ78q12lp2zTvaLAAAAAAAAA== --Apple-Mail=_4F73EB85-206F-4AAA-AA17-BDA05E68D795-- From nobody Mon Nov 3 10:21:13 2014 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 0B9051A6FB0 for ; Mon, 3 Nov 2014 10:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 SWsou7u9LSwW for ; Mon, 3 Nov 2014 10:21:04 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 71ECE1A0451 for ; Mon, 3 Nov 2014 10:21:04 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 33) id 66B882B44C8; Mon, 3 Nov 2014 18:21:03 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by spey.erg.abdn.ac.uk with HTTP; Mon, 3 Nov 2014 18:21:03 -0000 Message-ID: <957a62e7af8bb11fe9aefdfed7c07197.squirrel@spey.erg.abdn.ac.uk> In-Reply-To: <12F1CF3F-F015-4785-884E-DFFA547E985D@mit.edu> References: <07F9252C-C6D0-4D73-9F32-366C57C7A943@trammell.ch> <12F1CF3F-F015-4785-884E-DFFA547E985D@mit.edu> Date: Mon, 3 Nov 2014 18:21:03 -0000 From: gorry@erg.abdn.ac.uk To: "Marie-Jose Montpetit" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/TEMR1MlUd0q5pndt8ASexY3wiJo Cc: Karen Elisabeth Egede Nielsen , Brian Trammell , "taps@ietf.org" , Gorry Fairhurst , Aaron Falk Subject: Re: [Taps] new draft available: draft-fairhurst-taps-transports-00 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, 03 Nov 2014 18:21:07 -0000 See a few comments in-line on various things. > I thin kwe are going to face a lot of "extensions". Maybe a secondary goal > could be to define a standard way to access both IETF and "extension" > transports? > I think this may well be the case in the end, although there is still some way to go before we reach that. To me, the most important next step is we recognise common terminology and therefore can make progress getting the basic language correct. +1 with Brian, if we agree the basics we could then consider other protocols around this - there could be many that potentially could be considered. Gorry > /mjm > Marie-Jose Montpetit, Ph.D. > mariejo@mit.edu > @SocialTVMIT > >> On Nov 3, 2014, at 9:10 AM, Brian Trammell wrote: >> >> >>> On 03 Nov 2014, at 13:56, Karen Elisabeth Egede Nielsen >>> wrote: >>> >>> Hi, >>> >>> Thanks a lot for a good start. >>> >>> I notice that MPTCP is quoted as a transport protocol but that CMT-SCTP >>> isn’t. I assume that this >>> is motivated by the fact that the taps work very clearly draws the line >>> in between >>> features that have made it through IETF standardisation (even as >>> informational) and features that have not and >>> only are specified in “seemingly dormant” individual drafts. >>> Correct ? >> >> This is the intention (in keeping with item 1 on the charter). However, >> _this_ revision is very -00 and as such has only the most obvious things >> we could think of just before the deadline. My personal opinion is that >> if we can illustrate an interesting transport service using a proposed >> extension to an IETF protocol, then by all means let’s do so. >> >>> In terms of SCTP and the transport service that it provides, then I >>> wonder if the priority feature that it embeds is something >>> that afford special mentioning in this document. I.e., by usage of >>> streams and priority settings on streams then it is possible >>> to enforce that messages written on particular stream is able to >>> outrace messages written on other non-prioritized streams at least from >>> a >>> sender transmittal perspective. >>> The feature is actually started to be deployed for some applications in >>> present signalling networks but it is only partially standardized in >>> that the >>> tsvwg documents (ndata, secondary SCTP-pr) that specifies the feature >>> are not finished yet. Still the features are described in standards >>> track documents. >> >> This definitely seems to be a transport service of interest. >> >> Cheers, >> >> Brian >> >>> From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Aaron Falk >>> Sent: Tuesday, October 28, 2014 5:04 PM >>> To: taps@ietf.org >>> Cc: Gorry Fairhurst; Brian Trammell >>> Subject: [Taps] new draft available: draft-fairhurst-taps-transports-00 >>> >>> Hi Folks- >>> >>> Gorry & Brian have published an annotated framework for TAPS doc 1 on >>> transport services here. We'll discuss whether to adopt it as a >>> working group doc in Honolulu. I encourage you to send comments and >>> offers to contribute text before then. >>> >>> --aaron >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > From nobody Mon Nov 3 10:50:08 2014 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 D47C11A701D for ; Mon, 3 Nov 2014 10:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 Hevhq1KD26aw for ; Mon, 3 Nov 2014 10:50:02 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869CF1A702B for ; Mon, 3 Nov 2014 10:50:02 -0800 (PST) Received: from [192.168.1.104] (p508F357F.dip0.t-ipconnect.de [80.143.53.127]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 445DC1C1629CD; Mon, 3 Nov 2014 19:49:59 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <07F9252C-C6D0-4D73-9F32-366C57C7A943@trammell.ch> Date: Mon, 3 Nov 2014 19:49:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <07F9252C-C6D0-4D73-9F32-366C57C7A943@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/Aj30DXsDWoNxbu-_xmCpgbEA30Y Cc: Karen Elisabeth Egede Nielsen , Aaron Falk , Gorry Fairhurst , taps@ietf.org Subject: Re: [Taps] new draft available: draft-fairhurst-taps-transports-00 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, 03 Nov 2014 18:50:05 -0000 On 03 Nov 2014, at 15:10, Brian Trammell wrote: >=20 >> On 03 Nov 2014, at 13:56, Karen Elisabeth Egede Nielsen = wrote: >>=20 >> Hi, >>=20 >> Thanks a lot for a good start. >>=20 >> I notice that MPTCP is quoted as a transport protocol but that = CMT-SCTP isn=92t. I assume that this=20 >> is motivated by the fact that the taps work very clearly draws the = line in between=20 >> features that have made it through IETF standardisation (even as = informational) and features that have not and >> only are specified in =93seemingly dormant=94 individual drafts. = Correct ? >=20 > This is the intention (in keeping with item 1 on the charter). = However, _this_ revision is very -00 and as such has only the most = obvious things we could think of just before the deadline. My personal = opinion is that if we can=20 The main reason which the SCTP CMT ID is still very -00 is based on the = limited chances that it will progress to an RFC. This might change in the = future, but the last time I tried it was hard to find people willing to implement = it. It is currently implemented in FreeBSD and two simulation models (NS-2 = and INET for OMNeT++), and most of the people involved are coauthors. So it is hard to get = consumers of a potential RFC. Maybe someone implementing it in Linux and Solaris... Best regards Michael > illustrate an interesting transport service using a proposed extension = to an IETF protocol, then by all means let=92s do so.=20 >=20 >> In terms of SCTP and the transport service that it provides, then I = wonder if the priority feature that it embeds is something >> that afford special mentioning in this document. I.e., by usage of = streams and priority settings on streams then it is possible >> to enforce that messages written on particular stream is able to = outrace messages written on other non-prioritized streams at least from = a=20 >> sender transmittal perspective. >> The feature is actually started to be deployed for some applications = in present signalling networks but it is only partially standardized in = that the >> tsvwg documents (ndata, secondary SCTP-pr) that specifies the feature = are not finished yet. Still the features are described in standards = track documents. >=20 > This definitely seems to be a transport service of interest.=20 >=20 > Cheers, >=20 > Brian >=20 >> From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Aaron Falk >> Sent: Tuesday, October 28, 2014 5:04 PM >> To: taps@ietf.org >> Cc: Gorry Fairhurst; Brian Trammell >> Subject: [Taps] new draft available: = draft-fairhurst-taps-transports-00 >>=20 >> Hi Folks- >>=20 >> Gorry & Brian have published an annotated framework for TAPS doc 1 on = transport services here. We'll discuss whether to adopt it as a working = group doc in Honolulu. I encourage you to send comments and offers to = contribute text before then. =20 >>=20 >> --aaron >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Mon Nov 3 14:27:01 2014 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 65AF41A8782 for ; Mon, 3 Nov 2014 14:26:59 -0800 (PST) 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 bBZZP23IGLDW for ; Mon, 3 Nov 2014 14:26:58 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392C71A1A34 for ; Mon, 3 Nov 2014 14:26:58 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hi2so7758016wib.1 for ; Mon, 03 Nov 2014 14:26:56 -0800 (PST) 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=w8ficwdoLrdJSZtN1SDeXAcjn/pcjhiSdiEwqaCU6fI=; b=vqcNyyZFmZJ4YPiZsKmF91/ILRs4/wb3Hy87EOswF0I0WyiE3sDnqAWenQFEoCrSW3 Pq2ZkPOXiLya5folaNAgm+Gh26ld+7+ji9NGLRBPbz8PmeBZ22A7hLdvmmDbz3NfQ/Y5 I08A9ha5COP5TjVHD27S6pDgDsCIXGfUcFwKo6hFbbc70U91AYsVl7S1PGLs+Z6lmt/F hDi090jAcCu+EhTMjk9AVkndqkjMsg8KbeS0L0pl95foEM1tA4XWHzAVyzKQYPH/NwOi IBD5Gwf9I2eWdfgpF/hQQomw/H2DUJQDKvH+YbzCjWN9HBucHEQa3Dg79vpVE0CaCyUh 1kJw== MIME-Version: 1.0 X-Received: by 10.180.90.197 with SMTP id by5mr19638429wib.50.1415053616805; Mon, 03 Nov 2014 14:26:56 -0800 (PST) Received: by 10.216.67.137 with HTTP; Mon, 3 Nov 2014 14:26:56 -0800 (PST) Date: Mon, 3 Nov 2014 17:26:56 -0500 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=f46d0438eb6d2afc180506fbd8ac Archived-At: http://mailarchive.ietf.org/arch/msg/taps/jligZK-9GplfEyw5zqs2R9d0w64 Subject: [Taps] meeting time change 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, 03 Nov 2014 22:26:59 -0000 --f46d0438eb6d2afc180506fbd8ac Content-Type: text/plain; charset=UTF-8 Please note that the TAPS meeting time has been changed to Tuesday, afternoon session I (1300-1500 HST). --aaron --f46d0438eb6d2afc180506fbd8ac Content-Type: text/html; charset=UTF-8
Please note that the TAPS meeting time has been changed to Tuesday, afternoon session I (1300-1500 HST).

--aaron
--f46d0438eb6d2afc180506fbd8ac-- From nobody Mon Nov 3 14:34:15 2014 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 14FB71A878A for ; Mon, 3 Nov 2014 14:34:14 -0800 (PST) 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 2YHVCXnMZcLW for ; Mon, 3 Nov 2014 14:34:12 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0D61A0470 for ; Mon, 3 Nov 2014 14:34:12 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id l18so12107353wgh.24 for ; Mon, 03 Nov 2014 14:34:10 -0800 (PST) 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=1G2gs66WGwmX/QOR2pRSnRJE1XrgkGiTuTMkBCNVF3s=; b=XFcmsrb3bxW8m5r1W92EDZoDn0+ZyWKHO1S/aaJ2cBbETMhPlMiHw/xMJOjG9i+Fv9 +FcZawgNc7hUPNOed1p8lBeJoeaj2SMDFpQKPcvO2XX9yEi68hoUtqdv5zW5DYzd9RV+ Y4t98rPBv8QzrhrmpaAOKbdtuq8Fi+iJiADA5jHhW6FQqyCqHiEtaA9/8cR0hIwd1z+r XLaDwOZebk5zZj3GbwUJGA76Y4z21+TChUW9Tq5IHLXLfseuOn0QZyKFLGWop1VxY7O1 X3Cb56nIfz/z4zyydZP7hiWUNaSxhAiVCPPzTfNQ2ZuUDDNrybmAFdT3xpTaInF+BQR9 QsOA== MIME-Version: 1.0 X-Received: by 10.180.106.103 with SMTP id gt7mr6666176wib.0.1415054050871; Mon, 03 Nov 2014 14:34:10 -0800 (PST) Received: by 10.216.67.137 with HTTP; Mon, 3 Nov 2014 14:34:10 -0800 (PST) Date: Mon, 3 Nov 2014 17:34:10 -0500 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=f46d04428f440a4ea50506fbf22d Archived-At: http://mailarchive.ietf.org/arch/msg/taps/Q36a5gwJvj-VUqdbNKmMxiBQWPA Subject: [Taps] draft agenda for IETF-91 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, 03 Nov 2014 22:34:14 -0000 --f46d04428f440a4ea50506fbf22d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I received no comments regarding agenda content so here is the agenda that I'm posting. --aaron Transport Services (TAPS) 1300-1500 HST Tuesday Afternoon Session I AGENDA =3D=3D=3D=3D=3D=3D=3D 0. Agenda bashing 1. Terminology Review (Trammell, K=C3=BChlewind, Fairhurst) - 30 min 2. Discussion of draft-fairhurst-taps-transports-00 - 20 min 3. Hum: Adopt draft-fairhurst-taps-transports-00 as wg document? - 10 min --f46d04428f440a4ea50506fbf22d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I received no comments regarding agenda content so he= re is the agenda that I'm posting.

--aaron

Transport Services (TAPS)
1300-15= 00 HST=C2=A0 Tuesday Afternoon Sessi= on I

AGENDA
=3D=3D=3D=3D= =3D=3D=3D
0. Agenda bashing
1. Terminology Review (Tram= mell,=C2=A0K=C3=BChlewind, Fairhurst) - 30 min
2. Disc= ussion of=C2=A0draft-fairhurst-taps-transports-00=C2=A0- 20 min
3. Hum: Adopt draft-fairhurst-taps-transports-00 as wg document? - 10 min=
--f46d04428f440a4ea50506fbf22d-- From nobody Tue Nov 4 05:14:15 2014 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 B6E7F1A1B06 for ; Tue, 4 Nov 2014 05:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 LRWDjHERfLuh for ; Tue, 4 Nov 2014 05:14:11 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3351A00AD for ; Tue, 4 Nov 2014 05:14:11 -0800 (PST) Received: from [IPv6:2001:470:26:9c2:14b7:f4d1:15e6:6043] (unknown [IPv6:2001:470:26:9c2:14b7:f4d1:15e6:6043]) by trammell.ch (Postfix) with ESMTPSA id 4F1CE1A02C0 for ; Tue, 4 Nov 2014 14:14:10 +0100 (CET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 4 Nov 2014 14:14:09 +0100 To: taps WG Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/qEY8PvnDYfhPc9H3AABDBnaDVRs Subject: [Taps] terminology for draft-fairhurst-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: Tue, 04 Nov 2014 13:14:14 -0000 Greetings, all, As promised, here's an initial suggestion for terminology in = draft-fairhurst-taps-transports, compatible with but elaborating on the = minimal terminology in the charter, which would we would propose applies = to all TAPS work derived from this document: Transport Service:=20 An end-to-end facility provided by the transport layer that impacts the = design, operation, or deployment of the application using it. Example = Transport Services include reliable delivery of data, ordered delivery = of data, confidentiality of data with respect to in-path devices, or = latency guarantees for data transport.=20 Transport Service Composition:=20 A set of Transport Services taken together to meet the requirements of = an application for a given end-to-end interaction. Note that some = potential sets of Transport Services given transport service may = preclude the simultaneous use of other transport services for a given = end-to-end interaction (e.g. "reliable delivery" and "time-dependent = expiry of unacknowledged messages" as per SCTP-PR are mutually = exclusive). An example of a Transport Service Composition would be that = provided by the BSD SOCK_STREAM socket type: reliable, ordered, = non-boundary-perserving, stream-oriented transport, with limited out of = band capability.=20 Transport Instance:=20 A Transport Instance is an arrangement of transport protocols, = potentially encapsulated, and configurations thereof that implement a = Transport Service Composition. A given Transport Service Composition may = be implemented by multiple Instances (e.g., SOCK_STREAM can be = implemented atop TCP, SCTP, or SCTP over UDP).=20 Application:=20 In this and subsequent documents, an Application is defined as an entity = that uses the transport layer to interact with a remote Application = according to some set of requirements which can be met by Transport = Services. Here I'm pointedly leaving "transport protocol" undefined, mainly so as = to sidestep marginally productive conversations about how many transport = protools SCTP over DTLS over UDP is. The exact implementation of a = Transport Service Composition would appear to be a matter for our third = deliverable anyway. :) It's not perfect but it's a start. Thoughts? Cheers, Brian From nobody Tue Nov 4 05:31:09 2014 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 978151A1B06 for ; Tue, 4 Nov 2014 05:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 z5_d9w8zl7g9 for ; Tue, 4 Nov 2014 05:31:05 -0800 (PST) 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 7B1501A1B4E for ; Tue, 4 Nov 2014 05:31:03 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XleCL-0004Ov-C7; Tue, 04 Nov 2014 14:31:01 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1XleCK-0000Av-OU; Tue, 04 Nov 2014 14:31:01 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: Date: Tue, 4 Nov 2014 14:31:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Trammell X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 7 sum msgs/h 3 total rcpts 22022 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.2, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.16, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: BD065DECE7A9B7D0B59F5A672D5AD7947CD79919 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -51 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 6648 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/QM9bR4edWtJSfpVgsSGeQr6oWMo Cc: taps WG Subject: Re: [Taps] terminology for draft-fairhurst-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: Tue, 04 Nov 2014 13:31:07 -0000 On 4. nov. 2014, at 14:14, Brian Trammell wrote: > Greetings, all, >=20 > As promised, here's an initial suggestion for terminology in = draft-fairhurst-taps-transports, compatible with but elaborating on the = minimal terminology in the charter, which would we would propose applies = to all TAPS work derived from this document: >=20 >=20 > Transport Service:=20 > An end-to-end facility provided by the transport layer that impacts = the design, operation, or deployment of the application using it. = Example Transport Services include reliable delivery of data, ordered = delivery of data, confidentiality of data with respect to in-path = devices, or latency guarantees for data transport.=20 >=20 >=20 > Transport Service Composition:=20 > A set of Transport Services taken together to meet the requirements of = an application for a given end-to-end interaction. Note that some = potential sets of Transport Services given transport service may = preclude the simultaneous use of other transport services for a given = end-to-end interaction (e.g. "reliable delivery" and "time-dependent = expiry of unacknowledged messages" as per SCTP-PR are mutually = exclusive). An example of a Transport Service Composition would be that = provided by the BSD SOCK_STREAM socket type: reliable, ordered, = non-boundary-perserving, stream-oriented transport, with limited out of = band capability.=20 >=20 >=20 > Transport Instance:=20 > A Transport Instance is an arrangement of transport protocols, = potentially encapsulated, and configurations thereof that implement a = Transport Service Composition. A given Transport Service Composition may = be implemented by multiple Instances (e.g., SOCK_STREAM can be = implemented atop TCP, SCTP, or SCTP over UDP).=20 >=20 >=20 > Application:=20 > In this and subsequent documents, an Application is defined as an = entity that uses the transport layer to interact with a remote = Application according to some set of requirements which can be met by = Transport Services. >=20 >=20 > Here I'm pointedly leaving "transport protocol" undefined, mainly so = as to sidestep marginally productive conversations about how many = transport protools SCTP over DTLS over UDP is. The exact implementation = of a Transport Service Composition would appear to be a matter for our = third deliverable anyway. :) >=20 > It's not perfect but it's a start. Thoughts? We can and will probably debate this to death, but before that happens = I'll say: I think this is a very good starting point, thanks! Cheers, Michael From nobody Tue Nov 4 05:32:09 2014 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 AE4351A1B0D for ; Tue, 4 Nov 2014 05:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 UGPNYQOp8OFE for ; Tue, 4 Nov 2014 05:32:05 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E9241A1B06 for ; Tue, 4 Nov 2014 05:32:05 -0800 (PST) X-AuditID: 1209190d-f79c06d000006f95-ad-5458d553e87f Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 1E.21.28565.355D8545; Tue, 4 Nov 2014 08:32:03 -0500 (EST) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id sA4DW3TR013914; Tue, 4 Nov 2014 08:32:03 -0500 Received: from oc11exedge1.exchange.mit.edu (oc11exedge1.exchange.mit.edu [18.9.3.17]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id sA4DW1cQ009510; Tue, 4 Nov 2014 08:32:02 -0500 Received: from OC11EXCAS20.exchange.mit.edu (18.9.1.45) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 4 Nov 2014 08:31:47 -0500 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.121]) by OC11EXCAS20.exchange.mit.edu ([18.9.1.45]) with mapi id 14.03.0158.001; Tue, 4 Nov 2014 08:32:01 -0500 From: Marie-Jose Montpetit To: Brian Trammell Thread-Topic: [Taps] terminology for draft-fairhurst-taps-transports Thread-Index: AQHP+DE8stEK7+F4RU2nBJGj3cmI15xQytyA Date: Tue, 4 Nov 2014 13:32:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [76.118.234.192] Content-Type: multipart/signed; boundary="Apple-Mail=_D5C1E127-C7B7-4581-82E8-DF02E1FAEB56"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMJsWRmVeSWpSXmKPExsUixG6noht8NSLE4Np7c4uNLe/YLO7EODB5 LFnyk8njyf6ZLAFMUVw2Kak5mWWpRfp2CVwZXy4uYS+4oVPxZMJhpgbGe+pdjJwcEgImEq1r TrBC2GISF+6tZ+ti5OIQEpjNJHH3zVR2CGc/o8TS1ldMEM4xIOfJfWYIZyujxJ7X3VCZVYwS a87cZwcZxiagI/G0dREziC0ioCrR3XgJLM4sIC0xaf1kJhBbWMBZYtXX/0DLOYBqXCQWzNKF KDeS6DswjQXEZhFQkbgyeRpYK6+AlcSBtavBbCEBO4lTR86A3c0pYC/x98QSsDgj0A/fT61h glglLnHryXwmiN9EJB5ePM0G8+e/XQ+hbCWJiXcusUHUT2GUeLm6HGKXoMTJmU9YJjBKzEIy ahaSsllIyiDi2hLLFr5mngX0DTPQ95MXMkKETSVeH/0IZVtLzPh1kA3CVpSY0v2QfQEjxypG 2ZTcKt3cxMyc4tRk3eLkxLy81CJdI73czBK91JTSTYyg+OaU5N3B+O6g0iFGAQ5GJR7elSIR IUKsiWXFlbmHGCU5mJREeQ/OAQrxJeWnVGYkFmfEF5XmpBYfYlQB2vVow+oLjFIsefl5qUoi vNtOA9XxpiRWVqUW5cOUSXOwKInzbvrBFyIkkJ5YkpqdmlqQWgSTleHgUJLgtbkC1ChYlJqe WpGWmVOCkGbi4DzEKMHBAzQ8AKSGt7ggMbc4Mx0if4pRUUqcVw0kIQCSyCjNg+uFpeVXjOJA bwnzloBU8QBTOlz3K6DBTECDLXrABpckIqSkGhinc56cWsy0PV2EeU+syZe1Qe0pue7Tjyzu tdyjM+Ufu1iKQH7OlilZMeYta6/taPltpOwu1rtJk+mEhqn+EkED6xNaTNmd+/zXhFq3VXOJ RnaXXZgX2nbjwUxry107Sky+WehsK+9uYvNlXZF3422N7XNvQ+2K1MMa9Sb5iw5v0kqefurA PyWW4oxEQy3mouJEAEG12/emAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/taps/_8Q3cs4DhIlwuvSwINAKNmD3Oko Cc: taps WG Subject: Re: [Taps] terminology for draft-fairhurst-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: Tue, 04 Nov 2014 13:32:07 -0000 --Apple-Mail=_D5C1E127-C7B7-4581-82E8-DF02E1FAEB56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If we agree that "transport protocol" is undefined then "Transport = Instance" should not use it? then: > A Transport Instance is an arrangement of transport protocols, = potentially encapsulated, and configurations thereof that implement a = Transport Service Composition Could be=20 > A Transport Instance defines an implementation of a Transport Service = Composition. (or something like that? Marie-Jose Montpetit, Ph.D. mariejo@mit.edu @SocialTVMIT > On Nov 4, 2014, at 8:14 AM, Brian Trammell wrote: >=20 > Greetings, all, >=20 > As promised, here's an initial suggestion for terminology in = draft-fairhurst-taps-transports, compatible with but elaborating on the = minimal terminology in the charter, which would we would propose applies = to all TAPS work derived from this document: >=20 >=20 > Transport Service:=20 > An end-to-end facility provided by the transport layer that impacts = the design, operation, or deployment of the application using it. = Example Transport Services include reliable delivery of data, ordered = delivery of data, confidentiality of data with respect to in-path = devices, or latency guarantees for data transport.=20 >=20 >=20 > Transport Service Composition:=20 > A set of Transport Services taken together to meet the requirements of = an application for a given end-to-end interaction. Note that some = potential sets of Transport Services given transport service may = preclude the simultaneous use of other transport services for a given = end-to-end interaction (e.g. "reliable delivery" and "time-dependent = expiry of unacknowledged messages" as per SCTP-PR are mutually = exclusive). An example of a Transport Service Composition would be that = provided by the BSD SOCK_STREAM socket type: reliable, ordered, = non-boundary-perserving, stream-oriented transport, with limited out of = band capability.=20 >=20 >=20 > Transport Instance:=20 > A Transport Instance is an arrangement of transport protocols, = potentially encapsulated, and configurations thereof that implement a = Transport Service Composition. A given Transport Service Composition may = be implemented by multiple Instances (e.g., SOCK_STREAM can be = implemented atop TCP, SCTP, or SCTP over UDP).=20 >=20 >=20 > Application:=20 > In this and subsequent documents, an Application is defined as an = entity that uses the transport layer to interact with a remote = Application according to some set of requirements which can be met by = Transport Services. >=20 >=20 > Here I'm pointedly leaving "transport protocol" undefined, mainly so = as to sidestep marginally productive conversations about how many = transport protools SCTP over DTLS over UDP is. The exact implementation = of a Transport Service Composition would appear to be a matter for our = third deliverable anyway. :) >=20 > It's not perfect but it's a start. Thoughts? >=20 > Cheers, >=20 > Brian >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_D5C1E127-C7B7-4581-82E8-DF02E1FAEB56 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDRDCCA0Aw ggKpoAMCAQICEQDvxXGV9K8f4AQSxWSxJJPrMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0 ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQLEwxDbGllbnQgQ0EgdjEwHhcNMTQwNzAyMTM1MzUyWhcN MTUwNzMwMTM1MzUyWjCBqzELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAs BgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENs aWVudCBDQSB2MTEdMBsGA1UEAxMUTWFyaWUtSm9zZSBNb250cGV0aXQxHjAcBgkqhkiG9w0BCQEW D21hcmllam9ATUlULkVEVTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvMWfBmhCuS6ol1Q/ KWrhtk0nMP3xU6T6R7Q7y/VnbE6BtYxFaRQ09PzHiv9B58UDhbhNN5y59BVPWWfevOImFitx4PY0 c6wMYGxC6aR0l9VySQ0VNavkRRKujyPxxjz+GRb64mAWzP0xqutz6SaZ2Fi0lxgccRheH/d0OLTg agUCAwEAAaOBoTCBnjAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwCwYDVR0PBAQDAgXgMB0GA1UdDgQWBBRCoWStx3OeBP0pszhPjQgj z28cdDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY2EubWl0LmVkdS9jYS9taXRjbGllbnQuY3Js MA0GCSqGSIb3DQEBBQUAA4GBAHdNroykei2WKB4gO19mPUIyPMBFZrw5f87upM40csBB5HBBtZO4 op6JqoMxs93UrS+KO2+UK8c4zL/lRBRfbmQ7/r+gbJn0YqMb93eEHXR2u07xiRxHrI8oaC9RGhzc NMjbuAPbxlfY55CEPA2LLT/3nibZfvy+UPV/Xdkbg71gMYICtTCCArECAQEwgYEwbDELMAkGA1UE BhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5z dGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/FcZX0rx/gBBLF ZLEkk+swCQYFKw4DAhoFAKCCAYkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTQxMTA0MTMzMjAxWjAjBgkqhkiG9w0BCQQxFgQU/tvN6NjxhAnidHIo3XmbBhP4jhIw gZIGCSsGAQQBgjcQBDGBhDCBgTBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UE CxMMQ2xpZW50IENBIHYxAhEA78VxlfSvH+AEEsVksSST6zCBlAYLKoZIhvcNAQkQAgsxgYSggYEw bDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1 c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/F cZX0rx/gBBLFZLEkk+swDQYJKoZIhvcNAQEBBQAEgYCunpmLWA80+oCYUuzS5JH/n8CFg4r+UJ/R Cvox9Qc2T2U9QrkkKH5cIRFJ8RfZtOfOmH2GWJVur2Vg9QqvcQoLoJZVdCVxeNXJtgrZpbz9o+QK mCZwIDJRV5aMHorZSrsWXVFFfEHrqMFlNxI+G3YIoc5qQFXdZLSUmcHzl5KZ9wAAAAAAAA== --Apple-Mail=_D5C1E127-C7B7-4581-82E8-DF02E1FAEB56-- From nobody Wed Nov 5 17:32:00 2014 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 113981A1A4E for ; Wed, 5 Nov 2014 17:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.496 X-Spam-Level: X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-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 nAzEKYsvGdzh for ; Wed, 5 Nov 2014 17:31:58 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026AF1A00F5 for ; Wed, 5 Nov 2014 17:31:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,322,1413270000"; d="p7s'?scan'208";a="165524043" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx11-out.netapp.com with ESMTP; 05 Nov 2014 17:31:57 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 5 Nov 2014 17:31:57 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::9047:8c6c:1d6e:4581%21]) with mapi id 15.00.0995.031; Wed, 5 Nov 2014 17:31:57 -0800 From: "Eggert, Lars" To: "taps@ietf.org" Thread-Topic: Socket Intents: Leveraging Application Awareness for Multi-Access Connectivity Thread-Index: AQHP+WFzQqXlR9lDiEi7TyYv8AqkLw== Date: Thu, 6 Nov 2014 01:31:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1990.1) x-originating-ip: [10.120.60.35] Content-Type: multipart/signed; boundary="Apple-Mail=_CC478C19-512E-4A86-B3CE-5A02C2271939"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/oR2Z9hyUWbZfHS94z7yhQq31Y-U Subject: [Taps] Socket Intents: Leveraging Application Awareness for Multi-Access Connectivity 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, 06 Nov 2014 01:31:59 -0000 --Apple-Mail=_CC478C19-512E-4A86-B3CE-5A02C2271939 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii CONEXT paper possibly of interest to the WG: Socket Intents: Leveraging Application Awareness for Multi-Access = Connectivity http://conferences.sigcomm.org/co-next/2013/program/p295.pdf --Apple-Mail=_CC478C19-512E-4A86-B3CE-5A02C2271939 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVzCCBhsw ggUDoAMCAQICAwhPlDANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMTIwNjA3MDk0N1oXDTE0MTIwNzA3MDY0MVowOjEYMBYGA1UEAwwPbGFyc0BuZXRhcHAu Y29tMR4wHAYJKoZIhvcNAQkBFg9sYXJzQG5ldGFwcC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDS6c3AH5ZSxTExtqA4RCkRMWmh84KVsbd85iNmeq2VHJv2Pc9TXG6aZz7r3Fjp qXV+VtHlHOzZ1ncpMV0ldJMgi8F45/5WpSMEg4sXnYdtheE3drgWeR816PEaydHqSnaMNutAC7Td ykkOFHXIsVg8IblDXhfiVQiZBZd+Wz6BpyMe59gr4Bpveft18uPQIXSxE95EsDTMyd/UDLVB+AkB gHhO0+XxauzCbNUnubyiYYGOzgQ9G8J3Ewgrr/nVR+CrBCYgIsBP3foo0/h1hE7dHyI0Gl341yR7 J0AHDQ0DPIQOQtscFuRlthksCZLCfVSK6Mh6hVCOMEjVJxrgeBU3AgMBAAGjggLVMIIC0TAJBgNV HRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0O BBYEFHIOXgd2Y3/7a+OqwJ2giDTpYULAMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGC MBoGA1UdEQQTMBGBD2xhcnNAbmV0YXBwLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGB tTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRm MIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEB GoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBW YWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5j ZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRw Oi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0 dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBAMCLv+Qk QYJxSendSLJPbFKuMkgm1PdAVoqxKAi8HmbirBTPhxh0vzhmZ/rneCHHlqY4p6r81+Se9HsqDsB6 DBQ/IbNgs7FQlCqOvCIwbn7VK+k/0eJAyOjIaUDPoD1ZaA1AkaFjJxvD2ZUZLBNq4AvOuP52j0Dm i0FBC6pbBfnz57wuB++3P4NBTfZABbdazHlxl/2z1RGQNGov3R6zwNZLbxU2o2ftEJ48j4unuHjP islFru3GRp4dbm5JLuHjUdDyXtMw6CdDvlmWQCcAgtEfqbGDp9bSSE9vbXbgf8n6iHoIA96HnTBW BTDERdixe8t0T9AyT4ks9eHFLPL+PbwwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJ TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk aWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0U jM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQ dcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O 2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB /wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5z dGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmww J6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1Bgsr BgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRm MA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY 1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A +hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0 t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHD RHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI /EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO 7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+UdMY u9jGfIpDLtUUGSgsg2zMGs5R4jGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwhPlDAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDExMDYwMTMxNTZaMCMGCSqGSIb3DQEJBDEWBBRLsub2Qjpj2SoVoKVLZ2F4 /mbO9TCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwhP lDCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCE+U MA0GCSqGSIb3DQEBAQUABIIBAL2duUzMvhUqUNGAoGcKyXX2TI7TLTVtg8fPpGrAhKEbydgZs7PT Ka8DyIhZR+PcR8igO6AyMnhIURYvQICAUicrvFbAa1gmroEkLUkPrfhZrzIShx7mJN13iwc0hjUM ol13n9WzIiMZDYvo8oHO6PKlPbCRhfRqeK1znXmCw0LLHLdMYAJ7RwxHYAe7lvd1dKFYBbBppFEH OD2yiBRNaIS2Y9ZJNKxUy7seic4K3f8NuWzj7ic2gFx4N+VicxKrBPIq5oumb3gvjfXzkoxLfhls 3IoElaNKEX+d3/NZkgQsB7IhUjMU4c5RimGl4qyXpeNWb8s4DfWdrJUEjc/1u9wAAAAAAAA= --Apple-Mail=_CC478C19-512E-4A86-B3CE-5A02C2271939-- From nobody Thu Nov 6 02:55:34 2014 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 739151A1ADE for ; Thu, 6 Nov 2014 02:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 Su_4vRfxQxMK for ; Thu, 6 Nov 2014 02:55:22 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7B66A1A1ADA for ; Thu, 6 Nov 2014 02:55:22 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 33) id 22B012B448B; Thu, 6 Nov 2014 10:55:20 +0000 (GMT) Received: from 2001:630:241:207:21f:5bff:fe38:7354 (SquirrelMail authenticated user gorry) by spey.erg.abdn.ac.uk with HTTP; Thu, 6 Nov 2014 10:55:20 -0000 Message-ID: Date: Thu, 6 Nov 2014 10:55:20 -0000 From: gorry@erg.abdn.ac.uk To: taps@ietf.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/OKfxe7mYrd8XSQORS8z2V7aIA9M Cc: gorry@erg.abdn.ac.uk Subject: [Taps] TAPS: Getting things named correctly... what is a "transport service" 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, 06 Nov 2014 10:55:31 -0000 So... One of the things I have been trying to understand over the last couple of weeks is what entities we have to name in TAPS, and how we give the entities names that seem to be understood by our community and preferably are common with other uses in the IETF. I came across one term that appears to be defined differently in the charter discussions, to how I would normally understand this. This email tries to explain this, if you think the same as me, please speak-up and say this, if you think another definition is better, please say why. I think the group just needs to decide at this stage, so that all actual RFCs that are made will be consistent. --- 1) Transport Service I see a "Transport Service" as an end-to-end service that has traditionally been mapped by transport people down to a "port/socket" (perhaps the "S" part of tsv). This appears consistent with other uses, I have come across. However, a service is usually composed of a number of "components" - I seem to recall these be called "service elements" in OSI. Examples are: reliability, multicast, confirmed delivery, congestion control, integrity, minimal latency, etc. (we could, and probably should make a list). Application | Transport Service(s) | | Service Service Component Component(s) Hence, I see a service as offered via an API to an App or upper-layer protocol. I see a service as having multiple components. This is not necessarily the usage in the final charter fro TAPS!! --- 2) When the charter says; "Four examples of Transport Services are reliable delivery, ordered delivery of data, content privacy to in-path devices, and minimal latency." - I think these could indeed be transport services, but I'd actually now suggest they could be better described as components/elements of a transport service. In my thinking, one could always build an entire service that was oriented at "minimal latency" - but equally one could conceive of this as a transport service component that could be combined with security, ordering, etc. (using the language above). --- 3) Transport Protocols Transport protocols are not a service, because many transport protocols can provide multiple services (again my own terminology). Indeed a single transport can negotiate to support multiple "features". A "feature" represents a choice of protocol mechanisms/parameters to instantiate a service (or one component of a service, e.g. use of ECN, optional integrity checks, etc). This term has been sued before, one of the older uses could be FTP feature negotiation. DCCP formally included "features" in its protocol design. Transport protocol | | Feature Feature(s) | Protocol mechanism(s) --- For anyone in fear this is endless, it is NOT going to be. Mirja will present slides to ask for confirmation of the hierarchy terms at the meeting next week, and after a discussion we plan to very quickly and publish a new revised ID with the WG-"approved" terms and use these hence-forth. Gorry From nobody Sat Nov 8 16:04:07 2014 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 2957F1A0012 for ; Sat, 8 Nov 2014 16:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.494 X-Spam-Level: X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 Lg6sTt8Msv6o for ; Sat, 8 Nov 2014 16:03:43 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 253911A0020 for ; Sat, 8 Nov 2014 16:03:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A14BCD9305; Sun, 9 Nov 2014 01:03:40 +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 Ztp0sRTwoO30; Sun, 9 Nov 2014 01:03:40 +0100 (MET) Received: from [192.168.1.111] (udp260005uds.hawaiiantel.net [72.253.224.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 4BB8DD9303; Sun, 9 Nov 2014 01:03:39 +0100 (MET) Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Priority: 3 (Normal) In-Reply-To: Date: Sat, 8 Nov 2014 14:03:32 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <20B068C9-D9D5-44F4-B83F-CE02543F324A@tik.ee.ethz.ch> References: To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/Ju7oqjQ2TBlk8foj6EOU9bh99G4 Cc: taps@ietf.org Subject: Re: [Taps] TAPS: Getting things named correctly... what is a "transport service" 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, 09 Nov 2014 00:04:02 -0000 Hi all, one more proposal that in not inline with the charter definition but = therefore more similar to Gorry=E2=80=99s proposal. Basically we could = even avoid to use the term =E2=80=9Atransport service=E2=80=98 as a = stand-alone term and always use =E2=80=9Atransport service = =E2=80=98 instead to make the meaning more explicit (see = below). Further in addition to Gorry=E2=80=99s definition below I still = think we also need to distinguish something that actually provides a = certain implementation based on a concrete protocol/stack etc. Therefore this proposal: transport service component: e.g reliability transport service composition: a set of components (without any = association to a certain framing protocol). transport protocol: an implementation (using a specific framing/header = format) providing different transport service service compositions transport protocol feature: an implementation of one certain transport = service component e.g. reliability using ACKs (instead of NACKs) transport service instance: one implementation of one service = composition utilizing one or multiple protocols with a selected set of = features (and a certain parameterization), e.g. a protocol stack (RTP = over UDP) or even something that switches between two protocols = depending on the network conditions Any comments? Mirja > Am 06.11.2014 um 00:55 schrieb gorry@erg.abdn.ac.uk: >=20 >=20 > So... >=20 > One of the things I have been trying to understand over the last = couple of > weeks is what entities we have to name in TAPS, and how we give the > entities names that seem to be understood by our community and = preferably > are common with other uses in the IETF. >=20 > I came across one term that appears to be defined differently in the > charter discussions, to how I would normally understand this. This = email > tries to explain this, if you think the same as me, please speak-up = and > say this, if you think another definition is better, please say why. >=20 > I think the group just needs to decide at this stage, so that all = actual > RFCs that are made will be consistent. >=20 > --- > 1) Transport Service >=20 > I see a "Transport Service" as an end-to-end service that has > traditionally been mapped by transport people down to a "port/socket" > (perhaps the "S" part of tsv). >=20 > This appears consistent with other uses, I have come across. However, = a > service is usually composed of a number of "components" - I seem to = recall > these be called "service elements" in OSI. Examples are: reliability, > multicast, confirmed delivery, congestion control, integrity, minimal > latency, etc. (we could, and probably should make a list). >=20 > Application > | > Transport Service(s) > | | > Service Service > Component Component(s) >=20 > Hence, I see a service as offered via an API to an App or upper-layer > protocol. I see a service as having multiple components. This is not > necessarily the usage in the final charter fro TAPS!! >=20 > --- >=20 > 2) When the charter says; "Four examples of Transport Services are = reliable > delivery, ordered delivery of data, content privacy to in-path > devices, and minimal latency." >=20 > - I think these could indeed be transport services, but I'd actually = now > suggest they could be better described as components/elements of a > transport service. In my thinking, one could always build an entire > service that was oriented at "minimal latency" - but equally one could > conceive of this as a transport service component that could be = combined > with security, ordering, etc. (using the language above). >=20 > --- >=20 > 3) Transport Protocols >=20 > Transport protocols are not a service, because many transport = protocols > can provide multiple services (again my own terminology). Indeed a = single > transport can negotiate to support multiple "features". A "feature" > represents a choice of protocol mechanisms/parameters to instantiate a > service (or one component of a service, e.g. use of ECN, optional > integrity > checks, etc). This term has been sued before, one of the older uses = could > be FTP feature negotiation. DCCP formally included "features" in its > protocol design. >=20 > Transport protocol > | | > Feature Feature(s) > | > Protocol > mechanism(s) >=20 > --- >=20 > For anyone in fear this is endless, it is NOT going to be. Mirja will > present slides to ask for confirmation of the hierarchy terms at the > meeting next week, and after a discussion we plan to very = quickly > and publish a new revised ID with the WG-"approved" terms and use = these > hence-forth. >=20 > Gorry >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Mon Nov 10 21:42:23 2014 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 A76AB1ACD85 for ; Mon, 10 Nov 2014 21:42:21 -0800 (PST) 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 Mh6rFinKcJ54 for ; Mon, 10 Nov 2014 21:42:20 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228411A890E for ; Mon, 10 Nov 2014 21:42:20 -0800 (PST) Received: by mail-yk0-f172.google.com with SMTP id 10so3043954ykt.3 for ; Mon, 10 Nov 2014 21:42:19 -0800 (PST) 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=3atuzMW/c/E4aq92Y8IZ2HSjtSPsMlgJgq8H/mgNZng=; b=XobN1KCocNMZgx+2vIU3Sm93wwhrm1lZbsGl13j00iFq544lkEOcM3zwsATXRF9Q17 l7iLAsCL4/rHD5uf2YkMnhjStnGKB3Ai1bj741fHqQFjDCgt21ggzOGalAL/KVjizWvg 9grEoGq0X1GPQWXspm0cwCbIY569FO3vtFuL9B1sd8flXJUaFJqDjBT1lM4IjWYyc+hZ B6xN24oNstDnojy9YMbGHQWy0sNlV/u1YCwYGbromIK0wV28Xe+5U+RDyAz/UPltYjcP pHEcHHizROWNpq8V6bNN9Fdr9fasMNo+CFD8UOj+KYzr2/pZe0eosV5wQ3S5oOosiulC S5GQ== MIME-Version: 1.0 X-Received: by 10.221.20.74 with SMTP id qn10mr4685645vcb.50.1415684539386; Mon, 10 Nov 2014 21:42:19 -0800 (PST) Received: by 10.52.8.134 with HTTP; Mon, 10 Nov 2014 21:42:19 -0800 (PST) Date: Tue, 11 Nov 2014 00:42:19 -0500 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=001a11339e6215941005078ebe58 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/oi3JOXKR23kJKhDMlsZnbpEWLz4 Subject: [Taps] IETF-91 TAPS slides posted 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, 11 Nov 2014 05:42:21 -0000 --001a11339e6215941005078ebe58 Content-Type: text/plain; charset=UTF-8 Slides and a minor agenda tweak have been posted at https://datatracker.ietf.org/meeting/91/materials.html#wg-taps Cheers, --aaron --001a11339e6215941005078ebe58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Slides and a minor agenda tweak have been posted at=C2=A0<= a href=3D"https://datatracker.ietf.org/meeting/91/materials.html#wg-taps">h= ttps://datatracker.ietf.org/meeting/91/materials.html#wg-taps

<= /div>
Cheers,

--aaron
--001a11339e6215941005078ebe58-- From nobody Tue Nov 11 02:26:51 2014 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 C4D0B1A891F for ; Tue, 11 Nov 2014 02:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 Oaz9SVJddAr8 for ; Tue, 11 Nov 2014 02:26:39 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1CD31A888D for ; Tue, 11 Nov 2014 02:26:38 -0800 (PST) Received: from [10.0.1.103] (unknown [212.201.121.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id E7FE01C104DFC; Tue, 11 Nov 2014 11:26:35 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Tue, 11 Nov 2014 11:26:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Aaron Falk X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/1520V1alzGTiaznA3VyypwziUFE Cc: Gorry Fairhurst , Brian Trammell , "taps@ietf.org" Subject: Re: [Taps] new draft available: draft-fairhurst-taps-transports-00 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, 11 Nov 2014 10:26:41 -0000 On 28 Oct 2014, at 17:04, Aaron Falk wrote: > Hi Folks- >=20 > Gorry & Brian have published an annotated framework for TAPS doc 1 on = transport services here. We'll discuss whether to adopt it as a working = group doc in Honolulu. I encourage you to send comments and offers to = contribute text before then. =20 Dear all, I read the document and think it is a good starting point. I would = support to adopt this as a WG item. I'm willing to contribute to the document, for example by = writing text regarding SCTP (currently section 3.2) and helping to improve the text = in other sections. Best regards Michael >=20 > --aaron > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Nov 11 02:27:34 2014 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 EA5B31A1B34 for ; Tue, 11 Nov 2014 02:27:30 -0800 (PST) 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 iPpSMALFs3ru for ; Tue, 11 Nov 2014 02:27:22 -0800 (PST) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458A91A888D for ; Tue, 11 Nov 2014 02:27:21 -0800 (PST) Received: by mail-yh0-f48.google.com with SMTP id v1so2423801yhn.21 for ; Tue, 11 Nov 2014 02:27:20 -0800 (PST) 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=rZiNW5kpKHvPez7OGLaBoaumYL1CcfmyDxf5Uu8kO6M=; b=HzTzYhxhHmXN7dhhBzvwXp4bBqeSA9BsxWFPNcTLVtz2NzsmuR54gb/0e4aHdlyAbQ F9NiPKhwBa0yeVpCXWj+VZRYhhlHzchseiALZFwI3bZza0l1dWE6ScwkQRt0VCDZaoNP sZ0Mw4kt1sK5GPCGwVxBZA1Ox0pD8hmahOfQuxnHD+vqCfWD2sTCDgGyiFZnDheqIu+M GlQEqEdzxCcJs30p8EJucCgshK3F6YIJP+9FqCmSsZNyrrj/ATY/OlvI6SKmd5N2u5ow 7G+4HuqO3Q/ocOja5PDEexSAxXu2Cc5WdRDgeH2pnHHmLisCEMzTVltkFVMki0vxrDEP JKYw== MIME-Version: 1.0 X-Received: by 10.220.196.83 with SMTP id ef19mr26050994vcb.5.1415701640583; Tue, 11 Nov 2014 02:27:20 -0800 (PST) Received: by 10.52.8.134 with HTTP; Tue, 11 Nov 2014 02:27:20 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Nov 2014 05:27:20 -0500 Message-ID: From: Aaron Falk To: Michael Tuexen Content-Type: multipart/alternative; boundary=001a1133dcfe65223e050792b9e0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/zDyggIPYiySW8kmfDCZV3q5E4fk Cc: Gorry Fairhurst , Brian Trammell , "taps@ietf.org" Subject: Re: [Taps] new draft available: draft-fairhurst-taps-transports-00 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, 11 Nov 2014 10:27:31 -0000 --001a1133dcfe65223e050792b9e0 Content-Type: text/plain; charset=UTF-8 Thanks, Michael!! On Tue, Nov 11, 2014 at 5:26 AM, Michael Tuexen wrote: > On 28 Oct 2014, at 17:04, Aaron Falk wrote: > > > Hi Folks- > > > > Gorry & Brian have published an annotated framework for TAPS doc 1 on > transport services here. We'll discuss whether to adopt it as a working > group doc in Honolulu. I encourage you to send comments and offers to > contribute text before then. > Dear all, > > I read the document and think it is a good starting point. I would support > to adopt this > as a WG item. I'm willing to contribute to the document, for example by > writing text > regarding SCTP (currently section 3.2) and helping to improve the text in > other sections. > > Best regards > Michael > > > > --aaron > > _______________________________________________ > > Taps mailing list > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps > > --001a1133dcfe65223e050792b9e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Michael!!

On Tue, Nov 11, 2014 at 5:26 AM, Michael Tuexen <tuexen@fh-muenster.de> wrote:
On 28 Oct 2014, at 17:04, Aaron Falk <aaron.falk@gmail.com> wrote:

> Hi Folks-
>
> Gorry & Brian have published an annotated framework for TAPS doc 1= on transport services here.=C2=A0 We'll discuss whether to adopt it as= a working group doc in Honolulu.=C2=A0 I encourage you to send comments an= d offers to contribute text before then.
Dear all,

I read the document and think it is a good starting point. I would support = to adopt this
as a WG item. I'm willing to contribute to the document, for example by= writing text
regarding SCTP (currently section 3.2) and helping to improve the text in o= ther sections.

Best regards
Michael
>
> --aaron
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps


--001a1133dcfe65223e050792b9e0-- From nobody Tue Nov 11 04:24:34 2014 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 6016D1A1BA4 for ; Tue, 11 Nov 2014 04:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 9t5uXs4-8yng for ; Tue, 11 Nov 2014 04:24:31 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 939A01A1B8B for ; Tue, 11 Nov 2014 04:24:31 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 33) id 55C222B43BE; Tue, 11 Nov 2014 12:24:25 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by spey.erg.abdn.ac.uk with HTTP; Tue, 11 Nov 2014 12:24:25 -0000 Message-ID: <9659473abaa6c3e6a19268af7a45f8ea.squirrel@spey.erg.abdn.ac.uk> In-Reply-To: References: Date: Tue, 11 Nov 2014 12:24:25 -0000 From: gorry@erg.abdn.ac.uk To: "Michael Tuexen" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/6FlDk2t2s7Gndns5LdQQPgacI7c Cc: Aaron Falk , Gorry Fairhurst , "taps@ietf.org" , Brian Trammell Subject: Re: [Taps] new draft available: draft-fairhurst-taps-transports-00 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, 11 Nov 2014 12:24:33 -0000 Thanks Michael, This offer is good and welcome - we need help to complete the sections. Gorry > On 28 Oct 2014, at 17:04, Aaron Falk wrote: > >> Hi Folks- >> >> Gorry & Brian have published an annotated framework for TAPS doc 1 on >> transport services here. We'll discuss whether to adopt it as a working >> group doc in Honolulu. I encourage you to send comments and offers to >> contribute text before then. > Dear all, > > I read the document and think it is a good starting point. I would support > to adopt this > as a WG item. I'm willing to contribute to the document, for example by > writing text > regarding SCTP (currently section 3.2) and helping to improve the text in > other sections. > > Best regards > Michael >> >> --aaron >> _______________________________________________ >> 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 Fri Nov 14 15:14:40 2014 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 8F6771A8703 for ; Fri, 14 Nov 2014 15:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 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, HTML_OBFUSCATE_10_20=0.093, 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 VQnY1vMPpMgK for ; Fri, 14 Nov 2014 15:14:20 -0800 (PST) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBD4F1AD375 for ; Fri, 14 Nov 2014 15:14:14 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id hq12so6236899vcb.9 for ; Fri, 14 Nov 2014 15:14:14 -0800 (PST) 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=DTVgWBCUpmumZwp0g6WB783+h4xf3UjXHIy8Mba3hEo=; b=iO8NBbEc0X18wp37s1ccBoNgsuxtNdqeIMJAAntaHAp1uvT1jEnEtwKQis8OYA9yJ6 Q6KIjBt1eJgY5YNA9lta5U9uA5hItbB1fXez1ILrEQJHsbeSfUX/LiDVb90OZEAe40YF UsFQrY97JWF3WTUUTbGtTs7G76iUBevm6Dlnx8Q4cwW1ATDk0dZQULRtD9ovRealaDDh mSs132sr2g5pnCTU74FCRZvLNNbceqcdxNjmsTZoClk60EkLDUSeQDPqO+Z77pVxl9nP v/Qxh5vlCZEyc/23C1UDlA3nVHt59DUPAOZvf4g7HGJ3lrLHOeVVPD8m75QNExXRrul+ tglg== MIME-Version: 1.0 X-Received: by 10.52.237.131 with SMTP id vc3mr7469624vdc.12.1416006853948; Fri, 14 Nov 2014 15:14:13 -0800 (PST) Received: by 10.52.8.134 with HTTP; Fri, 14 Nov 2014 15:14:13 -0800 (PST) Date: Fri, 14 Nov 2014 13:14:13 -1000 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=089e01182b24877c4a0507d9c9eb Archived-At: http://mailarchive.ietf.org/arch/msg/taps/_wZkuPHQ80lob7uPN9dZoUlFrm4 Subject: [Taps] adopting draft-fairhurst-taps-transports-00.txt as a working group document 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, 14 Nov 2014 23:14:22 -0000 --089e01182b24877c4a0507d9c9eb Content-Type: text/plain; charset=UTF-8 There was unanimous opinion in the meeting room at IETF-91 that TAPS should adopt draft-fairhurst-taps-transports-00.txt as a working group document. Does anyone on the list object or want to discuss this? --aaron --089e01182b24877c4a0507d9c9eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There was unanimous opinion in the meeting room at IETF-91= that TAPS should adopt draft-fairhurst-taps-transports-00.txt=C2=A0as a working group d= ocument.=C2=A0 Does anyone on the list object or want to discuss this?
=
--aaron
--089e01182b24877c4a0507d9c9eb-- From nobody Sat Nov 22 13:31:39 2014 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 6C5071A0231 for ; Sat, 22 Nov 2014 13:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 4LgncktbAtyq for ; Sat, 22 Nov 2014 13:31:27 -0800 (PST) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BDFD1A0199 for ; Sat, 22 Nov 2014 13:31:26 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id ij19so3201893vcb.8 for ; Sat, 22 Nov 2014 13:31:25 -0800 (PST) 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=YPLH7S9EHzZqKFcfgCGPcGWWLjWQ1ZcuOYeflgR/xqI=; b=foyp1svBf1O1x4Hq/3Jx3AwX5vowAITugZJSZXeKAdwYvH2xDFhShSAaSp+dVFPssP dskAZayYZvpDonQOUZ8jj/yU45/y2Dl+GHFz+lBKHQkLfiEa15SGUlJ5h2+xLnxhzmth 90q4RVR22rE4FteZ8a387UmrvhCWQBXfW8gfp49G+IZXdyFMB7HuNhf2rx0F3HM03lwJ eIrUNQP3WlSpjAHKlbrXKI8ju6bGO7SUB+v8tyV13e2nw/HE8L/l7SOR/8V2EXXADLPE zsq8QZbz1Em38kpiWqQ0N0OZDVQE6yS855MEZwl277FXAHEUdyguO1x1enj3mhmH0rvo zOwQ== MIME-Version: 1.0 X-Received: by 10.221.22.136 with SMTP id qw8mr8833388vcb.77.1416691885667; Sat, 22 Nov 2014 13:31:25 -0800 (PST) Received: by 10.52.8.134 with HTTP; Sat, 22 Nov 2014 13:31:25 -0800 (PST) Date: Sat, 22 Nov 2014 16:31:25 -0500 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=001a1133768899fe4205087948fb Archived-At: http://mailarchive.ietf.org/arch/msg/taps/Xidyj64i2hzGs3oDwU_4HfquWFk Subject: [Taps] draft minutes from IETF-91 meeting 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, 22 Nov 2014 21:31:36 -0000 --001a1133768899fe4205087948fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If you spoke up in the Honolulu meeting, please review the minutes to confirm we captured your point. Thanks to Stuart Cheshire & Michael Welzl for their detailed notes. Thanks, --aaron =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Transport Services (TAPS) 1300-1500 HST Tuesday Afternoon Session I Notes taken by Stuart Cheshire & Michael Welzl AGENDA =3D=3D=3D=3D=3D=3D=3D 0. Agenda bashing 1. Charter Overview (Falk) - 10 min 2. Terminology Review (K=C3=BChlewind) - 30 min 3. Discussion of draft-fairhurst-taps-transports-00 (K=C3=BChlewi= nd) - 20 min 4. Hum: Adopt draft-fairhurst-taps-transports-00 as wg document? - 10 min Action items marked with ** =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94 13:05 Administrivia Aaron Falk: Who was at the TAPS BoF in Toronto? (Most people raised their hands.) Aaron Falk: And who is on the mailing list? (About the same.) Aaron Falk: In today=E2=80=99s meeting we=E2=80=99ll be having a discussion= of terminology, and then a discussion of the working group=E2=80=99s first draft. We will b= e looking for volunteers. The current draft is an independent submission from two volunteers: Gorry Fairhurst and Brian Trammell, neither of whom could be here. We=E2=80=99ll be asking whether the people in the room want to ado= pt this as a Working Group document. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94 13:08 Charter Overview (Falk) =E2=80=93 10 min Aaron Falk: The TAPS effort is focussing on the same area as the IAB Stack Evolution work, which is that there have been 20 years of transport area improvements that are largely undeployed because (i) the new transports are not supported in most operating systems, and (ii) the new transports may not work end-to-end on today=E2=80=99s Internet. As a result, application developers often build their own protocol on top of UDP, and sometimes that do that badly. The goal of this group is to enable application developers to get better performance and better behavior than they can get from TCP or UDP. The first task of the working group is to define what these behaviors are that application developers want to get. We call these =E2=80=9Ctransport services=E2=80=9D. Some examples are: Reliable delivery, in-order delivery, confidentiality, latency. It=E2=80=99s a way for applications to express wh= at they want from the transport layer, and to ask for combinations that aren=E2=80= =99t currently available from TCP and UDP. The transport layer then sees what=E2= =80=99s available and provides the best that it can, which might be HTTP over TCP. To do this we=E2=80=99re first going to examine existing IETF technologies = to see what behaviors they provide, to collect an initial set of behaviors that we think might be useful. We=E2=80=99re going to focus on communication betwe= en two endpoints, at least initially. That=E2=80=99s the first document, to submi= t to the IESG next June. Then there will be a second document which is a prioritization to select a subset of those services, and guidance how you might obtain those services using existing mechanisms. We will submit this to the IESG next December. The third document describes how to do discovery of whether these things work, how to do fallback, how to combine the protocols and make them available. We will submit this to the IESG in 2016. We=E2=80=99re not going to do signaling-based QoS. We=E2=80=99re not going = to talk about new encapsulations and tunneling. We=E2=80=99re not going to define, modify= , or extend transport protocols. We=E2=80=99re not going to define a language-sp= ecific API. We=E2=80=99re not going to do a detailed analysis of security, but we= will document the security properties of existing protocols. The emphasis of this work is not security. Kevin Fall: Are API changes in scope? (e.g. changing sockets to allow data-with-SYN, out-of-order delivery) Aaron Falk: Yes =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94 13:15 Terminology Review (K=C3=BChlewind) =E2=80=93 30 min (Mirja K=C3=BChlewind gave presentation of proposed terminology) Dave Thaler: Why not use term =E2=80=9Cfacility=E2=80=9D instead of =E2=80= =9Cservice component=E2=80=9D? The term =E2=80=9Cservice component=E2=80=9D usually means a piece of code. Stein Gjessing: =E2=80=9Ccomponent=E2=80=9D means =E2=80=9Cpart=E2=80=9D. T= hat=E2=80=99s not a =E2=80=9Cthing=E2=80=9D or =E2=80=9Cunit=E2=80=9D. Michael Welzl: I like this a lot. Brian Trammell: I=E2=80=99m okay with this suggestion. Kevin Fall: Standards Track RFC 2126 defines the term =E2=80=9Ctransport se= rvices=E2=80=9D as referred to by ISO. Don=E2=80=99t redefine terms that were already defin= ed by an International Standard. Mirja K=C3=BChlewind: Our definition is just a little more specific. Kevin Fall: Reliability is not a binary property. UDPLite has partial reliability. Mirja K=C3=BChlewind: We discussed earlier whether we need a concept smalle= r than a =E2=80=9Cservice component=E2=80=9D for different types of reliabili= ty. We call this an =E2=80=9Caspect=E2=80=9D. Kevin Fall: That term has been reserved as well. Joe Hildebrand: Just pick Swiss German words instead, and we=E2=80=99ll all= learn them. This way we have words that don=E2=80=99t have existing meanings in e= xisting networking standards. Dave Thaler: And then we could try using non-US characters in RFCs. Mirja K=C3=BChlewind: I don=E2=80=99t care what we call it. We just have to= agree on some terminology. Are those six descriptions the right concepts? Ignacio Solis: Is =E2=80=9Creliability=E2=80=9D an example of a =E2=80=9Cse= rvice component=E2=80=9D? Mirja K=C3=BChlewind: Right. A transport service today provides you with a = whole package of service components, not all of which you may want. It also may not include a service component that you do want. Ignacio Solis: We=E2=80=99re being bound by old thinking. Kevin Fall: You asked what is missing here. Is it connection-oriented? Is there connection establishment, notification? Is there flow control? None of that is mentioned. Mirja K=C3=BChlewind: These concepts are =E2=80=9Cservice components=E2=80= =9D; a specific instantiation would be a =E2=80=9Cprotocol feature=E2=80=9D. Aaron Falk: The first two terms are things that applications ask for. The other terms are how you provide those things. Brian Trammell: Kevin is describing =E2=80=9Caspects=E2=80=9D. A =E2=80=9Cf= eature=E2=80=9D is a thing that a protocol does on purpose, an =E2=80=9Caspect=E2=80=9D is something that i= t does, whether on purpose or not. Gorry Fairhurst: =E2=80=9CFeature=E2=80=9D is okay. Ken Calvert: I would call state establishment =E2=80=9Cmechanism=E2=80=9D I= don=E2=80=99t know if this will ever converge. Don=E2=80=99t conflate wire encoding with logical implementation. =E2=80=9CMechanism=E2=80=9D is wire encoding + function. Wh= y are you not saying =E2=80=9Cfunction=E2=80=9D? Mirja K=C3=BChlewind: For me, the terms =E2=80=9Cmechanism=E2=80=9D and =E2= =80=9Cfunction=E2=80=9D are too abstract. What you described is still a =E2=80=9Cfeature=E2=80=9D. Ken Calvert: I suggest not using =E2=80=9Creliability=E2=80=9D as an exampl= e because there are too many different kinds of reliability. Mirja K=C3=BChlewind: Do you think we need a term for concepts with smaller granularity than =E2=80=9Ccomponent=E2=80=9D? Ken Calvert: For that concept, use a Swiss German word. Mirja K=C3=BChlewind: Do we need one more term? Ken Calvert: Maybe. Andrew McGregor: The decomposition into pieces looks good, but I think =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80=9D should be swapped= . Mirja K=C3=BChlewind: I got this feedback already. Jana Iyengar: Well, you just got this feedback again. I agree with Andrew. We should switch =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80=9D.= A software =E2=80=9Ccomponent=E2=80=9D implements a =E2=80=9Cfeature=E2=80=9D. Mirja K=C3=BChlewind: Switching the terms would help? (A bunch of =E2=80=9Cyes=E2=80=9D comments from the room.) Aaron Falk: That=E2=80=99s consensus. Move on. Edward Lopez: We should talk about segregating transport services from applications. Applications become independent of transport services. We should start thinking about the rise of transport service gateways. If your application uses UDP and my application uses TCP then something=E2=80=99s g= ot to traverse. Is a gateway part of a potential terminology? Mirja K=C3=BChlewind: I think that=E2=80=99s out of scope. That would be a = meddlebox. Aaron Falk: The use case we=E2=80=99re focussed on is two applications on t= wo endpoints. You=E2=80=99re using =E2=80=9Capplication=E2=80=9D in a way that= =E2=80=99s confusing me. Edward Lopez: If we=E2=80=99re talking about transport services and potenti= al independence from applications, then when a common application is using different transport services, what=E2=80=99s going to interchange? What=E2= =80=99s going to aid that conversation? That=E2=80=99s what=E2=80=99s not discussed here. Aaron Falk: We have pushed that off. The third effort of the working group to talk about an experiment with end-to-end compatibility. Edward Lopez: Then we=E2=80=99d need transport service negotiation. Separat= ion of application from transport services leads me to think there=E2=80=99s a ter= m missing. Mirja K=C3=BChlewind: What we want is not that the application is requestin= g TCP. What we want is that the application is requesting a certain service composition, and then the layer below can make the decision to use TCP. Ronald in 't Velt: I have not heard the term =E2=80=9Celement=E2=80=9D yet.= I agree with Kevin Fall. Let=E2=80=99s see what=E2=80=99s already there. I have a paper = copy of ISO 8072 somewhere. I couldn=E2=80=99t find it. Mirja K=C3=BChlewind: I=E2=80=99m sure every term has already been used som= ewhere. Jana Iyengar: We should call them =E2=80=9CThing 1=E2=80=9D, =E2=80=9CThing= 2=E2=80=9D, =E2=80=9CThing 3=E2=80=9D, =E2=80=9CThing 4=E2=80=9D. Seriously, how would I think about TCP over IPv6 over SSL over = IPv4? Mirja K=C3=BChlewind: That=E2=80=99s an instance. If you request that servi= ce composition you get that stack. Aaron Falk: Jana, what is the application asking for? Pete Resnick: The whole idea of how discovery takes place where both transports talk to each other and say this is the way we=E2=80=99re going t= o communicate for this particular instance is independent right now and we=E2= =80=99ll have to figure that out, but it=E2=80=99s not something an application care= s about. We need to talk about feature discovery & negotiation. To address Ken=E2=80= =99s comment, reliability and ordering should absolutely be separate components. Stuart Cheshire: I want to follow up to Jana=E2=80=99s point. The choice ab= out what features to use is not decided only by the application. The choice of TCP vs UDP is decided by the application, but the choice of Ethernet vs Wi-Fi (with or without VPN) is decided by the user. Similarly, the choice of VPN or not may be decided by the corporate administrator, not the application, or the user. Aaron: The application needs to express hints about what it wants. You say there are other hints. Do we need to add something to our taxonomy that allows that information to get in? Stuart: I don=E2=80=99t think it extends this taxonomy, it might be an orth= ogonal dimension. User has an input, administrator has an input, application has an input. VPN is a classic example: application itself expresses no interest in security but the user does. Andrew McGregor: You can imagine that the API is that the application asks for a set of components, and the OS decides how to do that. Ignacio Solis: We are PARC are building something that doesn=E2=80=99t use = sockets. We have our own terminology. We call the transport layer the =E2=80=9Cframe= work=E2=80=9D. We build =E2=80=9Cstacks=E2=80=9D with =E2=80=9Ccomponents=E2=80=9D followi= ng the design of composable stacks. The management component is missing here, especially if we are considering how this relates to middleboxes. Mirja K=C3=BChlewind: It would be nice if you could provide some references= to this work on the list. Ignacio Solis: We have quite a number of things we=E2=80=99d be happy to sh= are. Mirja K=C3=BChlewind: You give the application a whole view of what=E2=80= =99s available at the transport layer. This work is to have an abstraction so the application doesn=E2=80=99t need to know the details. Ignacio Solis: We completely agree. The API hides the details of stack assembly from the application. But the application needs to be able to pick the entry component. The application needs to be able to pick the API it=E2= =80=99s going to use. Dave Thaler: I agree with Stuart=E2=80=99s points. I see a relationship bet= ween this and the MIF working group. The MIF working group is doing similar things here concerning multiple provisioning domains. The application can express a set of preferences and get back information about what was chosen. When you think about the choice of saying which L3 protocol, they say =E2=80=9CI=E2=80=99d like to go across a secure interface=E2=80=9D and = MIF does the interface selection logic. Aaron Falk: Are we re-using any MIF terms or concepts? Dave Thaler: I=E2=80=99m not aware of any any terminology collisions. Possi= bly we may be using different terms for the same things. The MIF work is complementary. Aaron Falk: Who in the room is active in the MIF working group? (Dave Thaler plus one other.) Aaron Falk: This whole conversation reminds me of DTN. Kevin Fall: With DTN we had to develop a pub/sub-style API. We also came to the conclusion that a third party needs an API to establish a policy on those bindings. In sockets there=E2=80=99s PF_* and AF_* to express some of= these desires. But the application can also specify the precise protocols using IP_PROTO_*. It=E2=80=99s useful to take this choice that used to be wired i= n code and expose it though an API to an agent. The unit of expressing things is URIs. Brian Trammell: So this problem has always been trying to match the crappy interface above the transport to the crappy interface below. The terminology (and taps charter for that matter) assume the lower interface can be ignored. Although that might be impossible from a terminology standpoint. I think we probably don't want to define a term for the controller... but we might want to have a way to describe the things that the controller knows about the lower-interface transport aspects and path aspects. Mirja K=C3=BChlewind: The goal for right now is to set up an initial termin= ology for us to use. Szilveszter: Don=E2=80=99t we have to define how to choose a protocol? Is i= t in TAPS scope to say how we compose a transport? Isn=E2=80=99t it just an inte= rface towards a transport? Aaron Falk: That is a question about the working group=E2=80=99s scope. The= second document is to pick a subset of all the things an application could ask for. Right now we=E2=80=99re trying to figure out what those behaviors are. Toerless Eckert: Not all of the components here are things that we would traditionally call =E2=80=9Ctransport=E2=80=9D. Some of the components are = in INT area. E.g. what about name resolution? Mirja K=C3=BChlewind: I believe name resolution is not a component. It=E2= =80=99s a service. This is just a first step. We can still change the terms. Andrew McGregor: We want diagnostic tools (ping, traceroute, etc.) to be using the same APIs as applications. Mirja K=C3=BChlewind: Let=E2=80=99s do the first step first. Andrew McGregor: Yes, but diagnostic tools require the ability to specify an exact stack in order to be able to generate the right sort of packet. Aaron Falk: That=E2=80=99s pretty clearly out of scope for the group. The g= oal here is to make things easier for application developers. Andrew McGregor: Is =E2=80=9Cping=E2=80=9D an application? Mirja K=C3=BChlewind: This should be hidden from the application. Andrew McGregor: The =E2=80=9Cping=E2=80=9D program is an application? Aaron Falk: No, it=E2=80=99s a utility, which is why it=E2=80=99s out of sc= ope. Michael Welzl: I remember from the BoF there was consensus that we should have some kind of determinism to flag to provide repeatability for testing. Jana Iyengar: What Andrew is suggesting would be good. We need better tools. Without deterministic unique composition, how can you have interoperability? Mirja K=C3=BChlewind: For interoperability we come up with a new shim layer= . This is what we want to hide from the application. Pete Resnick: Discussion of ping, etc, implicitly assumes a whole lot of layer violations. This working group has =E2=80=9Ctransport=E2=80=9D in the= name. Ping uses ICMP. ICMP is not in the transport layer. To Jana=E2=80=99s point, there=E2= =80=99s going to have to be some sort of rendezvous/discovery. Once an application requests a certain set of components, how the system establishes talking to the other side is just something for the lower layers to implement. Joe Hildebrand: Let=E2=80=99s agree what the components are before we debat= e how they=E2=80=99re negotiated. Andrew McGregor: Ping was a bad example. There=E2=80=99s a python library c= alled =E2=80=9Cscapy=E2=80=9D that lets you specify a bunch of properties and lea= ve the rest unspecified and it will try and make it work. From incomplete information it fills in the gaps to make something sensible. This is a practical example of something that=E2=80=99s already out there. Brian Trammell: The factoring of this terminology, if not the words, support _everything_ we're talking about here. you can ask for a component, you can ask for a composition, you can ask for a protocol instance. What it doesn't support describing yet is getting info up from the lower layer. Kevin Fall: Identification of the endpoint gives me some concern. TCP has concepts like ports. Semantics are associated with that. The style of naming is relevant. Mirja K=C3=BChlewind: You could have a component =E2=80=9CI want to transmi= t web traffic=E2=80=9D and then naturally the first thing the transport protocol = would do is open a connection on port 80. If that doesn=E2=80=99t work it could do s= omething else. Kevin Fall: That=E2=80=99s high level example compared to components like =E2=80=9Creliability=E2=80=9D. Mirja K=C3=BChlewind: This is not for sure. This is the next step. We have = to find out what=E2=80=99s out there and how we name these things. Kevin Fall: If these high level examples are what you=E2=80=99re talking ab= out then high level frameworks well above the sockets layer are relevant. Mirja K=C3=BChlewind: I just don=E2=80=99t know. Mirja K=C3=BChlewind: My conclusions from discussion: We=E2=80=99ll switch= the terms =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80=9D. This is a good s= tarting point. We can have more discussions and change things if necessary. We need a term like =E2=80=9Cas= pect=E2=80=9D which is even a lower granularity than =E2=80=9Ccomponent=E2=80=9D. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94 14:07 Discussion of draft-fairhurst-taps-transports-00 Authors Gorry Fairhurst and Brian Trammell. Presented by Mirja K=C3=BChlewi= nd. Goal is to survey existing transport protocols and extract the common components they have, and the ways they implement those. Slide 4: Relationship between transport protocols and service component Joe Hildebrand: There are other IETF areas who should be included (like RAI) that are not in the transport area but offer transport-like facilities. For example websocket. Mirja K=C3=BChlewind: As long as they are IETF protocols they are in scope. Dave Thaler: I strongly agree with Joe. Now we=E2=80=99re talking about architecture, how protocols map to services. I want to go back to what Stuart said about the multiple parties making the various requests. For example, it is not (usually) the application deciding that the link-layer should be Ethernet. We need to avoid the case where the applications at each end request the same service components but get different protocols and therefore have not interoperability. What that means is that the mapping from service components to protocol stacks needs to be deterministic on both ends. Mirja K=C3=BChlewind: There should be some kind of shim layer that does som= e kind of negotiation to make sure they can communicate. Dave Thaler: Okay, but the draft does not say that. Michael Welzl: This table may look like it proposes a mapping, but it=E2=80= =99s just listing the protocols that currently exist. Jana Iyengar: Are we explicitly excluding non-IETF protocols? Aaron Falk: Yes, for this work item. We might expand the scope later. Kevin Fall: In this matrix UDP is defined as unicast, which surprises me considering that all multicast work uses UDP. How does multicast fit into this? Andrew McGregor: Are CoAP, SPDY, HTTP/2 included? CoAP has multicast RESTful verbs. CoAP also has congestion control, so it=E2=80=99s a transpor= t protocol. Mirja K=C3=BChlewind: Right now we want to cover all the obvious transport protocols. If people want to contribute text for others, we can add those. Aaron Falk: Andrew, is this an area you have expertise in? Andrew McGregor: Some. ** Aaron Falk: Andrew McGregor will identify a contributor to describe CoAP (maybe himself). Brian (or Robert?) Adamson, NRL: We should solicit additions via the mailing list. Aaron Falk: Please send text. Joe Hildebrand: You asked the question: Is this a viable structure? My answer is: I think so. But we should start with a detailed analysis of something like TCP to make sure we understand how that fits the model. Aaron Falk: I=E2=80=99d suggest exploring two examples so that we have two = data points. Michael already volunteered to do SCTP. Slide 5: Who can contribute? Dave Thaler: I=E2=80=99m thinking of a type of protocol that=E2=80=99s miss= ing from the list, and that=E2=80=99s things like TLS. Applications ask for stuff. Proto= cols provide stuff. Applications ask for stuff like confidentiality, integrity, etc. Protocols like TLS and IPSEC provide confidentiality, integrity, etc. Mirja K=C3=BChlewind: Please contribute text. Dave Thaler: We think in terms of layers, but security is not a layer. It= =E2=80=99s on the side, affecting everything. We need to include the things on the side too. Brian Trammell: Security is definitely an aspect Gorry Fairhurst: +1 Mirja K=C3=BChlewind: =E2=80=9CAspect=E2=80=9D or =E2=80=9CComponent=E2=80= =9D? Gorry Fairhurst: What we want is a plan to make one of these sections concrete from someone with expertise in the protocol. Mirja K=C3=BChlewind: Yes. Brian Trammell: We're asking the structure question here. Andrew McGregor: The structure is ugly but I can=E2=80=99t see how it could= be better. We have to consider how you name the other endpoint. DNS name? URL? Something else? Should that identity be proved in some manner? How? TLS certificates? HIP identity hash match. Mirja K=C3=BChlewind: I don=E2=80=99t need to specify how identity is prove= d. Andrew McGregor: You might if you only have credentials in a particular form. Mirja K=C3=BChlewind: This restricts what the transport protocol can choose= . Joe Hildebrand: Let=E2=80=99s not debate API details until we have the prin= ciples adequately characterized. Let=E2=80=99s know what the building blocks are f= irst. Aaron Falk: I agree that we should flesh out a couple of sections and use that as a basis for refining the rest of the document. Who will volunteer to take on one of these sections? ** Kevin Fall: Open mouth, insert work. I will do UDP. Mirja K=C3=BChlewind: Are there no MPTCP people here? Aaron Falk: What about basic TCP? ** Mirja K=C3=BChlewind: I will do basic TCP, but it would be good to have = other people too. Varun Singh: Is RTP excluded? Mirja K=C3=BChlewind: Will you do that? ** Varun Singh: I=E2=80=99ll contribute text for RTP. Varun Singh: Is this document on GitHub? Mirja K=C3=BChlewind: Gorry Fairhurst and Brian Trammell can decide that. Brian Trammell: I can move to markdown over GitHub, no problem. Kevin Fall: Are the lessons we learn here going to reflected in the previous document? Mirja K=C3=BChlewind: This document just lists what=E2=80=99s there. Kevin Fall: If we discover that idempotency is an important concept, how does that get added to the document? Joe Hildebrand: Finding those is the point of this exercise. Aaron Falk: We=E2=80=99ll give you a cookie. Varun Singh: It seems like we=E2=80=99re going to replicate a lot of text f= rom existing RFCs. Aaron Falk: The goal is to take an existing protocol and identify what services it is offering to the application. That=E2=80=99s what we want to = get in this document. Mirja K=C3=BChlewind: What you as an expert for some protocol should do is describe the protocol as completely as possible. Dave Thaler: What are you looking for in each section? Service components? Protocol features? Both? Aaron Falk: I want the protocol components, but the way you get there is to analyze the protocol features. Mirja K=C3=BChlewind: Please provide text. ** Dave Thaler: I volunteer to help with getting the matrix right, of features vs. things that are protocols, e.g. inherent vs. optional is another key thing for features. I=E2=80=99ve done such work in the past. It= =E2=80=99s useful to know which things are inherent features, and which things are optional features. For example, with TCP you can have keepalives or not. Mirja K=C3=BChlewind: The first step is to describe the protocols. ** Dave Thaler: I=E2=80=99m volunteering to help with the matrix more than = the specific text, but I may be able to do some of that too. Jana Iyengar: Let=E2=80=99s not end up with a giant matrix and checkboxes f= or various features. That=E2=80=99s not useful. Mirja K=C3=BChlewind: There may be cases where two components do not work together. ** Karen Nielsen: I will provide SCTP text. Karen Nielsen: Protocol features like ACK or NACK are not specific to TCP. SCTP also has ACKs. You can=E2=80=99t say that protocol features are specif= ic to one protocol. Mirja K=C3=BChlewind: Protocol features are specific to one protocol. Karen Nielsen: So SCTP ACK is different to TCP ACK. ** P=C3=A5l-Erik Martinsen: I will provide text for STUN Charles Eckel: It will be helpful to combine everything into one table. Mirja K=C3=BChlewind: Having a single matrix would be really nice for the document. But the first step is to describe the protocols and extract the components they provide. Kenneth Calvert: Is one of the goals here to come out with an ontology of transport service components? Aaron Falk: We are trying to confine the scope to IETF protocols. A complete ontology would not necessarily be useful. Kenneth Calvert: For this draft, before you plunge into the matrix, it would be useful to define the existing components. Mirja K=C3=BChlewind: This is the end goal of the document. Brian (or Robert?) Adamson, NRL: Is there a template for a list of the aspects we care about? Mirja K=C3=BChlewind: This is just an initial attempt. Brian Trammell: To Kenneth, =E2=80=9Cyes=E2=80=9D (but I am allergic to the= word ontology.) Gorry Fairhurst: To Brian (or Robert?) Adamson: That=E2=80=99s the entire p= oint of this working group. Michael Ramalho: This is a very hard problem when I think about how some of these protocols were evolved to meet very special needs. Suppose I have this application that doesn=E2=80=99t want head-of-line-blocking, and maybe= I don=E2=80=99t want to retransmit once or twice, and let=E2=80=99s suppose I have somethin= g expressive enough to convey this to the transport layer, and it can=E2=80= =99t deliver this without using multiple TCP connections, and maybe I would have preferred DTLS. How do you express that to this layer? Mirja K=C3=BChlewind: The document is focussed on the simple cases first. Pete Resnick: It would be a terrible failure if, in such situations, the transport layer would ask the application what to do. The app doesn=E2=80= =99t care and doesn=E2=80=99t know. That I can pull this off with 3 TCP connections i= s not something the app cares about. You either give the app what it asks for or fail. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94 ** 14:43 Aaron Falk called for adopting draft-fairhurst-taps-transports-00 as WG document. Folks who read the draft: maybe 10 + Significant hum in support None against -- END --001a1133768899fe4205087948fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you spoke up in the Honolulu meeting, please review the= minutes to confirm we captured your point.=C2=A0 Thanks to Stuart Cheshire= & Michael Welzl for their detailed notes.

Thanks,

--aaron

=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<= br>
Transport Services (TAPS)
1300-1500 HST Tuesda= y Afternoon Session I
Notes taken by Stuart Cheshire & Michae= l Welzl

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AGENDA<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D=3D=3D=3D=3D=3D=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0. Agenda bashing
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 1. Charter Overview (Falk) - 10 min
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2. Terminology Review (K=C3=BChlewind) - 30= min
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3. Discussion of draft-fa= irhurst-taps-transports-00 (K=C3=BChlewind) - 20 min
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 4. Hum: Adopt draft-fairhurst-taps-transports-00 a= s wg document? - 10 min

Action items marked with *= *

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

13:05 A= dministrivia

Aaron Falk: Who was at the = TAPS BoF in Toronto? =C2=A0(Most people raised their hands.)

=
Aaron Falk: And who is on the mailing list? =C2=A0(About the sam= e.)

Aaron Falk: In today=E2=80=99s meeting we=E2= =80=99ll be having a discussion of terminology, and then a discussion of th= e working group=E2=80=99s first draft. We will be looking for volunteers. T= he current draft is an independent submission from two volunteers: Gorry Fa= irhurst and Brian Trammell, neither of whom could be here. We=E2=80=99ll be= asking whether the people in the room want to adopt this as a Working Grou= p document.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

=
13:08 Charter Overview (Falk) =E2=80=93 10 min

Aaron Falk: The TAPS effort is focussing on the same area as the IAB Stac= k Evolution work, which is that there have been 20 years of transport area = improvements that are largely undeployed because (i) the new transports are= not supported in most operating systems, and (ii) the new transports may n= ot work end-to-end on today=E2=80=99s Internet. As a result, application de= velopers often build their own protocol on top of UDP, and sometimes that d= o that badly. The goal of this group is to enable application developers to= get better performance and better behavior than they can get from TCP or U= DP.

The first task of the working group is to defi= ne what these behaviors are that application developers want to get. We cal= l these =E2=80=9Ctransport services=E2=80=9D. Some examples are: Reliable d= elivery, in-order delivery, confidentiality, latency. It=E2=80=99s a way fo= r applications to express what they want from the transport layer, and to a= sk for combinations that aren=E2=80=99t currently available from TCP and UD= P. The transport layer then sees what=E2=80=99s available and provides the = best that it can, which might be HTTP over TCP.=C2=A0 To do this we=E2=80= =99re first going to examine existing IETF technologies to see what behavio= rs they provide, to collect an initial set of behaviors that we think might= be useful.=C2=A0 We=E2=80=99re going to focus on communication between two= endpoints, at least initially.=C2=A0 That=E2=80=99s the first document, to= submit to the IESG next June.

Then there will be = a second document which is a prioritization to select a subset of those ser= vices, and guidance how you might obtain those services using existing mech= anisms. We will submit this to the IESG next December.

=
The third document describes how to do discovery of whether these thin= gs work, how to do fallback, how to combine the protocols and make them ava= ilable. We will submit this to the IESG in 2016.

W= e=E2=80=99re not going to do signaling-based QoS. We=E2=80=99re not going t= o talk about new encapsulations and tunneling. We=E2=80=99re not going to d= efine, modify, or extend transport protocols. We=E2=80=99re not going to de= fine a language-specific API.=C2=A0 We=E2=80=99re not going to do a detaile= d analysis of security, but we will document the security properties of exi= sting protocols. The emphasis of this work is not security.

<= /div>
Kevin Fall: Are API changes in scope? (e.g. changing sockets to a= llow data-with-SYN, out-of-order delivery)

Aaron F= alk: Yes

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

13:15 Terminology Review (K=C3=BChlewind) =E2=80=93 30 min
<= = http://www.ietf.org/proceedings/91/slides/slides-91-taps-1.pdf>

(Mirja K=C3=BChlewind gave presentation of proposed te= rminology)

Dave Thaler: Why not use term =E2=80=9C= facility=E2=80=9D instead of =E2=80=9Cservice component=E2=80=9D? The term = =E2=80=9Cservice component=E2=80=9D usually means a piece of code.

Stein Gjessing: =E2=80=9Ccomponent=E2=80=9D means =E2=80= =9Cpart=E2=80=9D. That=E2=80=99s not a =E2=80=9Cthing=E2=80=9D or =E2=80=9C= unit=E2=80=9D.

Michael Welzl: I like this a lot.

Brian Trammell: I=E2=80=99m okay with this suggesti= on.

Kevin Fall: Standards Track RFC 2126 defines t= he term =E2=80=9Ctransport services=E2=80=9D as referred to by ISO. Don=E2= =80=99t redefine terms that were already defined by an International Standa= rd.

Mirja K=C3=BChlewind: Our definition is just a= little more specific.


Kevin Fall: = Reliability is not a binary property. UDPLite has partial reliability.

Mirja K=C3=BChlewind: We discussed earlier whether we = need a concept smaller than a =E2=80=9Cservice component=E2=80=9D for diffe= rent types of reliability. We call this an =E2=80=9Caspect=E2=80=9D.
<= div>
Kevin Fall: That term has been reserved as well.

Joe Hildebrand: Just pick Swiss German words instead, and= we=E2=80=99ll all learn them. This way we have words that don=E2=80=99t ha= ve existing meanings in existing networking standards.

=
Dave Thaler: And then we could try using non-US characters in RFCs.

Mirja K=C3=BChlewind: I don=E2=80=99t care what we c= all it. We just have to agree on some terminology. Are those six descriptio= ns the right concepts?

Ignacio Solis: Is =E2=80=9C= reliability=E2=80=9D an example of a =E2=80=9Cservice component=E2=80=9D?

Mirja K=C3=BChlewind: Right. A transport service to= day provides you with a whole package of service components, not all of whi= ch you may want. It also may not include a service component that you do wa= nt.

Ignacio Solis: We=E2=80=99re being bound by ol= d thinking.

Kevin Fall: You asked what is missing = here. Is it connection-oriented? Is there connection establishment, notific= ation? Is there flow control? None of that is mentioned.

Mirja K=C3=BChlewind: These concepts are =E2=80=9Cservice components= =E2=80=9D; a specific instantiation would be a =E2=80=9Cprotocol feature=E2= =80=9D.

Aaron Falk: The first two terms are things= that applications ask for. The other terms are how you provide those thing= s.

Brian Trammell: Kevin is describing =E2=80=9Cas= pects=E2=80=9D. A =E2=80=9Cfeature=E2=80=9D is a thing that a protocol does= on purpose, an =E2=80=9Caspect=E2=80=9D is something that it does, whether= on purpose or not.

Gorry Fairhurst: =E2=80=9CFeat= ure=E2=80=9D is okay.

Ken Calvert: I would call st= ate establishment =E2=80=9Cmechanism=E2=80=9D I don=E2=80=99t know if this = will ever converge. Don=E2=80=99t conflate wire encoding with logical imple= mentation. =E2=80=9CMechanism=E2=80=9D is wire encoding + function. Why are= you not saying =E2=80=9Cfunction=E2=80=9D?

Mirja = K=C3=BChlewind: For me, the terms =E2=80=9Cmechanism=E2=80=9D and =E2=80=9C= function=E2=80=9D are too abstract. What you described is still a =E2=80=9C= feature=E2=80=9D.

Ken Calvert: I suggest not using= =E2=80=9Creliability=E2=80=9D as an example because there are too many dif= ferent kinds of reliability.

Mirja K=C3=BChlewind:= Do you think we need a term for concepts with smaller granularity than =E2= =80=9Ccomponent=E2=80=9D?

Ken Calvert: For that co= ncept, use a Swiss German word.

Mirja K=C3=BChlewi= nd: Do we need one more term?

Ken Calvert: Maybe.<= /div>

Andrew McGregor: The decomposition into pieces loo= ks good, but I think =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80= =9D should be swapped.

Mirja K=C3=BChlewind: I got= this feedback already.

Jana Iyengar: Well, you ju= st got this feedback again. I agree with Andrew. We should switch =E2=80=9C= component=E2=80=9D and =E2=80=9Cfeature=E2=80=9D. A software =E2=80=9Ccompo= nent=E2=80=9D implements a =E2=80=9Cfeature=E2=80=9D.

<= div>Mirja K=C3=BChlewind: Switching the terms would help?

(A bunch of =E2=80=9Cyes=E2=80=9D comments from the room.)

Aaron Falk: That=E2=80=99s consensus. Move on.
<= br>
Edward Lopez: We should talk about segregating transport serv= ices from applications. Applications become independent of transport servic= es. We should start thinking about the rise of transport service gateways. = If your application uses UDP and my application uses TCP then something=E2= =80=99s got to traverse. Is a gateway part of a potential terminology?

Mirja K=C3=BChlewind: I think that=E2=80=99s out of sc= ope. That would be a meddlebox.

Aaron Falk: The us= e case we=E2=80=99re focussed on is two applications on two endpoints. You= =E2=80=99re using =E2=80=9Capplication=E2=80=9D in a way that=E2=80=99s con= fusing me.

Edward Lopez: If we=E2=80=99re talking = about transport services and potential independence from applications, then= when a common application is using different transport services, what=E2= =80=99s going to interchange? What=E2=80=99s going to aid that conversation= ? That=E2=80=99s what=E2=80=99s not discussed here.

Aaron Falk: We have pushed that off. The third effort of the working grou= p to talk about an experiment with end-to-end compatibility.

=
Edward Lopez: Then we=E2=80=99d need transport service negotiati= on. Separation of application from transport services leads me to think the= re=E2=80=99s a term missing.

Mirja K=C3=BChlewind:= What we want is not that the application is requesting TCP. What we want i= s that the application is requesting a certain service composition, and the= n the layer below can make the decision to use TCP.

Ronald in 't Velt: I have not heard the term =E2=80=9Celement=E2=80= =9D yet. I agree with Kevin Fall. Let=E2=80=99s see what=E2=80=99s already = there. I have a paper copy of ISO 8072 somewhere. I couldn=E2=80=99t find i= t.

Mirja K=C3=BChlewind: I=E2=80=99m sure every te= rm has already been used somewhere.

Jana Iyengar: = We should call them =E2=80=9CThing 1=E2=80=9D, =E2=80=9CThing 2=E2=80=9D, = =E2=80=9CThing 3=E2=80=9D, =E2=80=9CThing 4=E2=80=9D. Seriously, how would = I think about TCP over IPv6 over SSL over IPv4?

Mi= rja K=C3=BChlewind: That=E2=80=99s an instance. If you request that service= composition you get that stack.

Aaron Falk: Jana,= what is the application asking for?

Pete Resnick:= The whole idea of how discovery takes place where both transports talk to = each other and say this is the way we=E2=80=99re going to communicate for t= his particular instance is independent right now and we=E2=80=99ll have to = figure that out, but it=E2=80=99s not something an application cares about.= We need to talk about feature discovery & negotiation. To address Ken= =E2=80=99s comment, reliability and ordering should absolutely be separate = components.

Stuart Cheshire: I want to follow up t= o Jana=E2=80=99s point. The choice about what features to use is not decide= d only by the application. The choice of TCP vs UDP is decided by the appli= cation, but the choice of Ethernet vs Wi-Fi (with or without VPN) is decide= d by the user. Similarly, the choice of VPN or not may be decided by the co= rporate administrator, not the application, or the user.

Aaron: The application needs to express hints about what it wants. Y= ou say there are other hints. Do we need to add something to our taxonomy t= hat allows that information to get in?

Stuart: I d= on=E2=80=99t think it extends this taxonomy, it might be an orthogonal dime= nsion. User has an input, administrator has an input, application has an in= put. VPN is a classic example: application itself expresses no interest in = security but the user does.

Andrew McGregor: You c= an imagine that the API is that the application asks for a set of component= s, and the OS decides how to do that.

Ignacio Soli= s: We are PARC are building something that doesn=E2=80=99t use sockets. We = have our own terminology. We call the transport layer the =E2=80=9Cframewor= k=E2=80=9D. We build =E2=80=9Cstacks=E2=80=9D with =E2=80=9Ccomponents=E2= =80=9D following the design of composable stacks. The management component = is missing here, especially if we are considering how this relates to middl= eboxes. =C2=A0

Mirja K=C3=BChlewind: It would be n= ice if you could provide some references to this work on the list.

Ignacio Solis: We have quite a number of things we=E2=80= =99d be happy to share.

Mirja K=C3=BChlewind: You = give the application a whole view of what=E2=80=99s available at the transp= ort layer. This work is to have an abstraction so the application doesn=E2= =80=99t need to know the details.

Ignacio Solis: W= e completely agree. The API hides the details of stack assembly from the ap= plication. But the application needs to be able to pick the entry component= . The application needs to be able to pick the API it=E2=80=99s going to us= e.

Dave Thaler: I agree with Stuart=E2=80=99s poin= ts. I see a relationship between this and the MIF working group. The MIF wo= rking group is doing similar things here concerning multiple provisioning d= omains. The application can express a set of preferences and get back infor= mation about what was chosen.=C2=A0 When you think about the choice of sayi= ng which L3 protocol, they say =E2=80=9CI=E2=80=99d like to go across a sec= ure interface=E2=80=9D and MIF does the interface selection logic.

Aaron Falk: Are we re-using any MIF terms or concepts?

Dave Thaler: I=E2=80=99m not aware of any any termino= logy collisions. Possibly we may be using different terms for the same thin= gs. The MIF work is complementary.

Aaron Falk: Who= in the room is active in the MIF working group?

(= Dave Thaler plus one other.)

Aaron Falk: This whol= e conversation reminds me of DTN.

Kevin Fall: With= DTN we had to develop a pub/sub-style API. We also came to the conclusion = that a third party needs an API to establish a policy on those bindings. In= sockets there=E2=80=99s PF_* and AF_* to express some of these desires. Bu= t the application can also specify the precise protocols using IP_PROTO_*. = It=E2=80=99s useful to take this choice that used to be wired in code and e= xpose it though an API to an agent. The unit of expressing things is URIs.<= /div>

Brian Trammell: So this problem has always been tr= ying to match the crappy interface above the transport to the crappy interf= ace below. The terminology (and taps charter for that matter) assume the lo= wer interface can be ignored. =C2=A0 Although that might be impossible from= a terminology standpoint. =C2=A0 I think we probably don't want to def= ine a term for the controller... but we might want to have a way to describ= e the things that the controller knows about the lower-interface transport = aspects and path aspects.

Mirja K=C3=BChlewind: Th= e goal for right now is to set up an initial terminology for us to use.

Szilveszter: Don=E2=80=99t we have to define how to c= hoose a protocol? Is it in TAPS scope to say how we compose a transport? Is= n=E2=80=99t it just an interface towards a transport?

<= div>Aaron Falk: That is a question about the working group=E2=80=99s scope.= The second document is to pick a subset of all the things an application c= ould ask for. Right now we=E2=80=99re trying to figure out what those behav= iors are.

Toerless Eckert: Not all of the componen= ts here are things that we would traditionally call =E2=80=9Ctransport=E2= =80=9D. Some of the components are in INT area.=C2=A0 E.g. what about name = resolution?

Mirja K=C3=BChlewind: I believe name r= esolution is not a component. It=E2=80=99s a service. This is just a first = step. We can still change the terms.

Andrew McGreg= or: We want diagnostic tools (ping, traceroute, etc.) to be using the same = APIs as applications.

Mirja K=C3=BChlewind: Let=E2= =80=99s do the first step first.

Andrew McGregor: = Yes, but diagnostic tools require the ability to specify an exact stack in = order to be able to generate the right sort of packet.

=
Aaron Falk: That=E2=80=99s pretty clearly out of scope for the group. = The goal here is to make things easier for application developers.

Andrew McGregor: Is =E2=80=9Cping=E2=80=9D an application?=

Mirja K=C3=BChlewind: This should be hidden from = the application.

Andrew McGregor: The =E2=80=9Cpin= g=E2=80=9D program is an application?

Aaron Falk: = No, it=E2=80=99s a utility, which is why it=E2=80=99s out of scope.

Michael Welzl: I remember from the BoF there was consensu= s that we should have some kind of determinism to flag to provide repeatabi= lity for testing.

Jana Iyengar: What Andrew is sug= gesting would be good. We need better tools. Without deterministic unique c= omposition, how can you have interoperability?

Mir= ja K=C3=BChlewind: For interoperability we come up with a new shim layer. T= his is what we want to hide from the application.

= Pete Resnick: Discussion of ping, etc, implicitly assumes a whole lot of la= yer violations. This working group has =E2=80=9Ctransport=E2=80=9D in the n= ame. Ping uses ICMP. ICMP is not in the transport layer. To Jana=E2=80=99s = point, there=E2=80=99s going to have to be some sort of rendezvous/discover= y. Once an application requests a certain set of components, how the system= establishes talking to the other side is just something for the lower laye= rs to implement.

Joe Hildebrand: Let=E2=80=99s agr= ee what the components are before we debate how they=E2=80=99re negotiated.=

Andrew McGregor: Ping was a bad example. There=E2= =80=99s a python library called =E2=80=9Cscapy=E2=80=9D that lets you speci= fy a bunch of properties and leave the rest unspecified and it will try and= make it work. From incomplete information it fills in the gaps to make som= ething sensible. This is a practical example of something that=E2=80=99s al= ready out there.

Brian Trammell: The factoring of = this terminology, if not the words, support _everything_ we're talking = about here. you can ask for a component, you can ask for a composition, you= can ask for a protocol instance. What it doesn't support describing ye= t is getting info up from the lower layer.

Kevin F= all: Identification of the endpoint gives me some concern. TCP has concepts= like ports. Semantics are associated with that. The style of naming is rel= evant.

Mirja K=C3=BChlewind: You could have a comp= onent =E2=80=9CI want to transmit web traffic=E2=80=9D and then naturally t= he first thing the transport protocol would do is open a connection on port= 80. If that doesn=E2=80=99t work it could do something else.
Kevin Fall: That=E2=80=99s high level example compared to compo= nents like =E2=80=9Creliability=E2=80=9D.

Mirja K= =C3=BChlewind: This is not for sure. This is the next step. We have to find= out what=E2=80=99s out there and how we name these things.

<= /div>
Kevin Fall: If these high level examples are what you=E2=80=99re = talking about then high level frameworks well above the sockets layer are r= elevant.

Mirja K=C3=BChlewind: I just don=E2=80=99= t know.

Mirja K=C3=BChlewind: My conclusions from = discussion: =C2=A0We=E2=80=99ll switch the terms =E2=80=9Ccomponent=E2=80= =9D and =E2=80=9Cfeature=E2=80=9D. This is a good starting point. We can ha= ve more discussions and change things if necessary. We need a term like =E2= =80=9Caspect=E2=80=9D which is even a lower granularity than =E2=80=9Ccompo= nent=E2=80=9D.

=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

14:07 Discussion of draft-fairhurst-taps-transports-00=C2=A0
<= div><http://www.ietf.org/proceedings/91/slides/slides-91-taps-4.pdf&= gt;

Authors Gorry Fairhurst and Brian Trammell. Pr= esented by Mirja K=C3=BChlewind.

Goal is to survey= existing transport protocols and extract the common components they have, = and the ways they implement those.

Slide 4: Relati= onship between transport protocols and service component

Joe Hildebrand: There are other IETF areas who should be included (l= ike RAI) that are not in the transport area but offer transport-like facili= ties. For example websocket.

Mirja K=C3=BChlewind:= As long as they are IETF protocols they are in scope.

=
Dave Thaler: I strongly agree with Joe. Now we=E2=80=99re talking abou= t architecture, how protocols map to services. I want to go back to what St= uart said about the multiple parties making the various requests. For examp= le, it is not (usually) the application deciding that the link-layer should= be Ethernet. We need to avoid the case where the applications at each end = request the same service components but get different protocols and therefo= re have not interoperability. What that means is that the mapping from serv= ice components to protocol stacks needs to be deterministic on both ends.

Mirja K=C3=BChlewind: There should be some kind of = shim layer that does some kind of negotiation to make sure they can communi= cate.

Dave Thaler: Okay, but the draft does not sa= y that.

Michael Welzl: This table may look like it= proposes a mapping, but it=E2=80=99s just listing the protocols that curre= ntly exist.

Jana Iyengar: Are we explicitly exclud= ing non-IETF protocols?

Aaron Falk: Yes, for this = work item. We might expand the scope later.

Kevin = Fall: In this matrix UDP is defined as unicast, which surprises me consider= ing that all multicast work uses UDP. How does multicast fit into this?

Andrew McGregor: Are CoAP, SPDY, HTTP/2 included? CoA= P has multicast RESTful verbs. CoAP also has congestion control, so it=E2= =80=99s a transport protocol.

Mirja K=C3=BChlewind= : Right now we want to cover all the obvious transport protocols. If people= want to contribute text for others, we can add those.

=
Aaron Falk: Andrew, is this an area you have expertise in?
<= br>
Andrew McGregor: Some.

** Aaron Falk= : Andrew McGregor will identify a contributor to describe CoAP (maybe himse= lf).

Brian (or Robert?) Adamson, NRL: We should so= licit additions via the mailing list.

Aaron Falk: = Please send text.

Joe Hildebrand: You asked the qu= estion: Is this a viable structure? My answer is: I think so. But we should= start with a detailed analysis of something like TCP to make sure we under= stand how that fits the model.

Aaron Falk: I=E2=80= =99d suggest exploring two examples so that we have two data points. Michae= l already volunteered to do SCTP.

Slide 5: Who can= contribute?

Dave Thaler: I=E2=80=99m thinking of = a type of protocol that=E2=80=99s missing from the list, and that=E2=80=99s= things like TLS. Applications ask for stuff. Protocols provide stuff. Appl= ications ask for stuff like confidentiality, integrity, etc. Protocols like= TLS and IPSEC provide confidentiality, integrity, etc.

Mirja K=C3=BChlewind: Please contribute text.

Dave Thaler: We think in terms of layers, but security is not a layer. It= =E2=80=99s on the side, affecting everything. We need to include the things= on the side too.

Brian Trammell: Security is defi= nitely an aspect

Gorry Fairhurst: +1
Mirja K=C3=BChlewind: =E2=80=9CAspect=E2=80=9D or =E2=80=9CComp= onent=E2=80=9D?

Gorry Fairhurst: What we want is a= plan to make one of these sections concrete from someone with expertise in= the protocol.

Mirja K=C3=BChlewind: Yes.

Brian Trammell: We're asking the structure question he= re.

Andrew McGregor: The structure is ugly but I c= an=E2=80=99t see how it could be better. We have to consider how you name t= he other endpoint. DNS name? URL? Something else? Should that identity be p= roved in some manner? How? TLS certificates? HIP identity hash match.
=

Mirja K=C3=BChlewind: I don=E2=80=99t need to specify h= ow identity is proved.

Andrew McGregor: You might = if you only have credentials in a particular form.

Mirja K=C3=BChlewind: This restricts what the transport protocol can choos= e.

Joe Hildebrand: Let=E2=80=99s not debate API de= tails until we have the principles adequately characterized. Let=E2=80=99s = know what the building blocks are first.

Aaron Fal= k: I agree that we should flesh out a couple of sections and use that as a = basis for refining the rest of the document. Who will volunteer to take on = one of these sections?

** Kevin Fall: Open mouth, = insert work. I will do UDP.

Mirja K=C3=BChlewind: = Are there no MPTCP people here?

Aaron Falk: What a= bout basic TCP?

** Mirja K=C3=BChlewind: I will do= basic TCP, but it would be good to have other people too.

Varun Singh: Is RTP excluded?

Mirja K=C3= =BChlewind: Will you do that?

** Varun Singh: I=E2= =80=99ll contribute text for RTP.

Varun Singh: Is = this document on GitHub?

Mirja K=C3=BChlewind: Gor= ry Fairhurst and Brian Trammell can decide that.

B= rian Trammell: I can move to markdown over GitHub, no problem.
Kevin Fall: Are the lessons we learn here going to reflected i= n the previous document?

Mirja K=C3=BChlewind: Thi= s document just lists what=E2=80=99s there.

Kevin = Fall: If we discover that idempotency is an important concept, how does tha= t get added to the document?

Joe Hildebrand: Findi= ng those is the point of this exercise.

Aaron Falk= : We=E2=80=99ll give you a cookie.

Varun Singh: It= seems like we=E2=80=99re going to replicate a lot of text from existing RF= Cs.

Aaron Falk: The goal is to take an existing pr= otocol and identify what services it is offering to the application. That= =E2=80=99s what we want to get in this document.

M= irja K=C3=BChlewind: What you as an expert for some protocol should do is d= escribe the protocol as completely as possible.

Da= ve Thaler: What are you looking for in each section? Service components? Pr= otocol features? Both?

Aaron Falk: I want the prot= ocol components, but the way you get there is to analyze the protocol featu= res.

Mirja K=C3=BChlewind: Please provide text.

** Dave Thaler: I volunteer to help with getting the= matrix right, of features vs. things that are protocols, e.g. inherent vs.= optional is another key thing for features. I=E2=80=99ve done such work in= the past. It=E2=80=99s useful to know which things are inherent features, = and which things are optional features. For example, with TCP you can have = keepalives or not.

Mirja K=C3=BChlewind: The first= step is to describe the protocols.

** Dave Thaler= : I=E2=80=99m volunteering to help with the matrix more than the specific t= ext, but I may be able to do some of that too.

Jan= a Iyengar: Let=E2=80=99s not end up with a giant matrix and checkboxes for = various features. That=E2=80=99s not useful.

Mirja= K=C3=BChlewind: There may be cases where two components do not work togeth= er.

** Karen Nielsen: I will provide SCTP text.

Karen Nielsen: Protocol features like ACK or NACK ar= e not specific to TCP. SCTP also has ACKs. You can=E2=80=99t say that proto= col features are specific to one protocol.

Mirja K= =C3=BChlewind: Protocol features are specific to one protocol.
Karen Nielsen: So SCTP ACK is different to TCP ACK.
=
** P=C3=A5l-Erik Martinsen: I will provide text for STUN

Charles Eckel: It will be helpful to combine everythi= ng into one table.

Mirja K=C3=BChlewind: Having a = single matrix would be really nice for the document.=C2=A0 But the first st= ep is to describe the protocols and extract the components they provide.

Kenneth Calvert: Is one of the goals here to come ou= t with an ontology of transport service components?

Aaron Falk: We are trying to confine the scope to IETF protocols. A compl= ete ontology would not necessarily be useful.

Kenn= eth Calvert: For this draft, before you plunge into the matrix, it would be= useful to define the existing components.

Mirja K= =C3=BChlewind: This is the end goal of the document.

Brian (or Robert?) Adamson, NRL: Is there a template for a list of the a= spects we care about?

Mirja K=C3=BChlewind: This i= s just an initial attempt.

Brian Trammell: To Kenn= eth, =E2=80=9Cyes=E2=80=9D (but I am allergic to the word ontology.)
<= div>
Gorry Fairhurst: To Brian (or Robert?) Adamson: That=E2= =80=99s the entire point of this working group.

Mi= chael Ramalho: This is a very hard problem when I think about how some of t= hese protocols were evolved to meet very special needs. Suppose I have this= application that doesn=E2=80=99t want head-of-line-blocking, and maybe I d= on=E2=80=99t want to retransmit once or twice, and let=E2=80=99s suppose I = have something expressive enough to convey this to the transport layer, and= it can=E2=80=99t deliver this without using multiple TCP connections, and = maybe I would have preferred DTLS. How do you express that to this layer?

Mirja K=C3=BChlewind: The document is focussed on t= he simple cases first.

Pete Resnick: It would be a= terrible failure if, in such situations, the transport layer would ask the= application what to do. The app doesn=E2=80=99t care and doesn=E2=80=99t k= now. That I can pull this off with 3 TCP connections is not something the a= pp cares about. You either give the app what it asks for or fail.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94

** 14:43 Aaron F= alk called for adopting draft-fairhurst-taps-transports-00 as WG document.<= /div>
Folks who read the draft: maybe 10 +
Significant hum in= support
None against

-- END
=
--001a1133768899fe4205087948fb--