From nobody Thu Jun 1 08:51:15 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEFB128D44 for ; Thu, 1 Jun 2017 08:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WDIRsrPzdpYF for ; Thu, 1 Jun 2017 08:51:13 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6854128A32 for ; Thu, 1 Jun 2017 08:51:13 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id y201so39688964qka.0 for ; Thu, 01 Jun 2017 08:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=pmVnjG0j/bYydCBxMcSfeQRmE4ivFsQQTpR7Hezaw/4=; b=KYtni5wkC6zdf6i0UJkY2hVOAturPHf3QgEsOgI+aVOHz8eavY/nyJ8GuoyDNiqY5F za2tkZeetW6DF7Mpgw1Zhj1V5Jp1/jFdBtXC/BXWpj05PDBoaV/9OU/lBGYA+KJcCiYz aGuqPAETh0Ffdz0h0dsn1tlULzp4F+yLrTf8Pk+Bi4P4Z99+bWM/taWvjrW53qcplhZD D/lFlmY+9vPqq9IYM+/nkrRSKTvRMZYzTqLQUF33838pqX3tHTjG7/0PtA9517Q8Ym44 yJA+t7mjrBHHgefpCP1sQjPwAxXpeizxwntIIS61vc8p47DbH7P1HoshnLk0nPyAmj9b nQ6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=pmVnjG0j/bYydCBxMcSfeQRmE4ivFsQQTpR7Hezaw/4=; b=RYMkR8T4Sb8G1T1X4xtNgg6StzD4FEtZ3Mrs50pX6LUR0W9GuShJfk2Yad1glkk8RF JBIrHYtFaIEJga/LT1J5AO1RCBDFL5We3XLZ1WiWG7cDuJny+NMXy4D1NdRMvjy1cnF3 etxS6cpQrMEbU1q038r1awPNohUHCA4etTcsYhmR3lmxgwNUUIVbVFpQWS3zwlcRmTrN jWskF1WYp1WPOly710Qy62OFiTWNSeDkqZi/ckcqFbt/bQ3bSU2UFvjrGvRD8aIM5izA nRWLgmquwFSkJFqNJUZWQHRxs3fU7IG9GJTZn2jgwfupWVg118IM7wIl4zsKqP3+iejm 7GOQ== X-Gm-Message-State: AKS2vOzomU98jP4uPsqETK0uIa5IYv9AJEtsYl9GvvzRrJFLxMrHhTIO NXEhEaWLEwQi49ZwAi4= X-Received: by 10.55.124.195 with SMTP id x186mr2336723qkc.137.1496332272763; Thu, 01 Jun 2017 08:51:12 -0700 (PDT) Received: from [169.254.169.186] ([72.246.0.14]) by smtp.gmail.com with ESMTPSA id z43sm13156964qtz.9.2017.06.01.08.51.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Jun 2017 08:51:12 -0700 (PDT) From: "Aaron Falk" To: "Philipp S. Tiesel" Cc: "taps WG" Date: Thu, 01 Jun 2017 11:51:11 -0400 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5356) Archived-At: Subject: Re: [Taps] TAPS drafts planning / Prague meeting X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 15:51:15 -0000 +taps list Hi Philipp- Should be interesting. We should be able to find time on the agenda for some discussion. —aaron On 1 Jun 2017, at 11:47, Philipp S. Tiesel wrote: > Hi Aaron, > > we are planning to submit three drafts for the Prague meeting (before > the deadline ;-) ): > > - one on the general concept of Socket Intents > A litte extension of what I presented on the IAB workshop in Zurich > and at IETF96 in Berlin > > - one on our implementation and Socket Intents for BSD sockets > which should basically be an example for the former > > - one as discussion starter about what is the right granularity > of communication units we need to operate on. > > I have some help from Brian and Mirja preparing these, but as these > are my first draft, let’s see how this will work out. > > AVE! > Philipp S. Tiesel > > -- > Technische Universität Berlin – FG Internet Network Architectures > (INET) > office: MAR 4.024 / Sekr.: MAR 4.4, Marchstr. 23, 10587 Berlin > e-mail: philipp@inet.tu-berlin.de • phone: +49-30-314-75763 From nobody Sun Jun 4 13:40:36 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71980126B71 for ; Sun, 4 Jun 2017 13:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 xQZLVe5jnvwn for ; Sun, 4 Jun 2017 13:40:32 -0700 (PDT) Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (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 894CE1200E5 for ; Sun, 4 Jun 2017 13:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1496608831; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7ZobhNDLtiAPC6IZB8lKz7jT8rBczyidcaWO4A0jnV0=; b=cJ2t0tJfTIb9rTbQFnranHQ6w5tj2b5LLPaq4Cdi8srBTaDX3fH76qelRPsDkoFf vnV2MALLayZsJoMDzbv517QdH9IrFyJ1WiFGVVsdmtzfLeIlUxrd/dkF9B5XGVbT Il2WfUSeHskraEpUdrJ4xuvUkzE2rtio6+wu/sgv0igq9lXXzfd2SfIAcaeZETKa liIo4L6QhsrsFvdtspyN7hHouqCke0Sg1G24z0jkX/Ipn5xIpy7o7bef+AfODqYZ fmm1Nlv6v4bFEwKYeMLEDzFUYrZNrDkvoJW5ngrWDfsbMP6aBZRoujIDpyDC+0qv cfx619EgKzlOe8EGg1wvxg==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id 20.31.02740.C3074395; Sun, 4 Jun 2017 13:40:31 -0700 (PDT) X-AuditID: 11ab0216-c35fb70000000ab4-36-5934703ca83c Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay4.apple.com (Apple SCV relay) with SMTP id B5.F3.02523.B3074395; Sun, 4 Jun 2017 13:40:28 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Wi9AZLssFKcoO0lNB846kA)" Received: from [17.153.59.25] (unknown [17.153.59.25]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OR100DD8IRFH960@nwk-mmpp-sz11.apple.com>; Sun, 04 Jun 2017 13:40:27 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <11EE2FCB-50A5-4C6E-BF23-9BCFDC7FEE8A@apple.com> Date: Sun, 04 Jun 2017 13:40:26 -0700 In-reply-to: <70A5CB94-DBFD-4A09-80D2-5B944F01F1C8@trammell.ch> Cc: taps WG To: "Brian Trammell (IETF)" , Aaron Falk References: <408986B2-B86B-4C7D-9E91-D554029579FA@gmail.com> <70A5CB94-DBFD-4A09-80D2-5B944F01F1C8@trammell.ch> X-Mailer: Apple Mail (2.3431) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUi2FAYrmtfYBJp8LRJxKLt9zRWi40t79gs 7sQ4MHvsnHWX3WPJkp9MHk/2z2QJYI7isklJzcksSy3St0vgyphyaS9rwVO7im+3dRsYp5l2 MXJySAiYSLz+vpypi5GLQ0hgDZPE7Ql7mGESH5+1MEIkDjFKdNyZwQ6S4BUQlPgx+R4LiM0s ECax8tJ0qO5+JonVF34CJTg4hAUkJDbvSQSpYRNQkTj+bQMzRK+NxK5/Z8B6hQWsJN7d7WYF sVkEVCX+7O1iA7E5Bewl/i6+ATVfWmLpt8mMILaIQLDE01nr2UDGCwkUSnSeS4e4U1Zi0/3H zCAnSAicYJOY9KqPdQKj0Cwkp85CcuosoHZmAXWJKVNyIcLaEk/eXWCFsNUkFv5exIQsvoCR bRWjcG5iZo5uZp6RkV5iQUFOql5yfu4mRlBkrGYS28F477XhIUYBDkYlHt4DaSaRQqyJZcWV uYcYpTlYlMR5vz40ihQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAKOEXsfrkk/4c9ZUrfDWW JVia+PxcvOK/0zb+rLtXI/Q5z3Ks4NV5vtT4QnZ4aPIx8WV7bzOqLWu1n/9gYueTcsYSr+1n GNarsVYr1xt1s7efPN67Zeq/etb+NbMW68nsmnVogfbRNwdfF3PuefxPL/j966wDv+3OaDpM PvrZKCzme26EzLbjgUosxRmJhlrMRcWJABqf8pFtAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMIsWRmVeSWpSXmKPExsUi2FA8W9emwCTS4M5dPou239NYLTa2vGOz uBPjwOyxc9Zddo8lS34yeTzZP5MlgDmKyyYlNSezLLVI3y6BK2PKpb2sBU/tKr7d1m1gnGba xcjJISFgIvHxWQtjFyMXh5DAIUaJjjsz2EESvAKCEj8m32MBsZkFwiRWXprOBFHUzySx+sJP oAQHh7CAhMTmPYkgNWwCKhLHv21ghui1kdj17wxYr7CAlcS7u92sIDaLgKrEn71dbCA2p4C9 xN/FN6DmS0ss/TaZEcQWEQiWeDprPRvIeCGBQonOc+kQd8pKbLr/mHkCI/8sJNfNQnLdLKAO ZgF1iSlTciHC2hJP3l1ghbDVJBb+XsSELL6AkW0Vo0BRak5ipYleYkFBTqpecn7uJkZwGBeG 72D8t8zqEKMAB6MSD69EpkmkEGtiWXFlLjCIOJiVRHgzrIFCvCmJlVWpRfnxRaU5qcWHGCcy Av04kVlKNDkfGGV5JfGGJiYGJsbGZsbG5ibmtBRWEuc1228UKSSQnliSmp2aWpBaBHMUEwen VAPjvOzPB4S++DOd3eJw+a+4a4hepguLo0Xdq7CkqSfTkzuM1v26fOCbxjO937yLToipv76p edXlnJq+4VybzWl78zK/MTrqGYh8maYiuLVoxuvdM/TTQ25v3LDHcTVDaUdT6817nPP4atQi d9t6dGvyHk7kejBxrVrTr99HC9zFuov1DSSE9V4psRRnJBpqMRcVJwIAoHRsdNYCAAA= Archived-At: Subject: Re: [Taps] WGLC start for -transports-usage- docs X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 20:40:34 -0000 --Boundary_(ID_Wi9AZLssFKcoO0lNB846kA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Agreed, these both look ready to go! Just a few minor typographical nits = below; these could be cleaned up later. Best, Tommy Usage Draft: - In Section 3.1, the style of most items is lower case without = underscores; however there are "USER TIMEOUT event:=E2=80=9D and = "ERROR_REPORT event:=E2=80=9D, and then the rest of the list is in = camel-case like "Type-of-Service:=E2=80=9D. These should probably be = cleaned up. Same for other lists. - In Section 5.1, would it be useful to explicitly mention MPTCP for the = common elements with TCP, or simply mention that anything that applies = to TCP also applies to MPTCP? UDP Usage Draft: - Section 3 has some mismatched parenthetical clauses: (in and how the transport is used (based on abstract API descriptions, where they are available). - Section 3.1 has a sentence that doesn=E2=80=99t parse well: should be able to create receive, source and destination ports and addresses - Also in Section 3.1, it seems that there should be a comma before the = =E2=80=9Cor by=E2=80=9D rather than a full stop. 1. bind(): A bind operation sets the local port, either implicitly, triggered by a "sendto" operation on an unbound, unconnected socket using an ephemeral port. Or by an explicit "bind" to use a configured or well-known port. - Section 3.1, "ERROR_REPORT The ERROR_REPORT=E2=80=9D is missing the = colon that all other items have. Same for SET_MIN_COVERAGE in section = 3.2 > On May 30, 2017, at 3:14 AM, Brian Trammell (IETF) = wrote: >=20 > hi Aaron, all, >=20 > I've read these, and IMO they're ready for publication. Many thanks to = the authors for the impressive amount of work that went into them! >=20 > Cheers, >=20 > Brian >=20 >=20 >> On 29 May 2017, at 18:30, Aaron Falk wrote: >>=20 >> Dear TAPS working group: >>=20 >> The authors have indicated the two drafts below are complete and are = ready for a final working group review. WGLC starts today and will be = three weeks, concluding June 19. Send comments, including an indication = that the docs are ready for publication, to the working group list. >>=20 >> =E2=80=A2 On the Usage of Transport Features Provided by IETF = Transport Protocols >> =E2=80=A2 Features of the User Datagram Protocol (UDP) and = Lightweight UDP (UDP- Lite) Transport Protocols >> =E2=80=94aaron >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_Wi9AZLssFKcoO0lNB846kA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Agreed, these both look ready to go! Just a few minor = typographical nits below; these could be cleaned up later.

Best,
Tommy

Usage Draft:

- In Section 3.1, the style of most items is lower case = without underscores; however there are "USER TIMEOUT event:=E2=80=9D and = "ERROR_REPORT event:=E2=80=9D, and then the rest of the list is in = camel-case like "Type-of-Service:=E2=80=9D. These should probably be = cleaned up. Same for other lists.

- In Section 5.1, would it be useful to = explicitly mention MPTCP for the common elements with TCP, or simply = mention that anything that applies to TCP also applies to = MPTCP?

UDP = Usage Draft:

 - Section 3 has some mismatched parenthetical = clauses:
(in and how the
   transport is used (based on abstract API descriptions, where they are
   available).
- Section 3.1 has a sentence that = doesn=E2=80=99t parse well:

should be able to create receive, source and
   destination ports and addresses

- Also in Section 3.1, it seems that there should = be a comma before the =E2=80=9Cor by=E2=80=9D rather than a full = stop.

 1.  bind(): A bind =
operation sets the local port, either
          implicitly, triggered by a "sendto" operation on an unbound,
          unconnected socket using an ephemeral port.  Or =
by an explicit
          "bind" to use a configured or well-known port.

- Section 3.1, "ERROR_REPORT The = ERROR_REPORT=E2=80=9D is missing the colon that all other items have. = Same for SET_MIN_COVERAGE in section 3.2


On May 30, 2017, at 3:14 AM, Brian Trammell = (IETF) <ietf@trammell.ch> wrote:

hi = Aaron, all,

I've read these, and IMO = they're ready for publication. Many thanks to the authors for the = impressive amount of work that went into them!

Cheers,

Brian


On 29 May = 2017, at 18:30, Aaron Falk <aaron.falk@gmail.com> wrote:

Dear TAPS working group:

The = authors have indicated the two drafts below are complete and are ready = for a final working group review. WGLC starts today and will be three = weeks, concluding June 19. Send comments, including an indication that = the docs are ready for publication, to the working group list.

=E2=80=A2 On the Usage of = Transport Features Provided by IETF Transport Protocols
= =E2=80=A2 Features of the User Datagram Protocol (UDP) and = Lightweight UDP (UDP- Lite) Transport Protocols
=E2=80=94aar= on

_______________________________________________
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

= --Boundary_(ID_Wi9AZLssFKcoO0lNB846kA)-- From nobody Thu Jun 8 12:50:28 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C166129477 for ; Thu, 8 Jun 2017 12:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 ZFth6EvrJcVd for ; Thu, 8 Jun 2017 12:50:23 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 DB9711292F4 for ; Thu, 8 Jun 2017 12:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1496951422; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1S3dce7171ETmGrUjJx9uDGQzvvq0JpgecVr8JJgjV4=; b=1tlevmfWtGfJe68CGJe+yTgzGYIy0bPoaDoZ8hRmhQTuzq/DffxjqRZ2bInkOHyL lHw2hi/NQwlVoERESureEXMZK4Mrj4IrOGHTJ9E9TwE0Pw4lWnb5RIfFKw56jyfO EQ3lXu+kF8srUtuG1ACaAto5dd/UX4W0IHAtDGWOdp3oC0AEMT6rnEQ3hqAjUIvc EsrNPkIQoaKqfGLYuWoQ45cK3NKFwD4RgQ7xMDsbW/BYCF+PztEqGGQFoGEnjLwg z6JnKdttTn7rB58wlIxgkh26+EdHakQ9BeV5iinT/SNKLI/YpiwHRibDd0NoU+jc 8kMjNp4oa/xy25poft1PFg==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 65.CC.01052.E7AA9395; Thu, 8 Jun 2017 12:50:22 -0700 (PDT) X-AuditID: 11973e12-7285e9a00000041c-d6-5939aa7e9643 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay2.apple.com (Apple SCV relay) with SMTP id AA.98.07829.B7AA9395; Thu, 8 Jun 2017 12:50:19 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_6+7HU6oeUl85wQegulJi7w)" Received: from [17.153.51.93] (unknown [17.153.51.93]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OR8001MUV3SY8C0@nwk-mmpp-sz09.apple.com> for taps@ietf.org; Thu, 08 Jun 2017 12:50:19 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <197539C8-A6D7-4A94-9897-B0D49DE07781@apple.com> Date: Thu, 08 Jun 2017 12:50:14 -0700 To: taps WG X-Mailer: Apple Mail (2.3431) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUi2FDorFu3yjLS4NUXTYs7MQ6MHkuW/GQK YIzisklJzcksSy3St0vgymifvZe1YK9YxYp3GxgbGBcLdzFyckgImEjM+dLA3sXIxSEksJpJ Yv6m36wwiWc3P7FCJA4ySsw8dY0ZJMErICjxY/I9FhCbWSBMYt+mFUwQRQuZJFYvPQTkcHAI C0hIbN6TCFLDJqAicfzbBrBeYQENib2fVjKDlPAK2EgsOicPYrIIqErsuOAGUiEiIC3xZs5p ZogTZCU23X/MDDJdQqCDTWJKx3T2CYz8s5BcMQvJFbOARjELqEtMmZILEdaWePLuAiuErSax 8PciJmTxBYxsqxiFchMzc3Qz80z0EgsKclL1kvNzNzGCwnS6ndAOxlOrrA4xCnAwKvHwJkRY RgqxJpYVV+YeYpTmYFES5/3ZZhEpJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdFCYWpXuOQB f9ngBaG9+/8YTl6Quf7XxbcmbuGWG3dc01SzPyNjvDnXnnnZ8w9/Yrep5wXtcaznCm6J97N9 Ubyx3V+McealH8tv/zDVXl+94/XZxZa1X7d0rSttzj/bxtFhfqeZj/Fb6uwjx1/5b6i4ebJm c6Fv2taSfu6mbQ91vx0NDdPbfU2JpTgj0VCLuag4EQDsqamcNAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42IRbCgO0K1eZRlpsHCWhcWdGAdGjyVLfjIF MEZx2aSk5mSWpRbp2yVwZbTP3stasFesYsW7DYwNjIuFuxg5OSQETCSe3fzE2sXIxSEkcJBR Yuapa8wgCV4BQYkfk++xgNjMAmES+zatYIIoWsgksXrpISCHg0NYQEJi855EkBo2ARWJ4982 gPUKC2hI7P20khmkhFfARmLROXkQk0VAVWLHBTeQChEBaYk3c04zQ5wgK7Hp/mPmCYw8s5As noVk8SygbmYBdYkpU3IhwtoST95dYIWw1SQW/l7EhCy+gJFtFaNAUWpOYqWRXmJBQU6qXnJ+ 7iZGcFgVOu9gPLbM6hCjAAejEg/vjijLSCHWxLLiytxDjBIczEoivEcNgEK8KYmVValF+fFF pTmpxYcYJzIC3T+RWUo0OR8Y9Hkl8YYmJgYmxsZmxsbmJua0FFYS5032sogUEkhPLEnNTk0t SC2COYqJg1OqgbEyKrlyalzU5E3VExt2z2Cx4f2ZWhyy25p7DcM9W2WDNtuu3pdzaiWn9PVs eF+U8S5F5kRnb5n5+sVffp+Wus5zdco7PamJfknZ7yY3O51NE5ez65mwVneJzK6Oe07/UqYJ 7WIs8eXJTnRm9wh0+1JYe2/enBzbWL7AHcqFU/4XzXEKqdQUUGIpzkg01GIuKk4EAHyLQpSe AgAA Archived-At: Subject: [Taps] User-Space Networking in iOS 11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 19:50:25 -0000 --Boundary_(ID_6+7HU6oeUl85wQegulJi7w) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hello, I wanted to point the TAPS group to some of the work that we announced = this week at WWDC that relates to the Post-Sockets API effort. You can = see a video of the session here (relevant section at ~13:50), along with = the slides: https://developer.apple.com/videos/play/wwdc2017/707 = In the current betas of iOS 11, we have introduced =E2=80=9CUser-Space = Networking=E2=80=9D beneath our networking APIs. The transport and IP = protocols are now being co-located with the security and application = protocols in the process, meaning that we are no longer using sockets = within the implementation of these APIs. This shift allows us to reduce = the context switches between protocol layers, and could potentially open = opportunities for the kind of stack flexibility and customization that = the TAPS group is looking at. We=E2=80=99re excited to be making some = first steps into a truly =E2=80=9CPost-Sockets=E2=80=9D world! Thanks, Tommy= --Boundary_(ID_6+7HU6oeUl85wQegulJi7w) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hello,

I = wanted to point the TAPS group to some of the work that we announced = this week at WWDC that relates to the Post-Sockets API effort. You can = see a video of the session here (relevant section at ~13:50), along with = the slides:

https://developer.apple.com/videos/play/wwdc2017/707
<= div class=3D"">
In the current betas = of iOS 11, we have introduced =E2=80=9CUser-Space Networking=E2=80=9D = beneath our networking APIs. The transport and IP protocols are now = being co-located with the security and application protocols in the = process, meaning that we are no longer using sockets within the = implementation of these APIs. This shift allows us to reduce the context = switches between protocol layers, and could potentially open = opportunities for the kind of stack flexibility and customization that = the TAPS group is looking at. We=E2=80=99re excited to be making some = first steps into a truly =E2=80=9CPost-Sockets=E2=80=9D world!

Thanks,
Tommy
= --Boundary_(ID_6+7HU6oeUl85wQegulJi7w)-- From nobody Thu Jun 8 19:13:40 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E659A129329 for ; Thu, 8 Jun 2017 19:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 rjt56whuvQ-D for ; Thu, 8 Jun 2017 19:13:36 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ABDB126BF0 for ; Thu, 8 Jun 2017 19:13:36 -0700 (PDT) Received: from [10.0.0.44] (unknown [38.64.177.99]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 52996721E281A; Fri, 9 Jun 2017 04:13:33 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Tuexen In-Reply-To: <197539C8-A6D7-4A94-9897-B0D49DE07781@apple.com> Date: Thu, 8 Jun 2017 22:13:31 -0400 Cc: taps WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <197539C8-A6D7-4A94-9897-B0D49DE07781@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Taps] User-Space Networking in iOS 11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 02:13:39 -0000 On 8. Jun 2017, at 15:50, Tommy Pauly wrote: >=20 > Hello, >=20 > I wanted to point the TAPS group to some of the work that we announced = this week at WWDC that relates to the Post-Sockets API effort. You can = see a video of the session here (relevant section at ~13:50), along with = the slides: >=20 > https://developer.apple.com/videos/play/wwdc2017/707 >=20 > In the current betas of iOS 11, we have introduced =E2=80=9CUser-Space = Networking=E2=80=9D beneath our networking APIs. The transport and IP = protocols are now being co-located with the security and application = protocols in the process, meaning that we are no longer using sockets = within the implementation of these APIs. This shift allows us to reduce = the context switches between protocol layers, and could potentially open = opportunities for the kind of stack flexibility and customization that = the TAPS group is looking at. We=E2=80=99re excited to be making some = first steps into a truly =E2=80=9CPost-Sockets=E2=80=9D world! Hi Tommy, so this means I can run my own TCP stack and my own IPv6 stack in my = application, if I understood that correctly. How is the port number space managed between the different applications? = I'm wondering how the demultiplexing is done? Can I also use the API for a transport protocol supporting the port = number concept, but not being UDP or TCP, like SCTP or UDP-Lite or DCCP or whatever might come up in the future? Best regards Michael >=20 > Thanks, > Tommy > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Jun 9 09:16:33 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C10128AFE for ; Fri, 9 Jun 2017 09:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 VE7Taimh1L_2 for ; Fri, 9 Jun 2017 09:16:30 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 D86B0120724 for ; Fri, 9 Jun 2017 09:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497024990; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=y0jMbQnmzz9IK/aNXLnJ1U3+QeVa9qQ1SoaaQfisPso=; b=ptru8Zwy+pJo9ODMu8uLjfmOLvXBl6wVCdzZJhg/KZj+Eb+pREnQlUKT3XmNkzHj DeuXlf1Gp776E21hgOYb8bhdn5WXEoqv713lB6Kka+w6D7zriN0VAm1ivS5RGyZV yHx3bnh4CJw1kOsdhpZTLFnTFyb/DWpoXfPnTKi04pwnncWk0gVrqzmrumXLqGQ6 aOhhVVw8jEawS8WMiNPU6pWTQWj4PxoGV3q2HOeFH2eMi6qPaHiuwON/e7UTJdbU J7yuCOa7/pxh3M5f1cnvaMoxqGSnI/oeRG9wULhg9yC1WGgZZ5foTaINzQcrZroK Du0YX4KbYh0OGRZHD5jc2g==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 70.74.07949.ED9CA395; Fri, 9 Jun 2017 09:16:30 -0700 (PDT) X-AuditID: 11973e16-0c7789a000001f0d-4c-593ac9de7592 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay2.apple.com (Apple SCV relay) with SMTP id F7.B4.07829.ED9CA395; Fri, 9 Jun 2017 09:16:30 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.153.57.155] (unknown [17.153.57.155]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORA003VTFVINI10@nwk-mmpp-sz09.apple.com>; Fri, 09 Jun 2017 09:16:30 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Fri, 09 Jun 2017 09:16:29 -0700 Cc: taps WG Content-transfer-encoding: quoted-printable Message-id: <06989608-DB4D-4C88-8F7A-D52FB82E4771@apple.com> References: <197539C8-A6D7-4A94-9897-B0D49DE07781@apple.com> To: Michael Tuexen X-Mailer: Apple Mail (2.3431) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUi2FDorHvvpFWkwezduhYXm5YwWtyJcWDy WLLkJ5PHhpYdTAFMUVw2Kak5mWWpRfp2CVwZuy9dZyl4KFYxdU87UwPjGaEuRk4OCQETie+3 zjN3MXJxCAmsZpL42LCDtYuRAyzxf64pRPwgo0Tfij3sIA28AoISPybfYwGpYRZQl5gyJRei ZiKTRMeh98wgcWEBCYnNexJByoUFjCXO733ODGKzCahIHP+2AczmFHCVeHnyIQuIzSKgKjHl 1TImEJtZQFpi6bfJjBC2tsSTdxdYIdbaSFxcuwEsLiRQLvH0+VYwW0TAVOLg8nksEL/ISmy6 /xjsFwmBJWwSR2Z0sE5gFJ6F5OxZCGfPQrJiASPzKkah3MTMHN3MPHO9xIKCnFS95PzcTYyg kJ5uJ7aD8eEqq0OMAhyMSjy8GvOsIoVYE8uKK3MPMUpzsCiJ81q9sowUEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwDin3c1mbWZb2pNrvJ9muZ8PWsJxo6HGxmntqcL/a4Wu35U462W3TnXv NF6rSVK8bIf/aJvs+biiPnBC9T5Hz/uGV1pn7pGe8iVyc56qgLPPBOt14sVV0Qur4tZ3Sxr2 npL1vPLsZLSY+xX91g8V0ll2XXMzsybVN16UTtLofrcuyIb5n8BuOSWW4oxEQy3mouJEADn+ FwlKAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42IRbCgO0L130irSYPE3eYuLTUsYLe7EODB5 LFnyk8ljQ8sOpgCmKC6blNSczLLUIn27BK6M3ZeusxQ8FKuYuqedqYHxjFAXIweHhICJxP+5 pl2MXBxCAgcZJfpW7GHvYuTk4BUQlPgx+R4LSA2zgLrElCm5EDUTmSQ6Dr1nBokLC0hIbN6T CFIuLGAscX7vc2YQm01AReL4tw1gNqeAq8TLkw9ZQGwWAVWJKa+WMYHYzALSEku/TWaEsLUl nry7wAqx1kbi4toNYHEhgXKJp8+3gtkiAqYSB5fPA5sjISArsen+Y+YJjAKzkFw6C+HSWUim LmBkXsUoUJSak1hppJdYUJCTqpecn7uJERyChc47GI8tszrEKMDBqMTDqzHPKlKINbGsuDL3 EKMEB7OSCG/7RKAQb0piZVVqUX58UWlOavEhxiqgXyYyS4km5wPjI68k3tDExMDE2NjM2Njc xJwqwkrivMleFpFCAumJJanZqakFqUUwy5k4OKUaGFV+qi7yv1C/YlPti5d13NEJ82Zl3IuZ zpQY1/jq4Tr3t9oKj/ye7lxvqNeRIZLCWVB6+rfji/ZHEyf8kZQ/65d4f/azdLuqIBaTNZEs dvW/dd4dqLfibw3t13i17ktvtvmaNg0LbqkgNYXyuXMONvfJHOHt2HdMZ+bPieHlpw3nZ9nc fBKYpMRSnJFoqMVcVJwIALib+5ycAgAA Archived-At: Subject: Re: [Taps] User-Space Networking in iOS 11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 16:16:33 -0000 HI Michael, > On Jun 8, 2017, at 7:13 PM, Michael Tuexen = wrote: >=20 > On 8. Jun 2017, at 15:50, Tommy Pauly wrote: >>=20 >> Hello, >>=20 >> I wanted to point the TAPS group to some of the work that we = announced this week at WWDC that relates to the Post-Sockets API effort. = You can see a video of the session here (relevant section at ~13:50), = along with the slides: >>=20 >> https://developer.apple.com/videos/play/wwdc2017/707 >>=20 >> In the current betas of iOS 11, we have introduced =E2=80=9CUser-Space = Networking=E2=80=9D beneath our networking APIs. The transport and IP = protocols are now being co-located with the security and application = protocols in the process, meaning that we are no longer using sockets = within the implementation of these APIs. This shift allows us to reduce = the context switches between protocol layers, and could potentially open = opportunities for the kind of stack flexibility and customization that = the TAPS group is looking at. We=E2=80=99re excited to be making some = first steps into a truly =E2=80=9CPost-Sockets=E2=80=9D world! > Hi Tommy, >=20 > so this means I can run my own TCP stack and my own IPv6 stack in my = application, if I understood that correctly. > How is the port number space managed between the different = applications? I'm wondering how the demultiplexing is > done? > Can I also use the API for a transport protocol supporting the port = number concept, but not being UDP or TCP, > like SCTP or UDP-Lite or DCCP or whatever might come up in the future? The ability to run your own stack is not currently exposed; the = user-space stack for TCP, etc, is part of the system library. However, = this architecture does open up the possibility to extend or modify this = in the future. If people have specific ways that they think this would = be most useful to extend and modify, please let me know. The kernel is still responsible for managing the port namespace between = applications, and demultiplexing incoming packets to the correct = processes. Since that is part of the kernel, the port demultiplexing = still needs to understand where to look for port numbers in known = protocols. It seems like for the use-case you=E2=80=99re mentioning for = new protocols, it could be useful to allow that logic to be extended, or = =E2=80=98learn=E2=80=99 new protocols. This isn=E2=80=99t something = we=E2=80=99re doing now, but definitely an interesting idea! Thanks, Tommy >=20 > Best regards > Michael >>=20 >> Thanks, >> Tommy >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Jun 9 10:04:39 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BC9128C81 for ; Fri, 9 Jun 2017 10:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 s_UXk8RrDvvT for ; Fri, 9 Jun 2017 10:04:35 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 6F772126C89 for ; Fri, 9 Jun 2017 10:04:34 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 185B7A5; Fri, 9 Jun 2017 19:04:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1497027872; bh=3nITu4PF2CXKyNAlRn2ubED8lkZLmxqobAcsG2sYKsw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=GvhGynrTia/ha72mttnR/cISlDzbKc6a7dXF51LDFhFDh1fOiCtK0oUHk4LFnVyn+ 3CQycruxrTwlV3zo56dtIfAT95+Y2hz8eO1Jja6hUPIkMdIdx3MkCVJp+WAusWTifG C+fOPVCcQP5FpqMv60B+mNwvEwuyDOmDh6Wdum/8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 13C47A2; Fri, 9 Jun 2017 19:04:32 +0200 (CEST) Date: Fri, 9 Jun 2017 19:04:32 +0200 (CEST) From: Mikael Abrahamsson To: Tommy Pauly cc: taps WG In-Reply-To: <06989608-DB4D-4C88-8F7A-D52FB82E4771@apple.com> Message-ID: References: <197539C8-A6D7-4A94-9897-B0D49DE07781@apple.com> <06989608-DB4D-4C88-8F7A-D52FB82E4771@apple.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1579517998-1497027872=:17963" Archived-At: Subject: Re: [Taps] User-Space Networking in iOS 11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 17:04:38 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1579517998-1497027872=:17963 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 9 Jun 2017, Tommy Pauly wrote: > The kernel is still responsible for managing the port namespace between > applications, and demultiplexing incoming packets to the correct > processes. Since that is part of the kernel, the port demultiplexing > still needs to understand where to look for port numbers in known > protocols. It seems like for the use-case you’re mentioning for new > protocols, it could be useful to allow that logic to be extended, or > ‘learn’ new protocols. This isn’t something we’re doing now, but > definitely an interesting idea! Also sounds like a use-case for the work on "device should be handed multiple addresses". If it were, you could multiple in a way that each process that needed to have its own port space or run special protocols, could get unique usage of a newly allocated IPv6 address. If this is something that would be useful, it would be good if this use-case was brought to 6man and v6ops. It would probably be more credible if you brought it than if I did. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1579517998-1497027872=:17963-- From nobody Fri Jun 9 16:55:59 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55071200FC for ; Fri, 9 Jun 2017 16:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 qZuFECYogqvk for ; Fri, 9 Jun 2017 16:55:44 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E79126C89 for ; Fri, 9 Jun 2017 16:55:42 -0700 (PDT) Received: from [10.65.20.152] (CPE00180a85ab99-CM00fc8dce3840.cpe.net.cable.rogers.com [174.112.21.213]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 173AC721E281E; Sat, 10 Jun 2017 01:55:37 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Tuexen In-Reply-To: <06989608-DB4D-4C88-8F7A-D52FB82E4771@apple.com> Date: Fri, 9 Jun 2017 19:55:32 -0400 Cc: taps WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <197539C8-A6D7-4A94-9897-B0D49DE07781@apple.com> <06989608-DB4D-4C88-8F7A-D52FB82E4771@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Taps] User-Space Networking in iOS 11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 23:55:48 -0000 > On 9. Jun 2017, at 12:16, Tommy Pauly wrote: >=20 > HI Michael, >=20 >> On Jun 8, 2017, at 7:13 PM, Michael Tuexen = wrote: >>=20 >> On 8. Jun 2017, at 15:50, Tommy Pauly wrote: >>>=20 >>> Hello, >>>=20 >>> I wanted to point the TAPS group to some of the work that we = announced this week at WWDC that relates to the Post-Sockets API effort. = You can see a video of the session here (relevant section at ~13:50), = along with the slides: >>>=20 >>> https://developer.apple.com/videos/play/wwdc2017/707 >>>=20 >>> In the current betas of iOS 11, we have introduced =E2=80=9CUser-Space= Networking=E2=80=9D beneath our networking APIs. The transport and IP = protocols are now being co-located with the security and application = protocols in the process, meaning that we are no longer using sockets = within the implementation of these APIs. This shift allows us to reduce = the context switches between protocol layers, and could potentially open = opportunities for the kind of stack flexibility and customization that = the TAPS group is looking at. We=E2=80=99re excited to be making some = first steps into a truly =E2=80=9CPost-Sockets=E2=80=9D world! >> Hi Tommy, >>=20 >> so this means I can run my own TCP stack and my own IPv6 stack in my = application, if I understood that correctly. >> How is the port number space managed between the different = applications? I'm wondering how the demultiplexing is >> done? >> Can I also use the API for a transport protocol supporting the port = number concept, but not being UDP or TCP, >> like SCTP or UDP-Lite or DCCP or whatever might come up in the = future? >=20 > The ability to run your own stack is not currently exposed; the = user-space stack for TCP, etc, is part of the system library. However, = this architecture does open up the possibility to extend or modify this = in the future. If people have specific ways that they think this would = be most useful to extend and modify, please let me know. >=20 > The kernel is still responsible for managing the port namespace = between applications, and demultiplexing incoming packets to the correct = processes. Since that is part of the kernel, the port demultiplexing = still needs to understand where to look for port numbers in known = protocols. It seems like for the use-case you=E2=80=99re mentioning for = new protocols, it could be useful to allow that logic to be extended, or = =E2=80=98learn=E2=80=99 new protocols. This isn=E2=80=99t something = we=E2=80=99re doing now, but definitely an interesting idea! Leaving the port multiplexing / demultiplexing at the kernel makes a lot = of sense. Are you doing something like: * open a TCP socket. * bind it. * set a socket option that you want to send/recv raw TCP packets That way you could pass the packets up and down to a userland stack and = could coexist with a kernel stack. (Assuming that the kernel/userland boundary = still uses sockets). However, that doesn't fit the figure shown a WWDC, where you had the IP = stack and the TCP as part of the userland stack. So does the application the route = selection, interface selection? Is there any documentation available for the interface between kernel = land and userland? Is the same architecture available on Mac OS X? Best regards Michael >=20 > Thanks, > Tommy >=20 >>=20 >> Best regards >> Michael >>>=20 >>> Thanks, >>> Tommy >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 From nobody Sat Jun 10 10:04:50 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084691205D3 for ; Sat, 10 Jun 2017 10:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 ukr3aA9HCqug for ; Sat, 10 Jun 2017 10:04:46 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 8BBE41200E5 for ; Sat, 10 Jun 2017 10:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497114286; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=X2YU3mShFNY2rskDVtqzAQnU3iAsHj1aCImj9aJ56Lg=; b=o2zlDgoZb4pT6iHYWIVzb2tlIcZVm1VhnfBi+cB1c6AAN7gzoCwNz5FmGSnHsuCb EGVUnOKjdDVDgersoBF5Y78JlqSjOBWsgfEcirj03IGnh4GDy/UENp35iONtavdA GaAO13DfGH7eJbMvw9eLE+6ipY+8+Wc6rnQt3G3lW5bMZRB3EIfjD2e4eNaazsWo aYoc4sr+jmlki0BAovrZRt9yY5dZQv0OFYlMQhstZ3RMSBZTKPEttp0HSVChFijC ELxX6v+I+9kV9utVcsefdWhbAhmixvYq6DsGkS3eM8LgOwAIt8RYbZddrK57NvoK cQfFwhVMgbEdizzx1OimmA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 37.47.07949.DA62C395; Sat, 10 Jun 2017 10:04:46 -0700 (PDT) X-AuditID: 11973e16-0c7789a000001f0d-c1-593c26ad96b8 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay6.apple.com (Apple SCV relay) with SMTP id F6.F7.09762.DA62C395; Sat, 10 Jun 2017 10:04:45 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_AesdPrbTAW+QuKCZ9c6JXQ)" Received: from [17.153.73.32] (unknown [17.153.73.32]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORC00MZUCRW9350@nwk-mmpp-sz09.apple.com>; Sat, 10 Jun 2017 10:04:45 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <9A11C380-B235-4765-B113-31B3933D729F@apple.com> Date: Sat, 10 Jun 2017 10:04:43 -0700 In-reply-to: Cc: taps WG To: Michael Tuexen References: <197539C8-A6D7-4A94-9897-B0D49DE07781@apple.com> <06989608-DB4D-4C88-8F7A-D52FB82E4771@apple.com> X-Mailer: Apple Mail (2.3431) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUi2FAYpbtOzSbSYHEfq8XFpiWMFndiHJg8 liz5yeSxoWUHUwBTFJdNSmpOZllqkb5dAlfG69vBBZt3M1YsWLqSvYHxykLGLkZODgkBE4kJ D1rZuhi5OIQEVjNJ9OyezQSTuPDiODOILSRwkFHi4NtSEJtXQFDix+R7LCA2s0CYxMKXTewQ zf1MEpNfHQNq5uAQFpCQ2LwnEaSGTUBF4vi3DcwQvTYS17s72EFsYQFjifN7n4PFWQRUJX7/ +ckGYnMKuEr8WPAFar60xNJvk8EOFREwlTi4fB4LxD1PGSXWzXKEuFNWYtP9x8wQ9gE2ib8v UiYwCs1CcuosJKfOArqOWUBdYsqUXIiwtsSTdxdYIWw1iYW/FzEhiy9gZFvFKJSbmJmjm5ln rpdYUJCTqpecn7uJERQF0+3EdjA+XGV1iFGAg1GJh1djnlWkEGtiWXFl7iFGaQ4WJXHeClvr SCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2Ma1amTmK6+fBywPSws7N6suf1tUtOlfvEcorp yPm/x/n9n32I2nVTT0//nlPt7v8yLCtn1NSL5n09FLRqgmjonr0udhOZdwpOf3nryfu4jjvV 9U+9t94MULgh+H5p2M6ihjWOfEuUt5ofE2ed/KCtR3Sm803Gozb73kwP3m0/rbBv0o1Nirfm XFdiKc5INNRiLipOBABo3XoVYwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUi2FAcoLtWzSbS4PZMHYuLTUsYLe7EODB5 LFnyk8ljQ8sOpgCmKC6blNSczLLUIn27BK6M17eDCzbvZqxYsHQlewPjlYWMXYycHBICJhIX XhxnBrGFBA4yShx8Wwpi8woISvyYfI8FxGYWCJNY+LKJvYuRC6imn0li8qtjTF2MHBzCAhIS m/ckgtSwCahIHP+2gRmi10biencHO4gtLGAscX7vc7A4i4CqxO8/P9lAbE4BV4kfC75AzZeW WPptMtg9IgKmEgeXz2OBuOcpo8S6WY4Qd8pKbLr/mHkCI/8sJOfNQnLeLKCLmAXUJaZMyYUI a0s8eXeBFcJWk1j4exETsvgCRrZVjAJFqTmJlWZ6iQUFOal6yfm5mxjBYVsYtYOxYbnVIUYB DkYlHl6NeVaRQqyJZcWVuYcYJTiYlUR42ycChXhTEiurUovy44tKc1KLDzFOZAR6ciKzlGhy PjCq8kriDU1MDEyMjc2Mjc1NzGkprCTOm+RlESkkkJ5YkpqdmlqQWgRzFBMHp1QDo1zfFlOB 9V5b82alss96vFeFqWalwcfHN5YEM7bP4Vmh8HX1mhc7W7r7eYJWP/gmuDDay2zzsp1ih+cW n9Do6LbZ6RY/SW+L8QeR+TP/zZ9cEWn6+dDWPNvr9+ecmbn1v37S/IOl84TETopaVPVyZ+wo 5VlUP/Nwgk5g/OGNTT8/zriW9qN691QlluKMREMt5qLiRADhKGrtzgIAAA== Archived-At: Subject: Re: [Taps] User-Space Networking in iOS 11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 17:04:49 -0000 --Boundary_(ID_AesdPrbTAW+QuKCZ9c6JXQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Jun 9, 2017, at 4:55 PM, Michael Tuexen = wrote: >=20 >> On 9. Jun 2017, at 12:16, Tommy Pauly wrote: >>=20 >> HI Michael, >>=20 >>> On Jun 8, 2017, at 7:13 PM, Michael Tuexen = wrote: >>>=20 >>> On 8. Jun 2017, at 15:50, Tommy Pauly wrote: >>>>=20 >>>> Hello, >>>>=20 >>>> I wanted to point the TAPS group to some of the work that we = announced this week at WWDC that relates to the Post-Sockets API effort. = You can see a video of the session here (relevant section at ~13:50), = along with the slides: >>>>=20 >>>> https://developer.apple.com/videos/play/wwdc2017/707 >>>>=20 >>>> In the current betas of iOS 11, we have introduced =E2=80=9CUser-Spac= e Networking=E2=80=9D beneath our networking APIs. The transport and IP = protocols are now being co-located with the security and application = protocols in the process, meaning that we are no longer using sockets = within the implementation of these APIs. This shift allows us to reduce = the context switches between protocol layers, and could potentially open = opportunities for the kind of stack flexibility and customization that = the TAPS group is looking at. We=E2=80=99re excited to be making some = first steps into a truly =E2=80=9CPost-Sockets=E2=80=9D world! >>> Hi Tommy, >>>=20 >>> so this means I can run my own TCP stack and my own IPv6 stack in my = application, if I understood that correctly. >>> How is the port number space managed between the different = applications? I'm wondering how the demultiplexing is >>> done? >>> Can I also use the API for a transport protocol supporting the port = number concept, but not being UDP or TCP, >>> like SCTP or UDP-Lite or DCCP or whatever might come up in the = future? >>=20 >> The ability to run your own stack is not currently exposed; the = user-space stack for TCP, etc, is part of the system library. However, = this architecture does open up the possibility to extend or modify this = in the future. If people have specific ways that they think this would = be most useful to extend and modify, please let me know. >>=20 >> The kernel is still responsible for managing the port namespace = between applications, and demultiplexing incoming packets to the correct = processes. Since that is part of the kernel, the port demultiplexing = still needs to understand where to look for port numbers in known = protocols. It seems like for the use-case you=E2=80=99re mentioning for = new protocols, it could be useful to allow that logic to be extended, or = =E2=80=98learn=E2=80=99 new protocols. This isn=E2=80=99t something = we=E2=80=99re doing now, but definitely an interesting idea! > Leaving the port multiplexing / demultiplexing at the kernel makes a = lot of sense. Are you doing something > like: > * open a TCP socket. > * bind it. > * set a socket option that you want to send/recv raw TCP packets > That way you could pass the packets up and down to a userland stack = and could > coexist with a kernel stack. (Assuming that the kernel/userland = boundary still uses sockets). > However, that doesn't fit the figure shown a WWDC, where you had the = IP stack and the TCP > as part of the userland stack. So does the application the route = selection, interface > selection? The figure shown on the slides shows the TCP/IP stack in the = process-space since the actual formation of the TCP and IP headers is = done there, along with all of the TCP state machine logic and IP = fragment reassembly, etc. The kernel/user boundary is not using sockets = at all for these connections, but instead is using a new mechanism for = memory-mapping to the kernel. The application can influence the route = and interface selection with preferences (no-cellular, for example), = which are combined with the kernel policies and routing tables, as in = the Policy Context in the Post-Sockets draft. This provides a binding = for ports and interface, which is used for subsequent traffic flows and = is validated by the kernel on egress. Effectively, this means that the = IP part of the stack in user space can be thinner, since the routing = information is more fixed and doesn=E2=80=99t require more routing = lookups as is typically done in a kernel implementation. >=20 > Is there any documentation available for the interface between kernel = land and userland? No, not yet at this time. This is the initial roll-out of the = architecture, so it=E2=80=99s still early days. > Is the same architecture available on Mac OS X? We do not currently expose the same functionality on macOS. As mentioned = in the talk, this is in part due to the fact that it is not compatible = with network kernel extensions, which are common on macOS, but will be = deprecated at some point in the future. Thanks, Tommy >=20 > Best regards > Michael >>=20 >> Thanks, >> Tommy >>=20 >>>=20 >>> Best regards >>> Michael >>>>=20 >>>> Thanks, >>>> Tommy >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps = >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps = --Boundary_(ID_AesdPrbTAW+QuKCZ9c6JXQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On Jun 9, 2017, at 4:55 PM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:

On 9. Jun 2017, at 12:16, = Tommy Pauly <tpauly@apple.com> wrote:

HI= Michael,

On Jun 8, 2017, at 7:13 PM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:

On 8. Jun 2017, at 15:50, Tommy Pauly <tpauly@apple.com> = wrote:

Hello,

I wanted to point the = TAPS group to some of the work that we announced this week at WWDC that = relates to the Post-Sockets API effort. You can see a video of the = session here (relevant section at ~13:50), along with the slides:

https://developer.apple.com/videos/play/wwdc2017/707

In the current betas of iOS 11, we have = introduced =E2=80=9CUser-Space Networking=E2=80=9D beneath our = networking APIs. The transport and IP protocols are now being co-located = with the security and application protocols in the process, meaning that = we are no longer using sockets within the implementation of these APIs. = This shift allows us to reduce the context switches between protocol = layers, and could potentially open opportunities for the kind of stack = flexibility and customization that the TAPS group is looking at. We=E2=80=99= re excited to be making some first steps into a truly =E2=80=9CPost-Socket= s=E2=80=9D world!
Hi Tommy,

so this means I can run my own TCP stack and my own IPv6 = stack in my application, if I understood that correctly.
How= is the port number space managed between the different applications? = I'm wondering how the demultiplexing is
done?
Can I also use the API for a transport protocol supporting = the port number concept, but not being UDP or TCP,
like = SCTP or UDP-Lite or DCCP or whatever might come up in the future?

The ability to run your own stack = is not currently exposed; the user-space stack for TCP, etc, is part of = the system library. However, this architecture does open up the = possibility to extend or modify this in the future. If people have = specific ways that they think this would be most useful to extend and = modify, please let me know.

The kernel is = still responsible for managing the port namespace between applications, = and demultiplexing incoming packets to the correct processes. Since that = is part of the kernel, the port demultiplexing still needs to understand = where to look for port numbers in known protocols. It seems like for the = use-case you=E2=80=99re mentioning for new protocols, it could be useful = to allow that logic to be extended, or =E2=80=98learn=E2=80=99 new = protocols. This isn=E2=80=99t something we=E2=80=99re doing now, but = definitely an interesting idea!
Leaving the port multiplexing / = demultiplexing at the kernel makes a lot of sense. Are you doing = something
like:
* open a TCP socket.
* bind it.
* set a socket option that you = want to send/recv raw TCP packets
That way you could pass the = packets up and down to a userland stack and could
coexist with a kernel stack. (Assuming that the = kernel/userland boundary still uses sockets).
However, that doesn't fit the figure shown a = WWDC, where you had the IP stack and the TCP
as part of the userland stack. So does the = application the route selection, interface
selection?

The = figure shown on the slides shows the TCP/IP stack in the process-space = since the actual formation of the TCP and IP headers is done there, = along with all of the TCP state machine logic and IP fragment = reassembly, etc. The kernel/user boundary is not using sockets at all = for these connections, but instead is using a new mechanism for = memory-mapping to the kernel. The application can influence the route = and interface selection with preferences (no-cellular, for example), = which are combined with the kernel policies and routing tables, as in = the Policy Context in the Post-Sockets draft. This provides a binding = for ports and interface, which is used for subsequent traffic flows and = is validated by the kernel on egress. Effectively, this means that the = IP part of the stack in user space can be thinner, since the routing = information is more fixed and doesn=E2=80=99t require more routing = lookups as is typically done in a kernel implementation.


Is there any documentation available for = the interface between kernel land and userland?

No, = not yet at this time. This is the initial roll-out of the architecture, = so it=E2=80=99s still early days.

Is the same architecture = available on Mac OS X?

We do = not currently expose the same functionality on macOS. As mentioned in = the talk, this is in part due to the fact that it is not compatible with = network kernel extensions, which are common on macOS, but will be = deprecated at some point in the future.

Thanks,
Tommy


Best regards
Michael

Thanks,
Tommy


Best regards
Michael

Thanks,
Tommy
_______________________________________________
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

= --Boundary_(ID_AesdPrbTAW+QuKCZ9c6JXQ)-- From nobody Sat Jun 10 10:20:52 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFED127076 for ; Sat, 10 Jun 2017 10:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 QnOWBveaaO6e for ; Sat, 10 Jun 2017 10:20:49 -0700 (PDT) Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (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 C98D4126DC2 for ; Sat, 10 Jun 2017 10:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497115249; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OYEivEMBLTNqkfhJq+FXEyrBdyx9IsWYmi1TDvtWKrI=; b=kjcoqsI6TP1LACSqSFm4Od1eFL/uFBfKDQY8az6iz7Y1YWYEB8tN4fln3pzeOByI PMY3TQZQoYjHQbvSigw9byfvPVoMNwIMLFZwFPgP0d9Tvdxnow5sZKzSP9Bo7U06 VtM/R54lyl/WiE8a+udydACWXmFnYn6fOYA5ilBLlkMpKo8/xHAdQMRTxNMkdAdZ uOWXw5p8ssaXRsXjuiAMdHhujWom/bov3JPd1NY93L+VZKUpNJ7Atpg//ypWhv3s PwutVSZyLeWLxROWiVVjbD6/Kmd+NYcGKkvGomthQ4sYv44YxKskQr8fqzX2l2EM 8girR/Nr8z6UEttpOq+1lQ==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id 9D.8C.02110.07A2C395; Sat, 10 Jun 2017 10:20:49 -0700 (PDT) X-AuditID: 11ab0219-f49ff7000000083e-e5-593c2a6fe69b Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay7.apple.com (Apple SCV relay) with SMTP id 8F.04.18088.F6A2C395; Sat, 10 Jun 2017 10:20:47 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.153.73.32] (unknown [17.153.73.32]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORC002AWDIMB180@nwk-mmpp-sz11.apple.com>; Sat, 10 Jun 2017 10:20:47 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Sat, 10 Jun 2017 10:20:46 -0700 Cc: taps WG Content-transfer-encoding: quoted-printable Message-id: <997E3C15-610E-4648-B852-89F14D335019@apple.com> References: <197539C8-A6D7-4A94-9897-B0D49DE07781@apple.com> <06989608-DB4D-4C88-8F7A-D52FB82E4771@apple.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3431) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUi2FCYqluoZRNpcOIeo8XLpVvZLO7EODB5 LFnyk8nj76SHTAFMUVw2Kak5mWWpRfp2CVwZ9/6sYyz4LVixfs5/xgbGg3xdjJwcEgImEuce fWLuYuTiEBJYyyTxYNt/ti5GDrDEjiMREPFDjBI3L/xkAWngFRCU+DH5HgtIDbOAusSUKbkQ Nf1MEucbGlhB4sICEhKb9ySClAsLGEuc3/ucGcRmE1CROP5tA5jNKeAs8WPOezCbRUBV4trJ D2DjmQWkJZZ+m8wIYWtLPHl3gRVirY3E7L3z2SF2PWaUOHe0gx0kISKgKbFx+wY2iGdkJTbd fwz2jIRAI5vEwi+XGCcwCs9CcvcshLtnIdmxgJF5FaNwbmJmjm5mnpGpXmJBQU6qXnJ+7iZG UFivZpLcwfj1teEhRgEORiUeXo15VpFCrIllxZW5hxilOViUxHnzba0jhQTSE0tSs1NTC1KL 4otKc1KLDzEycXBKAUN7h8b9S0/7Rdk72Bb9qt+dIZcoXuttHHbksdyxV9mvRL7HPM23XZjP dZF1HfMjjcaFNzRDuLtZX8f9muvesSwwuepD1JbySQeF/T8rxzz5N83jtYqUl8o9N+3kHP3Z Hd68PAu5by5O1tjN5aF0g9dt8Zo6lSL3qZPKdt3i3LKRq2qTCauVjRJLcUaioRZzUXEiAI8C bhBMAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUi2FA8WzdfyybS4H+3uMXLpVvZLO7EODB5 LFnyk8nj76SHTAFMUVw2Kak5mWWpRfp2CVwZ9/6sYyz4LVixfs5/xgbGg3xdjBwcEgImEjuO RHQxcnEICRxilLh54SdLFyMnB6+AoMSPyfdYQGqYBdQlpkzJhajpZ5I439DAChIXFpCQ2Lwn EaRcWMBY4vze58wgNpuAisTxbxvAbE4BZ4kfc96D2SwCqhLXTn4AG88sIC2x9NtkRghbW+LJ uwusEGttJGbvnc8Osesxo8S5ox3sIAkRAU2Jjds3sIHYEgKyEpvuP2aewCgwC8mpsxBOnYVk 7AJG5lWMAkWpOYmV5nqJBQU5qXrJ+bmbGMFBWJi6g7FxudUhRgEORiUeXo15VpFCrIllxZW5 wLDgYFYS4W2fCBTiTUmsrEotyo8vKs1JLT7EKM3BoiTOm+plESkkkJ5YkpqdmlqQWgSTZeLg lGpgDCu3m70+9M+LQz4lb3ueH/5Q0v8qmn9PiunZJSKaW2ub9mw6OfNLBZtY2Z3t2i83Pj61 9/qsWWpX7i7mmbkpb2nhf/+lyzz37zil1txiO3+eGNOWZsnWprrnBb/apoWb2wbs/qn6M/W8 +ebsasHA6bs91yi8UjH7Om+zhK0M1xphFr4Vu096qSixFGckGmoxFxUnAgBZtUzzPgIAAA== Archived-At: Subject: Re: [Taps] User-Space Networking in iOS 11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 17:20:51 -0000 > On Jun 9, 2017, at 10:04 AM, Mikael Abrahamsson = wrote: >=20 > On Fri, 9 Jun 2017, Tommy Pauly wrote: >=20 >> The kernel is still responsible for managing the port namespace = between applications, and demultiplexing incoming packets to the correct = processes. Since that is part of the kernel, the port demultiplexing = still needs to understand where to look for port numbers in known = protocols. It seems like for the use-case you=E2=80=99re mentioning for = new protocols, it could be useful to allow that logic to be extended, or = =E2=80=98learn=E2=80=99 new protocols. This isn=E2=80=99t something = we=E2=80=99re doing now, but definitely an interesting idea! >=20 > Also sounds like a use-case for the work on "device should be handed = multiple addresses". If it were, you could multiple in a way that each = process that needed to have its own port space or run special protocols, = could get unique usage of a newly allocated IPv6 address. >=20 > If this is something that would be useful, it would be good if this = use-case was brought to 6man and v6ops. It would probably be more = credible if you brought it than if I did. Hi Mikael, A per-process IPv6 address is not something we=E2=80=99re doing at this = time, but it=E2=80=99s certainly a natural extension of an in-process = networking stack. If the device is being allocated multiple IPv6 = address, and ideally a /64, as recommended by RFC 7934, then the host = system could assign an address to each process, or at least each process = that has beyond-ordinary networking needs. This could also have interesting implications for a device that=E2=80=99s = dealing with multiple Provisioning Domains (PvDs). Processes could be = grouped to share the address/port namespaces of a given PvD; for = example, enterprise applications could be using a common address and set = of ports, while personal applications could be sharing another set. The main open question I would have would be around how an application = would express that it should be using a separate address-space, or how = that would be indicated as some sort of TAPS parameters. Any ideas are = welcome =3D) Thanks, Tommy >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Jun 11 01:33:32 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499AB1294BD for ; Sun, 11 Jun 2017 01:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 7ejpSra5x__J for ; Sun, 11 Jun 2017 01:33:27 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA286120721 for ; Sun, 11 Jun 2017 01:33:26 -0700 (PDT) Received: from [192.168.1.204] (p57BB435B.dip0.t-ipconnect.de [87.187.67.91]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id DA4A5721E280C; Sun, 11 Jun 2017 10:33:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Tuexen In-Reply-To: <9A11C380-B235-4765-B113-31B3933D729F@apple.com> Date: Sun, 11 Jun 2017 10:33:21 +0200 Cc: taps WG Content-Transfer-Encoding: quoted-printable Message-Id: <3B134837-FBAE-4516-A926-5549DEE4DD85@lurchi.franken.de> References: <197539C8-A6D7-4A94-9897-B0D49DE07781@apple.com> <06989608-DB4D-4C88-8F7A-D52FB82E4771@apple.com> <9A11C380-B235-4765-B113-31B3933D729F@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Taps] User-Space Networking in iOS 11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 08:33:30 -0000 > On 10. Jun 2017, at 19:04, Tommy Pauly wrote: >=20 >=20 >=20 >> On Jun 9, 2017, at 4:55 PM, Michael Tuexen = wrote: >>=20 >>> On 9. Jun 2017, at 12:16, Tommy Pauly wrote: >>>=20 >>> HI Michael, >>>=20 >>>> On Jun 8, 2017, at 7:13 PM, Michael Tuexen = wrote: >>>>=20 >>>> On 8. Jun 2017, at 15:50, Tommy Pauly wrote: >>>>>=20 >>>>> Hello, >>>>>=20 >>>>> I wanted to point the TAPS group to some of the work that we = announced this week at WWDC that relates to the Post-Sockets API effort. = You can see a video of the session here (relevant section at ~13:50), = along with the slides: >>>>>=20 >>>>> https://developer.apple.com/videos/play/wwdc2017/707 >>>>>=20 >>>>> In the current betas of iOS 11, we have introduced =E2=80=9CUser-Spa= ce Networking=E2=80=9D beneath our networking APIs. The transport and IP = protocols are now being co-located with the security and application = protocols in the process, meaning that we are no longer using sockets = within the implementation of these APIs. This shift allows us to reduce = the context switches between protocol layers, and could potentially open = opportunities for the kind of stack flexibility and customization that = the TAPS group is looking at. We=E2=80=99re excited to be making some = first steps into a truly =E2=80=9CPost-Sockets=E2=80=9D world! >>>> Hi Tommy, >>>>=20 >>>> so this means I can run my own TCP stack and my own IPv6 stack in = my application, if I understood that correctly. >>>> How is the port number space managed between the different = applications? I'm wondering how the demultiplexing is >>>> done? >>>> Can I also use the API for a transport protocol supporting the port = number concept, but not being UDP or TCP, >>>> like SCTP or UDP-Lite or DCCP or whatever might come up in the = future? >>>=20 >>> The ability to run your own stack is not currently exposed; the = user-space stack for TCP, etc, is part of the system library. However, = this architecture does open up the possibility to extend or modify this = in the future. If people have specific ways that they think this would = be most useful to extend and modify, please let me know. >>>=20 >>> The kernel is still responsible for managing the port namespace = between applications, and demultiplexing incoming packets to the correct = processes. Since that is part of the kernel, the port demultiplexing = still needs to understand where to look for port numbers in known = protocols. It seems like for the use-case you=E2=80=99re mentioning for = new protocols, it could be useful to allow that logic to be extended, or = =E2=80=98learn=E2=80=99 new protocols. This isn=E2=80=99t something = we=E2=80=99re doing now, but definitely an interesting idea! >> Leaving the port multiplexing / demultiplexing at the kernel makes a = lot of sense. Are you doing something >> like: >> * open a TCP socket. >> * bind it. >> * set a socket option that you want to send/recv raw TCP packets >> That way you could pass the packets up and down to a userland stack = and could >> coexist with a kernel stack. (Assuming that the kernel/userland = boundary still uses sockets). >> However, that doesn't fit the figure shown a WWDC, where you had the = IP stack and the TCP >> as part of the userland stack. So does the application the route = selection, interface >> selection? >=20 > The figure shown on the slides shows the TCP/IP stack in the = process-space since the actual formation of the TCP and IP headers is = done there, along with all of the TCP state machine logic and IP = fragment reassembly, etc. The kernel/user boundary is not using sockets = at all for these connections, but instead is using a new mechanism for = memory-mapping to the kernel. The application can influence the route = and interface selection with preferences (no-cellular, for example), = which are combined with the kernel policies and routing tables, as in = the Policy Context in the Post-Sockets draft. This provides a binding = for ports and interface, which is used for subsequent traffic flows and = is validated by the kernel on egress. Effectively, this means that the = IP part of the stack in user space can be thinner, since the routing = information is more fixed and doesn=E2=80=99t require more routing = lookups as is typically done in a kernel implementation. Ahh, I see. Similar to the multistack approach described in https://www.ietf.org/proceedings/95/slides/slides-95-tsvarea-2.pdf >=20 >>=20 >> Is there any documentation available for the interface between kernel = land and userland? >=20 > No, not yet at this time. This is the initial roll-out of the = architecture, so it=E2=80=99s still early days. >=20 >> Is the same architecture available on Mac OS X? >=20 > We do not currently expose the same functionality on macOS. As = mentioned in the talk, this is in part due to the fact that it is not = compatible with network kernel extensions, which are common on macOS, = but will be deprecated at some point in the future. I see. Thanks a lot for your explanations. They really help to = understand what Apple is providing! Best regards Michael >=20 > Thanks, > Tommy >=20 >>=20 >> Best regards >> Michael >>>=20 >>> Thanks, >>> Tommy >>>=20 >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>> Thanks, >>>>> Tommy >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >=20 From nobody Thu Jun 15 08:42:46 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77397128D2E for ; Thu, 15 Jun 2017 08:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YrTjMVzxxKqn for ; Thu, 15 Jun 2017 08:42:43 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9332127876 for ; Thu, 15 Jun 2017 08:42:43 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id l75so8179601ywc.3 for ; Thu, 15 Jun 2017 08:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=F1h2iQMQO1LFzY8V8/pn5HImbPwCDjNNTM0jt39HSP8=; b=u078/TjmWWCvpX7ViyHzg1JrTRfD0+O3JLcSuOD/rjzPiKVm5b38E1r0DXw1qom1R2 w0aqieGG1/mH+Xh+46MLNx37DaG8wCWv6aM55gY7L28Y3Gpd0Em/bQYEyGGRY3w7R8gQ jlElNm/z1LqOC8JrdIIHZd0moVd3E9WziXyYAAsSLw6X0nZZKz+zftKdlgys0/JOUAd4 d2E3TzuAFMZP4K8y6q3Up7FhoSkiorkG37kWtbxiWLzqEOzV9pYgq4emMjlU9flRj/g7 JNbhz0IWReCNawcgoCBG+49kyMSFOGFpwTNAB9wNo/Ti4/GuTVSeh4iCed1yBOivzUrl UtTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=F1h2iQMQO1LFzY8V8/pn5HImbPwCDjNNTM0jt39HSP8=; b=NmxCY53/G9rYrUJcovgiNRDE7CkdBncVx8I19yqB1St+NCamuCIcZODG8AvRRHjyrt 0JeS27sW0nzTk5R0PG9/TNbKs3VROV7LE334XyTHxTEBIDCxTme9tFcSQSoM2C/6dsuY w+p3UjGt/BM9Fr9PT/UAZW+o7qq8zPacnGUOQjJeM1Wc/NIK2NbnZ2RgOHP7ejhno3jS 72aSlLmo1htkwPYGcoiQwelM7yHlFi0sxnjurLrdyK9Oi5wJZdJOf6WZvxCGNGWJXeDV X6ECVvXtfiIHM2m1E41etAXV98gOurZRHT7flp//hcR5cwKCX4qIssXIC01scBWziVAy EbxA== X-Gm-Message-State: AKS2vOyz35oGqPFQ9Hxg33qhr0yPdx9rQkCeHA6KdqCUlW4JEsfvX+4/ 92jC6ABnsCbOaBk78Sk= X-Received: by 10.55.80.6 with SMTP id e6mr7491689qkb.122.1497541362861; Thu, 15 Jun 2017 08:42:42 -0700 (PDT) Received: from [169.254.200.31] ([72.246.0.14]) by smtp.gmail.com with ESMTPSA id m9sm299830qke.8.2017.06.15.08.42.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 08:42:42 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Thu, 15 Jun 2017 11:42:41 -0400 Message-ID: <0E92B2D0-7802-4568-A79B-BCC460E15646@gmail.com> In-Reply-To: <408986B2-B86B-4C7D-9E91-D554029579FA@gmail.com> References: <408986B2-B86B-4C7D-9E91-D554029579FA@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_AA211737-E7E6-4FF0-B7AD-71F16DDCF29B_=" X-Mailer: MailMate (1.9.6r5356) Archived-At: Subject: Re: [Taps] WGLC start for -transports-usage- docs X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 15:42:45 -0000 --=_MailMate_AA211737-E7E6-4FF0-B7AD-71F16DDCF29B_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Reminder: WGLC on these docs concludes this coming Monday. Please read = and comment. Thanks, =E2=80=94aaron On 29 May 2017, at 12:30, Aaron Falk wrote: > Dear TAPS working group: > > The authors have indicated the two drafts below are complete and are = > ready for a final working group review. WGLC starts today and will be = > three weeks, concluding June 19. Send comments, including an = > indication that the docs are ready for publication, to the working = > group list. > > * [On the Usage of Transport Features Provided by IETF Transport = > Protocols](https://www.ietf.org/internet-drafts/draft-ietf-taps-transpo= rts-usage-05.txt) > * [Features of the User Datagram Protocol (UDP) and Lightweight UDP = > (UDP- Lite) Transport = > Protocols](https://www.ietf.org/internet-drafts/draft-ietf-taps-transpo= rts-usage-udp-03.txt) > > > =E2=80=94aaron --=_MailMate_AA211737-E7E6-4FF0-B7AD-71F16DDCF29B_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Reminder: WGLC on these docs concludes this coming Monday= =2E Please read and comment.

Thanks,

=E2=80=94aaron

On 29 May 2017, at 12:30, Aaron Falk wrote:

Dear TAPS working group:

The authors have indicated the two drafts below are compl= ete and are ready for a final working group review. WGLC starts today an= d will be three weeks, concluding June 19. Send comments, including an i= ndication that the docs are ready for publication, to the working group l= ist.

=E2=80=94aaron

--=_MailMate_AA211737-E7E6-4FF0-B7AD-71F16DDCF29B_=-- From nobody Fri Jun 16 01:54:56 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E25B131717 for ; Fri, 16 Jun 2017 01:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 hiFN60d6ymO5 for ; Fri, 16 Jun 2017 01:54:52 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 3005D131714 for ; Fri, 16 Jun 2017 01:54:50 -0700 (PDT) X-Envelope-From: phils@in-panik.de X-Envelope-To: Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v5G8sR4B031022 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 16 Jun 2017 10:54:27 +0200 Received: from [2001:638:809:ff1f::8295:dc3a] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dLn1K-00031g-Rk for taps@ietf.org; Fri, 16 Jun 2017 10:54:22 +0200 From: "Philipp S. Tiesel" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <1977C9AB-7BD1-4651-ACA8-DF042759C683@in-panik.de> Date: Fri, 16 Jun 2017 10:54:26 +0200 To: taps WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Taps] =?utf-8?q?Socket_Intents_Draft_=E2=80=93_draft-tiesel-taps?= =?utf-8?q?-socketintents-00?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 08:54:54 -0000 Hi, I just uploaded draft-tiesel-taps-socketintents-00 to the data tracker = yesterday. https://datatracker.ietf.org/doc/draft-tiesel-taps-socketintents/ This draft should fits into point three of the TAPS charter. =20 Socket Intents allow applications to share their knowledge about = upcoming communication and express their performance preferences in an API = independent way. Therefore, thy can be used by an OS/API to gain enough knowledge to = perform access as well as transport protocol selection and tuning. A draft explaining an experimental implementation based on BSD sockets = will follow. I am looking forward to the discussion, here and in Prague. AVE! Philipp S. Tiesel / phils=E2=80=A6 From nobody Fri Jun 16 11:23:25 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC9E129B48 for ; Fri, 16 Jun 2017 11:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 cHVe8fb9BPSp for ; Fri, 16 Jun 2017 11:23:22 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 0B423126C22 for ; Fri, 16 Jun 2017 11:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497637401; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fwlH8kmXDy7K87Fyi9ozprtepHD+rI0WjBITJjuxnbk=; b=GPBkZ5P4I6RC+ap1WbyGwo+OBdXeorDRwMvyP8QaexV/Z/iSShje9Z6BG7LsY3fC iu5IVGOR4Ulf/Ynvxdw7v60id2BLFslGqBPuyXxXzz0Hywh16CY1yPxgPBXhSg85 XHdVcEOhKvRqVw6DYKegWstWVMDR6MjCR+OAbsaTi1k2ftCKjsbmvPjjTWa12bqB BozbePGOXjpV7tebnX/S2GVz8ef+Rux1bG1refTeuc3QqQkWNpmxdnVVx3FBTQ9N Q/m392qA2JZY6zpoMFUdXHvPnpcbSETJUckA7ypSWNaxsNpBD8WVDwpYYJvT8etO +hwHB7IAQ88cjfVwO9/4Cw==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id B2.4F.24649.91224495; Fri, 16 Jun 2017 11:23:21 -0700 (PDT) X-AuditID: 11973e15-f22c49a000006049-0b-59442219f969 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay8.apple.com (Apple SCV relay) with SMTP id D5.37.27384.91224495; Fri, 16 Jun 2017 11:23:21 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.153.94.85] (unknown [17.153.94.85]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORN00EG4KEXOJ40@nwk-mmpp-sz11.apple.com>; Fri, 16 Jun 2017 11:23:21 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <1977C9AB-7BD1-4651-ACA8-DF042759C683@in-panik.de> Date: Fri, 16 Jun 2017 11:23:20 -0700 Cc: taps WG Content-transfer-encoding: quoted-printable Message-id: <54C05CB6-2420-4632-8BE9-12C690F07414@apple.com> References: <1977C9AB-7BD1-4651-ACA8-DF042759C683@in-panik.de> To: "Philipp S. Tiesel" X-Mailer: Apple Mail (2.3435) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUi2FCYpiup5BJp8LZR16J9+TomizsxDkwe S5b8ZPJouSIcwBTFZZOSmpNZllqkb5fAlfH+9APmgs/CFY1npzA1ME4V6GLk5JAQMJE4f/ww I4gtJLCGSeLIZWWYePP18yxdjFxA8UOMEgd+9LCAJHgFBCV+TL4HZHNwMAuoS0yZkgtR088k Mff7MkaQuLCAhMTmPYkQZplEz1dZkE42ARWJ4982MIPYnAL2Em+fbwFbyyKgKvFy32SwOLOA tMTSb5MZIWxtiSfvLrCCjOEVsJH4MiEd4ko7iTnrvoKViACVHJi1mBHiYlmJLW3H2UGukRBY wCax7M499gmMwrOQHD0L4ehZSDYsYGRexSiUm5iZo5uZZ6aXWFCQk6qXnJ+7iREUzNPtRHcw nllldYhRgINRiYeX4bZzpBBrYllxZe4hRmkOFiVx3pl/nSKFBNITS1KzU1MLUovii0pzUosP MTJxcEo1MKZI7127WSJgiW7r0wVBaSZ7G62NOSLvfzK0DVnT3pn0R9C1L1ZjzVxJ1Z6V7McM BfliX3xPKTQwTr19L/B56Ytkv+/as833HtpzuS6AYee0Sbfnlqw/M1tt99VqxqxCjRcS254d Ziovv8CxYHfhFQX2R8E/Yz4vWKoqdWHDOsnfuvEfVefavlBiKc5INNRiLipOBACmBDrqRwIA AA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42IRbCierSup5BJp8GGRskX78nVMFndiHJg8 liz5yeTRckU4gCmKyyYlNSezLLVI3y6BK+P96QfMBZ+FKxrPTmFqYJwq0MXIySEhYCLRfP08 SxcjF4eQwCFGiQM/elhAErwCghI/Jt8Dsjk4mAXUJaZMyYWo6WeSmPt9GSNIXFhAQmLznkQI s0yi56ssSCebgIrE8W8bmEFsTgF7ibfPtzCC2CwCqhIv900GizMLSEss/TaZEcLWlnjy7gIr yBheARuJLxPSQcJCAnYSc9Z9BSsRASo5MGsxI8TFshJb2o6zT2AUmIXkzlkId85CMnQBI/Mq RoGi1JzESgu9xIKCnFS95PzcTYzg8CtM28HYtNzqEKMAB6MSDy+DhWOkEGtiWXFlLjAgOJiV RHhvrwcK8aYkVlalFuXHF5XmpBYfYqwCemUis5Rocj4wNvJK4g1NTAxMjI3NjI3NTcypIqwk zlsU4BQpJJCeWJKanZpakFoEs5yJg1OqgVHEUmLV1CtXXHyyV6h93u/zanXDTM2PL0SeTjZj Uo/98bV9zx6Ji6ca9lx611z39aymcOL65KJfZz6piF93aBN8d6NN3X/rlP2fXReJMC56psf/ 5rV7tP/Da03r/4Yxczno7bLO27Dv+IHANeE381hZVnnJclbYVp3dWuA1T774u4392y0igRlK LMUZiYZazEXFiQBLe2ovmgIAAA== Archived-At: Subject: Re: [Taps] =?utf-8?q?Socket_Intents_Draft_=E2=80=93_draft-tiesel-tap?= =?utf-8?q?s-socketintents-00?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 18:23:24 -0000 Hi Philipp, Thanks for sharing this document! Providing an API for generic network = intents is something of a Holy Grail=E2=80=94valuable but elusive to = nail down. This document should be a good place to start a conversation, = and I look forward to discussing it in Prague. A few initial comments: - I=E2=80=99d love to see the terminology be less sockets-specific, = especially considering the work for Post-Sockets APIs. A set of intents = should be able to be applied to individual messages being sent or on a = higher-level protocol, ideally, not just on the level of a transport = connection as represented by a socket. - Certain properties, like burstiness, are focused on what the = application will be sending, and what its sending pattern will look = like. This works fine for some use cases, but in the case of downloads, = the application may not have enough/any insight into what patterns the = server will have. What do you think the best way to account for this is? - While explicit intents are a great way to avoid ossification, I would = also argue that we should minimize the surface of the intents in order = to reduce the complexity for application writers. Do you think that some = of these intent properties can also be inferred automatically based on = the traffic patterns observed by the system? I=E2=80=99m thinking here = of traffic category, in which we=E2=80=99re asking the app to say if = they=E2=80=99re using queries or streams or bulk downloads, etc. Thanks, Tommy > On Jun 16, 2017, at 1:54 AM, Philipp S. Tiesel = wrote: >=20 > Hi, >=20 > I just uploaded draft-tiesel-taps-socketintents-00 to the data tracker = yesterday. > https://datatracker.ietf.org/doc/draft-tiesel-taps-socketintents/ >=20 > This draft should fits into point three of the TAPS charter. >=20 > Socket Intents allow applications to share their knowledge about = upcoming > communication and express their performance preferences in an API = independent way. > Therefore, thy can be used by an OS/API to gain enough knowledge to = perform access > as well as transport protocol selection and tuning. >=20 > A draft explaining an experimental implementation based on BSD sockets = will follow. >=20 > I am looking forward to the discussion, here and in Prague. >=20 > AVE! > Philipp S. Tiesel / phils=E2=80=A6 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Sat Jun 17 03:02:21 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FAA12702E for ; Sat, 17 Jun 2017 03:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 vj_e4u2VasAF for ; Sat, 17 Jun 2017 03:02:16 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 A39AE120721 for ; Sat, 17 Jun 2017 03:02:16 -0700 (PDT) Received: from mail-mx05.uio.no ([129.240.10.49]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dMAYX-0003wr-Gr for taps@ietf.org; Sat, 17 Jun 2017 12:02:13 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx05.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dMAYW-000C0T-Qc for taps@ietf.org; Sat, 17 Jun 2017 12:02:13 +0200 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 17 Jun 2017 12:02:14 +0200 References: <1977C9AB-7BD1-4651-ACA8-DF042759C683@in-panik.de> <54C05CB6-2420-4632-8BE9-12C690F07414@apple.com> To: "taps@ietf.org" In-Reply-To: <54C05CB6-2420-4632-8BE9-12C690F07414@apple.com> Message-Id: <68CB4570-7371-49EA-8E62-20F424FB0E41@ifi.uio.no> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx05.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 2 sum msgs/h 2 total rcpts 55711 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.087, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6466FC4A1D23BC268A3BA89059077E7B896AE327 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1592 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] =?utf-8?q?Socket_Intents_Draft_=E2=80=93_draft-tiesel-tap?= =?utf-8?q?s-socketintents-00?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 10:02:20 -0000 Hi, Thanks indeed for sharing this - I think this is very interesting input = to the group. I agree with the things Tommy says below, but I have some additional = thoughts that I wanted to share. Our charter is about existing protocols and what they can do. For TCP, = MPTCP, UDP, UDP-Lite, SCTP and LEBAT, draft-gjessing-taps-minset breaks = this list down into transport features that really must be exposed in = order to become usable, some that really shouldn=E2=80=99t be exposed = (as they would forever tie your application to one specific protocol = only), and some that could (perhaps) be automatized. So, with that in mind, if I try to imagine how to implement a system = implementing draft-tiesel-taps-socketintents on top of TCP, MPTCP, UDP, = =E2=80=A6etc, I see two degrees of freedom here: 1) deciding which protocol to use, and making good use of the features = that we call =E2=80=9Cautomatable=E2=80=9D in = draft-gjessing-taps-minset. As a concrete example, we say that the = choice of the network interface is based on network- or OS-wide, but not = application-specific knowledge, and so it should be automatable. = However, making a choice does need *some* knowledge about app behavior, = and this is exactly a hole that some of the things in = draft-tiesel-taps-socketintents appear to fill. 2) I guess that some of the services of protocols can be = =E2=80=9Ctranslated=E2=80=9D into a slightly different representation. = Here I=E2=80=99m thinking of your =E2=80=9CApplication Resilience=E2=80=9D= , for example: how does this relate to "Change timeout for aborting = connection (using retransmit limit or time value)=E2=80=9D (from (MP)TCP = and SCTP) and "Suggest timeout to the peer=E2=80=9D (from (MP)TCP, via = UTO)? Isn=E2=80=99t a very disruption-resilient application going to = want a large timeout value? But then maybe such resilience is best = configured in seconds=E2=80=A6 and =E2=80=9Ctimeliness=E2=80=9D in your section 5.6 pretty obviously = maps to "Specify DSCP field=E2=80=9D (from (MP)TCP, SCTP and UDP(-Lite)) = - which we actually already combined with other things and translated = into a higher-level representation that we call =E2=80=9Ccapacity = profile=E2=80=9D in = https://tools.ietf.org/html/draft-gjessing-taps-minset-04#section-5.5 I understand that the idea of socket intents is to describe an = application=E2=80=99s behaviour, not request QoS - but using the DSCP as = in draft-ietf-tsvwg-rtcweb-qos isn=E2=80=99t about guarantees either. = All in all, considering just the API, I don=E2=80=99t see much = difference between an application using socket intents and choosing = =E2=80=9Cbackground=E2=80=9D or using the DSCP value and choosing = =E2=80=9Cbackground=E2=80=9D. Once a TAPS system has this information, = the question becomes what it really does with it (truly set the DSCP = value, or do something else?). So these were just some thoughts. To summarize, I think it would be = interesting to see how the things in draft-tiesel-taps-socketintents map = to: - the choice of protocols - configuring transport features of existing protocols that we call = =E2=80=9Cautomatable=E2=80=9D - and simply using transport features that, according to = draft-gjessing-taps-minset, already should be exposed anyway.=20 Cheers, Michael > On Jun 16, 2017, at 8:23 PM, Tommy Pauly wrote: >=20 > Hi Philipp, >=20 > Thanks for sharing this document! Providing an API for generic network = intents is something of a Holy Grail=E2=80=94valuable but elusive to = nail down. This document should be a good place to start a conversation, = and I look forward to discussing it in Prague. >=20 > A few initial comments: >=20 > - I=E2=80=99d love to see the terminology be less sockets-specific, = especially considering the work for Post-Sockets APIs. A set of intents = should be able to be applied to individual messages being sent or on a = higher-level protocol, ideally, not just on the level of a transport = connection as represented by a socket. >=20 > - Certain properties, like burstiness, are focused on what the = application will be sending, and what its sending pattern will look = like. This works fine for some use cases, but in the case of downloads, = the application may not have enough/any insight into what patterns the = server will have. What do you think the best way to account for this is? >=20 > - While explicit intents are a great way to avoid ossification, I = would also argue that we should minimize the surface of the intents in = order to reduce the complexity for application writers. Do you think = that some of these intent properties can also be inferred automatically = based on the traffic patterns observed by the system? I=E2=80=99m = thinking here of traffic category, in which we=E2=80=99re asking the app = to say if they=E2=80=99re using queries or streams or bulk downloads, = etc. >=20 > Thanks, > Tommy >=20 >> On Jun 16, 2017, at 1:54 AM, Philipp S. Tiesel = wrote: >>=20 >> Hi, >>=20 >> I just uploaded draft-tiesel-taps-socketintents-00 to the data = tracker yesterday. >> https://datatracker.ietf.org/doc/draft-tiesel-taps-socketintents/ >>=20 >> This draft should fits into point three of the TAPS charter. >>=20 >> Socket Intents allow applications to share their knowledge about = upcoming >> communication and express their performance preferences in an API = independent way. >> Therefore, thy can be used by an OS/API to gain enough knowledge to = perform access >> as well as transport protocol selection and tuning. >>=20 >> A draft explaining an experimental implementation based on BSD = sockets will follow. >>=20 >> I am looking forward to the discussion, here and in Prague. >>=20 >> AVE! >> Philipp S. Tiesel / phils=E2=80=A6 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Sat Jun 17 04:38:27 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59544128CF0 for ; Sat, 17 Jun 2017 04:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 1u0XaD1LRGci for ; Sat, 17 Jun 2017 04:38:24 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 BB46F128BC8 for ; Sat, 17 Jun 2017 04:38:22 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v5HBbvsn007919 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 17 Jun 2017 13:37:57 +0200 Received: from [2001:bf0:c801:101:f8ea:165c:4f1c:37ca] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dMC36-0003jX-Sc; Sat, 17 Jun 2017 13:37:52 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Philipp S. Tiesel" In-Reply-To: <54C05CB6-2420-4632-8BE9-12C690F07414@apple.com> Date: Sat, 17 Jun 2017 13:37:56 +0200 Cc: taps WG Content-Transfer-Encoding: quoted-printable Message-Id: <5675BF0A-5817-49B8-9477-18B055D49A6F@in-panik.de> References: <1977C9AB-7BD1-4651-ACA8-DF042759C683@in-panik.de> <54C05CB6-2420-4632-8BE9-12C690F07414@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Taps] =?utf-8?q?Socket_Intents_Draft_=E2=80=93_draft-tiesel-tap?= =?utf-8?q?s-socketintents-00?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 11:38:26 -0000 Hi Tommy, thanks for your appreciation and comments. =20 > A few initial comments: >=20 > - I=E2=80=99d love to see the terminology be less sockets-specific, = especially considering the work for Post-Sockets APIs. A set of intents = should be able to be applied to individual messages being sent or on a = higher-level protocol, ideally, not just on the level of a transport = connection as represented by a socket. I totally agree that the Idea of Intents is not limited to sockets and = the transport layer, but the Idea started from there. =20 Background: The the original idea was very close to the sockets and = targeted at deciding which network interface to use for upcoming = connections. We extended this in the meantime to smaller communication = units (HTTP Request/Response pairs) and it worked very well in = simulations and our prototype using the "Object Size=E2=80=9D Intent. I = try to give more background on this in an additional draft.=20 I take making the terminology be less sockets-specific as a ToDo-Item = for the -01 version. By introducing an applicability scope and choosing levels that do not = directly map the protocol layering, but an abstract=20 layering of functionality (Flow, Association, Stream, or Object level), = I took the first step towards a more generic abstraction. For me, Object level indeed would include individual messages in an = application layer protocol like HTTP Requests. Question: Is this sufficient or do we need to need more or different = levels? We might also consider postponing this question as we are now in the = progress of writing a draft on explaining this levels and how multipath-funtionality may be distributed over them.=20= =20 > - Certain properties, like burstiness, are focused on what the = application will be sending, and what its sending pattern will look = like. This works fine for some use cases, but in the case of downloads, = the application may not have enough/any insight into what patterns the = server will have. What do you think the best way to account for this is? Currently, In this cases I would either not set the Intent at all or = explicitly to "mixed/don=E2=80=99t know=E2=80=9D. I consider setting Intents best effort - what the application doesn=E2=80=99= t know it can't communicate. Therefore, some of the Intents are not really overlap-free. Setting = =E2=80=9CObject Size=E2=80=9D to something really large, the "Traffic = Category=E2=80=9D is pretty obvious even when not set. This also plays = into you next question.=20 > - While explicit intents are a great way to avoid ossification, I = would also argue that we should minimize the surface of the intents in = order to reduce the complexity for application writers. Do you think = that some of these intent properties can also be inferred automatically = based on the traffic patterns observed by the system? I=E2=80=99m = thinking here of traffic category, in which we=E2=80=99re asking the app = to say if they=E2=80=99re using queries or streams or bulk downloads, = etc. I don=E2=80=99t see having Intents and inferring their values as = exclusive, but as complementary.=20 I anticipate inferring traffic pattern will work fine for many = applications, but not for all.=20 What I definitely want to avoid is application developers having to = train machine learning algorithms in order to have their applications = working. Therefore, I prefer exposing more Intents and making them = optional over relying on being able to infer them. AVE! Philipp S. Tiesel / phils=E2=80=A6 --=20 = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en = | o Schr an muss hc h (Kurt = Schwitters) | :wq! <----(phone: +49-179-6737439)---<---(jabber: = phils@in-panik.de)----' From nobody Mon Jun 19 06:17:42 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78091300E7 for ; Mon, 19 Jun 2017 06:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 MCOYIXZjGp50 for ; Mon, 19 Jun 2017 06:17:40 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4423512FB9A for ; Mon, 19 Jun 2017 06:17:35 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v5JDGWIS005845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 19 Jun 2017 06:16:42 -0700 (PDT) To: Tommy Pauly , "Philipp S. Tiesel" Cc: taps WG References: <1977C9AB-7BD1-4651-ACA8-DF042759C683@in-panik.de> <54C05CB6-2420-4632-8BE9-12C690F07414@apple.com> From: Joe Touch Message-ID: <87487d98-11a0-387d-950d-845ba2ba803f@isi.edu> Date: Mon, 19 Jun 2017 06:16:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <54C05CB6-2420-4632-8BE9-12C690F07414@apple.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Taps] =?utf-8?q?Socket_Intents_Draft_=E2=80=93_draft-tiesel-tap?= =?utf-8?q?s-socketintents-00?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 13:17:42 -0000 On 6/16/2017 11:23 AM, Tommy Pauly wrote: > - I’d love to see the terminology be less sockets-specific, especially considering the work for Post-Sockets APIs. A set of intents should be able to be applied to individual messages being sent or on a higher-level protocol, ideally, not just on the level of a transport connection as represented by a socket. I sincerely hope this and other TAPS documents are more specific about what is meant by a "socket". An Internet socket is an IP address paired with a transport protocol port (RFC793), such that a socket pair defines a connection (TCP, SCTP, DCCP) or association (UDP). A Unix socket is a OS mechanism that allows user-space applications to access transport-layer connections or associations. The two are otherwise not related; there are many Unix socket parameters focusing on the OS user-space to kernel-space interface, interprocess communication management, etc, and have no relation to Internet socket pairs. Unix sockets do not represent transport connections; they are interfaces that include access to the transport API. Joe From nobody Mon Jun 19 11:21:00 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80EE21287A5 for ; Mon, 19 Jun 2017 11:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tlB-s-wQhn9S for ; Mon, 19 Jun 2017 11:20:57 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1475126CD6 for ; Mon, 19 Jun 2017 11:20:55 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id a199so40111248qkb.2 for ; Mon, 19 Jun 2017 11:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=97gFzzykXtdID/9+85zsM0WgjiqH25j3nfPVSkyNKU4=; b=Ie5LA6k6nI+vtaQQv/wQ5GHxpOERZ6s0I8VTjqOJ3zRJ1oKswSm3o3Z91A3Z9k0F1E cgBUyAXYeddmxVK+d9XEGis6v1TSus5tIEwlg6XsQL5sR/FvVhrttGur4MTybzJBxdb/ 0iUc8j5G+bdv3jMEZPoRTqLKJVv6AkJ8ymWWzjgepsQ67uLi+NFfgfIJmqy0xkU5wZiM pJzyebeCOyvQxwGiwUvFCkjlMrYPDv95pOta13FUlaLDzZZMFdhXDIsYQCFMVkyKw/DL sUNeA89RgCgiWHdKHiXJnqIaZoPkDMHrSpV2jcN/RMrnF5XyN5a81gDYuCfhTyDpqLGD nheQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=97gFzzykXtdID/9+85zsM0WgjiqH25j3nfPVSkyNKU4=; b=Rnm70+G49KBPAsUdi12QCEEifKGhDM+ry15pS5mcizbAjByc+fYWy7cuVgR755HkT2 iB1KTR5O7T+Zupd09dsSVp6p607SAlh1nlXPyGNCeKEtNrQSZLjTgcSM6W9z0nbYA5Vp 6KwSPwTrYiUGIuQvM/noSLBdHA38tXBRTWOlcsteyaoBaYDTPTEJ6xSwxADdiAEAeI5v FW5eznmWbx/MOOj5vDH0Vt4cgCtA7WfYoNFuHDlRdxMKS1QjbSvpsT3mLOshjxaULfg1 Oy7cp0jF5RJWIY6LAFAVf+jgz61T3R+6T6/FYgQBzRUohxH8i55DdIYMDVA4crPcXlZS glWA== X-Gm-Message-State: AKS2vOwsuGCrEH/lHAkY6AaCs6RJ+gQ7dP/v+fQf9I6yDwNA5yxFEQOh vxCCpFflwH7BBAv+Uqs= X-Received: by 10.55.41.14 with SMTP id p14mr19474957qkh.209.1497896454603; Mon, 19 Jun 2017 11:20:54 -0700 (PDT) Received: from [169.254.36.107] ([72.246.0.14]) by smtp.gmail.com with ESMTPSA id z45sm7531090qtb.4.2017.06.19.11.20.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jun 2017 11:20:54 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Mon, 19 Jun 2017 14:20:53 -0400 Message-ID: <6E3B3326-77A6-4BF0-A157-BB097A9A5F5D@gmail.com> In-Reply-To: <408986B2-B86B-4C7D-9E91-D554029579FA@gmail.com> References: <408986B2-B86B-4C7D-9E91-D554029579FA@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_355616AE-7707-4823-A3CC-E8D02D8A08A7_=" X-Mailer: MailMate (1.9.6r5356) Archived-At: Subject: [Taps] review comments - Re: WGLC start for -transports-usage- docs X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 18:20:59 -0000 --=_MailMate_355616AE-7707-4823-A3CC-E8D02D8A08A7_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable IMO, the doc looks good and should be published. See below for a couple = of comments that should be addressed before submission for AD review. For both docs, the introduction (plus the appendix) does a good job of = talking about =E2=80=98what=E2=80=99 is in the doc but the = draft-ietf-taps-transports-usage-05.txt excerpt below is the only = statement of =E2=80=98why=E2=80=99 and I think it is insufficient. As a = courtesy to = the reader, a short summary of how this fits into the TAPS design = process would be helpful. Specifically, I think we need to say that = this document captures an intermediate stage of the design process, a = snapshot in time analysis of the IETF transport protocols, and is being = published as an RFC to document the authors=E2=80=99 & working group=E2=80= =99s = analysis generating a set of transport abstractions that can be exported = in the TAPS API. (You=E2=80=99ll probably be able to phrase it better. := ) > The list of primitives, events and transport features in this > document is strictly based on the parts of protocol specifications > that describe what the protocol provides to an application using it > and how the application interacts with it. Together with an = > overview > of the services provided by IETF transport protocols and congestion > > > > Welzl, et al. Expires November 25, 2017 [Page = > 3] > =0C > Internet-Draft Transport Services May = > 2017 > > > control mechanisms [RFC8095] and an analysis of UDP and UDP-Lite > [FJ16], it provides the basis for the minimal set of transport > services that end systems should support > [I-D.draft-gjessing-taps-minset]. Regarding the above, we probably want to say =E2=80=9Cend systems support= ing = TAPS should implement=E2=80=9D or something. Saying end systems =E2=80=9C= should = support=E2=80=9D this set of services is a strong statement and we probab= ly = shouldn=E2=80=99t say it. Probably also want draft-ietf-taps-transports-usage to point to = draft-ietf-taps-transports-usage-udp in the introduction so it=E2=80=99s = clear = to the reader that these are a set. =E2=80=94aaron On 29 May 2017, at 12:30, Aaron Falk wrote: > Dear TAPS working group: > > The authors have indicated the two drafts below are complete and are = > ready for a final working group review. WGLC starts today and will be = > three weeks, concluding June 19. Send comments, including an = > indication that the docs are ready for publication, to the working = > group list. > > * [On the Usage of Transport Features Provided by IETF Transport = > Protocols](https://www.ietf.org/internet-drafts/draft-ietf-taps-transpo= rts-usage-05.txt) > * [Features of the User Datagram Protocol (UDP) and Lightweight UDP = > (UDP- Lite) Transport = > Protocols](https://www.ietf.org/internet-drafts/draft-ietf-taps-transpo= rts-usage-udp-03.txt) > > > =E2=80=94aaron --=_MailMate_355616AE-7707-4823-A3CC-E8D02D8A08A7_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

IMO, the doc looks good and should be published. See bel= ow for a couple of comments that should be addressed before submission fo= r AD review.

For both docs, the introduction (plus the appendix) does = a good job of talking about =E2=80=98what=E2=80=99 is in the doc but the = draft-ietf-taps-transports-usage-05.txt excerpt below is the only stateme= nt of =E2=80=98why=E2=80=99 and I think it is insufficient. As a courtes= y to the reader, a short summary of how this fits into the TAPS design pr= ocess would be helpful. Specifically, I think we need to say that this d= ocument captures an intermediate stage of the design process, a snapshot = in time analysis of the IETF transport protocols, and is being published = as an RFC to document the authors=E2=80=99 & working group=E2=80=99s = analysis generating a set of transport abstractions that can be exported = in the TAPS API. (You=E2=80=99ll probably be able to phrase it better. := )

The list of primitives, events and transport features in = this
document is strictly based on the parts of protocol specifications
= that describe what the protocol provides to an application using it and how the application interacts with it. Together with an overview<= br> of the services provided by IETF transport protocols and congestion

Welzl, et al. Expires November 25, 2017 = [Page 3]

Internet-Draft Transport Services May 2017<= /p>

control mechanisms [RFC8095] and an analysis of UDP and U= DP-Lite
[FJ16], it provides the basis for the minimal set of transport
services that end systems should support
[I-D.draft-gjessing-taps-minset].

Regarding the above, we probably want to say =E2=80=9Cend= systems supporting TAPS should implement=E2=80=9D or something. Saying = end systems =E2=80=9Cshould support=E2=80=9D this set of services is a st= rong statement and we probably shouldn=E2=80=99t say it.

Probably also want draft-ietf-taps-transports-usage to po= int to draft-ietf-taps-transports-usage-udp in the introduction so it=E2=80= =99s clear to the reader that these are a set.

=E2=80=94aaron

On 29 May 2017, at 12:30, Aaron Falk wrote:

Dear TAPS working group:

The authors have indicated the two drafts below are compl= ete and are ready for a final working group review. WGLC starts today an= d will be three weeks, concluding June 19. Send comments, including an i= ndication that the docs are ready for publication, to the working group l= ist.

=E2=80=94aaron

--=_MailMate_355616AE-7707-4823-A3CC-E8D02D8A08A7_=-- From nobody Tue Jun 20 06:21:49 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8F212EAF9 for ; Tue, 20 Jun 2017 06:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 YVaO5mKImg0d for ; Tue, 20 Jun 2017 06:21:43 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 CFB7312EB89 for ; Tue, 20 Jun 2017 06:21:28 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dNJ5y-000FqA-Br for taps@ietf.org; Tue, 20 Jun 2017 15:21:26 +0200 Received: from [147.178.6.137] (helo=[10.41.10.220]) by mail-mx03.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dNJ5w-000GAP-4J for taps@ietf.org; Tue, 20 Jun 2017 15:21:26 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_282969DA-CAC0-4D71-9095-873D99E8E2C4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <5BE6202F-8666-4158-964A-41781FD04BF2@ifi.uio.no> References: <149796416409.23697.3832758224070683494.idtracker@ietfa.amsl.com> To: "taps@ietf.org" Date: Tue, 20 Jun 2017 14:21:25 +0100 X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 147.178.6.137 is neither permitted nor denied by domain of ifi.uio.no) client-ip=147.178.6.137; envelope-from=michawe@ifi.uio.no; helo=[10.41.10.220]; X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 3 sum rcpts/h 8 sum msgs/h 5 total rcpts 55812 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.102, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 51DB67F96E1C2AC9C82CDE0878020F09C045373D X-UiO-SPAM-Test: remote_host: 147.178.6.137 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 48 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [Taps] Fwd: New Version Notification for draft-gjessing-taps-minset-05.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 13:21:47 -0000 --Apple-Mail=_282969DA-CAC0-4D71-9095-873D99E8E2C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear group, We just updated the minset document. Important changes are: - the minset itself is now presented early, all the long boring text = about how stuff was derived has been moved to an appendix - a first stab at an abstract API representation of the minset is now = included! Cheers, Michael & Stein > Begin forwarded message: >=20 > From: > Subject: New Version Notification for = draft-gjessing-taps-minset-05.txt > Date: June 20, 2017 at 2:09:24 PM GMT+1 > To: Michael Welzl , Stein Gjessing = > Resent-From: >=20 >=20 > A new version of I-D, draft-gjessing-taps-minset-05.txt > has been successfully submitted by Michael Welzl and posted to the > IETF repository. >=20 > Name: draft-gjessing-taps-minset > Revision: 05 > Title: A Minimal Set of Transport Services for TAPS = Systems > Document date: 2017-06-20 > Group: Individual Submission > Pages: 44 > URL: = https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-05.txt > Status: = https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/ > Htmlized: = https://tools.ietf.org/html/draft-gjessing-taps-minset-05 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-gjessing-taps-minset-05 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-gjessing-taps-minset-05 >=20 > Abstract: > This draft recommends a minimal set of IETF Transport Services > offered by end systems supporting TAPS, and gives guidance on > choosing among the available mechanisms and protocols. It is based > on the set of transport features given in the TAPS document > draft-ietf-taps-transports-usage-05. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_282969DA-CAC0-4D71-9095-873D99E8E2C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear group,

We just updated the minset document. Important changes = are:
- the minset itself is now presented early, = all the long boring text about how stuff was derived has been moved to = an appendix
- a first stab at an abstract API = representation of the minset is now included!

Cheers,
Michael & = Stein


Begin forwarded = message:

From: = <internet-drafts@ietf.org>
Subject: = New Version = Notification for draft-gjessing-taps-minset-05.txt
Date: = June 20, 2017 at 2:09:24 PM = GMT+1
To: = Michael Welzl <michawe@ifi.uio.no>, = Stein Gjessing <steing@ifi.uio.no>
Resent-From: = <michawe@ifi.uio.no>


A new version = of I-D, draft-gjessing-taps-minset-05.txt
has been = successfully submitted by Michael Welzl and posted to the
IETF repository.

Name: = draft-gjessing-taps-minset
Revision: 05
Title:= = A Minimal Set of Transport Services for TAPS Systems
Document date: 2017-06-20
Group:= = Individual Submission
Pages: 44
URL: =            https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset= -05.txt
Status: =         https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/
Htmlized:       https://tools.ietf.org/html/draft-gjessing-taps-minset-05Htmlized:       https://datatracker.ietf.org/doc/html/draft-gjessing-taps-minse= t-05
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-gjessing-taps-minset-= 05

Abstract:
=   This draft recommends a minimal set of IETF Transport = Services
  offered by end systems supporting = TAPS, and gives guidance on
  choosing among = the available mechanisms and protocols.  It is based
=   on the set of transport features given in the TAPS = document
=   draft-ietf-taps-transports-usage-05.




Please note that = it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


= --Apple-Mail=_282969DA-CAC0-4D71-9095-873D99E8E2C4-- From nobody Fri Jun 23 15:17:25 2017 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4DA120227; Fri, 23 Jun 2017 15:17:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149825624313.7722.12244606198259765368@ietfa.amsl.com> Date: Fri, 23 Jun 2017 15:17:23 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transports-usage-06.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 22:17:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services of the IETF. Title : On the Usage of Transport Features Provided by IETF Transport Protocols Authors : Michael Welzl Michael Tuexen Naeem Khademi Filename : draft-ietf-taps-transports-usage-06.txt Pages : 51 Date : 2017-06-23 Abstract: This document describes how the transport protocols Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP) and Lightweight User Datagram Protocol (UDP-Lite) expose services to applications and how an application can configure and use the features that make up these services. It also discusses the service provided by the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism. The description results in a set of transport abstractions that can be exported in a TAPS API. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transports-usage-06 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 23 15:20:07 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D95F1287A3 for ; Fri, 23 Jun 2017 15:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 jaLZSNhMxLMd for ; Fri, 23 Jun 2017 15:20:02 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 C31B112943A for ; Fri, 23 Jun 2017 15:20:01 -0700 (PDT) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dOWvn-0005ro-IS for taps@ietf.org; Sat, 24 Jun 2017 00:19:59 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dOWvm-0004w3-Qo for taps@ietf.org; Sat, 24 Jun 2017 00:19:59 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_06577ECE-B7EA-48F6-BF14-9D3A8A8804C9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 24 Jun 2017 00:19:58 +0200 References: <408986B2-B86B-4C7D-9E91-D554029579FA@gmail.com> <70A5CB94-DBFD-4A09-80D2-5B944F01F1C8@trammell.ch> <11EE2FCB-50A5-4C6E-BF23-9BCFDC7FEE8A@apple.com> To: "taps@ietf.org" In-Reply-To: <11EE2FCB-50A5-4C6E-BF23-9BCFDC7FEE8A@apple.com> Message-Id: <4C14EFBA-267D-442B-B802-D2DDC24D5FE6@ifi.uio.no> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 55907 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.058, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0D210FEE855A1E81729F571038D2A83AC54953D6 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1611 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] WGLC start for -transports-usage- docs X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 22:20:06 -0000 --Apple-Mail=_06577ECE-B7EA-48F6-BF14-9D3A8A8804C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Tommy, Thanks a lot for your comments! Very helpful - and painful too :-) to = fix the messy style (lower case / upper case / ..), which originated = from me just copy+pasting it from the various source RFCs=E2=80=A6 I = should have fixed this long ago, I think it looks much better now - so = thanks indeed for making me do this! About MPTCP, that=E2=80=99s also done (mention that everything applies = to both - I actually did say so for an earlier =E2=80=9Cpass=E2=80=9D = but now I added it for pass 3 too). Cheers, Michael > On Jun 4, 2017, at 10:40 PM, Tommy Pauly wrote: >=20 > Agreed, these both look ready to go! Just a few minor typographical = nits below; these could be cleaned up later. >=20 > Best, > Tommy >=20 > Usage Draft: >=20 > - In Section 3.1, the style of most items is lower case without = underscores; however there are "USER TIMEOUT event:=E2=80=9D and = "ERROR_REPORT event:=E2=80=9D, and then the rest of the list is in = camel-case like "Type-of-Service:=E2=80=9D. These should probably be = cleaned up. Same for other lists. >=20 > - In Section 5.1, would it be useful to explicitly mention MPTCP for = the common elements with TCP, or simply mention that anything that = applies to TCP also applies to MPTCP? >=20 > UDP Usage Draft: >=20 > - Section 3 has some mismatched parenthetical clauses: > (in and how the > transport is used (based on abstract API descriptions, where they = are > available). > - Section 3.1 has a sentence that doesn=E2=80=99t parse well: >=20 > should be able to create receive, source and > destination ports and addresses >=20 > - Also in Section 3.1, it seems that there should be a comma before = the =E2=80=9Cor by=E2=80=9D rather than a full stop. >=20 > 1. bind(): A bind operation sets the local port, either > implicitly, triggered by a "sendto" operation on an unbound, > unconnected socket using an ephemeral port. Or by an = explicit > "bind" to use a configured or well-known port. >=20 > - Section 3.1, "ERROR_REPORT The ERROR_REPORT=E2=80=9D is missing the = colon that all other items have. Same for SET_MIN_COVERAGE in section = 3.2 >=20 >=20 >> On May 30, 2017, at 3:14 AM, Brian Trammell (IETF) > wrote: >>=20 >> hi Aaron, all, >>=20 >> I've read these, and IMO they're ready for publication. Many thanks = to the authors for the impressive amount of work that went into them! >>=20 >> Cheers, >>=20 >> Brian >>=20 >>=20 >>> On 29 May 2017, at 18:30, Aaron Falk > wrote: >>>=20 >>> Dear TAPS working group: >>>=20 >>> The authors have indicated the two drafts below are complete and are = ready for a final working group review. WGLC starts today and will be = three weeks, concluding June 19. Send comments, including an indication = that the docs are ready for publication, to the working group list. >>>=20 >>> =E2=80=A2 On the Usage of Transport Features Provided by IETF = Transport Protocols >>> =E2=80=A2 Features of the User Datagram Protocol (UDP) and = Lightweight UDP (UDP- Lite) Transport Protocols >>> =E2=80=94aaron >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_06577ECE-B7EA-48F6-BF14-9D3A8A8804C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Tommy,

Thanks a lot for your comments! Very helpful - and painful = too  :-)  to fix the messy style (lower case / upper case / = ..), which originated from me just copy+pasting it from the various = source RFCs=E2=80=A6 I should have fixed this long ago, I think it looks = much better now - so thanks indeed for making me do this!

About MPTCP, that=E2=80=99= s also done (mention that everything applies to both - I actually did = say so for an earlier =E2=80=9Cpass=E2=80=9D but now I added it for pass = 3 too).

Cheers,
Michael


On Jun 4, 2017, at 10:40 PM, = Tommy Pauly <tpauly@apple.com> wrote:

Agreed, = these both look ready to go! Just a few minor typographical nits below; = these could be cleaned up later.

Best,
Tommy

Usage Draft:

- In Section 3.1, the style of most items is lower case = without underscores; however there are "USER TIMEOUT event:=E2=80=9D and = "ERROR_REPORT event:=E2=80=9D, and then the rest of the list is in = camel-case like "Type-of-Service:=E2=80=9D. These should probably be = cleaned up. Same for other lists.

- In Section 5.1, would it be useful to = explicitly mention MPTCP for the common elements with TCP, or simply = mention that anything that applies to TCP also applies to = MPTCP?

UDP = Usage Draft:

 - Section 3 has some mismatched parenthetical = clauses:
(in and how the
   transport is used (based on abstract API descriptions, where they are
   available).
- Section 3.1 has a sentence that = doesn=E2=80=99t parse well:

should be able to create receive, source and
   destination ports and addresses

- Also in Section 3.1, it seems that there should = be a comma before the =E2=80=9Cor by=E2=80=9D rather than a full = stop.

 1.  bind(): A bind =
operation sets the local port, either
          implicitly, triggered by a "sendto" operation on an unbound,
          unconnected socket using an ephemeral port.  Or =
by an explicit
          "bind" to use a configured or well-known port.

- Section 3.1, = "ERROR_REPORT The ERROR_REPORT=E2=80=9D is missing the colon that all = other items have. Same for SET_MIN_COVERAGE in section = 3.2


On May = 30, 2017, at 3:14 AM, Brian Trammell (IETF) <ietf@trammell.ch> = wrote:

hi Aaron, all,

I've read these, = and IMO they're ready for publication. Many thanks to the authors for = the impressive amount of work that went into them!

Cheers,

Brian


On 29 May = 2017, at 18:30, Aaron Falk <aaron.falk@gmail.com> wrote:

Dear TAPS working group:

The = authors have indicated the two drafts below are complete and are ready = for a final working group review. WGLC starts today and will be three = weeks, concluding June 19. Send comments, including an indication that = the docs are ready for publication, to the working group list.

=E2=80=A2 On the Usage of = Transport Features Provided by IETF Transport Protocols
= =E2=80=A2 Features of the User Datagram Protocol (UDP) and = Lightweight UDP (UDP- Lite) Transport Protocols
=E2=80=94aar= on

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

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

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

= --Apple-Mail=_06577ECE-B7EA-48F6-BF14-9D3A8A8804C9-- From nobody Fri Jun 23 15:22:16 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C33812943A for ; Fri, 23 Jun 2017 15:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 pfBsbGeWXfnv for ; Fri, 23 Jun 2017 15:22:12 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 8EC931293E1 for ; Fri, 23 Jun 2017 15:22:12 -0700 (PDT) Received: from mail-mx05.uio.no ([129.240.10.49]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dOWxu-00067Y-W4 for taps@ietf.org; Sat, 24 Jun 2017 00:22:11 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx05.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dOWxu-0005Ct-9I for taps@ietf.org; Sat, 24 Jun 2017 00:22:10 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_43BA4AA5-2900-4698-80E7-6749B5195BA0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 24 Jun 2017 00:22:09 +0200 References: <408986B2-B86B-4C7D-9E91-D554029579FA@gmail.com> <6E3B3326-77A6-4BF0-A157-BB097A9A5F5D@gmail.com> To: "taps@ietf.org" In-Reply-To: <6E3B3326-77A6-4BF0-A157-BB097A9A5F5D@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx05.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 4 sum msgs/h 2 total rcpts 55908 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.091, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: BF8FA65C3CAD3077587893529A7D9C6D716EC72C X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1612 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] review comments - Re: WGLC start for -transports-usage- docs X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 22:22:15 -0000 --Apple-Mail=_43BA4AA5-2900-4698-80E7-6749B5195BA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Aaron, Thanks a lot for your comments! In line: > On Jun 19, 2017, at 8:20 PM, Aaron Falk wrote: >=20 > IMO, the doc looks good and should be published. See below for a = couple of comments that should be addressed before submission for AD = review. >=20 > For both docs, the introduction (plus the appendix) does a good job of = talking about =E2=80=98what=E2=80=99 is in the doc but the = draft-ietf-taps-transports-usage-05.txt excerpt below is the only = statement of =E2=80=98why=E2=80=99 and I think it is insufficient. As a = courtesy to the reader, a short summary of how this fits into the TAPS = design process would be helpful. Specifically, I think we need to say = that this document captures an intermediate stage of the design process, = a snapshot in time analysis of the IETF transport protocols, and is = being published as an RFC to document the authors=E2=80=99 & working = group=E2=80=99s analysis generating a set of transport abstractions that = can be exported in the TAPS API. (You=E2=80=99ll probably be able to = phrase it better. :) >=20 Done in the intro, and also added a sentence to the abstract. > The list of primitives, events and transport features in this > document is strictly based on the parts of protocol specifications > that describe what the protocol provides to an application using it > and how the application interacts with it. Together with an overview > of the services provided by IETF transport protocols and congestion >=20 > Welzl, et al. Expires November 25, 2017 [Page 3] >=20 > Internet-Draft Transport Services May 2017 >=20 > control mechanisms [RFC8095] and an analysis of UDP and UDP-Lite > [FJ16], it provides the basis for the minimal set of transport > services that end systems should support > [I-D.draft-gjessing-taps-minset]. >=20 > Regarding the above, we probably want to say =E2=80=9Cend systems = supporting TAPS should implement=E2=80=9D or something. Saying end = systems =E2=80=9Cshould support=E2=80=9D this set of services is a = strong statement and we probably shouldn=E2=80=99t say it. >=20 Absolutely agree, indeed I didn=E2=80=99t mean to recommend that all the = world=E2=80=99s end systems be changed (though I=E2=80=99d love that = ;-) ). Fixed. > Probably also want draft-ietf-taps-transports-usage to point to = draft-ietf-taps-transports-usage-udp in the introduction so it=E2=80=99s = clear to the reader that these are a set. >=20 Agree, done (I think I did already but now the citation is in a more = obvious position I think) Cheers, Michael > =E2=80=94aaron >=20 > On 29 May 2017, at 12:30, Aaron Falk wrote: >=20 > Dear TAPS working group: >=20 > The authors have indicated the two drafts below are complete and are = ready for a final working group review. WGLC starts today and will be = three weeks, concluding June 19. Send comments, including an indication = that the docs are ready for publication, to the working group list. >=20 > On the Usage of Transport Features Provided by IETF Transport = Protocols = > Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- = Lite) Transport Protocols = > =E2=80=94aaron >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_43BA4AA5-2900-4698-80E7-6749B5195BA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Aaron,

Thanks a lot for your comments!

In line:


On Jun 19, 2017, at 8:20 PM, = Aaron Falk <aaron.falk@gmail.com> wrote:

IMO, = the doc looks good and should be published. See below for a couple of = comments that should be addressed before submission for AD review.

For both docs, the introduction (plus the = appendix) does a good job of talking about =E2=80=98what=E2=80=99 is in = the doc but the draft-ietf-taps-transports-usage-05.txt excerpt below is = the only statement of =E2=80=98why=E2=80=99 and I think it is = insufficient. As a courtesy to the reader, a short summary of how this = fits into the TAPS design process would be helpful. Specifically, I = think we need to say that this document captures an intermediate stage = of the design process, a snapshot in time analysis of the IETF transport = protocols, and is being published as an RFC to document the authors=E2=80=99= & working group=E2=80=99s analysis generating a set of transport = abstractions that can be exported in the TAPS API. (You=E2=80=99ll = probably be able to phrase it better. = :)

Done in the intro, and = also added a sentence to the abstract.

The list of = primitives, events and transport features in this
document is strictly based on the parts of protocol specifications
that describe what the protocol provides to an application using = it
and how the application interacts with it. Together with an = overview
of the services provided by IETF transport protocols and = congestion

Welzl, et al. Expires = November 25, 2017 [Page 3]

Internet-Draft Transport Services May = 2017

control mechanisms [RFC8095] and an = analysis of UDP and UDP-Lite
[FJ16], it provides the basis for the minimal set of transport
services that end systems should support
[I-D.draft-gjessing-taps-minset].

Regarding the above, we probably = want to say =E2=80=9Cend systems supporting TAPS should implement=E2=80=9D= or something. Saying end systems =E2=80=9Cshould support=E2=80=9D this = set of services is a strong statement and we probably shouldn=E2=80=99t = say it.

Absolutely agree, indeed = I didn=E2=80=99t mean to recommend that all the world=E2=80=99s end = systems be changed (though I=E2=80=99d love that  ;-)  ). =  Fixed.


Probably also want draft-ietf-taps-transports-usage to point = to draft-ietf-taps-transports-usage-udp in the introduction so it=E2=80=99= s clear to the reader that these are a = set.

Agree, done (I think I did = already but now the citation is in a more obvious position I = think)

Cheers,
Michael



=E2=80=94aaron

On 29 May 2017, = at 12:30, Aaron Falk wrote:

Dear TAPS = working group:

The authors have indicated = the two drafts below are complete and are ready for a final working = group review. WGLC starts today and will be three weeks, concluding = June 19. Send comments, including an indication that the docs are ready = for publication, to the working group list.

=E2=80=94aaron

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

= --Apple-Mail=_43BA4AA5-2900-4698-80E7-6749B5195BA0-- From nobody Fri Jun 23 15:25:16 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35C512943A for ; Fri, 23 Jun 2017 15:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 n1Akfz-OZLwU for ; Fri, 23 Jun 2017 15:25:12 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 90A7F1293E1 for ; Fri, 23 Jun 2017 15:25:12 -0700 (PDT) Received: from mail-mx05.uio.no ([129.240.10.49]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dOX0o-0004dM-Vr for taps@ietf.org; Sat, 24 Jun 2017 00:25:10 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx05.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dOX0o-0005Nq-Bs for taps@ietf.org; Sat, 24 Jun 2017 00:25:10 +0200 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 24 Jun 2017 00:25:09 +0200 References: <149825624313.7722.12244606198259765368@ietfa.amsl.com> To: "taps@ietf.org" In-Reply-To: <149825624313.7722.12244606198259765368@ietfa.amsl.com> Message-Id: <88D7AE82-1A6D-4BF0-AEE4-99AA317794AD@ifi.uio.no> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx05.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 3 sum rcpts/h 5 sum msgs/h 3 total rcpts 55909 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.093, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 82DA4222A5C84F30E5142885DFC8DF4C747C05E6 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 1613 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-usage-06.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 22:25:15 -0000 Hi all, This is a minor update, addressing the comments from Aaron and Tommy. = The biggest change is the consistency fix for uppercase / lower case / = camel case =E2=80=A6 no change to the technical content was made. Cheers, Michael > On Jun 24, 2017, at 12:17 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Services of the IETF. >=20 > Title : On the Usage of Transport Features Provided = by IETF Transport Protocols > Authors : Michael Welzl > Michael Tuexen > Naeem Khademi > Filename : draft-ietf-taps-transports-usage-06.txt > Pages : 51 > Date : 2017-06-23 >=20 > Abstract: > This document describes how the transport protocols Transmission > Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control > Transmission Protocol (SCTP), User Datagram Protocol (UDP) and > Lightweight User Datagram Protocol (UDP-Lite) expose services to > applications and how an application can configure and use the > features that make up these services. It also discusses the service > provided by the Low Extra Delay Background Transport (LEDBAT) > congestion control mechanism. The description results in a set of > transport abstractions that can be exported in a TAPS API. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-taps-transports-usage-06 > = https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-usage-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Jun 23 17:14:49 2017 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FBA12EB56; Fri, 23 Jun 2017 17:07:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: spencerdawkins.ietf@gmail.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826283466.7840.14462629794118521730.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:14 -0700 Archived-At: Subject: [Taps] taps - Requested session has been scheduled for IETF 99 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:15 -0000 Dear Aaron Falk, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. taps Session 1 (2:30:00) Tuesday, Morning Session I 0930-1200 Room Name: Congress Hall I size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Aaron Falk Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat aqm tsvarea appsawg apparea quic Second Priority: webpush tcpinc nvo3 mptcp icnrg httpbis irtfopen Third Priority: mmusic tram People who must be present: Aaron Falk Michael Welzl Gorry Fairhurst Spencer Dawkins Brian Trammell Zaheduzzaman Sarker Mirja Kuehlewind Tommy Pauly Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Jun 24 04:16:32 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9524212896F for ; Sat, 24 Jun 2017 04:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 eupoTUceDyW3 for ; Sat, 24 Jun 2017 04:16:28 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 BF795120724 for ; Sat, 24 Jun 2017 04:16:26 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v5OBG3Ht022808 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 24 Jun 2017 13:16:03 +0200 Received: from [2001:bf0:c801:101:bcbe:3810:e1ad:7c85] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dOj2j-0001Ww-Ux; Sat, 24 Jun 2017 13:15:58 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Philipp S. Tiesel" In-Reply-To: <68CB4570-7371-49EA-8E62-20F424FB0E41@ifi.uio.no> Date: Sat, 24 Jun 2017 13:16:02 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <1977C9AB-7BD1-4651-ACA8-DF042759C683@in-panik.de> <54C05CB6-2420-4632-8BE9-12C690F07414@apple.com> <68CB4570-7371-49EA-8E62-20F424FB0E41@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Taps] =?utf-8?q?Socket_Intents_Draft_=E2=80=93_draft-tiesel-tap?= =?utf-8?q?s-socketintents-00?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 11:16:30 -0000 Hi Michael, > On 17. Jun 2017, at 12:02, Michael Welzl wrote: >=20 > Hi, >=20 > Thanks indeed for sharing this - I think this is very interesting = input to the group. > I agree with the things Tommy says below, but I have some additional = thoughts that I wanted to share. >=20 > Our charter is about existing protocols and what they can do. For TCP, = MPTCP, UDP, UDP-Lite, SCTP and LEBAT, draft-gjessing-taps-minset breaks = this list down into transport features that really must be exposed in = order to become usable, some that really shouldn=E2=80=99t be exposed = (as they would forever tie your application to one specific protocol = only), and some that could (perhaps) be automatized. >=20 > So, with that in mind, if I try to imagine how to implement a system = implementing draft-tiesel-taps-socketintents on top of TCP, MPTCP, UDP, = =E2=80=A6etc, I see two degrees of freedom here: >=20 > 1) deciding which protocol to use, and making good use of the features = that we call =E2=80=9Cautomatable=E2=80=9D in = draft-gjessing-taps-minset. As a concrete example, we say that the = choice of the network interface is based on network- or OS-wide, but not = application-specific knowledge, and so it should be automatable. = However, making a choice does need *some* knowledge about app behavior, = and this is exactly a hole that some of the things in = draft-tiesel-taps-socketintents appear to fill. >=20 > 2) I guess that some of the services of protocols can be = =E2=80=9Ctranslated=E2=80=9D into a slightly different representation. The third (and primary use-case for Socket Intents so far) was using = them for Access-Selection, which includes automatic selection of = transport options like destination, path, and what packet / stream = scheduling strategy to use for MPTCP and SCPT. As far as I interpret draft-gjessing-taps-minset and the WG charter, = this is not exactly the focus of the WG, but also not out of scope. I think we should put this a little clearer in a -01 version of the = draft-tiesel-taps-socketintents. > Here I=E2=80=99m thinking of your =E2=80=9CApplication Resilience=E2=80=9D= , for example: how does this relate to "Change timeout for aborting = connection (using retransmit limit or time value)=E2=80=9D (from (MP)TCP = and SCTP) and "Suggest timeout to the peer=E2=80=9D (from (MP)TCP, via = UTO)? Isn=E2=80=99t a very disruption-resilient application going to = want a large timeout value? But then maybe such resilience is best = configured in seconds=E2=80=A6 One of the Ideas of Socket Intents is that intents are expressed in an = abstract way. While a timeout in seconds is indeed a value that is = protocol independent, it is very concrete and therefore fits much better = in the abstract mindset api than into socket intents. Application Resilience as stated in draft-tiesel-taps-socketintents-00 = is useful for transport option selection and deriving a timeout default. = This can be either adjusted by explicitly setting a timeout or an by an = additional intent like =E2=80=9CConnection Failure Detection = Sensitivity=E2=80=9D. =20 > and =E2=80=9Ctimeliness=E2=80=9D in your section 5.6 pretty obviously = maps to "Specify DSCP field=E2=80=9D (from (MP)TCP, SCTP and UDP(-Lite)) = - which we actually already combined with other things and translated = into a higher-level representation that we call =E2=80=9Ccapacity = profile=E2=80=9D in = https://tools.ietf.org/html/draft-gjessing-taps-minset-04#section-5.5 > I understand that the idea of socket intents is to describe an = application=E2=80=99s behaviour, not request QoS - but using the DSCP as = in draft-ietf-tsvwg-rtcweb-qos isn=E2=80=99t about guarantees either. = All in all, considering just the API, I don=E2=80=99t see much = difference between an application using socket intents and choosing = =E2=80=9Cbackground=E2=80=9D or using the DSCP value and choosing = =E2=80=9Cbackground=E2=80=9D. Once a TAPS system has this information, = the question becomes what it really does with it (truly set the DSCP = value, or do something else?). Correct. capacity profile and the =E2=80=9Ctimeliness=E2=80=9D and = =E2=80=9Ccategory=E2=80=9D Intent differ mainly in their scope of = effect: while the Intents are primarily thought as input to automatic = transport option selection, the capacity profile is primarily a way to = specify the DSCP field. Nevertheless, the value of the Intents can be = used to derive the DSCP filed if desired. >=20 > So these were just some thoughts. To summarize, I think it would be = interesting to see how the things in draft-tiesel-taps-socketintents map = to: > - the choice of protocols > - configuring transport features of existing protocols that we call = =E2=80=9Cautomatable=E2=80=9D > - and simply using transport features that, according to = draft-gjessing-taps-minset, already should be exposed anyway.=20 Reasonable questions - I don=E2=80=99t know whether I will find the time = to elaborate on this in the draft till the cutoff date for Prague, but I = agree that these relations should be clarified in a future version of = the draft. > Cheers, > Michael >=20 >=20 >=20 >> On Jun 16, 2017, at 8:23 PM, Tommy Pauly wrote: >>=20 >> Hi Philipp, >>=20 >> Thanks for sharing this document! Providing an API for generic = network intents is something of a Holy Grail=E2=80=94valuable but = elusive to nail down. This document should be a good place to start a = conversation, and I look forward to discussing it in Prague. >>=20 >> A few initial comments: >>=20 >> - I=E2=80=99d love to see the terminology be less sockets-specific, = especially considering the work for Post-Sockets APIs. A set of intents = should be able to be applied to individual messages being sent or on a = higher-level protocol, ideally, not just on the level of a transport = connection as represented by a socket. >>=20 >> - Certain properties, like burstiness, are focused on what the = application will be sending, and what its sending pattern will look = like. This works fine for some use cases, but in the case of downloads, = the application may not have enough/any insight into what patterns the = server will have. What do you think the best way to account for this is? >>=20 >> - While explicit intents are a great way to avoid ossification, I = would also argue that we should minimize the surface of the intents in = order to reduce the complexity for application writers. Do you think = that some of these intent properties can also be inferred automatically = based on the traffic patterns observed by the system? I=E2=80=99m = thinking here of traffic category, in which we=E2=80=99re asking the app = to say if they=E2=80=99re using queries or streams or bulk downloads, = etc. >>=20 >> Thanks, >> Tommy >>=20 >>> On Jun 16, 2017, at 1:54 AM, Philipp S. Tiesel = wrote: >>>=20 >>> Hi, >>>=20 >>> I just uploaded draft-tiesel-taps-socketintents-00 to the data = tracker yesterday. >>> https://datatracker.ietf.org/doc/draft-tiesel-taps-socketintents/ >>>=20 >>> This draft should fits into point three of the TAPS charter. >>>=20 >>> Socket Intents allow applications to share their knowledge about = upcoming >>> communication and express their performance preferences in an API = independent way. >>> Therefore, thy can be used by an OS/API to gain enough knowledge to = perform access >>> as well as transport protocol selection and tuning. >>>=20 >>> A draft explaining an experimental implementation based on BSD = sockets will follow. >>>=20 >>> I am looking forward to the discussion, here and in Prague. >>>=20 >>> AVE! >>> Philipp S. Tiesel / phils=E2=80=A6 >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps AVE! Philipp S. Tiesel / phils=E2=80=A6 --=20 = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en = | o Schr an muss hc h (Kurt = Schwitters) | :wq! <----(phone: +49-179-6737439)---<---(jabber: = phils@in-panik.de)----' From nobody Sat Jun 24 09:39:28 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C90D1200FC for ; Sat, 24 Jun 2017 09:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5E7JfIeVBeQs for ; Sat, 24 Jun 2017 09:39:24 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 E628B1204DA for ; Sat, 24 Jun 2017 09:39:23 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dOo5h-0004cf-Mu; Sat, 24 Jun 2017 18:39:21 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx03.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dOo5g-0005wZ-DQ; Sat, 24 Jun 2017 18:39:21 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: Date: Sat, 24 Jun 2017 18:39:23 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <509CE105-F0F6-4F56-ADDE-D41C12C932D1@ifi.uio.no> References: <1977C9AB-7BD1-4651-ACA8-DF042759C683@in-panik.de> <54C05CB6-2420-4632-8BE9-12C690F07414@apple.com> <68CB4570-7371-49EA-8E62-20F424FB0E41@ifi.uio.no> To: "Philipp S. Tiesel" X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 4 sum msgs/h 1 total rcpts 55915 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.048, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C2AA7E75B0E96500714F7918AF0011B333E4CBA0 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1615 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] =?utf-8?q?Socket_Intents_Draft_=E2=80=93_draft-tiesel-tap?= =?utf-8?q?s-socketintents-00?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 16:39:27 -0000 Hi, > On Jun 24, 2017, at 1:16 PM, Philipp S. Tiesel = wrote: >=20 > Hi Michael, >=20 >> On 17. Jun 2017, at 12:02, Michael Welzl wrote: >>=20 >> Hi, >>=20 >> Thanks indeed for sharing this - I think this is very interesting = input to the group. >> I agree with the things Tommy says below, but I have some additional = thoughts that I wanted to share. >>=20 >> Our charter is about existing protocols and what they can do. For = TCP, MPTCP, UDP, UDP-Lite, SCTP and LEBAT, draft-gjessing-taps-minset = breaks this list down into transport features that really must be = exposed in order to become usable, some that really shouldn=E2=80=99t be = exposed (as they would forever tie your application to one specific = protocol only), and some that could (perhaps) be automatized. >>=20 >> So, with that in mind, if I try to imagine how to implement a system = implementing draft-tiesel-taps-socketintents on top of TCP, MPTCP, UDP, = =E2=80=A6etc, I see two degrees of freedom here: >>=20 >> 1) deciding which protocol to use, and making good use of the = features that we call =E2=80=9Cautomatable=E2=80=9D in = draft-gjessing-taps-minset. As a concrete example, we say that the = choice of the network interface is based on network- or OS-wide, but not = application-specific knowledge, and so it should be automatable. = However, making a choice does need *some* knowledge about app behavior, = and this is exactly a hole that some of the things in = draft-tiesel-taps-socketintents appear to fill. >>=20 >> 2) I guess that some of the services of protocols can be = =E2=80=9Ctranslated=E2=80=9D into a slightly different representation. >=20 > The third (and primary use-case for Socket Intents so far) was using = them for Access-Selection, which includes automatic selection of = transport options like destination, path, and what packet / stream = scheduling strategy to use for MPTCP and SCPT. > As far as I interpret draft-gjessing-taps-minset and the WG charter, = this is not exactly the focus of the WG, but also not out of scope. > I think we should put this a little clearer in a -01 version of the = draft-tiesel-taps-socketintents. I=E2=80=99d classify access selection as my item 1) above: it=E2=80=99s = one of the things (e.g. of MPTCP) that we call =E2=80=9Cautomatable=E2=80=9D= . Now just because it *might* be possible to automate access selection, = this doesn=E2=80=99t mean that it wouldn=E2=80=99t be better to add more = information from the application to make a better decision - the minset = is indeed only a =E2=80=9Cminimum set=E2=80=9D. >> Here I=E2=80=99m thinking of your =E2=80=9CApplication Resilience=E2=80= =9D, for example: how does this relate to "Change timeout for aborting = connection (using retransmit limit or time value)=E2=80=9D (from (MP)TCP = and SCTP) and "Suggest timeout to the peer=E2=80=9D (from (MP)TCP, via = UTO)? Isn=E2=80=99t a very disruption-resilient application going to = want a large timeout value? But then maybe such resilience is best = configured in seconds=E2=80=A6 >=20 > One of the Ideas of Socket Intents is that intents are expressed in an = abstract way. While a timeout in seconds is indeed a value that is = protocol independent, it is very concrete and therefore fits much better = in the abstract mindset api than into socket intents. >=20 > Application Resilience as stated in draft-tiesel-taps-socketintents-00 = is useful for transport option selection and deriving a timeout default. = This can be either adjusted by explicitly setting a timeout or an by an = additional intent like =E2=80=9CConnection Failure Detection = Sensitivity=E2=80=9D. I understand, and I=E2=80=99m in favor of raising the abstraction level = a bit (for the sake of greater flexibility) - as long as there=E2=80=99s = at least one clear implementation possibility, using existing protocols. >> and =E2=80=9Ctimeliness=E2=80=9D in your section 5.6 pretty obviously = maps to "Specify DSCP field=E2=80=9D (from (MP)TCP, SCTP and UDP(-Lite)) = - which we actually already combined with other things and translated = into a higher-level representation that we call =E2=80=9Ccapacity = profile=E2=80=9D in = https://tools.ietf.org/html/draft-gjessing-taps-minset-04#section-5.5 >=20 >> I understand that the idea of socket intents is to describe an = application=E2=80=99s behaviour, not request QoS - but using the DSCP as = in draft-ietf-tsvwg-rtcweb-qos isn=E2=80=99t about guarantees either. = All in all, considering just the API, I don=E2=80=99t see much = difference between an application using socket intents and choosing = =E2=80=9Cbackground=E2=80=9D or using the DSCP value and choosing = =E2=80=9Cbackground=E2=80=9D. Once a TAPS system has this information, = the question becomes what it really does with it (truly set the DSCP = value, or do something else?). >=20 > Correct. capacity profile and the =E2=80=9Ctimeliness=E2=80=9D and = =E2=80=9Ccategory=E2=80=9D Intent differ mainly in their scope of = effect: while the Intents are primarily thought as input to automatic = transport option selection, the capacity profile is primarily a way to = specify the DSCP field. Nevertheless, the value of the Intents can be = used to derive the DSCP filed if desired. >=20 >>=20 >> So these were just some thoughts. To summarize, I think it would be = interesting to see how the things in draft-tiesel-taps-socketintents map = to: >> - the choice of protocols >> - configuring transport features of existing protocols that we call = =E2=80=9Cautomatable=E2=80=9D >> - and simply using transport features that, according to = draft-gjessing-taps-minset, already should be exposed anyway.=20 >=20 > Reasonable questions - I don=E2=80=99t know whether I will find the = time to elaborate on this in the draft till the cutoff date for Prague, = but I agree that these relations should be clarified in a future version = of the draft. Cool! Cheers, Michael From nobody Mon Jun 26 07:18:54 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C5112EA6A for ; Mon, 26 Jun 2017 07:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 B2vq-ZbFy2Ci for ; Mon, 26 Jun 2017 07:18:50 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:638:809:ff11:130:149:220:242]) by ietfa.amsl.com (Postfix) with ESMTP id DF969129B91 for ; Mon, 26 Jun 2017 07:18:49 -0700 (PDT) Received: from [130.149.220.45] (esmeralda.net.t-labs.tu-berlin.de [130.149.220.45]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id E676773 for ; Mon, 26 Jun 2017 16:18:48 +0200 (CEST) References: <149796416409.23697.3832758224070683494.idtracker@ietfa.amsl.com> <5BE6202F-8666-4158-964A-41781FD04BF2@ifi.uio.no> From: Theresa Enghardt To: taps@ietf.org Message-ID: <9c28b754-7e49-f968-72b6-d822a96b029d@inet.tu-berlin.de> Date: Mon, 26 Jun 2017 16:18:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5BE6202F-8666-4158-964A-41781FD04BF2@ifi.uio.no> Content-Type: multipart/alternative; boundary="------------AE2D6147646802476110F191" Archived-At: Subject: [Taps] Feedback Re: Fwd: New Version Notification for draft-gjessing-taps-minset-05.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 14:18:53 -0000 This is a multi-part message in MIME format. --------------AE2D6147646802476110F191 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi, when reading the minset draft, I stumbled over a couple of points. Some of them may be nits and/or obvious to everyone except me, but I thought I'd offer them as feedback. Section 2 (Terminology): Would it make sense to define several more terms here, such as Flow, Flow group, Message and Frame? While reading the rest of the draft I was, e.g., wondering if a "TAPS flow" is the same as "Connection" defined in Section 2 or something else. E.g., in Section 3.1 the draft talks about how to create a TAPS flow and at least for me it would be helpful to read a description of what a TAPS flow actually is beforehand. Section 3.1 (Flow Creation, Connection and Termination), second paragraph: "A created flow can be queried for the maximum amount of data that an application can possibly expect to have transmitted before or during connection establishment." I had trouble understanding this sentence, as it was not immediately obvious to me that it is possible to send data before a connection is established. Maybe it would be helpful to first state that this is a feature that some protocols have. Section 3.2 (Flow Group Configuration): Is it also possible to configure these features on individual flows? Only if they do not have a group? (I had the same question again later at the beginning of Section 4.) Section 3.3 (Flow Configuration): At this point I was also wondering how to configuring a flow to be, e.g., reliable. As reliability is one of the most obvious transport features for me, I would find it useful to make this explicit. It is not configured per flow, but per message, right? So an application can send both reliable and unreliable messages in one flow, but it does not communicate this through the TAPS API at flow creation time, but only later when it actually sends the messages? Section 3.4.1 (The Sender): This section talks about messages and per-frame properties. Is a message the same as a frame here? Features that are optional - So are these still mandatory features to have in the API (which I thought the minset was) but then they do not have to be implemented, i.e., actually do something? Section 4 (An Abstract MinSet API): Do I have to create a flow-group-id explicitly or is the flow-group-id just the flow-id of a previous flow? In other words, are the flow-id and the flow-group-id the same number space or are they distinct? Best, Theresa On 20.06.2017 15:21, Michael Welzl wrote: > Dear group, > > We just updated the minset document. Important changes are: > - the minset itself is now presented early, all the long boring text > about how stuff was derived has been moved to an appendix > - a first stab at an abstract API representation of the minset is now > included! > > Cheers, > Michael & Stein > > >> Begin forwarded message: >> >> *From: *> >> *Subject: **New Version Notification for >> draft-gjessing-taps-minset-05.txt* >> *Date: *June 20, 2017 at 2:09:24 PM GMT+1 >> *To: *Michael Welzl >, >> Stein Gjessing > >> *Resent-From: *> >> >> >> A new version of I-D, draft-gjessing-taps-minset-05.txt >> has been successfully submitted by Michael Welzl and posted to the >> IETF repository. >> >> Name:draft-gjessing-taps-minset >> Revision:05 >> Title:A Minimal Set of Transport Services for TAPS Systems >> Document date:2017-06-20 >> Group:Individual Submission >> Pages:44 >> URL: >> https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-05.txt >> Status: >> https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/ >> Htmlized: https://tools.ietf.org/html/draft-gjessing-taps-minset-05 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-gjessing-taps-minset-05 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-gjessing-taps-minset-05 >> >> Abstract: >> This draft recommends a minimal set of IETF Transport Services >> offered by end systems supporting TAPS, and gives guidance on >> choosing among the available mechanisms and protocols. It is based >> on the set of transport features given in the TAPS document >> draft-ietf-taps-transports-usage-05. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org >> . >> >> The IETF Secretariat >> > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --------------AE2D6147646802476110F191 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi,

when reading the minset draft, I stumbled over a couple of points. Some of them may be nits and/or obvious to everyone except me, but I thought I'd offer them as feedback.

Section 2 (Terminology): Would it make sense to define several more terms here, such as Flow, Flow group, Message and Frame? While reading the rest of the draft I was, e.g., wondering if a "TAPS flow" is the same as "Connection" defined in Section 2 or something else. E.g., in Section 3.1 the draft talks about how to create a TAPS flow and at least for me it would be helpful to read a description of what a TAPS flow actually is beforehand.

Section 3.1 (Flow Creation, Connection and Termination), second paragraph: "A created flow can be queried for the maximum amount of data that an application can possibly expect to have transmitted before or during connection establishment."
I had trouble understanding this sentence, as it was not immediately obvious to me that it is possible to send data before a connection is established. Maybe it would be helpful to first state that this is a feature that some protocols have.

Section 3.2 (Flow Group Configuration): Is it also possible to configure these features on individual flows? Only if they do not have a group? (I had the same question again later at the beginning of Section 4.)

Section 3.3 (Flow Configuration): At this point I was also wondering how to configuring a flow to be, e.g., reliable. As reliability is one of the most obvious transport features for me, I would find it useful to make this explicit. It is not configured per flow, but per message, right? So an application can send both reliable and unreliable messages in one flow, but it does not communicate this through the TAPS API at flow creation time, but only later when it actually sends the messages?

Section 3.4.1 (The Sender): This section talks about messages and per-frame properties. Is a message the same as a frame here?

Features that are optional - So are these still mandatory features to have in the API (which I thought the minset was) but then they do not have to be implemented, i.e., actually do something?

Section 4 (An Abstract MinSet API): Do I have to create a flow-group-id explicitly or is the flow-group-id just the flow-id of a previous flow? In other words, are the flow-id and the flow-group-id the same number space or are they distinct?


Best,
Theresa


On 20.06.2017 15:21, Michael Welzl wrote:
Dear group,

We just updated the minset document. Important changes are:
- the minset itself is now presented early, all the long boring text about how stuff was derived has been moved to an appendix
- a first stab at an abstract API representation of the minset is now included!

Cheers,
Michael & Stein


Begin forwarded message:

Subject: New Version Notification for draft-gjessing-taps-minset-05.txt
Date: June 20, 2017 at 2:09:24 PM GMT+1
To: Michael Welzl <michawe@ifi.uio.no>, Stein Gjessing <steing@ifi.uio.no>
Resent-From: <michawe@ifi.uio.no>


A new version of I-D, draft-gjessing-taps-minset-05.txt
has been successfully submitted by Michael Welzl and posted to the
IETF repository.

Name: draft-gjessing-taps-minset
Revision: 05
Title: A Minimal Set of Transport Services for TAPS Systems
Document date: 2017-06-20
Group: Individual Submission
Pages: 44
URL: https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-05.txt
Status: https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/
Htmlized: https://tools.ietf.org/html/draft-gjessing-taps-minset-05
Htmlized: https://datatracker.ietf.org/doc/html/draft-gjessing-taps-minset-05
Diff: https://www.ietf.org/rfcdiff?url2=draft-gjessing-taps-minset-05

Abstract:
This draft recommends a minimal set of IETF Transport Services
offered by end systems supporting TAPS, and gives guidance on
choosing among the available mechanisms and protocols. It is based
on the set of transport features given in the TAPS document
draft-ietf-taps-transports-usage-05.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
--------------AE2D6147646802476110F191-- From nobody Mon Jun 26 08:38:10 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DCA129BA0 for ; Mon, 26 Jun 2017 08:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 QwrGZLDCcTMN for ; Mon, 26 Jun 2017 08:38:05 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 B190A12EB0E for ; Mon, 26 Jun 2017 08:38:00 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v5QFbcdg012285 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Jun 2017 17:37:38 +0200 Received: from [2001:638:809:ff1f::8295:dc3a] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dPW4y-00024w-RH; Mon, 26 Jun 2017 17:37:32 +0200 From: "Philipp S. Tiesel" Message-Id: <5EA32521-8E9E-417E-B7D9-4D7874FB1614@in-panik.de> Content-Type: multipart/alternative; boundary="Apple-Mail=_51A5A8A3-A5CB-4D8D-8776-8C908D97AAD2" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 26 Jun 2017 17:37:38 +0200 In-Reply-To: <5BE6202F-8666-4158-964A-41781FD04BF2@ifi.uio.no> Cc: "taps@ietf.org" To: Michael Welzl References: <149796416409.23697.3832758224070683494.idtracker@ietfa.amsl.com> <5BE6202F-8666-4158-964A-41781FD04BF2@ifi.uio.no> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Taps] New Version Notification for draft-gjessing-taps-minset-05.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 15:38:09 -0000 --Apple-Mail=_51A5A8A3-A5CB-4D8D-8776-8C908D97AAD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michael, Hi Stein, I also read through the draft (now more than once) and have some = questions and comments. I hope not to open old rat-holes with this=E2=80=A6 Sec 1 (Intro)=20 The number of transport features of current IETF transports is large, and exposing all of them has a number of disadvantages: generally, the more functionality is exposed, the less freedom a TAPS system has to automate usage of the various functions of its available set of transport protocols. Some functions only exist in one particular protocol, and if an application would use them, this would statically tie the application to this protocol, counteracting the purpose of a TAPS system. Also, if the number of exposed features is exceedingly large, a TAPS system might become very hard to use for an application programmer. Taking [TAPS2] as a basis, this document therefore develops a minimal set of transport features, removing the ones that could be harmful to the purpose of a TAPS system but keeping the ones that must be retained for applications to benefit from useful transport functionality. I am somewhat unsure if a TAPS system really should withhold an = application from, e.g., using TCP specific features if it has strong = evidence that the other endpoint will be TCP only?=20 I agree that an application using TAPS should make use of automation = when possible to avoid ossification, but is excluding applications that = need protocol specific functionality much more dangerous as it requires = a non-TAPS API to be present to service them? This "minimal set" can be implemented one-sided with a fall-back to TCP: i.e., a sender-side TAPS system can talk to a non-TAPS TCP receiver, and a receiver-side TAPS system can talk to a non-TAPS TCP sender. For systems that do not have this requirement, [I-D.trammell-taps-post-sockets] describes a way to extend the functionality of the minimal set such that several of its limitations are removed. I am glad to see that fallback is addressed, but why exclusively to TCP = and not TCP or UDP =E2=80=93 whatever is more applicable? I also don=E2=80=99t see any reason why a system like post sockets = shouldn=E2=80=99t support fallback. If using something happy eyeballs to = check what protocols are available (biased by preference)m there is no = reason why supporting a fallback ha to limit functionality. Sec 2.3 (Flow Group Configuration) Does the "capacity profile=E2=80=9D only apply to a flow group or can it = also be applied on a per-message basis? If this is only intended to imply the DSCP value, a message would be a = much better scope, e.g. for protocols that multiplex multiple kinds of = message within a single flow/flow group. Same applies to more values. Does it make sense to make them = configurable on multiple levels? Sec. 4 CONFIGURE_URGENCY (flow-group-id [scheduler] [capacity_profile] [low_watermark]) Do these three really belong together or are this these rathe three more = or less independent configuration variables? CONNECT (flow-id dst_addr) Connects a flow. This primitive may or may not trigger a notification (continuing LISTEN) on the listening side. If a send precedes this call, then data may be transmitted with this connect. PARAMETERS: dst_addr: the destination transport address to connect to Might be only a knit but this looks very TCP centric for me =E2=80=93 = how would a usage example for "UDP connect=E2=80=9D (which is somewhat = of a contradiction anyway) =E2=80=93 maybe I only dislike connect = here=E2=80=A6 Maybe this also needs what types of dst_addr might take - do I have to = think this something like a sockaddr_t or as a host / service pair? The = latter is much more useful for automation. AVE! Philipp S. Tiesel / phils=E2=80=A6 > On 20. Jun 2017, at 15:21, Michael Welzl wrote: >=20 > Dear group, >=20 > We just updated the minset document. Important changes are: > - the minset itself is now presented early, all the long boring text = about how stuff was derived has been moved to an appendix > - a first stab at an abstract API representation of the minset is now = included! >=20 > Cheers, > Michael & Stein >=20 >=20 >> Begin forwarded message: >>=20 >> From: > >> Subject: New Version Notification for = draft-gjessing-taps-minset-05.txt >> Date: June 20, 2017 at 2:09:24 PM GMT+1 >> To: Michael Welzl >, = Stein Gjessing > >> Resent-From: > >>=20 >>=20 >> A new version of I-D, draft-gjessing-taps-minset-05.txt >> has been successfully submitted by Michael Welzl and posted to the >> IETF repository. >>=20 >> Name: draft-gjessing-taps-minset >> Revision: 05 >> Title: A Minimal Set of Transport Services for TAPS = Systems >> Document date: 2017-06-20 >> Group: Individual Submission >> Pages: 44 >> URL: = https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-05.txt = >> Status: = https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/ = >> Htmlized: = https://tools.ietf.org/html/draft-gjessing-taps-minset-05 = >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-gjessing-taps-minset-05 = >> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-gjessing-taps-minset-05 = >>=20 >> Abstract: >> This draft recommends a minimal set of IETF Transport Services >> offered by end systems supporting TAPS, and gives guidance on >> choosing among the available mechanisms and protocols. It is based >> on the set of transport features given in the TAPS document >> draft-ietf-taps-transports-usage-05. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org = . >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_51A5A8A3-A5CB-4D8D-8776-8C908D97AAD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Michael,
Hi Stein,
I also read through the draft (now = more than once) and have some questions and comments.
I hope not to open old rat-holes with this=E2=80=A6


Sec 1 (Intro) 

   The number of transport features of current IETF =
transports is large,
   and exposing all of them has a number of disadvantages: generally,
   the more functionality is exposed, the less freedom a TAPS system has
   to automate usage of the various functions of its available set of
   transport protocols.  Some functions only exist in one particular
   protocol, and if an application would use them, this would statically
   tie the application to this protocol, counteracting the purpose of a
   TAPS system.  Also, if the number of exposed features is exceedingly
   large, a TAPS system might become very hard to use for an application
   programmer.  Taking [TAPS2] as a basis, this document therefore
   develops a minimal set of transport features, removing the ones that
   could be harmful to the purpose of a TAPS system but keeping the ones
   that must be retained for applications to benefit from useful
   transport functionality.

I am somewhat unsure if a TAPS = system really should withhold an application from, e.g., using TCP = specific features if it has strong evidence that the other endpoint will = be TCP only? 

I agree that an application using TAPS should make use of = automation when possible to avoid ossification, but is excluding = applications that need protocol specific functionality much more = dangerous as it requires a non-TAPS API to be present to service = them?

   This "minimal set" can be =
implemented one-sided with a fall-back to
   TCP: i.e., a sender-side TAPS system can talk to a non-TAPS TCP
   receiver, and a receiver-side TAPS system can talk to a non-TAPS TCP
   sender.  For systems that do not have this requirement,
   [I-D.trammell-taps-post-sockets] describes a way to extend the
   functionality of the minimal set such that several of its limitations
   are removed.
I am glad to see that fallback is = addressed, but why exclusively to TCP and not TCP or UDP =E2=80=93 = whatever is more applicable?

I also don=E2=80=99t see any reason why = a system like post sockets shouldn=E2=80=99t support fallback. If using = something happy eyeballs to check what protocols are available (biased = by preference)m there is no reason why supporting a fallback ha to limit = functionality.


Sec 2.3 (Flow Group = Configuration)

Does the "capacity profile=E2=80=9D only apply to a flow = group or can it also be applied on a per-message basis?
If this is only intended to imply the DSCP value, a message = would be a much better scope, e.g. for protocols that multiplex multiple = kinds of message within a single flow/flow group.
Same applies to more values. Does it = make sense to make them configurable on multiple levels?


Sec. 4

CONFIGURE_URGENCY =
(flow-group-id [scheduler] [capacity_profile]
   [low_watermark])

Do these three really belong together or are this these rathe = three more or less independent configuration variables?


   CONNECT (flow-id =
dst_addr)

   Connects a flow.  This primitive may or may not trigger a
   notification (continuing LISTEN) on the listening side.  If a send
   precedes this call, then data may be transmitted with this connect.

   PARAMETERS:
   dst_addr:  the destination transport address to connect to

Might be only a = knit but this looks very TCP centric for me =E2=80=93 how would a usage = example for "UDP connect=E2=80=9D (which is somewhat of a contradiction = anyway) =E2=80=93 maybe I only dislike connect here=E2=80=A6

Maybe this also needs = what types of dst_addr might take - do I have to think this something = like a sockaddr_t or as a host / service pair? The latter is much more = useful for automation.


AVE!
  = Philipp S. Tiesel / phils=E2=80=A6

On 20. Jun 2017, at 15:21, Michael Welzl = <michawe@ifi.uio.no> wrote:

Dear = group,

We just = updated the minset document. Important changes are:
-= the minset itself is now presented early, all the long boring text = about how stuff was derived has been moved to an appendix
- a first stab at an abstract API representation of the = minset is now included!

Cheers,
Michael & = Stein


Begin = forwarded message:

From: <internet-drafts@ietf.org>
Subject: New Version Notification for = draft-gjessing-taps-minset-05.txt
Date: June 20, 2017 at 2:09:24 PM GMT+1
To: Michael Welzl <michawe@ifi.uio.no>, = Stein Gjessing <steing@ifi.uio.no>
Resent-From: <michawe@ifi.uio.no>


A new version = of I-D, draft-gjessing-taps-minset-05.txt
has been = successfully submitted by Michael Welzl and posted to the
IETF repository.

Name: = draft-gjessing-taps-minset
Revision: 05
Title:= = A Minimal Set of Transport Services for TAPS Systems
Document date: 2017-06-20
Group:= = Individual Submission
Pages: 44
URL: =            https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset= -05.txt
Status: =         https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/
Htmlized:       https://tools.ietf.org/html/draft-gjessing-taps-minset-05Htmlized:       https://datatracker.ietf.org/doc/html/draft-gjessing-taps-minse= t-05
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-gjessing-taps-minset-= 05

Abstract:
=   This draft recommends a minimal set of IETF Transport = Services
  offered by end systems supporting = TAPS, and gives guidance on
  choosing among = the available mechanisms and protocols.  It is based
=   on the set of transport features given in the TAPS = document
=   draft-ietf-taps-transports-usage-05.




Please note that = it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

= --Apple-Mail=_51A5A8A3-A5CB-4D8D-8776-8C908D97AAD2-- From nobody Mon Jun 26 09:06:05 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B54129C29 for ; Mon, 26 Jun 2017 09:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 snqvBIAvDvRx for ; Mon, 26 Jun 2017 09:06:02 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A41129B38 for ; Mon, 26 Jun 2017 09:06:02 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id 16so4979201qkg.2 for ; Mon, 26 Jun 2017 09:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=WO+0DaoAfdwga0XbiRU3aeYn6PTP9C2mIjjQ+o/H290=; b=hwkLDGuZj3o4IJeASWNv+bV+dOkwTnCpBM1prA0nF8F5pbdDyvBByrvtI1+nBzebxr 3XCA36ePIVRzNvJr24PVzOBs19WcozyWGoTu0mOcugnKSUWRVSUCt39b1adTJ/6WCoq4 FuFWH6B15rm4+7TZTxpeuTk4ygeKfewQ3WFvc19EAe0o8hNKMIEg+bWVIFqLC7rtIq8g RZjEme1uF+FeJHVJA+2HyHflY9Mrl0yLyw5+oeq7N0I/ntDUfSr7Eu1NXfHFxTun9Gfv C69uz4ocnZvbxYtpSIV8c1IODd2tzmXl0P0qC0iAFTuaDhM1fDAH6QVVQoAdw9R1QW17 H3lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=WO+0DaoAfdwga0XbiRU3aeYn6PTP9C2mIjjQ+o/H290=; b=OSP/D9wmnBFMPUPCCX92w60CEnLejrfv2DUx4MMHuyWg7X2CXhaG2Sq+W7GHSELB3B lF2SzKZrORgRNyob5LkB8sR0mVgTg0kdJ7pwqE6RBwVHYUC0TgiISq/8pCUE7fAWE4Xe idfBH3mNJhxrrQx5kDC4jY8XkbV7rl7ALCMzZmH//g67I86iwiVjQ16AleVe9VOQkWbr GarEzBTIRbIxOchOUrm01UIU/bB1BDgoMzIEuI0TVdSRiC9d5D/XFD/viOFjuFP6gAh2 mAW3KNwGFrs/qmQ3S/YOikCPDC1mDymzSlVqubmn1gHEJqzmHIHQvBCXlfuwQEqWhepd 639A== X-Gm-Message-State: AKS2vOzoiRM/IVAzByL67SfGsiTNnkc9WELus5bUmGstMS0gBRVEsm0v MqcYjh/7p5s8BssK0CM= X-Received: by 10.55.116.66 with SMTP id p63mr1123960qkc.250.1498493161294; Mon, 26 Jun 2017 09:06:01 -0700 (PDT) Received: from [169.254.62.184] ([72.246.0.14]) by smtp.gmail.com with ESMTPSA id o41sm409726qtc.26.2017.06.26.09.06.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jun 2017 09:06:00 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Mon, 26 Jun 2017 12:06:00 -0400 Message-ID: In-Reply-To: <408986B2-B86B-4C7D-9E91-D554029579FA@gmail.com> References: <408986B2-B86B-4C7D-9E91-D554029579FA@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_CE54D89E-1AF6-4EB4-A8B7-34531DD4959C_=" X-Mailer: MailMate (1.9.6r5356) Archived-At: Subject: Re: [Taps] WGLC start for -transports-usage- docs X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 16:06:04 -0000 --=_MailMate_CE54D89E-1AF6-4EB4-A8B7-34531DD4959C_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable WGLC for these drafts has concluded. While there were only a few = comments on the final drafts, they were all constructive and positive. = A significant amount of work and review has gone into the drafts = creation by all the folks engaged in the working group so I=E2=80=99m not= = surprised at the minimal review discussion. In my view, the docs are = ready to publish, modulo a possible revision of the UDP doc. We need a shepherd to take these drafts through the publication process. = Ideally, it won=E2=80=99t be a wg chair or author. Would someone step = forward? =E2=80=94aaron On 29 May 2017, at 12:30, Aaron Falk wrote: > Dear TAPS working group: > > The authors have indicated the two drafts below are complete and are = > ready for a final working group review. WGLC starts today and will be = > three weeks, concluding June 19. Send comments, including an = > indication that the docs are ready for publication, to the working = > group list. > > * [On the Usage of Transport Features Provided by IETF Transport = > Protocols](https://www.ietf.org/internet-drafts/draft-ietf-taps-transpo= rts-usage-05.txt) > * [Features of the User Datagram Protocol (UDP) and Lightweight UDP = > (UDP- Lite) Transport = > Protocols](https://www.ietf.org/internet-drafts/draft-ietf-taps-transpo= rts-usage-udp-03.txt) > > > =E2=80=94aaron --=_MailMate_CE54D89E-1AF6-4EB4-A8B7-34531DD4959C_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

WGLC for these drafts has concluded. While there were on= ly a few comments on the final drafts, they were all constructive and pos= itive. A significant amount of work and review has gone into the drafts = creation by all the folks engaged in the working group so I=E2=80=99m not= surprised at the minimal review discussion. In my view, the docs are re= ady to publish, modulo a possible revision of the UDP doc.

We need a shepherd to take these drafts through the publi= cation process. Ideally, it won=E2=80=99t be a wg chair or author. Woul= d someone step forward?

=E2=80=94aaron

On 29 May 2017, at 12:30, Aaron Falk wrote:

Dear TAPS working group:

The authors have indicated the two drafts below are compl= ete and are ready for a final working group review. WGLC starts today an= d will be three weeks, concluding June 19. Send comments, including an i= ndication that the docs are ready for publication, to the working group l= ist.

=E2=80=94aaron

--=_MailMate_CE54D89E-1AF6-4EB4-A8B7-34531DD4959C_=-- From nobody Mon Jun 26 10:32:54 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B2D1292FD for ; Mon, 26 Jun 2017 10:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 e2GyI7KKflqh for ; Mon, 26 Jun 2017 10:32:50 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 B70C6129B34 for ; Mon, 26 Jun 2017 10:32:50 -0700 (PDT) Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dPXsX-0000rX-5F for taps@ietf.org; Mon, 26 Jun 2017 19:32:49 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx01.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dPXsW-0000m2-8M; Mon, 26 Jun 2017 19:32:49 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: <9c28b754-7e49-f968-72b6-d822a96b029d@inet.tu-berlin.de> Date: Mon, 26 Jun 2017 19:32:47 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <00F55AFA-E5C2-40A1-8C24-2CD57AA18F62@ifi.uio.no> References: <149796416409.23697.3832758224070683494.idtracker@ietfa.amsl.com> <5BE6202F-8666-4158-964A-41781FD04BF2@ifi.uio.no> <9c28b754-7e49-f968-72b6-d822a96b029d@inet.tu-berlin.de> To: Theresa Enghardt X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 4 sum msgs/h 2 total rcpts 55947 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 417FCE4E3FD8DE5C1DA322F50A3E68B74D4EF557 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1629 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] Feedback Re: Fwd: New Version Notification for draft-gjessing-taps-minset-05.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 17:32:53 -0000 Hi, and thanks a lot for your comments! Answers in line: > On Jun 26, 2017, at 4:18 PM, Theresa Enghardt = wrote: >=20 > Hi, >=20 > when reading the minset draft, I stumbled over a couple of points. = Some of them may be nits and/or obvious to everyone except me, but I = thought I'd offer them as feedback. >=20 > Section 2 (Terminology): Would it make sense to define several more = terms here, such as Flow, Flow group, Message and Frame? While reading = the rest of the draft I was, e.g., wondering if a "TAPS flow" is the = same as "Connection" defined in Section 2 or something else. E.g., in = Section 3.1 the draft talks about how to create a TAPS flow and at least = for me it would be helpful to read a description of what a TAPS flow = actually is beforehand. Good input, will do! (the answer is: it can be a (TCP) connection, a stream of an (SCTP) = association, an (SCTP) association, =E2=80=A6 so i thought it=E2=80=99s = good to use a new word; yet it does fit the definition of a connection = in section 2) > Section 3.1 (Flow Creation, Connection and Termination), second = paragraph: "A created flow can be queried for the maximum amount of data = that an application can possibly expect to have transmitted before or = during connection establishment."=20 > I had trouble understanding this sentence, as it was not immediately = obvious to me that it is possible to send data before a connection is = established. Maybe it would be helpful to first state that this is a = feature that some protocols have. ACK, will do, thanks! > Section 3.2 (Flow Group Configuration): Is it also possible to = configure these features on individual flows? Only if they do not have a = group? (I had the same question again later at the beginning of Section = 4.) These things apply to a group only, because in case a flow becomes a = stream of an association, the protocol can only apply them to all = (e.g., change the timeout - you can=E2=80=99t do that for one stream of = an SCTP association only). I=E2=80=99ll try to clarify this in the text. > Section 3.3 (Flow Configuration): At this point I was also wondering = how to configuring a flow to be, e.g., reliable. As reliability is one = of the most obvious transport features for me, I would find it useful to = make this explicit. It is not configured per flow, but per message, = right? So an application can send both reliable and unreliable messages = in one flow, but it does not communicate this through the TAPS API at = flow creation time, but only later when it actually sends the messages? Exactly. Though here lies a fault - if this is not communicated at all, = the TAPS system may choose UDP, and then a sender decides for = reliability=E2=80=A6. bad! Good catch ! Will try to fix. > Section 3.4.1 (The Sender): This section talks about messages and = per-frame properties. Is a message the same as a frame here? Yes - but it=E2=80=99s another fault, I tried to use frame everywhere as = the new term here just to avoid making a connection between = =E2=80=9Cmessage=E2=80=9D and an SCTP =E2=80=9Cmessage=E2=80=9D (can be = the same but doesn=E2=80=99t have to be). So, use of message is a = mistake. Will fix! > Features that are optional - So are these still mandatory features to = have in the API (which I thought the minset was) but then they do not = have to be implemented, i.e., actually do something? Hm, I see them as optional in the API=E2=80=A6 I don=E2=80=99t think we = can truly =E2=80=9Cmandate=E2=80=9D a minset - it is meant to be a set = of functions that you will never be able to use unless you offer them in = an API in one way or another. In that sense, offering e.g. "Get max. transport frame size that may be = sent without fragmentation from the configured interface=E2=80=9D is = just an optimization, because a user could just as well decide to forbid = fragmenting and test various frame sizes =E2=80=A6 a less efficient way = of implementing PMTUD atop minset than by using this extra = functionality. So, I thought it=E2=80=99s less important to offer this = extra... Then again since nothing is *truly* mandatory maybe we should just skip = saying =E2=80=9Cthis and this is optional=E2=80=9D. > Section 4 (An Abstract MinSet API): Do I have to create a = flow-group-id explicitly or is the flow-group-id just the flow-id of a = previous flow? In other words, are the flow-id and the flow-group-id the = same number space or are they distinct? They=E2=80=99re distinct. The group is just a number to group flows, and = flows must have identifiers too - so you can have group 1 containing = flows 1, 2, 3 and group 2 containing flows 1, 2, 3. I=E2=80=99ll try to make the text clearer, thanks! Cheers, Michael From nobody Mon Jun 26 14:00:55 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E303D12EB74 for ; Mon, 26 Jun 2017 14:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0IhQe-4Jljxh for ; Mon, 26 Jun 2017 14:00:48 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 321FD12EB71 for ; Mon, 26 Jun 2017 14:00:48 -0700 (PDT) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dPb7m-000FIA-E4; Mon, 26 Jun 2017 23:00:46 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dPb7l-00046X-3d; Mon, 26 Jun 2017 23:00:46 +0200 From: Michael Welzl Message-Id: <35EF4149-8991-4CEC-B64F-585F57092AA5@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_5CD1756B-520C-4130-9BEA-1BBEB09AC668" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 26 Jun 2017 23:00:44 +0200 In-Reply-To: <5EA32521-8E9E-417E-B7D9-4D7874FB1614@in-panik.de> Cc: "taps@ietf.org" To: "Philipp S. Tiesel" References: <149796416409.23697.3832758224070683494.idtracker@ietfa.amsl.com> <5BE6202F-8666-4158-964A-41781FD04BF2@ifi.uio.no> <5EA32521-8E9E-417E-B7D9-4D7874FB1614@in-panik.de> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 4 sum msgs/h 1 total rcpts 55949 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.3, required=5.0, autolearn=disabled, AWL=-0.275, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AFF6403892DA5699D930A51061FD390EF151C608 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -52 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1630 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] New Version Notification for draft-gjessing-taps-minset-05.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 21:00:53 -0000 --Apple-Mail=_5CD1756B-520C-4130-9BEA-1BBEB09AC668 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Philipp, Thanks a lot for your comments! Definitely not rat-holing, you ask some = quite interesting questions - it=E2=80=99s great to get some discussion = on this! My answers are in line: > On Jun 26, 2017, at 5:37 PM, Philipp S. Tiesel = wrote: >=20 > Hi Michael, > Hi Stein, >=20 > I also read through the draft (now more than once) and have some = questions and comments. > I hope not to open old rat-holes with this=E2=80=A6 >=20 >=20 > Sec 1 (Intro)=20 >=20 > The number of transport features of current IETF transports is = large, > and exposing all of them has a number of disadvantages: generally, > the more functionality is exposed, the less freedom a TAPS system = has > to automate usage of the various functions of its available set of > transport protocols. Some functions only exist in one particular > protocol, and if an application would use them, this would = statically > tie the application to this protocol, counteracting the purpose of = a > TAPS system. Also, if the number of exposed features is = exceedingly > large, a TAPS system might become very hard to use for an = application > programmer. Taking [TAPS2] as a basis, this document therefore > develops a minimal set of transport features, removing the ones = that > could be harmful to the purpose of a TAPS system but keeping the = ones > that must be retained for applications to benefit from useful > transport functionality. >=20 > I am somewhat unsure if a TAPS system really should withhold an = application from, e.g., using TCP specific features if it has strong = evidence that the other endpoint will be TCP only?=20 Let me give you an SCTP example: "Specifying a "payload protocol-id" = (handed over as such by the receiver)=E2=80=9D. This is actually just a = mechanism to send an out-of-band number that=E2=80=99s logically = associated with an SCTP association. I wouldn=E2=80=99t think it=E2=80=99s= the world=E2=80=99s most useful mechanism, either=E2=80=A6 but: if you = use this, any chance of falling back to TCP flies out the window. I.e.: = if SCTP doesn=E2=80=99t work, the TAPS system fails. You write about = TCP; this is a bit of a special case, because it=E2=80=99s the protocol = that we chose to be able to fall back to - so forever binding an = application to TCP won=E2=80=99t make the TAPS system fail. It will, = however, make it less flexible, so I don=E2=80=99t think it=E2=80=99s = advisable. Note these are all informational documents, there=E2=80=99s no TAPS = =E2=80=9Cpolice=E2=80=9D - if you implement a TAPS system that goes = against this rule this is still a good way forward! But I think having = this word of caution against such protocol-specific functions here makes = sense. > I agree that an application using TAPS should make use of automation = when possible to avoid ossification, but is excluding applications that = need protocol specific functionality much more dangerous as it requires = a non-TAPS API to be present to service them? I don=E2=80=99t know - maybe we should discuss this based on concrete = cases. What functionality are you missing? To me, if possible, the better thing to do would be to express this = functionality abstract enough so it doesn=E2=80=99t get in the way of a = TAPS system=E2=80=99s flexibility. > This "minimal set" can be implemented one-sided with a fall-back to > TCP: i.e., a sender-side TAPS system can talk to a non-TAPS TCP > receiver, and a receiver-side TAPS system can talk to a non-TAPS = TCP > sender. For systems that do not have this requirement, > [I-D.trammell-taps-post-sockets] describes a way to extend the > functionality of the minimal set such that several of its = limitations > are removed. > I am glad to see that fallback is addressed, but why exclusively to = TCP and not TCP or UDP =E2=80=93 whatever is more applicable? That=E2=80=99s a tricky one. At some point, when designing this, I = thought of addressing both =E2=80=A6 and that would have made the draft = even longer and the story even more complex. This was my main motivation = for TCP-only :) Also, TCP does suit for many things - even UDP applications won=E2=80=99t = =E2=80=9Cbreak=E2=80=9D with TCP (actually some UDP apps such as Skype = *do* fall back to TCP), but most TCP apps would =E2=80=9Cbreak=E2=80=9D = with UDP. > I also don=E2=80=99t see any reason why a system like post sockets = shouldn=E2=80=99t support fallback. If using something happy eyeballs to = check what protocols are available (biased by preference)m there is no = reason why supporting a fallback ha to limit functionality. I disagree with the second sentence, but maybe this is a = misunderstanding, as there are multiple degrees of freedom here. If =E2=80=9Cfallback=E2=80=9D is only about the protocol on the wire, = not about the system on the other end, then there is no limitation: you = can define pretty much any protocol you wish atop UDP. However, fallback as in the minset draft requires only a one-sided = change - i.e., a minset client is able to talk to a TAPS-ignorant TCP = server. post-sockets is somewhere in between: it does assume a post-socket = system on both ends (e.g., to guarantee that the receiving application = is informed about message boundaries), but most of it can probably be = implemented with existing protocols. > Sec 2.3 (Flow Group Configuration) >=20 > Does the "capacity profile=E2=80=9D only apply to a flow group or can = it also be applied on a per-message basis? > If this is only intended to imply the DSCP value, a message would be a = much better scope, e.g. for protocols that multiplex multiple kinds of = message within a single flow/flow group. First: it=E2=80=99s not only intended to imply the DSCP value - I tried = to make things a tiny bit more abstract and uniform by inventing this = transport feature that encompasses the DSCP but also e.g. the choice of = LEDBAT or not, or controlling Nagle. Second: conceptually I agree that a message would be a better scope if = it was only the DSCP (but it isn=E2=80=99t - and e.g. switching to = LEDBAT clearly isn=E2=80=99t a per-message thing), but even for the DSCP = this doesn=E2=80=99t seem doable with TCP, or with SCTP, where the DSCP = is a parameter of a =E2=80=9Cpeer address=E2=80=9D, i.e. related to an = association: https://tools.ietf.org/html/rfc6458#section-8.1.12 = > Same applies to more values. Does it make sense to make them = configurable on multiple levels? What do you mean? > Sec. 4 >=20 > CONFIGURE_URGENCY (flow-group-id [scheduler] [capacity_profile] > [low_watermark]) >=20 > Do these three really belong together or are this these rathe three = more or less independent configuration variables? Oh, that was just an effort to group them somehow. We could just as well = have a big =E2=80=9CCONFIGURE=E2=80=9D call that lets you configure = anything, I just felt it=E2=80=99s a bit more organized this way. To me, = these fit together, but I don=E2=80=99t have a very strong opinion about = this. > CONNECT (flow-id dst_addr) >=20 > Connects a flow. This primitive may or may not trigger a > notification (continuing LISTEN) on the listening side. If a send > precedes this call, then data may be transmitted with this connect. >=20 > PARAMETERS: > dst_addr: the destination transport address to connect to >=20 > Might be only a knit but this looks very TCP centric for me =E2=80=93 = how would a usage example for "UDP connect=E2=80=9D (which is somewhat = of a contradiction anyway) =E2=80=93 maybe I only dislike connect = here=E2=80=A6 It=E2=80=99s not a contradiction - CONNECT just creates a context, e.g. = for configuration transport features (see = draft-ietf-taps-transports-usage-udp ). In the minset, a flow can also = be a stream of an SCTP association, in which case opening flow #2 and #3 = of an association doesn=E2=80=99t actually produce any effect on the = wire - just as with UDP. > Maybe this also needs what types of dst_addr might take - do I have to = think this something like a sockaddr_t or as a host / service pair? The = latter is much more useful for automation. Ah, I see - =E2=80=9Ctransport address=E2=80=9D is defined in the list = in the usage draft, but not in the minset draft. I think that=E2=80=99s = a mistake, based on copying an older version of this list. Sorry! =46rom the usage draft: *** Transport Address: the combination of an IP address, transport protocol and the port number used by the transport protocol. *** Cheers, Michael --Apple-Mail=_5CD1756B-520C-4130-9BEA-1BBEB09AC668 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Philipp,

Thanks a lot for your comments!  Definitely not = rat-holing, you ask some quite interesting questions - it=E2=80=99s = great to get some discussion on this!

My answers are in line:

On Jun 26, 2017, at 5:37 PM, Philipp S. Tiesel <phils@in-panik.de> = wrote:

Hi = Michael,
Hi Stein,
I also read through the draft (now = more than once) and have some questions and comments.
I hope not to open old rat-holes with this=E2=80=A6


Sec 1 (Intro) 

   The number of transport features of current IETF =
transports is large,
   and exposing all of them has a number of disadvantages: generally,
   the more functionality is exposed, the less freedom a TAPS system has
   to automate usage of the various functions of its available set of
   transport protocols.  Some functions only exist in one particular
   protocol, and if an application would use them, this would statically
   tie the application to this protocol, counteracting the purpose of a
   TAPS system.  Also, if the number of exposed features is exceedingly
   large, a TAPS system might become very hard to use for an application
   programmer.  Taking [TAPS2] as a basis, this document therefore
   develops a minimal set of transport features, removing the ones that
   could be harmful to the purpose of a TAPS system but keeping the ones
   that must be retained for applications to benefit from useful
   transport functionality.

I am somewhat unsure if a TAPS = system really should withhold an application from, e.g., using TCP = specific features if it has strong evidence that the other endpoint will = be TCP only? 

Let me give you an SCTP example: "Specifying a = "payload protocol-id" (handed over as such by the receiver)=E2=80=9D. =  This is actually just a mechanism to send an out-of-band number = that=E2=80=99s logically associated with an SCTP association. I = wouldn=E2=80=99t think it=E2=80=99s the world=E2=80=99s most useful = mechanism, either=E2=80=A6 but: if you use this, any chance of falling = back to TCP flies out the window. I.e.: if SCTP doesn=E2=80=99t work, = the TAPS system fails. You write about TCP; this is a bit of a special = case, because it=E2=80=99s the protocol that we chose to be able to fall = back to - so forever binding an application to TCP won=E2=80=99t make = the TAPS system fail. It will, however, make it less flexible, so I = don=E2=80=99t think it=E2=80=99s advisable.

Note these are all informational = documents, there=E2=80=99s no TAPS =E2=80=9Cpolice=E2=80=9D - if you = implement a TAPS system that goes against this rule this is still a good = way forward!  But I think having this word of caution against such = protocol-specific functions here makes sense.


I agree = that an application using TAPS should make use of automation when = possible to avoid ossification, but is excluding applications that need = protocol specific functionality much more dangerous as it requires a = non-TAPS API to be present to service = them?

I= don=E2=80=99t know - maybe we should discuss this based on concrete = cases. What functionality are you missing?
To me, if possible, = the better thing to do would be to express this functionality abstract = enough so it doesn=E2=80=99t get in the way of a TAPS system=E2=80=99s = flexibility.


   This "minimal set" can be =
implemented one-sided with a fall-back to
   TCP: i.e., a sender-side TAPS system can talk to a non-TAPS TCP
   receiver, and a receiver-side TAPS system can talk to a non-TAPS TCP
   sender.  For systems that do not have this requirement,
   [I-D.trammell-taps-post-sockets] describes a way to extend the
   functionality of the minimal set such that several of its limitations
   are removed.
I am glad to see that fallback is = addressed, but why exclusively to TCP and not TCP or UDP =E2=80=93 = whatever is more = applicable?

That=E2=80=99s a tricky one. At some point, when = designing this, I thought of addressing both =E2=80=A6 and that would = have made the draft even longer and the story even more complex. This = was my main motivation for TCP-only  :)
Also, TCP does = suit for many things - even UDP applications won=E2=80=99t =E2=80=9Cbreak=E2= =80=9D with TCP (actually some UDP apps such as Skype *do* fall back to = TCP), but most TCP apps would =E2=80=9Cbreak=E2=80=9D with = UDP.


I also don=E2=80=99t see any reason why a system like post = sockets shouldn=E2=80=99t support fallback. If using something happy = eyeballs to check what protocols are available (biased by preference)m = there is no reason why supporting a fallback ha to limit = functionality.

I disagree with the second sentence, but maybe = this is a misunderstanding, as there are multiple degrees of freedom = here.
If =E2=80=9Cfallback=E2=80=9D is only about the protocol = on the wire, not about the system on the other end, then there is no = limitation: you can define pretty much any protocol you wish atop = UDP.
However, fallback as in the minset draft requires only a = one-sided change - i.e., a minset client is able to talk to a = TAPS-ignorant TCP server.

post-sockets= is somewhere in between: it does assume a post-socket system on both = ends (e.g., to guarantee that the receiving application is informed = about message boundaries), but most of it can probably be implemented = with existing protocols.


Sec 2.3 (Flow Group Configuration)

Does the "capacity = profile=E2=80=9D only apply to a flow group or can it also be applied on = a per-message basis?
If this is only intended to = imply the DSCP value, a message would be a much better scope, e.g. for = protocols that multiplex multiple kinds of message within a single = flow/flow group.

First: it=E2=80=99s not only intended to imply the = DSCP value - I tried to make things a tiny bit more abstract and uniform = by inventing this transport feature that encompasses the DSCP but also = e.g. the choice of LEDBAT or not, or controlling = Nagle.
Second: conceptually I agree that a message would be a = better scope if it was only the DSCP (but it isn=E2=80=99t - and e.g. = switching to LEDBAT clearly isn=E2=80=99t a per-message thing), but even = for the DSCP this doesn=E2=80=99t seem doable with TCP, or with SCTP, = where the DSCP is a parameter of a =E2=80=9Cpeer address=E2=80=9D, i.e. = related to an association: https://tools.ietf.org/html/rfc6458#section-8.1.12


Same applies = to more values. Does it make sense to make them configurable on multiple = levels?

What do you mean?

Sec. 4

CONFIGURE_URGENCY (flow-group-id [scheduler] =
[capacity_profile]
   [low_watermark])

Do these three really belong together or are this these rathe = three more or less independent configuration = variables?

Oh, that was just an effort to group them somehow. = We could just as well have a big =E2=80=9CCONFIGURE=E2=80=9D call that = lets you configure anything, I just felt it=E2=80=99s a bit more = organized this way. To me, these fit together, but I don=E2=80=99t have = a very strong opinion about this.


   CONNECT (flow-id dst_addr)

   Connects a flow.  This primitive may or may not trigger a
   notification (continuing LISTEN) on the listening side.  If a send
   precedes this call, then data may be transmitted with this connect.

   PARAMETERS:
   dst_addr:  the destination transport address to connect to

Might be only a = knit but this looks very TCP centric for me =E2=80=93 how would a usage = example for "UDP connect=E2=80=9D (which is somewhat of a contradiction = anyway) =E2=80=93 maybe I only dislike connect = here=E2=80=A6

It=E2=80=99s not a contradiction - CONNECT just = creates a context, e.g. for configuration transport features (see = draft-ietf-taps-transports-usage-udp ). In the minset, a flow can = also be a stream of an SCTP association, in which case opening flow #2 = and #3 of an association doesn=E2=80=99t actually produce any effect on = the wire - just as with UDP.


Maybe this also needs what types of dst_addr = might take - do I have to think this something like a sockaddr_t or as a = host / service pair? The latter is much more useful for = automation.

Ah, I see - =E2=80=9Ctransport address=E2=80=9D is = defined in the list in the usage draft, but not in the minset draft. I = think that=E2=80=99s a mistake, based on copying an older version of = this list. Sorry!
=46rom the usage draft:

***
  =  Transport Address:  the combination of an IP address, = transport
      protocol and the = port number used by the transport protocol.
***

Cheers,
Michael

= --Apple-Mail=_5CD1756B-520C-4130-9BEA-1BBEB09AC668-- From nobody Tue Jun 27 02:23:58 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DA5129AA3 for ; Tue, 27 Jun 2017 02:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 lE-0qTU6jsMs for ; Tue, 27 Jun 2017 02:23:53 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 412AF1293E1 for ; Tue, 27 Jun 2017 02:23:51 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v5R9NTGT016769 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Jun 2017 11:23:29 +0200 Received: from [2001:638:809:ff1f::8295:dc3a] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dPmiR-0002yI-JR; Tue, 27 Jun 2017 11:23:23 +0200 From: "Philipp S. Tiesel" Message-Id: <1FD02744-1342-4800-9F5B-960DA1B72A02@in-panik.de> Content-Type: multipart/alternative; boundary="Apple-Mail=_4897EEBB-2319-4042-8681-F475DEC8A6C5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 27 Jun 2017 11:23:29 +0200 In-Reply-To: <35EF4149-8991-4CEC-B64F-585F57092AA5@ifi.uio.no> Cc: "taps@ietf.org" To: Michael Welzl References: <149796416409.23697.3832758224070683494.idtracker@ietfa.amsl.com> <5BE6202F-8666-4158-964A-41781FD04BF2@ifi.uio.no> <5EA32521-8E9E-417E-B7D9-4D7874FB1614@in-panik.de> <35EF4149-8991-4CEC-B64F-585F57092AA5@ifi.uio.no> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Taps] New Version Notification for draft-gjessing-taps-minset-05.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 09:23:57 -0000 --Apple-Mail=_4897EEBB-2319-4042-8681-F475DEC8A6C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michael, > On 26. Jun 2017, at 23:00, Michael Welzl wrote: >=20 > Hi Philipp, >=20 > Thanks a lot for your comments! Definitely not rat-holing, you ask = some quite interesting questions - it=E2=80=99s great to get some = discussion on this! >=20 > My answers are in line: >=20 >> On Jun 26, 2017, at 5:37 PM, Philipp S. Tiesel > wrote: >>=20 >> Hi Michael, >> Hi Stein, >>=20 >> I also read through the draft (now more than once) and have some = questions and comments. >> I hope not to open old rat-holes with this=E2=80=A6 >>=20 >>=20 >> Sec 1 (Intro)=20 >>=20 >> The number of transport features of current IETF transports is = large, >> and exposing all of them has a number of disadvantages: generally, >> the more functionality is exposed, the less freedom a TAPS system = has >> to automate usage of the various functions of its available set of >> transport protocols. Some functions only exist in one particular >> protocol, and if an application would use them, this would = statically >> tie the application to this protocol, counteracting the purpose of = a >> TAPS system. Also, if the number of exposed features is = exceedingly >> large, a TAPS system might become very hard to use for an = application >> programmer. Taking [TAPS2] as a basis, this document therefore >> develops a minimal set of transport features, removing the ones = that >> could be harmful to the purpose of a TAPS system but keeping the = ones >> that must be retained for applications to benefit from useful >> transport functionality. >>=20 >> I am somewhat unsure if a TAPS system really should withhold an = application from, e.g., using TCP specific features if it has strong = evidence that the other endpoint will be TCP only?=20 >=20 > Let me give you an SCTP example: "Specifying a "payload protocol-id" = (handed over as such by the receiver)=E2=80=9D. This is actually just a = mechanism to send an out-of-band number that=E2=80=99s logically = associated with an SCTP association. I wouldn=E2=80=99t think it=E2=80=99s= the world=E2=80=99s most useful mechanism, either=E2=80=A6 but: if you = use this, any chance of falling back to TCP flies out the window. I.e.: = if SCTP doesn=E2=80=99t work, the TAPS system fails. You write about = TCP; this is a bit of a special case, because it=E2=80=99s the protocol = that we chose to be able to fall back to - so forever binding an = application to TCP won=E2=80=99t make the TAPS system fail. It will, = however, make it less flexible, so I don=E2=80=99t think it=E2=80=99s = advisable. Ok - this case looks as useful as TCP urgent data =E2=80=93 I agree = recommending against using such mechanisms. > Note these are all informational documents, there=E2=80=99s no TAPS = =E2=80=9Cpolice=E2=80=9D - if you implement a TAPS system that goes = against this rule this is still a good way forward! But I think having = this word of caution against such protocol-specific functions here makes = sense. I think this is a little more complex=E2=80=A6 If you want a TAPS system = to fully replace other Socket APIs, I assume it should also make = protocol features available, that are nor portable across protocols. I = agree that these features are a) not part of a minimal set b) no =E2=80=9Cfirst class citizens=E2=80=9D = c) recommended against using.=20 The question is whether this discussion should go into this or another = draft. >> I agree that an application using TAPS should make use of automation = when possible to avoid ossification, but is excluding applications that = need protocol specific functionality much more dangerous as it requires = a non-TAPS API to be present to service them? >=20 > I don=E2=80=99t know - maybe we should discuss this based on concrete = cases. What functionality are you missing? > To me, if possible, the better thing to do would be to express this = functionality abstract enough so it doesn=E2=80=99t get in the way of a = TAPS system=E2=80=99s flexibility. I definitely see OOB mechanisms as discussed above and path management = in MPTCP and SCPT.=20 The latter is a good candidate for abstract terms and automation, but = there might also be use cases for which a more concrete, protocol = independent API to bind data to certain paths is needed. For OOB mechanisms, there might be use of some special flags to the = send_frame and recv_frame calls that are a) protocol specific, b) cause = an error if called on a flow using the wrong protocol and c) are = recommended against using. >> This "minimal set" can be implemented one-sided with a fall-back = to >> TCP: i.e., a sender-side TAPS system can talk to a non-TAPS TCP >> receiver, and a receiver-side TAPS system can talk to a non-TAPS = TCP >> sender. For systems that do not have this requirement, >> [I-D.trammell-taps-post-sockets] describes a way to extend the >> functionality of the minimal set such that several of its = limitations >> are removed. >> I am glad to see that fallback is addressed, but why exclusively to = TCP and not TCP or UDP =E2=80=93 whatever is more applicable? >=20 > That=E2=80=99s a tricky one. At some point, when designing this, I = thought of addressing both =E2=80=A6 and that would have made the draft = even longer and the story even more complex. This was my main motivation = for TCP-only :) > Also, TCP does suit for many things - even UDP applications won=E2=80=99= t =E2=80=9Cbreak=E2=80=9D with TCP (actually some UDP apps such as Skype = *do* fall back to TCP), but most TCP apps would =E2=80=9Cbreak=E2=80=9D = with UDP. For doing this, you would have to move the reliable/unreliable decision = up to the "Flow Group=E2=80=9D level=E2=80=A6 But finally, I guess it is needed at both levels. In case = =E2=80=9Cunreliable=E2=80=9D it is set at "Flow Group=E2=80=9D level, = all messages will be unreliable, if set at message level, the single = message is sent unreliable if supported by the underlying protocol. >> I also don=E2=80=99t see any reason why a system like post sockets = shouldn=E2=80=99t support fallback. If using something happy eyeballs to = check what protocols are available (biased by preference)m there is no = reason why supporting a fallback ha to limit functionality. >=20 > I disagree with the second sentence, but maybe this is a = misunderstanding, as there are multiple degrees of freedom here. > If =E2=80=9Cfallback=E2=80=9D is only about the protocol on the wire, = not about the system on the other end, then there is no limitation: you = can define pretty much any protocol you wish atop UDP. > However, fallback as in the minset draft requires only a one-sided = change - i.e., a minset client is able to talk to a TAPS-ignorant TCP = server. >=20 > post-sockets is somewhere in between: it does assume a post-socket = system on both ends (e.g., to guarantee that the receiving application = is informed about message boundaries), but most of it can probably be = implemented with existing protocols. Oh, I never read that from the Post Socket publications. But I guess we = should discuss this with Brian how much he has Post Socket to = =E2=80=9CLegacy=E2=80=9D communication in mind. >> Sec 2.3 (Flow Group Configuration) >>=20 >> Does the "capacity profile=E2=80=9D only apply to a flow group or can = it also be applied on a per-message basis? >> If this is only intended to imply the DSCP value, a message would be = a much better scope, e.g. for protocols that multiplex multiple kinds of = message within a single flow/flow group. >=20 > First: it=E2=80=99s not only intended to imply the DSCP value - I = tried to make things a tiny bit more abstract and uniform by inventing = this transport feature that encompasses the DSCP but also e.g. the = choice of LEDBAT or not, or controlling Nagle. > Second: conceptually I agree that a message would be a better scope if = it was only the DSCP (but it isn=E2=80=99t - and e.g. switching to = LEDBAT clearly isn=E2=80=99t a per-message thing), but even for the DSCP = this doesn=E2=80=99t seem doable with TCP, or with SCTP, where the DSCP = is a parameter of a =E2=80=9Cpeer address=E2=80=9D, i.e. related to an = association: https://tools.ietf.org/html/rfc6458#section-8.1.12 = >=20 >=20 >> Same applies to more values. Does it make sense to make them = configurable on multiple levels? >=20 > What do you mean? I primarily had the reliability issue in mind, but as I am about to = publish a draft on how to compose multipath aware protocol stacks, I = fear almost all transport features can be implemented at almost all = levels=E2=80=A6=20 >> Sec. 4 >>=20 >> CONFIGURE_URGENCY (flow-group-id [scheduler] [capacity_profile] >> [low_watermark]) >>=20 >> Do these three really belong together or are this these rathe three = more or less independent configuration variables? >=20 > Oh, that was just an effort to group them somehow. We could just as = well have a big =E2=80=9CCONFIGURE=E2=80=9D call that lets you configure = anything, I just felt it=E2=80=99s a bit more organized this way. To me, = these fit together, but I don=E2=80=99t have a very strong opinion about = this. >=20 >=20 >> CONNECT (flow-id dst_addr) >>=20 >> Connects a flow. This primitive may or may not trigger a >> notification (continuing LISTEN) on the listening side. If a send >> precedes this call, then data may be transmitted with this = connect. >>=20 >> PARAMETERS: >> dst_addr: the destination transport address to connect to >>=20 >> Might be only a knit but this looks very TCP centric for me =E2=80=93 = how would a usage example for "UDP connect=E2=80=9D (which is somewhat = of a contradiction anyway) =E2=80=93 maybe I only dislike connect = here=E2=80=A6 >=20 > It=E2=80=99s not a contradiction - CONNECT just creates a context, = e.g. for configuration transport features (see = draft-ietf-taps-transports-usage-udp ). In the minset, a flow can also = be a stream of an SCTP association, in which case opening flow #2 and #3 = of an association doesn=E2=80=99t actually produce any effect on the = wire - just as with UDP. Fine - I just know too many people that scream when mentioning UDP and = connect together ;-) >> Maybe this also needs what types of dst_addr might take - do I have = to think this something like a sockaddr_t or as a host / service pair? = The latter is much more useful for automation. >=20 > Ah, I see - =E2=80=9Ctransport address=E2=80=9D is defined in the list = in the usage draft, but not in the minset draft. I think that=E2=80=99s = a mistake, based on copying an older version of this list. Sorry! > =46rom the usage draft: >=20 > *** > Transport Address: the combination of an IP address, transport > protocol and the port number used by the transport protocol. > *** Ok - thanks for clarifying - so no name resolution and endpoint = selection in the minimal mindset? AVE! Philipp S. Tiesel / phils=E2=80=A6 --Apple-Mail=_4897EEBB-2319-4042-8681-F475DEC8A6C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Michael,


On 26. Jun 2017, at 23:00, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi = Philipp,

Thanks a lot for = your comments!  Definitely not rat-holing, you ask some quite = interesting questions - it=E2=80=99s great to get some discussion on = this!

My answers are in = line:

On Jun = 26, 2017, at 5:37 PM, Philipp S. Tiesel <phils@in-panik.de> = wrote:

Hi Michael,
Hi Stein,

I also read through the draft (now more = than once) and have some questions and comments.
I = hope not to open old rat-holes with this=E2=80=A6

Sec= 1 (Intro) 

   The =
number of transport features of current IETF transports is large,
   and exposing all of them has a number of disadvantages: generally,
   the more functionality is exposed, the less freedom a TAPS system has
   to automate usage of the various functions of its available set of
   transport protocols.  Some functions only exist in one particular
   protocol, and if an application would use them, this would statically
   tie the application to this protocol, counteracting the purpose of a
   TAPS system.  Also, if the number of exposed features is exceedingly
   large, a TAPS system might become very hard to use for an application
   programmer.  Taking [TAPS2] as a basis, this document therefore
   develops a minimal set of transport features, removing the ones that
   could be harmful to the purpose of a TAPS system but keeping the ones
   that must be retained for applications to benefit from useful
   transport functionality.

I am somewhat unsure if a TAPS = system really should withhold an application from, e.g., using TCP = specific features if it has strong evidence that the other endpoint will = be TCP only? 
Let me give you an SCTP example: = "Specifying a "payload protocol-id" (handed over as such by the = receiver)=E2=80=9D.  This is actually just a mechanism to send an = out-of-band number that=E2=80=99s logically associated with an SCTP = association. I wouldn=E2=80=99t think it=E2=80=99s the world=E2=80=99s = most useful mechanism, either=E2=80=A6 but: if you use this, any chance = of falling back to TCP flies out the window. I.e.: if SCTP doesn=E2=80=99t= work, the TAPS system fails. You write about TCP; this is a bit of a = special case, because it=E2=80=99s the protocol that we chose to be able = to fall back to - so forever binding an application to TCP won=E2=80=99t = make the TAPS system fail. It will, however, make it less flexible, so I = don=E2=80=99t think it=E2=80=99s = advisable.

Ok - this case looks as useful as TCP urgent data = =E2=80=93 I agree recommending against using such = mechanisms.


Note these are all informational documents, = there=E2=80=99s no TAPS =E2=80=9Cpolice=E2=80=9D - if you implement a = TAPS system that goes against this rule this is still a good way = forward!  But I think having this word of caution against such = protocol-specific functions here makes = sense.

I think this is a little more complex=E2=80=A6 If = you want a TAPS system to fully replace other Socket APIs, I assume it = should also make protocol features available, that are nor portable = across protocols. I agree that these features are
a) not part = of a minimal set b) no =E2=80=9Cfirst class citizens=E2=80=9D c) = recommended against using. 
The question is whether this = discussion should go into this or another draft.


I agree that an = application using TAPS should make use of automation when possible to = avoid ossification, but is excluding applications that need protocol = specific functionality much more dangerous as it requires a non-TAPS API = to be present to service them?

I don=E2=80=99t know - = maybe we should discuss this based on concrete cases. What functionality = are you missing?
To me, if possible, the better = thing to do would be to express this functionality abstract enough so it = doesn=E2=80=99t get in the way of a TAPS system=E2=80=99s = flexibility.

I definitely see OOB mechanisms as discussed above = and path management in MPTCP and SCPT. 
The latter is a = good candidate for abstract terms and automation, but there might also = be use cases for which a more concrete, protocol independent API to bind = data to certain paths is needed.
For OOB mechanisms, there = might be use of some special flags to the send_frame and recv_frame = calls that are a) protocol specific, b) cause an error if called on a = flow using the wrong protocol and c) are recommended against = using.


   =
This "minimal set" can be implemented one-sided with a fall-back to
   TCP: i.e., a sender-side TAPS system can talk to a non-TAPS TCP
   receiver, and a receiver-side TAPS system can talk to a non-TAPS TCP
   sender.  For systems that do not have this requirement,
   [I-D.trammell-taps-post-sockets] describes a way to extend the
   functionality of the minimal set such that several of its limitations
   are removed.
I am glad to see that fallback is = addressed, but why exclusively to TCP and not TCP or UDP =E2=80=93 = whatever is more = applicable?

That=E2=80=99s a tricky one. At some = point, when designing this, I thought of addressing both =E2=80=A6 and = that would have made the draft even longer and the story even more = complex. This was my main motivation for TCP-only  :)
Also, TCP does suit for many things - even UDP applications = won=E2=80=99t =E2=80=9Cbreak=E2=80=9D with TCP (actually some UDP apps = such as Skype *do* fall back to TCP), but most TCP apps would = =E2=80=9Cbreak=E2=80=9D with UDP.

For doing this, you would have to move the = reliable/unreliable decision up to the "Flow Group=E2=80=9D = level=E2=80=A6
But finally, I guess it is needed at both = levels. In case =E2=80=9Cunreliable=E2=80=9D it is set at "Flow Group=E2=80= =9D level, all messages will be unreliable, if set at message level, the = single message is sent unreliable if supported by the underlying = protocol.


I also don=E2=80=99t see any reason why a = system like post sockets shouldn=E2=80=99t support fallback. If using = something happy eyeballs to check what protocols are available (biased = by preference)m there is no reason why supporting a fallback ha to limit = functionality.

I disagree with the = second sentence, but maybe this is a misunderstanding, as there are = multiple degrees of freedom here.
If =E2=80=9Cfallbac= k=E2=80=9D is only about the protocol on the wire, not about the system = on the other end, then there is no limitation: you can define pretty = much any protocol you wish atop UDP.
However, = fallback as in the minset draft requires only a one-sided change - i.e., = a minset client is able to talk to a TAPS-ignorant TCP server.

post-sockets is = somewhere in between: it does assume a post-socket system on both ends = (e.g., to guarantee that the receiving application is informed about = message boundaries), but most of it can probably be implemented with = existing protocols.

Oh, I never read that from the Post Socket = publications. But I guess we should discuss this with Brian how much he = has Post Socket to =E2=80=9CLegacy=E2=80=9D communication in = mind.


Sec 2.3 (Flow Group Configuration)

Does the "capacity = profile=E2=80=9D only apply to a flow group or can it also be applied on = a per-message basis?
If this is only intended to = imply the DSCP value, a message would be a much better scope, e.g. for = protocols that multiplex multiple kinds of message within a single = flow/flow group.

First: it=E2=80=99s not = only intended to imply the DSCP value - I tried to make things a tiny = bit more abstract and uniform by inventing this transport feature that = encompasses the DSCP but also e.g. the choice of LEDBAT or not, or = controlling Nagle.
Second: conceptually I agree = that a message would be a better scope if it was only the DSCP (but it = isn=E2=80=99t - and e.g. switching to LEDBAT clearly isn=E2=80=99t a = per-message thing), but even for the DSCP this doesn=E2=80=99t seem = doable with TCP, or with SCTP, where the DSCP is a parameter of a = =E2=80=9Cpeer address=E2=80=9D, i.e. related to an association: https://tools.ietf.org/html/rfc6458#section-8.1.12


Same = applies to more values. Does it make sense to make them configurable on = multiple levels?

What do you = mean?

I = primarily had the reliability issue in mind, but as I am about to = publish a draft on how to compose multipath aware protocol stacks, I = fear almost all transport features can be implemented at almost all = levels=E2=80=A6 


Sec. 4
CONFIGURE_URGENCY (flow-group-id [scheduler] [capacity_profile]
   [low_watermark])

Do these three really belong together or are this these rathe = three more or less independent configuration = variables?

Oh, that was just an effort to group = them somehow. We could just as well have a big =E2=80=9CCONFIGURE=E2=80=9D= call that lets you configure anything, I just felt it=E2=80=99s a bit = more organized this way. To me, these fit together, but I don=E2=80=99t = have a very strong opinion about this.


   CONNECT (flow-id dst_addr)

   Connects a flow.  This primitive may or may not trigger a
   notification (continuing LISTEN) on the listening side.  If a send
   precedes this call, then data may be transmitted with this connect.

   PARAMETERS:
   dst_addr:  the destination transport address to connect to

Might be only a = knit but this looks very TCP centric for me =E2=80=93 how would a usage = example for "UDP connect=E2=80=9D (which is somewhat of a contradiction = anyway) =E2=80=93 maybe I only dislike connect = here=E2=80=A6

It=E2=80=99s not a = contradiction - CONNECT just creates a context, e.g. for configuration = transport features (see draft-ietf-taps-transports-usage-udp ). In = the minset, a flow can also be a stream of an SCTP association, in which = case opening flow #2 and #3 of an association doesn=E2=80=99t actually = produce any effect on the wire - just as with = UDP.

Fine - I = just know too many people that scream when mentioning UDP and connect = together ;-)


Maybe this also needs what = types of dst_addr might take - do I have to think this something like a = sockaddr_t or as a host / service pair? The latter is much more useful = for automation.

Ah, I see - =E2=80=9Ctransport = address=E2=80=9D is defined in the list in the usage draft, but not in = the minset draft. I think that=E2=80=99s a mistake, based on copying an = older version of this list. Sorry!
=46rom the usage = draft:

***
  =  Transport Address:  the combination of an IP address, = transport
      protocol and the = port number used by the transport protocol.
***

Ok = - thanks for clarifying - so no name resolution and endpoint selection = in the minimal mindset?


AVE!
  Philipp S. Tiesel / phils=E2=80=A6
= --Apple-Mail=_4897EEBB-2319-4042-8681-F475DEC8A6C5-- From nobody Tue Jun 27 04:22:08 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57528129789 for ; Tue, 27 Jun 2017 04:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 nlsJ6KroXPD2 for ; Tue, 27 Jun 2017 04:22:01 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 4F8481267BB for ; Tue, 27 Jun 2017 04:22:01 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dPoZD-00031i-6L; Tue, 27 Jun 2017 13:21:59 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx03.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dPoZB-0005wD-OG; Tue, 27 Jun 2017 13:21:59 +0200 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CF00C699-40D0-4B0C-9063-3E1C6A9BF97D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 27 Jun 2017 13:21:57 +0200 In-Reply-To: <1FD02744-1342-4800-9F5B-960DA1B72A02@in-panik.de> Cc: "taps@ietf.org" To: "Philipp S. Tiesel" References: <149796416409.23697.3832758224070683494.idtracker@ietfa.amsl.com> <5BE6202F-8666-4158-964A-41781FD04BF2@ifi.uio.no> <5EA32521-8E9E-417E-B7D9-4D7874FB1614@in-panik.de> <35EF4149-8991-4CEC-B64F-585F57092AA5@ifi.uio.no> <1FD02744-1342-4800-9F5B-960DA1B72A02@in-panik.de> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 3 sum rcpts/h 7 sum msgs/h 3 total rcpts 55960 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.049, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 025BDEFE066E5B751CADFF4F479B2A3E2CA99E01 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 1635 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] New Version Notification for draft-gjessing-taps-minset-05.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 11:22:06 -0000 --Apple-Mail=_CF00C699-40D0-4B0C-9063-3E1C6A9BF97D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I=E2=80=99m cutting some stuff (things that we just seem to agree about) = away and answering in line again: >> Note these are all informational documents, there=E2=80=99s no TAPS = =E2=80=9Cpolice=E2=80=9D - if you implement a TAPS system that goes = against this rule this is still a good way forward! But I think having = this word of caution against such protocol-specific functions here makes = sense. >=20 > I think this is a little more complex=E2=80=A6 If you want a TAPS = system to fully replace other Socket APIs, I assume it should also make = protocol features available, that are nor portable across protocols. I = agree that these features are > a) not part of a minimal set b) no =E2=80=9Cfirst class citizens=E2=80=9D= c) recommended against using.=20 > The question is whether this discussion should go into this or another = draft. But it=E2=80=99s a =E2=80=9Cminimum set=E2=80=9D, so it really *is* okay = to go beyond, as long as people are aware about the pro=E2=80=99s and = con=E2=80=99s. Anyway, maybe there=E2=80=99s an alternative solution. My suggestion would be: for any functionality that we=E2=80=99re really = missing and that would create a protocol dependency, can we try to raise = the abstraction level just enough to avoid the TAPS system coming back = and saying =E2=80=9Csorry, I can=E2=80=99t=E2=80=9D ? E.g.: =E2=80=9CPick interfaces X and Y=E2=80=9D is something that not = every protocol can do. Since it relates to system-wide or = network-related information (isn=E2=80=99t really application-specific), = minset says this could be automatized. However, giving information about the app behavior like you propose in = the socketintents draft can clearly help a TAPS system make the best = decision about the interface choice, and it=E2=80=99s only advisory = information - if a TAPS system just ignores it, e.g. because MPTCP = isn=E2=80=99t available, nothing bad will happen. >>> I agree that an application using TAPS should make use of automation = when possible to avoid ossification, but is excluding applications that = need protocol specific functionality much more dangerous as it requires = a non-TAPS API to be present to service them? >>=20 >> I don=E2=80=99t know - maybe we should discuss this based on concrete = cases. What functionality are you missing? >> To me, if possible, the better thing to do would be to express this = functionality abstract enough so it doesn=E2=80=99t get in the way of a = TAPS system=E2=80=99s flexibility. >=20 > I definitely see OOB mechanisms as discussed above and path management = in MPTCP and SCPT.=20 > The latter is a good candidate for abstract terms and automation, =E2=80=A6 indeed. > but there might also be use cases for which a more concrete, protocol = independent API to bind data to certain paths is needed. =E2=80=A6 well yes, perhaps=E2=80=A6 but maybe only advisory, without = guaranteeing success? These things take away freedom to automatize; = I=E2=80=99d expect developers of TAPS systems to add some such things = anyway if they truly want them, but *recommending* them=E2=80=A6 ? > For OOB mechanisms, there might be use of some special flags to the = send_frame and recv_frame calls that are a) protocol specific, b) cause = an error if called on a flow using the wrong protocol and c) are = recommended against using. So what OOB mechanism are you missing? I=E2=80=99m a bit confused about = this bit, you wrote =E2=80=9COOB mechanisms as discussed above=E2=80=9D = but this discussion featured us agreeing that one particular feature = isn=E2=80=99t useful. So=E2=80=A6 ? >>> This "minimal set" can be implemented one-sided with a fall-back = to >>> TCP: i.e., a sender-side TAPS system can talk to a non-TAPS TCP >>> receiver, and a receiver-side TAPS system can talk to a non-TAPS = TCP >>> sender. For systems that do not have this requirement, >>> [I-D.trammell-taps-post-sockets] describes a way to extend the >>> functionality of the minimal set such that several of its = limitations >>> are removed. >>> I am glad to see that fallback is addressed, but why exclusively to = TCP and not TCP or UDP =E2=80=93 whatever is more applicable? >>=20 >> That=E2=80=99s a tricky one. At some point, when designing this, I = thought of addressing both =E2=80=A6 and that would have made the draft = even longer and the story even more complex. This was my main motivation = for TCP-only :) >> Also, TCP does suit for many things - even UDP applications won=E2=80=99= t =E2=80=9Cbreak=E2=80=9D with TCP (actually some UDP apps such as Skype = *do* fall back to TCP), but most TCP apps would =E2=80=9Cbreak=E2=80=9D = with UDP. >=20 > For doing this, you would have to move the reliable/unreliable = decision up to the "Flow Group=E2=80=9D level=E2=80=A6 > But finally, I guess it is needed at both levels. In case = =E2=80=9Cunreliable=E2=80=9D it is set at "Flow Group=E2=80=9D level, = all messages will be unreliable, if set at message level, the single = message is sent unreliable if supported by the underlying protocol. Yes and yes! As I wrote in my answer to Theresa, that=E2=80=99s clearly = a mistake in the minset, and I=E2=80=99ll fix it - thanks for this = catch! >>> I also don=E2=80=99t see any reason why a system like post sockets = shouldn=E2=80=99t support fallback. If using something happy eyeballs to = check what protocols are available (biased by preference)m there is no = reason why supporting a fallback ha to limit functionality. >>=20 >> I disagree with the second sentence, but maybe this is a = misunderstanding, as there are multiple degrees of freedom here. >> If =E2=80=9Cfallback=E2=80=9D is only about the protocol on the wire, = not about the system on the other end, then there is no limitation: you = can define pretty much any protocol you wish atop UDP. >> However, fallback as in the minset draft requires only a one-sided = change - i.e., a minset client is able to talk to a TAPS-ignorant TCP = server. >>=20 >> post-sockets is somewhere in between: it does assume a post-socket = system on both ends (e.g., to guarantee that the receiving application = is informed about message boundaries), but most of it can probably be = implemented with existing protocols. >=20 > Oh, I never read that from the Post Socket publications. But I guess = we should discuss this with Brian how much he has Post Socket to = =E2=80=9CLegacy=E2=80=9D communication in mind. Well, that post sockets assumes a system on both ends was my = understanding after the last meeting (I think this was a side = conversation with Tommy, though, not the open TAPS session). Either way, = it=E2=80=99s implicitly clear because it just wouldn=E2=80=99t work = without a TAPS-system on both ends (or fall back badly, basically saying = =E2=80=9Cyou can=E2=80=99t get this here, all you get is a stream=E2=80=9D= - which is pretty much the same as saying =E2=80=9Csorry, only TCP = here=E2=80=9D, in which case we haven=E2=80=99t really achieved anything = in terms of being protocol-independent). I agree that this should be made clear in the post-sockets draft. >>> Sec 2.3 (Flow Group Configuration) >>>=20 >>> Does the "capacity profile=E2=80=9D only apply to a flow group or = can it also be applied on a per-message basis? >>> If this is only intended to imply the DSCP value, a message would be = a much better scope, e.g. for protocols that multiplex multiple kinds of = message within a single flow/flow group. >>=20 >> First: it=E2=80=99s not only intended to imply the DSCP value - I = tried to make things a tiny bit more abstract and uniform by inventing = this transport feature that encompasses the DSCP but also e.g. the = choice of LEDBAT or not, or controlling Nagle. >> Second: conceptually I agree that a message would be a better scope = if it was only the DSCP (but it isn=E2=80=99t - and e.g. switching to = LEDBAT clearly isn=E2=80=99t a per-message thing), but even for the DSCP = this doesn=E2=80=99t seem doable with TCP, or with SCTP, where the DSCP = is a parameter of a =E2=80=9Cpeer address=E2=80=9D, i.e. related to an = association: https://tools.ietf.org/html/rfc6458#section-8.1.12 = >>=20 >>=20 >>> Same applies to more values. Does it make sense to make them = configurable on multiple levels? >>=20 >> What do you mean? >=20 > I primarily had the reliability issue in mind, but as I am about to = publish a draft on how to compose multipath aware protocol stacks, I = fear almost all transport features can be implemented at almost all = levels=E2=80=A6=20 Thanks again for the reliability catch. I=E2=80=99m looking forward to = this other draft, I=E2=80=99m interested in what this is. As long as it = can be made to work with existing protocols it would seem in scope to = me... >> *** >> Transport Address: the combination of an IP address, transport >> protocol and the port number used by the transport protocol. >> *** >=20 > Ok - thanks for clarifying - so no name resolution and endpoint = selection in the minimal mindset? It=E2=80=99s just a set, not really a mindset :-) :-) :-) Right, no name resolution (and, with it, remote endpoint selection) = because it=E2=80=99s not strictly a mechanism of the protocols that we = have used as a basis (btw, we do this in NEAT - but it=E2=80=99s not in = the minset). As for local endpoint selection, see = https://tools.ietf.org/html/draft-gjessing-taps-minset-05#appendix-A.1.1 = = / AVAILABILITY: listen allows 1 specified local interface with all protocols, and all = local interfaces too. Only SCTP allows listening on only a specific = subset of interfaces. It was a decision to remove this filter and say =E2=80=9Cany=E2=80=9D - = we could have said =E2=80=9Cany, or 1 interface only=E2=80=9D if this is = really useful=E2=80=A6 again the logic in removing the =E2=80=9C1 = interface=E2=80=9D case was to say that this choice isn=E2=80=99t = application-specific. Cheers, Michael --Apple-Mail=_CF00C699-40D0-4B0C-9063-3E1C6A9BF97D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I=E2=80= =99m cutting some stuff (things that we just seem to agree about) away = and answering in line again:


Note these are all = informational documents, there=E2=80=99s no TAPS =E2=80=9Cpolice=E2=80=9D = - if you implement a TAPS system that goes against this rule this is = still a good way forward!  But I think having this word of caution = against such protocol-specific functions here makes = sense.

I think this is a little more = complex=E2=80=A6 If you want a TAPS system to fully replace other Socket = APIs, I assume it should also make protocol features available, that are = nor portable across protocols. I agree that these features are
a) not part of a minimal set b) no =E2=80=9Cfirst class = citizens=E2=80=9D c) recommended against using. 
The question is whether this discussion should go into this = or another draft.

But it=E2=80=99s a =E2=80=9Cminimum set=E2=80=9D, = so it really *is* okay to go beyond, as long as people are aware about = the pro=E2=80=99s and con=E2=80=99s. Anyway, maybe there=E2=80=99s an = alternative solution.
My suggestion would be: for any = functionality that we=E2=80=99re really missing and that would create a = protocol dependency, can we try to raise the abstraction level just = enough to avoid the TAPS system coming back and saying =E2=80=9Csorry, I = can=E2=80=99t=E2=80=9D ?

E.g.: = =E2=80=9CPick interfaces X and Y=E2=80=9D is something that not every = protocol can do. Since it relates to system-wide or network-related = information (isn=E2=80=99t really application-specific), minset says = this could be automatized.
However, giving information about = the app behavior like you propose in the socketintents draft can clearly = help a TAPS system make the best decision about the interface choice, = and it=E2=80=99s only advisory information - if a TAPS system just = ignores it, e.g. because MPTCP isn=E2=80=99t available, nothing bad will = happen.


I = agree that an application using TAPS should make use of automation when = possible to avoid ossification, but is excluding applications that need = protocol specific functionality much more dangerous as it requires a = non-TAPS API to be present to service = them?

I don=E2=80=99t know - maybe we should = discuss this based on concrete cases. What functionality are you = missing?
To me, if possible, the better thing to do = would be to express this functionality abstract enough so it doesn=E2=80=99= t get in the way of a TAPS system=E2=80=99s = flexibility.

I definitely see OOB mechanisms as = discussed above and path management in MPTCP and SCPT. 
The latter is a good candidate for abstract terms and = automation,

=E2=80=A6 indeed.

but there might also be use cases for which = a more concrete, protocol independent API to bind data to certain paths = is needed.

=E2=80=A6 well yes, perhaps=E2=80=A6 but maybe only = advisory, without guaranteeing success? These things take away freedom = to automatize; I=E2=80=99d expect developers of TAPS systems to add some = such things anyway if they truly want them, but *recommending* them=E2=80=A6= ?


For OOB mechanisms, there might be use of some special flags = to the send_frame and recv_frame calls that are a) protocol specific, b) = cause an error if called on a flow using the wrong protocol and c) are = recommended against = using.

So what OOB mechanism are you missing? I=E2=80=99m = a bit confused about this bit, you wrote =E2=80=9COOB mechanisms as = discussed above=E2=80=9D but this discussion featured us agreeing that = one particular feature isn=E2=80=99t useful. So=E2=80=A6 ?



   =
This "minimal set" can be implemented one-sided with a fall-back to
   TCP: i.e., a sender-side TAPS system can talk to a non-TAPS TCP
   receiver, and a receiver-side TAPS system can talk to a non-TAPS TCP
   sender.  For systems that do not have this requirement,
   [I-D.trammell-taps-post-sockets] describes a way to extend the
   functionality of the minimal set such that several of its limitations
   are removed.
I am glad to see that fallback is = addressed, but why exclusively to TCP and not TCP or UDP =E2=80=93 = whatever is more = applicable?

That=E2=80=99s a tricky one. At some = point, when designing this, I thought of addressing both =E2=80=A6 and = that would have made the draft even longer and the story even more = complex. This was my main motivation for TCP-only  :)
Also, TCP does suit for many things - even UDP applications = won=E2=80=99t =E2=80=9Cbreak=E2=80=9D with TCP (actually some UDP apps = such as Skype *do* fall back to TCP), but most TCP apps would = =E2=80=9Cbreak=E2=80=9D with UDP.

For doing this, you would have to move = the reliable/unreliable decision up to the "Flow Group=E2=80=9D = level=E2=80=A6
But finally, I guess it is needed at = both levels. In case =E2=80=9Cunreliable=E2=80=9D it is set at "Flow = Group=E2=80=9D level, all messages will be unreliable, if set at message = level, the single message is sent unreliable if supported by the = underlying protocol.

Yes and yes!  As I wrote in my answer to = Theresa, that=E2=80=99s clearly a mistake in the minset, and I=E2=80=99ll = fix it - thanks for this catch!


I also don=E2=80=99t see any = reason why a system like post sockets shouldn=E2=80=99t support = fallback. If using something happy eyeballs to check what protocols are = available (biased by preference)m there is no reason why supporting a = fallback ha to limit = functionality.

I disagree with the = second sentence, but maybe this is a misunderstanding, as there are = multiple degrees of freedom here.
If =E2=80=9Cfallbac= k=E2=80=9D is only about the protocol on the wire, not about the system = on the other end, then there is no limitation: you can define pretty = much any protocol you wish atop UDP.
However, = fallback as in the minset draft requires only a one-sided change - i.e., = a minset client is able to talk to a TAPS-ignorant TCP server.

post-sockets is = somewhere in between: it does assume a post-socket system on both ends = (e.g., to guarantee that the receiving application is informed about = message boundaries), but most of it can probably be implemented with = existing protocols.

Oh, I never read that from the Post Socket = publications. But I guess we should discuss this with Brian how much he = has Post Socket to =E2=80=9CLegacy=E2=80=9D communication in = mind.

Well, that post sockets assumes a system on both = ends was my understanding after the last meeting (I think this was a = side conversation with Tommy, though, not the open TAPS session). Either = way, it=E2=80=99s implicitly clear because it just wouldn=E2=80=99t work = without a TAPS-system on both ends (or fall back badly, basically saying = =E2=80=9Cyou can=E2=80=99t get this here, all you get is a stream=E2=80=9D= - which is pretty much the same as saying =E2=80=9Csorry, only TCP = here=E2=80=9D, in which case we haven=E2=80=99t really achieved anything = in terms of being protocol-independent).
I agree that this = should be made clear in the post-sockets draft.


Sec = 2.3 (Flow Group Configuration)

Does the "capacity profile=E2=80=9D = only apply to a flow group or can it also be applied on a per-message = basis?
If this is only intended to imply the DSCP = value, a message would be a much better scope, e.g. for protocols that = multiplex multiple kinds of message within a single flow/flow = group.

First: it=E2=80=99s not only intended = to imply the DSCP value - I tried to make things a tiny bit more = abstract and uniform by inventing this transport feature that = encompasses the DSCP but also e.g. the choice of LEDBAT or not, or = controlling Nagle.
Second: conceptually I agree = that a message would be a better scope if it was only the DSCP (but it = isn=E2=80=99t - and e.g. switching to LEDBAT clearly isn=E2=80=99t a = per-message thing), but even for the DSCP this doesn=E2=80=99t seem = doable with TCP, or with SCTP, where the DSCP is a parameter of a = =E2=80=9Cpeer address=E2=80=9D, i.e. related to an association: https://tools.ietf.org/html/rfc6458#section-8.1.12


Same = applies to more values. Does it make sense to make them configurable on = multiple levels?

What do you = mean?

I primarily had the reliability issue = in mind, but as I am about to publish a draft on how to compose = multipath aware protocol stacks, I fear almost all transport features = can be implemented at almost all = levels=E2=80=A6 

Thanks again for the reliability catch. I=E2=80=99m = looking forward to this other draft, I=E2=80=99m interested in what this = is. As long as it can be made to work with existing protocols it would = seem in scope to me...


***
  =  Transport Address:  the combination of an IP address, = transport
      protocol and the = port number used by the transport protocol.
***

Ok - thanks for clarifying - so no name resolution and = endpoint selection in the minimal = mindset?

It=E2=80=99s just a set, not really a mindset =  :-)  :-)  :-)

Right, no = name resolution (and, with it, remote endpoint selection) because it=E2=80= =99s not strictly a mechanism of the protocols that we have used as a = basis (btw, we do this in NEAT - but it=E2=80=99s not in the = minset).
As for local endpoint selection, see https://tools.ietf.org/html/draft-gjessing-taps-minset-05#appen= dix-A.1.1 / AVAILABILITY:
listen allows 1 = specified local interface with all protocols, and all local interfaces = too. Only SCTP allows listening on only a specific subset of = interfaces.
It was a decision to remove this filter and say = =E2=80=9Cany=E2=80=9D - we could have said =E2=80=9Cany, or 1 interface = only=E2=80=9D if this is really useful=E2=80=A6 again the logic in = removing the =E2=80=9C1 interface=E2=80=9D case was to say that this = choice isn=E2=80=99t application-specific.

Cheers,
Michael

= --Apple-Mail=_CF00C699-40D0-4B0C-9063-3E1C6A9BF97D-- From nobody Tue Jun 27 12:21:27 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82C212EB0B for ; Tue, 27 Jun 2017 12:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 aEifE7sutqrC for ; Tue, 27 Jun 2017 12:21:23 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653F712EB0A for ; Tue, 27 Jun 2017 12:21:23 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id 16so33806441qkg.2 for ; Tue, 27 Jun 2017 12:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=PI48JGVZ1MG0jctGeyAF08U1wGPqAZDcvAmUzcI+Pk0=; b=nUL0mQRK1X3/2Uv9TJKKB8NsWm+5HwfCiQa+YjAhlNGhvhBb1Uo1FDirW6P3PUfMfE 9py28wL+0WtfgdUt087YJ6cwgI/bfJRXGqpV+RIHXcFjFMUJW7j+GQZiAWa3o/SG0r42 MTy8t66BJUSt2QlRWV9/j3ZyOVhpeLgNXDZisyB/ZfG65ybPK8vIkYs5gtAaAHYTvezS eGFL/rb2b8U28nN7o1oAsOu0nA5/VbrPgXlkwi70C+tItyazT9LtsnmMQyxLG2nRfjBm mVQPC8FH4fv7kKeDT67RtxDDgHznyIgQ/XgK9NgwV611S4WGqZH4Qr2t3MX5KuXUlSV8 wr9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=PI48JGVZ1MG0jctGeyAF08U1wGPqAZDcvAmUzcI+Pk0=; b=GYfmAU11Shz4sAecqc614eLJYKzaFUqC59LJ0UZyIk/xgAEust3hUHuictGZUHgCOI +hd9eDlBK7npt9Sxc0+zUgBs9V/0hiSW81BoythZNNZ7b8nCzGRw51OLJOl50uuL/ORl DB2g30UVPThhdnqUVHVDn6+UsJw79d0PFUeCpFf5b99RgJwKdv8W3VcALdifYuhe7gEh 8xdXkYzLy05DjRHEynEOQFMnZjd5786Jqmv1XPiRN5qiGMXJVu/QQn5jRRF2I5Wg9jWf MUBjWMyt7RjOgPsYQ044cETNVdmQXVObezEjgaGHo8TtnT6R+E9f02r4ivdFBdgSPYI3 M5ig== X-Gm-Message-State: AKS2vOwaXK+bc2RvEealq0Ho8x9/WkrWy9yG4PfytwFXWIgzBIUy0Rf/ YJ6x/KOEh70f+ZUaUn8= X-Received: by 10.55.33.80 with SMTP id h77mr7802217qkh.86.1498591282392; Tue, 27 Jun 2017 12:21:22 -0700 (PDT) Received: from [169.254.206.58] ([72.246.0.14]) by smtp.gmail.com with ESMTPSA id y58sm57099qtc.36.2017.06.27.12.21.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jun 2017 12:21:21 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Tue, 27 Jun 2017 15:21:21 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_99724508-F190-4F88-A541-71F18BD5AB28_=" X-Mailer: MailMate (1.9.6r5356) Archived-At: Subject: [Taps] Prague agenda planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 19:21:26 -0000 --=_MailMate_99724508-F190-4F88-A541-71F18BD5AB28_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Here the short list of topics recently raised for our next meeting and = some questions/comments. Please respond and suggest any other topics. * `draft-gjessing-taps-minset-05.txt` * There=E2=80=99s been some interesting discussion on the draft. Are = there = any specific topics we should set aside time to discuss? * Socket Intents * Again, what specific topics should we discuss? * We=E2=80=99ve been told to expect 3 drafts: on general concepts, BSD= = implementation, & communication granularity. What=E2=80=99s worth discus= sing? * Michio Honda HotNets paper =E2=80=9C[PASTE: Network Stacks Must Integra= te = with NVMM = Abstractions](http://www.ht.sfc.keio.ac.jp/~micchie/papers/paste-hotnets1= 6.pdf)=E2=80=9D * *=E2=80=9CThese days I'm working on networking interface for non-vol= atile = main memory (a.k.a. persistent memory and storage-class memory), because = with such devices networking stack/API becomes a bottleneck in the = end-to-end communication that involves persistent media (disk or SSDs = for now). I saw some post-socket discussion in the minutes of the last = meeting, so I wonder if this type of work could give some useful = information to IETFers who design new transport API standards.=E2=80=9D* * Is there interest in this topic? AFAIK, there=E2=80=99s no Internet= = Draft. I will inquire whether Michio intends to submit one. --=_MailMate_99724508-F190-4F88-A541-71F18BD5AB28_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Here the short list of topics recently raised for our nex= t meeting and some questions/comments. Please respond and suggest any ot= her topics.

--=_MailMate_99724508-F190-4F88-A541-71F18BD5AB28_=-- From nobody Tue Jun 27 13:23:05 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5D712EA6A for ; Tue, 27 Jun 2017 13:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 lIjukw9ibutw for ; Tue, 27 Jun 2017 13:23:02 -0700 (PDT) Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (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 EB7F5126B71 for ; Tue, 27 Jun 2017 13:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498594981; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Twlxe8zb6zd14ASUtSkoyiZovN3lu655sM1ahdo9MRc=; b=nBEbRi3vQnJzL9/F8zzv2MvdbLh8UF5lWRoFXLVFWvjk6+KC506Kj2j+dDYZyTD6 5LQv3muclbhSSmuITeXS3+LQRlwEDm2dtSXF9krIyk+QXTyzY8LjSlwF1ktXmAHy c6SlMwgo7p0zec5TR1qmM9dxCAfz2uE+16DD4wmCSJ+urcrTnTNGL3R+Gsjt0CG3 EzF9CFzO/hhpsdSoNMBuQ8h0WU3AR5uhqisGDaClFs6dAY06JxLD8T4zNB10mKv2 R0SZuZ/5GSXs3xuDGi+fAZBM/SLVNPMFY6EmOStfifCetCHj+X8QxG0keYH8frRv sj467X1k7x2BWTOWnOMBVQ==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id 70.8B.05889.4AEB2595; Tue, 27 Jun 2017 13:23:01 -0700 (PDT) X-AuditID: 11ab0216-007859c000001701-46-5952bea40316 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay6.apple.com (Apple SCV relay) with SMTP id 32.A1.05199.4AEB2595; Tue, 27 Jun 2017 13:23:00 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_0Dyg87IbbUHpTXWDqGP/rA)" Received: from [17.234.109.187] (unknown [17.234.109.187]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OS800DGF3ACI6A0@nwk-mmpp-sz10.apple.com>; Tue, 27 Jun 2017 13:23:00 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Tue, 27 Jun 2017 13:22:59 -0700 In-reply-to: Cc: taps WG , Chris Wood To: Aaron Falk References: X-Mailer: Apple Mail (2.3435) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUi2FAYpbt0X1Ckwb/P/BZtv6exWtyJcWDy 2DnrLrvHkiU/mQKYorhsUlJzMstSi/TtErgyPp2/z1qwXKdi9oNm5gbGVrUuRk4OCQETiek7 j7N3MXJxCAmsYZLY3H2KCSbxdMY9FojEIUaJdxd+giV4BQQlfkwGSXByMAuESZy4MYsRomgy k8T57fOBHA4OYQEJic17EkFq2ARUJI5/28AM0WsjseD8ZnYQW1hAS+LZqYdsIDaLgKrEzo/H wWZyCthKbLm0jR1ivpXEgUl7WUFsEaCaZS/aweqFgOZ8ff0J6lBZiS1tEB9ICOxgk1hy6RP7 BEahWUhunYXk1llA5zELqEtMmZILEdaWePLuAiuErSax8PciJmTxBYxsqxiFcxMzc3Qz84yM 9BILCnJS9ZLzczcxgiJhNZPYDsZ7rw0PMQpwMCrx8GpEBkUKsSaWFVfmHmKU5mBREuddNCcw UkggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMjw+U/CT8Cejl0DSKMhM5MfZ337dmRlf8Nwmwl IybZiDCv3JWUuuMin4/Axu6oA8obzSreahWftUiQTTy1ZdrD0/7NeW+MpigvldNbd2mKV8hP e/1AbqkpC8+s45d6tunskf/9kjWrrblTCu0kz/LxOgqLhZ8/WP5BRGtj5fSaWf8fmqoc0Fug xFKckWioxVxUnAgAneglJmUCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUi2FBcpbtkX1Ckwf9/5hZtv6exWtyJcWDy 2DnrLrvHkiU/mQKYorhsUlJzMstSi/TtErgyPp2/z1qwXKdi9oNm5gbGVrUuRk4OCQETiacz 7rF0MXJxCAkcYpR4d+EnE0iCV0BQ4sdkkAQnB7NAmMSJG7MYIYomM0mc3z4fyOHgEBaQkNi8 JxGkhk1AReL4tw3MEL02EgvOb2YHsYUFtCSenXrIBmKzCKhK7Px4HGwmp4CtxJZL29gh5ltJ HJi0lxXEFgGqWfaiHaxeCGjO19efmCAOlZXY0nacfQIj/ywk581Cct4soIuYBdQlpkzJhQhr Szx5d4EVwlaTWPh7EROy+AJGtlWMAkWpOYmVZnqJBQU5qXrJ+bmbGMFhWxi1g7FhudUhRgEO RiUeXo3IoEgh1sSy4spcYBhxMCuJ8LJsBgrxpiRWVqUW5ccXleakFh9inMgI9OREZinR5Hxg VOWVxBuamBiYGBubGRubm5jTUlhJnFemB+gigfTEktTs1NSC1CKYo5g4OKUaGAOsl/Rk1FVO 3x1je/VohG8iL1dr6k9VxTkO4bPiP87SWdqv5v/oj+3yP8m6E2MPV9394C6oGzC/YUJ9xpx7 BQVLP+RdWuU9WffBdSUr+ZMtFtZrFvrX8L60DVs6x83sivy1mi2rJnz5VHtR1nI+4zrxhs7K Y1tc/P56mhZl6scKx178KLKwRomlOCPRUIu5qDgRAKeA2LbOAgAA Archived-At: Subject: Re: [Taps] Prague agenda planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 20:23:04 -0000 --Boundary_(ID_0Dyg87IbbUHpTXWDqGP/rA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Aaron, We have a draft we=E2=80=99ll be publishing in the next week that does a = survey of Transport Security protocols, and the interfaces they expose = to the transport layer as well as applications. We=E2=80=99d like to = have a slot to discuss this topic with the WG. Thanks, Tommy > On Jun 27, 2017, at 12:21 PM, Aaron Falk wrote: >=20 > Here the short list of topics recently raised for our next meeting and = some questions/comments. Please respond and suggest any other topics. >=20 > draft-gjessing-taps-minset-05.txt >=20 > There=E2=80=99s been some interesting discussion on the draft. Are = there any specific topics we should set aside time to discuss? > Socket Intents >=20 > Again, what specific topics should we discuss? > We=E2=80=99ve been told to expect 3 drafts: on general concepts, BSD = implementation, & communication granularity. What=E2=80=99s worth = discussing? > Michio Honda HotNets paper =E2=80=9CPASTE: Network Stacks Must = Integrate with NVMM Abstractions = =E2=80= =9D >=20 > =E2=80=9CThese days I'm working on networking interface for = non-volatile main memory (a.k.a. persistent memory and storage-class = memory), because with such devices networking stack/API becomes a = bottleneck in the end-to-end communication that involves persistent = media (disk or SSDs for now). I saw some post-socket discussion in the = minutes of the last meeting, so I wonder if this type of work could give = some useful information to IETFers who design new transport API = standards.=E2=80=9D > Is there interest in this topic? AFAIK, there=E2=80=99s no Internet = Draft. I will inquire whether Michio intends to submit one. > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_0Dyg87IbbUHpTXWDqGP/rA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi = Aaron,

We have a = draft we=E2=80=99ll be publishing in the next week that does a survey of = Transport Security protocols, and the interfaces they expose to the = transport layer as well as applications. We=E2=80=99d like to have a = slot to discuss this topic with the WG.

Thanks,
Tommy

On Jun 27, 2017, at 12:21 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

Here = the short list of topics recently raised for our next meeting and some = questions/comments. Please respond and suggest any other topics.

  • draft-gjessing-taps-minset-05.txt

    • There=E2=80=99s been some interesting discussion on the = draft. Are there any specific topics we should set aside time to = discuss?

  • Socket Intents

    • Again, what specific topics should we discuss?
    • We=E2=80=99ve been told to expect 3 drafts: on general = concepts, BSD implementation, & communication granularity. What=E2=80= =99s worth discussing?

  • Michio Honda HotNets paper = =E2=80=9CPASTE: Network Stacks Must = Integrate with NVMM Abstractions=E2=80=9D

    • =E2=80=9CThese days I'm working on = networking interface for non-volatile main memory (a.k.a. persistent = memory and storage-class memory), because with such devices networking = stack/API becomes a bottleneck in the end-to-end communication that = involves persistent media (disk or SSDs for now). I saw some = post-socket discussion in the minutes of the last meeting, so I wonder = if this type of work could give some useful information to IETFers who = design new transport API standards.=E2=80=9D
    • Is there interest in this topic? AFAIK, there=E2=80=99s = no Internet Draft. I will inquire whether Michio intends to submit = one.
_______________________________________________
Taps = mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Boundary_(ID_0Dyg87IbbUHpTXWDqGP/rA)-- From nobody Tue Jun 27 13:44:17 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2B312EAE9 for ; Tue, 27 Jun 2017 13:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pFFGeOKQw5Jo for ; Tue, 27 Jun 2017 13:44:12 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B140D12EB21 for ; Tue, 27 Jun 2017 13:44:12 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id r30so34821698qtc.0 for ; Tue, 27 Jun 2017 13:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:embedded-html; bh=ccI1GnB21NRx4IoDlHVkiF9b7GEPX9H3LZ2Kb9cuUIA=; b=ln1AmN0JFqTy9+u7oAk21rWtW4RBau26PYI3ba1DzgYVGMHejZh/+m7oT4uaZeglVZ IYPUgQXSgNxSLgpNOsSnqwpVNyPkGRZ84DjvBeiVtcg7PeAQeMHG3MjRsR95XAxUV7S8 DHRNuiAv6QuUMPs6t6dF4k8xkpSjr3lblaNSPHone5u972pFpy43jaS4rj/qikc47I5e rqFM8wxLVKzTVQJFgQfOEHUKVHm3SeUvVB2vYAtNpkb7mf3UKyWPxlPs1GZHg7og7g4V SWYW3Tb/nkE49XhUEHy63UBbkxE0mrPt8WyawOb6Ao4pt03o9mqe92oz/JclxZW9ayTr HKjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding:embedded-html; bh=ccI1GnB21NRx4IoDlHVkiF9b7GEPX9H3LZ2Kb9cuUIA=; b=XzsDvKMpeMFdraTlRnNriszh2FPcof7jNATewTa2BDKofztw21vIy4PPVIiMpI+aq6 aRhfaz5V39fWTLWwv0NCF7Z4YPFU4fwe7yjRmZgSmgDOcsxeOMvTBPBmk9ylNpzxl8Ei LcqFJCecv0w7fvKPGrh/CnXmvUH3iGzXzbEoXkzmTcboIzjy/y1iGb3C92+/nfMiIh3W Mfbenbemc1D4dE5BJVP4iqpye4n6kibct6cnu80IkkJ4swZs1YHX+Xkv2DdtrvgDtq0O IVqj0zz4uaquwHyyKS+zOyM2rgEA59Y6Cq2qkKyKDISBn6E/25Fg6VbirflHzsMuvbga ng0g== X-Gm-Message-State: AKS2vOwpNVku3leZRXJXlnRHuaznLEWAPy+eQPE3y8BkXVfZT0+cU+CN 26QuxOI1ZCP8dg== X-Received: by 10.200.44.74 with SMTP id e10mr9740117qta.123.1498596251892; Tue, 27 Jun 2017 13:44:11 -0700 (PDT) Received: from [169.254.240.205] ([72.246.0.14]) by smtp.gmail.com with ESMTPSA id 34sm232359qtp.17.2017.06.27.13.44.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jun 2017 13:44:11 -0700 (PDT) From: "Aaron Falk" To: "Tommy Pauly" Cc: "taps WG" , "Chris Wood" Date: Tue, 27 Jun 2017 16:44:10 -0400 Message-ID: <3DEF9AEB-C09D-4A37-BC23-231C6313ACC1@gmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_CE253FCA-ADE7-4EA1-9186-1F90F9ECCD9A_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[481, 3061], "plain":[102, 1794], "uuid":"16A07167-748B-494D-BC1F-1B66C257F47A"}] X-Mailer: MailMate (1.9.6r5356) Archived-At: Subject: Re: [Taps] Prague agenda planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 20:44:15 -0000 --=_MailMate_CE253FCA-ADE7-4EA1-9186-1F90F9ECCD9A_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cool. Are you proposing this as a wg item? --aaron On 27 Jun 2017, at 16:22, Tommy Pauly wrote: > Hi Aaron, > > We have a draft we’ll be publishing in the next week that does a > survey of Transport Security protocols, and the interfaces they expose > to the transport layer as well as applications. We’d like to have a > slot to discuss this topic with the WG. > > Thanks, > Tommy > >> On Jun 27, 2017, at 12:21 PM, Aaron Falk >> wrote: >> >> Here the short list of topics recently raised for our next meeting >> and some questions/comments. Please respond and suggest any other >> topics. >> >> draft-gjessing-taps-minset-05.txt >> >> There’s been some interesting discussion on the draft. Are there >> any specific topics we should set aside time to discuss? >> Socket Intents >> >> Again, what specific topics should we discuss? >> We’ve been told to expect 3 drafts: on general concepts, BSD >> implementation, & communication granularity. What’s worth >> discussing? >> Michio Honda HotNets paper “PASTE: Network Stacks Must Integrate >> with NVMM Abstractions >> ” >> >> “These days I'm working on networking interface for non-volatile >> main memory (a.k.a. persistent memory and storage-class memory), >> because with such devices networking stack/API becomes a bottleneck >> in the end-to-end communication that involves persistent media (disk >> or SSDs for now). I saw some post-socket discussion in the minutes of >> the last meeting, so I wonder if this type of work could give some >> useful information to IETFers who design new transport API >> standards.” >> Is there interest in this topic? AFAIK, there’s no Internet Draft. >> I will inquire whether Michio intends to submit one. >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps --=_MailMate_CE253FCA-ADE7-4EA1-9186-1F90F9ECCD9A_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Cool. Are you proposing this as a wg item?

--aaron

On 27 Jun 2017, at 16:22, Tommy Pauly wrote:

Hi Aaron,

We have a draft we=E2=80=99ll be publishing in the ne= xt week that does a survey of Transport Security protocols, and the inter= faces they expose to the transport layer as well as applications. We=E2=80= =99d like to have a slot to discuss this topic with the WG.

Thanks,
Tommy

On Jun 27, 2017, at 12:21 PM, Aaron Falk <aaron.falk@gmail.com> wro= te:

Here the short list of to= pics recently raised for our next meeting and some questions/comments. P= lease respond and suggest any other topics.

  • draft-gjessing-taps-minset-05.txt

    • There=E2=80=99s been some interesting discussion on the dr= aft. Are there any specific topics we should set aside time to discuss?<= /li>

  • Socket Intents

    • Again, what specific topics should we discuss?
    • We=E2=80=99ve been told to expect 3 drafts: on general con= cepts, BSD implementation, & communication granularity. What=E2=80=99= s worth discussing?

  • Michio Honda HotNets paper =E2=80= =9CPASTE: Network Stacks Must In= tegrate with NVMM Abstractions=E2=80=9D

    • =E2=80=9CThese days I'm working on networki= ng interface for non-volatile main memory (a.k.a. persistent memory and s= torage-class memory), because with such devices networking stack/API beco= mes a bottleneck in the end-to-end communication that involves persistent= media (disk or SSDs for now). I saw some post-socket discussion in the = minutes of the last meeting, so I wonder if this type of work could give = some useful information to IETFers who design new transport API standards= =2E=E2=80=9D
    • Is there interest in this topic? AFAIK, there=E2=80=99s n= o Internet Draft. I will inquire whether Michio intends to submit one.
_______________________________________________
Taps mailin= g list
Taps@iet= f.org
https://www.ietf.org/mailman/listinfo/taps

--=_MailMate_CE253FCA-ADE7-4EA1-9186-1F90F9ECCD9A_=-- From nobody Tue Jun 27 14:34:04 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAC112706D for ; Tue, 27 Jun 2017 14:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 TSLXNhQgGvnH for ; Tue, 27 Jun 2017 14:34:00 -0700 (PDT) Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (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 5EC7112EB38 for ; Tue, 27 Jun 2017 14:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498599239; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zZxr8XKqKCBVPc0SxXLycuqvg2C9W7xxmVW3C7CEbXk=; b=rrEX1tUA2EputjqDdczK2o9ArGMBOZiT7K1CLzcODXA/BTjL2UZOi+svA6sxmVLH pf9zWOugyo8oF2mPABWWjH0GFhFBhPF9ZQjmU8+eowp6mRXMHarn4LP4ky5ylK6+ umAmojfab0jJ5WmGochy97t6w/eM5pcpIzCypxrC1/R+nZpnKi+546J+qYzAtF7Y tNE9ympkfI5+91VA+Ppu3zS+Qa74ocAHY7FXvjnalkYkTWAZ6dpGdt/z2LbqTH8Y vFy3mDWfwoOvrZkb2c0pNF2UCRTTLeTFcRVdH8cICa3LFFz3ne1/j/mCCOQpjneV AvM8ybNzTJuo5snoLjWrLQ==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id C8.F0.05889.74FC2595; Tue, 27 Jun 2017 14:33:59 -0700 (PDT) X-AuditID: 11ab0216-007859c000001701-9e-5952cf478e05 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay5.apple.com (Apple SCV relay) with SMTP id 6E.67.09344.74FC2595; Tue, 27 Jun 2017 14:33:59 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_h/+mBoUKwCjExOz0ZwQ5bQ)" Received: from [17.234.62.40] (unknown [17.234.62.40]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OS800EKY6KMAH10@nwk-mmpp-sz12.apple.com>; Tue, 27 Jun 2017 14:33:59 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Tue, 27 Jun 2017 14:33:58 -0700 In-reply-to: <3DEF9AEB-C09D-4A37-BC23-231C6313ACC1@gmail.com> Cc: Chris Wood , taps WG To: Aaron Falk References: <3DEF9AEB-C09D-4A37-BC23-231C6313ACC1@gmail.com> X-Mailer: Apple Mail (2.3435) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUi2FAYoet+PijS4N5hDYu239NYLe7EODB5 7Jx1l91jyZKfTAFMUVw2Kak5mWWpRfp2CVwZrzY9ZC3Y5VDR/VWwgfGMeRcjJ4eEgInEhKd3 WLoYuTiEBNYwSbw5v5kNJrHs0G2oxCFGifkLe5lAErwCghI/Jt8DSnBwMAuESVxalQxR088k 0fN1IjNIXFhAQmLznkSQcjYBFYnj3zaAhXkFbCTWz8sGCQsLaEk8O/UQbBWLgKrE3Ucb2EFs TgFbiUtbD7BDTLeS+LxEByQsAlSy7EU7WLmQwCJGiUnH7CGulJXY0nacHeQCCYEdbBKf+2Yz T2AUmoXk0FkIh0KY6hJTpuSCVDALaEs8eXeBFcJWk1j4exETsvgCRrZVjMK5iZk5upl5RkZ6 iQUFOal6yfm5mxhB4b+aSWwH473XhocYBTgYlXh4NSKDIoVYE8uKK3MPMUpzsCiJ8y6aExgp JJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVHH5sJfyzgtC2PHszO3bf2gJmTWlt/mumDBnTni NdsibQ9xHRf/dvKL5aFFkj6ZfD6Fy2p2mQmvfOY+LfHYNAE1i60Xm6snX9xazjJbTMXr+RqT /VEbL59nm2f9eXVQdtXerM73fi0vpA1Srh0ymnlt35wtB1tz1c73rGje07Dqye/3CoJpBSeU WIozEg21mIuKEwHqg9e4YAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUi2FB8Rtf9fFCkwfSL/BZtv6exWtyJcWDy 2DnrLrvHkiU/mQKYorhsUlJzMstSi/TtErgyXm16yFqwy6Gi+6tgA+MZ8y5GTg4JAROJZYdu s3QxcnEICRxilJi/sJcJJMErICjxY/I9oAQHB7NAmMSlVckQNf1MEj1fJzKDxIUFJCQ270kE KWcTUJE4/m0DWJhXwEZi/bxskLCwgJbEs1MP2UBsFgFVibuPNrCD2JwCthKXth5gh5huJfF5 iQ5IWASoZNmLdrByIYFFjBKTjtlDXCkrsaXtOPsERv5ZSG6bhXAbhKkuMWVKLkgFs4C2xJN3 F1ghbDWJhb8XMSGLL2BkW8UoUJSak1hpqpdYUJCTqpecn7uJERyshRE7GP8vszrEKMDBqMTD qxEZFCnEmlhWXJkLDB8OZiURXpbNQCHelMTKqtSi/Pii0pzU4kOMExmBXpzILCWanA+MpbyS eEMTEwMTY2MzY2NzE3NaCiuJ80r3AF0kkJ5YkpqdmlqQWgRzFBMHp1QD46R7P4oZ7V7dOiXr mXcvJ5lv9VPZObdXGLwU3KrBucCLf3P9nMJ7rMVVwTK32pdOCptR8mBF1kLNldde9m9hmrMj +WrlFxEJWw2tS1XP1Vc8NLHU/V5+XmbeBr1l+wKT2Su/Sv5i/e1uIZxYz2Gwz2zPYb37L/xO JWnJ/l759qnZjlubD+vNO6rEUpyRaKjFXFScCAACP00JyQIAAA== Archived-At: Subject: Re: [Taps] Prague agenda planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 21:34:03 -0000 --Boundary_(ID_h/+mBoUKwCjExOz0ZwQ5bQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Yes, we=E2=80=99d like to add this as a WG item once published. This is = based on the conversation had at the meeting in Chicago about wanting a = draft to include Security protocols for TAPS API considerations. Thanks, Tommy > On Jun 27, 2017, at 1:44 PM, Aaron Falk wrote: >=20 > Cool. Are you proposing this as a wg item? >=20 > --aaron >=20 > On 27 Jun 2017, at 16:22, Tommy Pauly wrote: >=20 > Hi Aaron, >=20 > We have a draft we=E2=80=99ll be publishing in the next week that does = a survey of Transport Security protocols, and the interfaces they expose = to the transport layer as well as applications. We=E2=80=99d like to = have a slot to discuss this topic with the WG. >=20 > Thanks, > Tommy >=20 >> On Jun 27, 2017, at 12:21 PM, Aaron Falk > wrote: >>=20 >> Here the short list of topics recently raised for our next meeting = and some questions/comments. Please respond and suggest any other = topics. >>=20 >> draft-gjessing-taps-minset-05.txt >>=20 >> There=E2=80=99s been some interesting discussion on the draft. Are = there any specific topics we should set aside time to discuss? >> Socket Intents >>=20 >> Again, what specific topics should we discuss? >> We=E2=80=99ve been told to expect 3 drafts: on general concepts, BSD = implementation, & communication granularity. What=E2=80=99s worth = discussing? >> Michio Honda HotNets paper =E2=80=9CPASTE: Network Stacks Must = Integrate with NVMM Abstractions = =E2=80= =9D >>=20 >> =E2=80=9CThese days I'm working on networking interface for = non-volatile main memory (a.k.a. persistent memory and storage-class = memory), because with such devices networking stack/API becomes a = bottleneck in the end-to-end communication that involves persistent = media (disk or SSDs for now). I saw some post-socket discussion in the = minutes of the last meeting, so I wonder if this type of work could give = some useful information to IETFers who design new transport API = standards.=E2=80=9D >> Is there interest in this topic? AFAIK, there=E2=80=99s no Internet = Draft. I will inquire whether Michio intends to submit one. >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_h/+mBoUKwCjExOz0ZwQ5bQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Yes, = we=E2=80=99d like to add this as a WG item once published. This is based = on the conversation had at the meeting in Chicago about wanting a draft = to include Security protocols for TAPS API considerations.

Thanks,
Tommy

On Jun 27, 2017, at 1:44 PM, = Aaron Falk <aaron.falk@gmail.com> wrote:

Cool. = Are you proposing this as a wg item?

--aaron

On 27 Jun 2017, at = 16:22, Tommy Pauly wrote:

Hi Aaron,

We have a draft we=E2=80=99ll be = publishing in the next week that does a survey of Transport Security = protocols, and the interfaces they expose to the transport layer as well = as applications. We=E2=80=99d like to have a slot to discuss this topic = with the WG.

Thanks,
Tommy

On Jun 27, 2017, at 12:21 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

Here = the short list of topics recently raised for our next meeting and some = questions/comments. Please respond and suggest any other topics.

  • draft-gjessing-taps-minset-05.txt

    • There=E2=80=99s been some interesting discussion on the = draft. Are there any specific topics we should set aside time to = discuss?

  • Socket Intents

    • Again, what specific topics should we discuss?
    • We=E2=80=99ve been told to expect 3 drafts: on general = concepts, BSD implementation, & communication granularity. What=E2=80= =99s worth discussing?

  • Michio Honda HotNets paper = =E2=80=9CPASTE: Network Stacks Must = Integrate with NVMM Abstractions=E2=80=9D

    • =E2=80=9CThese days I'm working on = networking interface for non-volatile main memory (a.k.a. persistent = memory and storage-class memory), because with such devices networking = stack/API becomes a bottleneck in the end-to-end communication that = involves persistent media (disk or SSDs for now). I saw some = post-socket discussion in the minutes of the last meeting, so I wonder = if this type of work could give some useful information to IETFers who = design new transport API standards.=E2=80=9D
    • Is there interest in this topic? AFAIK, there=E2=80=99s = no Internet Draft. I will inquire whether Michio intends to submit = one.
_______________________________________________
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

= --Boundary_(ID_h/+mBoUKwCjExOz0ZwQ5bQ)-- From nobody Tue Jun 27 14:55:56 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC341200CF for ; Tue, 27 Jun 2017 14:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 7CQKhMeBYGXM for ; Tue, 27 Jun 2017 14:55:52 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 DEFB81200C5 for ; Tue, 27 Jun 2017 14:55:51 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dPySb-0003Xd-RK; Tue, 27 Jun 2017 23:55:49 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx03.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dPySa-0002Vt-OK; Tue, 27 Jun 2017 23:55:49 +0200 From: Michael Welzl Message-Id: <7CEA46A4-62DC-48FA-BD60-13DEDFD80BB3@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_E016E160-81EC-4246-810D-327BF6BADBE6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 27 Jun 2017 23:55:50 +0200 In-Reply-To: Cc: Aaron Falk , Chris Wood , "taps@ietf.org" To: Tommy Pauly References: <3DEF9AEB-C09D-4A37-BC23-231C6313ACC1@gmail.com> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 8 sum msgs/h 3 total rcpts 55983 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.048, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 45FDECE2079693E97566DEA14BEA4D189AC56998 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1650 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] Prague agenda planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 21:55:56 -0000 --Apple-Mail=_E016E160-81EC-4246-810D-327BF6BADBE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 =E2=80=A6 and the latest version of the minset draft excludes security = from the final minset, mentioning that this will be addressed in a = separate draft (which should be this one). Cheers, Michael > On Jun 27, 2017, at 11:33 PM, Tommy Pauly wrote: >=20 > Yes, we=E2=80=99d like to add this as a WG item once published. This = is based on the conversation had at the meeting in Chicago about wanting = a draft to include Security protocols for TAPS API considerations. >=20 > Thanks, > Tommy >=20 >> On Jun 27, 2017, at 1:44 PM, Aaron Falk > wrote: >>=20 >> Cool. Are you proposing this as a wg item? >>=20 >> --aaron >>=20 >> On 27 Jun 2017, at 16:22, Tommy Pauly wrote: >>=20 >> Hi Aaron, >>=20 >> We have a draft we=E2=80=99ll be publishing in the next week that = does a survey of Transport Security protocols, and the interfaces they = expose to the transport layer as well as applications. We=E2=80=99d like = to have a slot to discuss this topic with the WG. >>=20 >> Thanks, >> Tommy >>=20 >>> On Jun 27, 2017, at 12:21 PM, Aaron Falk > wrote: >>>=20 >>> Here the short list of topics recently raised for our next meeting = and some questions/comments. Please respond and suggest any other = topics. >>>=20 >>> draft-gjessing-taps-minset-05.txt >>>=20 >>> There=E2=80=99s been some interesting discussion on the draft. Are = there any specific topics we should set aside time to discuss? >>> Socket Intents >>>=20 >>> Again, what specific topics should we discuss? >>> We=E2=80=99ve been told to expect 3 drafts: on general concepts, BSD = implementation, & communication granularity. What=E2=80=99s worth = discussing? >>> Michio Honda HotNets paper =E2=80=9CPASTE: Network Stacks Must = Integrate with NVMM Abstractions = =E2=80= =9D >>>=20 >>> =E2=80=9CThese days I'm working on networking interface for = non-volatile main memory (a.k.a. persistent memory and storage-class = memory), because with such devices networking stack/API becomes a = bottleneck in the end-to-end communication that involves persistent = media (disk or SSDs for now). I saw some post-socket discussion in the = minutes of the last meeting, so I wonder if this type of work could give = some useful information to IETFers who design new transport API = standards.=E2=80=9D >>> Is there interest in this topic? AFAIK, there=E2=80=99s no Internet = Draft. I will inquire whether Michio intends to submit one. >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps = >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_E016E160-81EC-4246-810D-327BF6BADBE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 =E2=80=A6 and the latest version of the minset draft excludes = security from the final minset, mentioning that this will be addressed = in a separate draft (which should be this one).

Cheers,
Michael


On Jun 27, 2017, at 11:33 PM, Tommy Pauly <tpauly@apple.com> = wrote:

Yes, we=E2=80=99d like = to add this as a WG item once published. This is based on the = conversation had at the meeting in Chicago about wanting a draft to = include Security protocols for TAPS API considerations.
Thanks,
Tommy

On Jun 27, 2017, at 1:44 PM, Aaron Falk = <aaron.falk@gmail.com> wrote:

Cool. = Are you proposing this as a wg item?

--aaron

On 27 Jun 2017, at = 16:22, Tommy Pauly wrote:

Hi Aaron,

We have a draft we=E2=80=99ll be = publishing in the next week that does a survey of Transport Security = protocols, and the interfaces they expose to the transport layer as well = as applications. We=E2=80=99d like to have a slot to discuss this topic = with the WG.

Thanks,
Tommy

On Jun 27, 2017, at 12:21 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

Here = the short list of topics recently raised for our next meeting and some = questions/comments. Please respond and suggest any other topics.

  • draft-gjessing-taps-minset-05.txt

    • There=E2=80=99s been some interesting discussion on the = draft. Are there any specific topics we should set aside time to = discuss?

  • Socket Intents

    • Again, what specific topics should we discuss?
    • We=E2=80=99ve been told to expect 3 drafts: on general = concepts, BSD implementation, & communication granularity. What=E2=80= =99s worth discussing?

  • Michio Honda HotNets paper = =E2=80=9CPASTE: Network Stacks Must = Integrate with NVMM Abstractions=E2=80=9D

    • =E2=80=9CThese days I'm working on = networking interface for non-volatile main memory (a.k.a. persistent = memory and storage-class memory), because with such devices networking = stack/API becomes a bottleneck in the end-to-end communication that = involves persistent media (disk or SSDs for now). I saw some = post-socket discussion in the minutes of the last meeting, so I wonder = if this type of work could give some useful information to IETFers who = design new transport API standards.=E2=80=9D
    • Is there interest in this topic? AFAIK, there=E2=80=99s = no Internet Draft. I will inquire whether Michio intends to submit = one.
_______________________________________________
Taps = mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

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

= --Apple-Mail=_E016E160-81EC-4246-810D-327BF6BADBE6-- From nobody Wed Jun 28 02:42:07 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3966812942F for ; Wed, 28 Jun 2017 02:42:05 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 C76rRR6SOfzt for ; Wed, 28 Jun 2017 02:42:03 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.242]) by ietfa.amsl.com (Postfix) with ESMTP id D939C129468 for ; Wed, 28 Jun 2017 02:42:02 -0700 (PDT) Received: from [IPv6:2001:638:809:ff1f::8295:dc3a] (unknown [IPv6:2001:638:809:ff1f::8295:dc3a]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id B95364F for ; Wed, 28 Jun 2017 11:42:01 +0200 (CEST) From: "Philipp S. Tiesel" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: References: <149858819190.31089.15287933072764133714.idtracker@ietfa.amsl.com> To: taps WG Date: Wed, 28 Jun 2017 11:42:01 +0200 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Taps] Fwd: New Version Notification for draft-tiesel-taps-communitgrany-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 09:42:05 -0000 Hi, as promised, here is our second draft towards automatic selection of = transport option. It is primarily focusing on endpoint- and path selection and still lacks = details about Transport Protocol Stack Instance Selection. Thanks to Mirja for early feedback preventing unnecessary terminology = issues. Nevertheless, I expect some discussion about terminology. I welcome feedback and suggestions where more detail/discussion is = needed.=20 > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-tiesel-taps-communitgrany-00.txt > Date: 27. June 2017 at 20:29:51 GMT+2 > To: "Philipp Tiesel" , "Theresa Enghardt" = , "Philipp S. Tiesel" = >=20 >=20 > A new version of I-D, draft-tiesel-taps-communitgrany-00.txt > has been successfully submitted by Philipp S. Tiesel and posted to the > IETF repository. >=20 > Name: draft-tiesel-taps-communitgrany > Revision: 00 > Title: Communication Units Granularity Considerations = for Multi-Path Aware Transport Selection > Document date: 2017-06-27 > Group: Individual Submission > Pages: 10 > URL: = https://www.ietf.org/internet-drafts/draft-tiesel-taps-communitgrany-00.tx= t > Status: = https://datatracker.ietf.org/doc/draft-tiesel-taps-communitgrany/ > Htmlized: = https://tools.ietf.org/html/draft-tiesel-taps-communitgrany-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-tiesel-taps-communitgrany-00 >=20 >=20 > Abstract: > This document provides an abstract framework to reason about the > composition of multi-path aware systems in a protocol-independent > fashion. It discusses basic mechanisms that are used in multi-path > systems and their applicability to different granularities of > communication units. This document is targeted as consideration > basis for automation of destination, path and transport protocol > selection within the transport layer. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 AVE! Philipp S. Tiesel --=20 Technische Universit=C3=A4t Berlin =E2=80=93 FG Internet Network = Architectures (INET) office: MAR 4.024 / Sekr.: MAR 4.4, Marchstr. 23, 10587 Berlin e-mail: philipp@inet.tu-berlin.de =E2=80=A2 phone: +49-30-314-75763 From nobody Thu Jun 29 08:36:18 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBC513146F for ; Thu, 29 Jun 2017 08:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EjTwsbCjs8vk for ; Thu, 29 Jun 2017 08:36:13 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4EF212EC06 for ; Thu, 29 Jun 2017 08:36:13 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id p21so79423625qke.3 for ; Thu, 29 Jun 2017 08:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=dMmHfsfzBg9/oOjuTT5WXE5Ef8Qnr3DlQANsiLKL4Ac=; b=faVPbIAszaW79xe9KDi5rRvyqcukjR/55BwBMXwj4EqhcRj8aWVNF8kM5dMVuOIiWA SzFGpVTeegBkyNtBBL69WvIafkc1Etawn8Wp3NjqLRou2X/BEe8RpAhZZke5JYu1/aBj pr9EfjHbj+v1Bt+uCn8rdozjh59CMvV40EbmaMBW3SV7Xuu6SP3GaJ9sa/DMDyh2JL1P ESVPSHlJ4fhAGTV+t47T3NfgOK+1Uc1Yh9JI38lef3K+shlPP6GMcoT6uOyyixdcCXAi L+ttLqzrRNScYWLbzjFBQSbzKf9xq/WcG1CSbr2Q8q9DgGZg07FQIKjXaHcvbYVJXDZQ 4xGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=dMmHfsfzBg9/oOjuTT5WXE5Ef8Qnr3DlQANsiLKL4Ac=; b=n1fG9XaF5U0PRDSYYdGSy/Z18uJ9pUGNB939K9NWLo6HeP7oLLu3Sf6QK5x1NLoO9a nVdmrjSXzT6BnvZ9Y7Ma3HK4OFR9irFcy4qyHJxDpBesWRJzP3Ddx1+TCnN1YyZB0mn0 yLlZ0xxcgWMPrMs1jvoQwSh68MBsySlc5ukpogofmRRsIES+9IL24OUEmOt0x08paGsu yaagW9QhIFC9egiCwhssmoJsWzGCEaL7SkHgvoQ85Pw3nW9hVH+s2CoqmoF30///nsdV 36nkkB+VLxs3Ga7W+HVzhS1F8X8J4mKR1c0og+4nd+haZdKAXO7ux0WcLqlsOked0pxk UNew== X-Gm-Message-State: AKS2vOw51UwHuz8PTVZvwInr5NJ45n/LdsK9yM2f80NGyuVkNpb67Qnt qlNjiRH27H2EEHKRhqgoKw== X-Received: by 10.55.37.205 with SMTP id l74mr18969527qkl.157.1498750572539; Thu, 29 Jun 2017 08:36:12 -0700 (PDT) Received: from [172.19.35.224] ([72.246.0.14]) by smtp.gmail.com with ESMTPSA id e84sm2411855qkb.56.2017.06.29.08.36.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 08:36:11 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Thu, 29 Jun 2017 11:36:11 -0400 Message-ID: <3A3686B5-FF60-448E-9E13-4B493B472C6D@gmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_1BBBB4F1-5911-474A-8215-27644524CAA7_=" X-Mailer: MailMate (1.9.6r5356) Archived-At: Subject: Re: [Taps] Prague agenda planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 15:36:17 -0000 --=_MailMate_1BBBB4F1-5911-474A-8215-27644524CAA7_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Updating. Our agenda time is much more productive if we can home in on = specific questions to discuss rather than just give document overviews. = Authors & other folk: what=E2=80=99s interesting, unclear, or controversi= al = here? * `draft-gjessing-taps-minset-05.txt` * There=E2=80=99s been some interesting discussion on the draft. Are = there = any specific topics we should set aside time to discuss? * Socket Intents, Philipp * Again, what specific topics should we discuss? * We=E2=80=99ve been told to expect 3 drafts: on general concepts, BSD= = implementation, & communication granularity. What=E2=80=99s worth discus= sing? * Michio Honda HotNets paper =E2=80=9C[PASTE: Network Stacks Must Integra= te = with NVMM = Abstractions](http://www.ht.sfc.keio.ac.jp/~micchie/papers/paste-hotnets1= 6.pdf)=E2=80=9D * *=E2=80=9CThese days I'm working on networking interface for non-vol= atile = main memory (a.k.a. persistent memory and storage-class memory), because = with such devices networking stack/API becomes a bottleneck in the = end-to-end communication that involves persistent media (disk or SSDs = for now). I saw some post-socket discussion in the minutes of the last = meeting, so I wonder if this type of work could give some useful = information to IETFers who design new transport API standards.=E2=80=9D* * Is there interest in this topic? AFAIK, there=E2=80=99s no Internet= = Draft. I will inquire whether Michio intends to submit one. * Transport Security Protocol Survey, Tommy --=_MailMate_1BBBB4F1-5911-474A-8215-27644524CAA7_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Updating. Our agenda time is much more productive if we = can home in on specific questions to discuss rather than just give docume= nt overviews. Authors & other folk: what=E2=80=99s interesting, uncl= ear, or controversial here?

--=_MailMate_1BBBB4F1-5911-474A-8215-27644524CAA7_=-- From nobody Thu Jun 29 09:07:35 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD649126CF6 for ; Thu, 29 Jun 2017 09:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Z8nUY1o8JUEH for ; Thu, 29 Jun 2017 09:07:24 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [IPv6:2001:8e0:40:325::45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3F2129B36 for ; Thu, 29 Jun 2017 09:07:24 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 95965340EE2; Thu, 29 Jun 2017 18:07:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.25609); Thu, 29 Jun 2017 18:07:22 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 29 Jun 2017 18:07:22 +0200 (CEST) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 22307508; Thu, 29 Jun 2017 18:07:22 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_AA4B4C5B-B5A4-48CC-908A-443EB91C2B73"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: <3A3686B5-FF60-448E-9E13-4B493B472C6D@gmail.com> Date: Thu, 29 Jun 2017 18:07:21 +0200 Cc: taps WG Message-Id: References: <3A3686B5-FF60-448E-9E13-4B493B472C6D@gmail.com> To: Aaron Falk X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Taps] Prague agenda planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 16:07:34 -0000 --Apple-Mail=_AA4B4C5B-B5A4-48CC-908A-443EB91C2B73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Aaron, > On 29 Jun 2017, at 17:36, Aaron Falk wrote: >=20 > Updating. Our agenda time is much more productive if we can home in on = specific questions to discuss rather than just give document overviews. = Authors & other folk: what=E2=80=99s interesting, unclear, or = controversial here? I think it's time to level up and have a discussion about "policy" and = how it relates to TAPS. I'm going to leave the definition of "policy" here deliberately vague = with the hope that we can start to build some terminology around it at = the meeting. >=20 > =E2=80=A2 draft-gjessing-taps-minset-05.txt >=20 > =E2=80=A2 There=E2=80=99s been some interesting = discussion on the draft. Are there any specific topics we should set = aside time to discuss? > =E2=80=A2 Socket Intents, Philipp >=20 > =E2=80=A2 Again, what specific topics should we discuss? > =E2=80=A2 We=E2=80=99ve been told to expect 3 drafts: on = general concepts, BSD implementation, & communication granularity. = What=E2=80=99s worth discussing? Given the focus of the socket intents and granularity work, I think = starting the policy discussion here makes sense. > =E2=80=A2 Michio Honda HotNets paper =E2=80=9CPASTE: Network = Stacks Must Integrate with NVMM Abstractions=E2=80=9D >=20 > =E2=80=A2 =E2=80=9CThese days I'm working on networking = interface for non-volatile main memory (a.k.a. persistent memory and = storage-class memory), because with such devices networking stack/API = becomes a bottleneck in the end-to-end communication that involves = persistent media (disk or SSDs for now). I saw some post-socket = discussion in the minutes of the last meeting, so I wonder if this type = of work could give some useful information to IETFers who design new = transport API standards.=E2=80=9D > =E2=80=A2 Is there interest in this topic? AFAIK, = there=E2=80=99s no Internet Draft. I will inquire whether Michio intends = to submit one. IMO this is very interesting stuff. Might be better as a tsvarea = presentation? Cheers, Brian > =E2=80=A2 Transport Security Protocol Survey, Tommy >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_AA4B4C5B-B5A4-48CC-908A-443EB91C2B73 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZVSW5AAoJEIoSt78L6kajVOsP/jtzAWLrJgsCSZo5LOm7qbAB oUPp0X1N+l+/4/jrUNW9GA5VB7t8EE+7gN15x7OV1L5DydgOCRrhHune52LEQcjw AxGSvqXSdx+gIGmKPoFtOoDnP9o3cfEm9NsdIQJNDJ1nMLTrbByyUO1eDtxmIW9i qHeACN6dTc82BHzBfk6upL1lyiDezIyfZYbg8bLevoLRw4eyhJX0LVq813xb/rIv 9QIhSf01iHyM9QBSRVwxJy71mrsCL4hIhzrFHPn8iQ3UN7QdLtAN0MlWzI+Rsezt JdFzyUlBNIkaP/FssM6Aacbzmf41Eew71Tza4ZhsRp9O9TGKrgKMbBnvHEAvh/12 ku3ry6O5FNtAXancClVViZ35NexqWXvAIjxLpUk8QC9z8IF8zoB5L0V9NRpoRbr3 UDuAokEiy0KtJv8Kr0jAq1Nauy5LkXY1PekafdR1ftKRjjWAuE+ltWgOhbK51Gfq RqS0sYCBsTWSt1jtaMitG/2UUYypKlpUJnxnuGUslngvgqoxmbyHFDJLwNUKTGSa NR4jxgTa3nK6mqGGjRcdoJfSselom1eZ485wOORvQAVYwF/51XH6IvLGXq61NvzD Ky6g4AGH+z2AnmurCm7aXqzkEn9Ypm7ZWiP1jQDDkz9ozIZ6gA7R9+K0TTw859t0 zWCnfWz+qLS0THeCntBn =/IhG -----END PGP SIGNATURE----- --Apple-Mail=_AA4B4C5B-B5A4-48CC-908A-443EB91C2B73-- From nobody Thu Jun 29 09:27:59 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E016D128CFF for ; Thu, 29 Jun 2017 09:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 JQH5rWlmtyrg for ; Thu, 29 Jun 2017 09:27:55 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 88CA0129B6A for ; Thu, 29 Jun 2017 09:27:55 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v5TGRD3s023839 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Jun 2017 18:27:13 +0200 Received: from [2001:638:809:ff1f::8295:dc3a] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dQcHa-0000th-N8; Thu, 29 Jun 2017 18:27:06 +0200 From: "Philipp S. Tiesel" Message-Id: <63E9883D-CDD8-415E-9FCD-CE267E005F3A@in-panik.de> Content-Type: multipart/signed; boundary="Apple-Mail=_CF06B09E-6FDE-47D8-9DF3-D69D46808808"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 29 Jun 2017 18:27:06 +0200 In-Reply-To: Cc: taps WG To: Aaron Falk References: <3A3686B5-FF60-448E-9E13-4B493B472C6D@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Taps] Prague agenda planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 16:27:58 -0000 --Apple-Mail=_CF06B09E-6FDE-47D8-9DF3-D69D46808808 Content-Type: multipart/alternative; boundary="Apple-Mail=_411BEE80-904E-4E40-9F8D-8FF8EBDE6BA0" --Apple-Mail=_411BEE80-904E-4E40-9F8D-8FF8EBDE6BA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Aaron, > On 29. Jun 2017, at 18:07, Brian Trammell (IETF) = wrote: >=20 > hi Aaron, >=20 >> On 29 Jun 2017, at 17:36, Aaron Falk wrote: >>=20 >> Updating. Our agenda time is much more productive if we can home in = on specific questions to discuss rather than just give document = overviews. Authors & other folk: what=E2=80=99s interesting, unclear, or = controversial here? >=20 > I think it's time to level up and have a discussion about "policy" and = how it relates to TAPS. >=20 > I'm going to leave the definition of "policy" here deliberately vague = with the hope that we can start to build some terminology around it at = the meeting. >=20 >>=20 >> =E2=80=A2 draft-gjessing-taps-minset-05.txt >>=20 >> =E2=80=A2 There=E2=80=99s been some interesting = discussion on the draft. Are there any specific topics we should set = aside time to discuss? >> =E2=80=A2 Socket Intents, Philipp >>=20 >> =E2=80=A2 Again, what specific topics should we discuss? >> =E2=80=A2 We=E2=80=99ve been told to expect 3 drafts: on = general concepts, BSD implementation, & communication granularity. = What=E2=80=99s worth discussing? >=20 > Given the focus of the socket intents and granularity work, I think = starting the policy discussion here makes sense. Agreed - 10min talk for context and run though about socket intents and = granularity stuff would be great (plus 2 to 5min for discussion how to = proceed with both drafts). The Policy discussion following that might take some time=E2=80=A6 The third draft is expected tomorrow or on Monday and I think it does = not really need separate discussing in Prague. It is mainly context for the socket intents draft and contains some = lessons learned that might be useful for other projects around TAPS. AVE! Philipp S. Tiesel / phils=E2=80=A6 --Apple-Mail=_411BEE80-904E-4E40-9F8D-8FF8EBDE6BA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Aaron,

On 29. Jun 2017, at 18:07, = Brian Trammell (IETF) <ietf@trammell.ch> wrote:

hi = Aaron,

On 29 Jun 2017, at 17:36, Aaron Falk <aaron.falk@gmail.com> wrote:

Updating. Our agenda time is much more productive if we can = home in on specific questions to discuss rather than just give document = overviews. Authors & other folk: what=E2=80=99s interesting, = unclear, or controversial here?

I think it's time to level up and have a discussion about = "policy" and how it relates to TAPS.

I'm = going to leave the definition of "policy" here deliberately vague with = the hope that we can start to build some terminology around it at the = meeting.


=E2=80=A2 = draft-gjessing-taps-minset-05.txt

=E2=80=A2 = There=E2=80=99s been some interesting discussion on the draft. Are there = any specific topics we should set aside time to discuss?
= =E2=80=A2 Socket Intents, Philipp

= = =E2=80=A2 Again, what specific topics should we discuss?
= = =E2=80=A2 We=E2=80=99ve been told to expect 3 drafts: on general = concepts, BSD implementation, & communication granularity. What=E2=80=99= s worth discussing?

Given the = focus of the socket intents and granularity work, I think starting the = policy discussion here makes sense.

Agreed = - 10min talk for context and run though about socket intents and = granularity stuff would be great (plus 2 to 5min for discussion how to = proceed with both drafts). 

The = Policy discussion following that might take some = time=E2=80=A6 

The third draft = is expected tomorrow or on Monday and I think it does not really need = separate discussing in Prague.
It is mainly context for = the socket intents draft and contains some lessons learned that might be = useful for other projects around TAPS.

AVE!
  Philipp S. Tiesel / phils=E2=80=A6
= --Apple-Mail=_411BEE80-904E-4E40-9F8D-8FF8EBDE6BA0-- --Apple-Mail=_CF06B09E-6FDE-47D8-9DF3-D69D46808808 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZVSpgAAoJEPf3adBuwTwt5CIP/04LN0dndwIi4wbpwYD1alv6 BQ3Xj+DjuarW+8ECrkueGaCMS+N1efhKZSWaAsSpvGbHHadLYST2NboCFqmJM7vT 83hQUOP8MYwu+v9/7DfvmN+CV3jVqGbkXAgSlSaRqKEQzFRgKdSkZCiU+ptjyRtn ZqWBZsWk5HCjzIxNsmHiG39dH7UnM7OIDHB7rIRKA1BQC75EGLSghDCiN3N4KmKG ZbDT4g04y99OB18wtx+kWbSOtauzwL5/LfqeSy/3iZESAxa0fhILHxC2N5F3h1ah 4uqVch3PGbC+tR9r4NcBTKQZe3BWaTxF/LT0qtDYhd3GtLGNlBcrzDyaIUP1u+IC z1fdlFvwhxTJ/eGQjiZ5GK2PX1MGnfpsROSTOq8obsqUksXq1+5j+mygAbk9wYr0 rRJAzrT6r6/Mzc4ayqGr9duyRAQiP4vciks8hdeNYmcGEXJdrOhfDqHmKuRrHZa4 vYYpKlyFXj1rX9tkg1AMVcD7i3/3dlKmWn5/3SOlAJNhbI42mAu+31ouZd/xOoxs VpkB3pDe96yYymBhInmzmlNFuy5bnP0KBjfhtAfiiozE/f03JbNnVv+7+guNCh8J v0urHFLRaf0oXTY4E3jnwiKYr+H1w/wAqY7/zWe23TKdGi00PqP/D+Zo9wjvXTYq mAGl0NBnvAxqGmYGt8Lb =64b2 -----END PGP SIGNATURE----- --Apple-Mail=_CF06B09E-6FDE-47D8-9DF3-D69D46808808-- From nobody Thu Jun 29 10:10:03 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67978129B5E for ; Thu, 29 Jun 2017 10:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 JdJ92asF8Fpd for ; Thu, 29 Jun 2017 10:10:00 -0700 (PDT) Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (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 9CF9C1200C1 for ; Thu, 29 Jun 2017 10:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498756199; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4Xb9pczO3335mXwO3QBYcUEYCPPsTYnCY2ejRLUNAuQ=; b=T5OSFDI18rnX+G9sV7D72qn3hVP/SxghuU4qWAVrlKd+s4BdWiJV0TfEH87AZSjw R8mCqQ94IjBfIRAcP/bXG4CfXOofSUM3e+b1l71cpkSeAB0LGyWwHOkCl8OuLFdf 8ekkZVYNnYxbQAHkvkk77lbKGpOTrVrdnAVkQLkG8kK0Vkr9sGowKZDjxpYc/w/w ZRd82Lzrm1mDJjv84RkmeOFb8PVaO5TaUDse0U5jy9vnBHd5sDGhzk+eoiIt51Ss apSTaKsdTN+sJwwYk+IpS3bnMKQPN/tktUuGRVbAxN9yUBjHA/3zU7SX8NtNVXif sIpBuLo7phtWlmmljdUTcg==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id 4F.F0.07017.76435595; Thu, 29 Jun 2017 10:09:59 -0700 (PDT) X-AuditID: 11ab0215-43f899c000001b69-14-59553467e31d Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay5.apple.com (Apple SCV relay) with SMTP id B1.29.09344.76435595; Thu, 29 Jun 2017 10:09:59 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from da0602a-dhcp103.apple.com (da0602a-dhcp103.apple.com [17.226.23.103]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OSB009VZJON1560@nwk-mmpp-sz10.apple.com>; Thu, 29 Jun 2017 10:09:59 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Thu, 29 Jun 2017 10:09:58 -0700 Cc: Aaron Falk , taps WG Content-transfer-encoding: quoted-printable Message-id: References: <3A3686B5-FF60-448E-9E13-4B493B472C6D@gmail.com> To: "Brian Trammell (IETF)" X-Mailer: Apple Mail (2.3435) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUi2FAYoZtuEhpp0LnEwqLt9zRWi40t79gs 7sQ4MHvsnHWX3WPJkp9MHk/2z2QJYI7isklJzcksSy3St0vgyri5ZiFTwULJiv5t51kbGG+J dDFyckgImEh833WEpYuRi0NIYA2TxMvle9hhEj/+b2WFSBxilPi0fQEjSIJXQFDix+R7QB0c HMwC6hJTpuRC1KxlkvhyqYsZJC4sICGxeU8iSLmwgJbEs1MP2UBsNgEViePfNoCVcArYS+zs qgEJswioSmyYu58ZxGYWsJOYdm8WlK0t8eTdBVaIrTYS10/uBrOFBJYwStzqdwCxRQT0JFb+ +ccCcbKsxJa24+wg50gIbGCTePfyOdMERuFZSK6ehXD1LCQrFjAyr2IUzk3MzNHNzDMy1Ess KMhJ1UvOz93ECAr01UyiOxjnvzI8xCjAwajEw7tBIzRSiDWxrLgy9xCjNAeLkjivunZIpJBA emJJanZqakFqUXxRaU5q8SFGJg5OqQbG2MO32yZ8WLF3/pxYrqkFVmvEvk5rZG9JLLg1qaNU P3Nuz9yvPtdDVD1ZGewe/9zdHHkoYcaFiqXWLMrM1u1LO/Pia8OL7hoF/92uK5W1P5w/3U7J 6NV5Pl+njmUlOlz3XebMLX39wq0mkYkj+freY89Z1a/UfHn1m5NJ1HfVUc2i9d1d5/yVWIoz Eg21mIuKEwHzC7tvVQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUi2FBcpZtuEhppsG2dsEXb72msFhtb3rFZ 3IlxYPbYOesuu8eSJT+ZPJ7sn8kSwBzFZZOSmpNZllqkb5fAlXFzzUKmgoWSFf3bzrM2MN4S 6WLk5JAQMJH48X8raxcjF4eQwCFGiU/bFzCCJHgFBCV+TL7H0sXIwcEsoC4xZUouRM1aJokv l7qYQeLCAhISm/ckgpQLC2hJPDv1kA3EZhNQkTj+bQNYCaeAvcTOrhqQMIuAqsSGufuZQWxm ATuJafdmQdnaEk/eXWCF2Gojcf3kbjBbSGAJo8StfgcQW0RAT2Lln38sECfLSmxpO84+gVFg FpJDZyEcOgvJ1AWMzKsYBYpScxIrTfUSCwpyUvWS83M3MYLDsjBiB+P/ZVaHGAU4GJV4eDdo hEYKsSaWFVfmAkOCg1lJhLdIHSjEm5JYWZValB9fVJqTWnyIsQrol4nMUqLJ+cCYySuJNzQx MTAxNjYzNjY3MaeKsJI474rbwZFCAumJJanZqakFqUUwy5k4OKUaGJuqe7X6/rtOrWib484Z tCQlemqzof/bE3KtBlPXLZjWr6mgsO6fyQKFrWe00g49tU6emnblxPQPCirftr8qtLw0b2ar 1/5rvoKiFWkCJrq7Z7O2lvKyzNwe1R3Xd/oYY17ig/Vfzh+Jm/ho7nOPS8raXU/eObR2Vt7+ +Dcw+pFx6LHcQ2yh7kosxRmJhlrMRcWJAPgM5eSmAgAA Archived-At: Subject: Re: [Taps] Prague agenda planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 17:10:02 -0000 > On Jun 29, 2017, at 9:07 AM, Brian Trammell (IETF) = wrote: >=20 > hi Aaron, >=20 >> On 29 Jun 2017, at 17:36, Aaron Falk wrote: >>=20 >> Updating. Our agenda time is much more productive if we can home in = on specific questions to discuss rather than just give document = overviews. Authors & other folk: what=E2=80=99s interesting, unclear, or = controversial here? >=20 > I think it's time to level up and have a discussion about "policy" and = how it relates to TAPS. >=20 > I'm going to leave the definition of "policy" here deliberately vague = with the hope that we can start to build some terminology around it at = the meeting. +1 to having a general discussion on the topic of policy (both = application-specified and system-specified), likely following onto the = presentation of intents. Getting a formal set of definitions would = really help moving forward in our discussions. >=20 >>=20 >> =E2=80=A2 draft-gjessing-taps-minset-05.txt >>=20 >> =E2=80=A2 There=E2=80=99s been some interesting = discussion on the draft. Are there any specific topics we should set = aside time to discuss? >> =E2=80=A2 Socket Intents, Philipp >>=20 >> =E2=80=A2 Again, what specific topics should we discuss? >> =E2=80=A2 We=E2=80=99ve been told to expect 3 drafts: on = general concepts, BSD implementation, & communication granularity. = What=E2=80=99s worth discussing? >=20 > Given the focus of the socket intents and granularity work, I think = starting the policy discussion here makes sense. >=20 >> =E2=80=A2 Michio Honda HotNets paper =E2=80=9CPASTE: Network = Stacks Must Integrate with NVMM Abstractions=E2=80=9D >>=20 >> =E2=80=A2 =E2=80=9CThese days I'm working on networking = interface for non-volatile main memory (a.k.a. persistent memory and = storage-class memory), because with such devices networking stack/API = becomes a bottleneck in the end-to-end communication that involves = persistent media (disk or SSDs for now). I saw some post-socket = discussion in the minutes of the last meeting, so I wonder if this type = of work could give some useful information to IETFers who design new = transport API standards.=E2=80=9D >> =E2=80=A2 Is there interest in this topic? AFAIK, = there=E2=80=99s no Internet Draft. I will inquire whether Michio intends = to submit one. >=20 > IMO this is very interesting stuff. Might be better as a tsvarea = presentation? >=20 > Cheers, >=20 > Brian >=20 >> =E2=80=A2 Transport Security Protocol Survey, Tommy Since the security part of the protocols is a bit new in TAPS, we=E2=80=99= ll probably want to give a bit of document overview, but I think the = interesting discussion points here are in: - The common features/interface presented by various security protocols - The ability to separate security handshakes from data encryption Thanks, Tommy >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Jun 29 12:53:28 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B918129B5B for ; Thu, 29 Jun 2017 12:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eJO3yumHzzqb for ; Thu, 29 Jun 2017 12:53:25 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1CC129B66 for ; Thu, 29 Jun 2017 12:53:25 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id d78so85081221qkb.1 for ; Thu, 29 Jun 2017 12:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=RrSUMsg+N1nrajA5ebfbYz6yLNIsl84xd4HA2qeuAgY=; b=HxcXGAncE3Uv51wiTf8tbzzp+sjUt20/7gqYbJv8Z7GRO9XPO7ypStdd3eNH1RWm+9 ASqDXYQyrSNWdKzculq6mjkn4RPJukdRNdoX0DTwgyC4TkVzD3ZxBlAMaTqtFA62CpEC L1JSo/0cFVugRrKtdPWQXX2WTZy+4JdkOJP/eu6Aog9e859TwSUtunwvUEMcN1aJb8HO uckOuipc0jKzD/Vi920IYerZSYLraCJIqJLFlEeEmDcUFsX32cuZ3MKhmoN60YyuJ85o VSMnftahUFOESkHAk3ER9Mb1xL8v372jsENQm17Gs+9rbu58jsFFLGya866ZhnoRJkgs KEKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=RrSUMsg+N1nrajA5ebfbYz6yLNIsl84xd4HA2qeuAgY=; b=VB2ErZvabM8v1X20ogoAuTQkyYuE2uiWKai6/U9WnOdw61HQqpMdbnRUvqasC6VCW+ EDnaJWAU4qgwTEiFy4t7GjLnJI8OisoK1LQ1ENsX7X/gTLYsFLvDGuX7DmL20LsGL4IP twLTljTotnS3ls2o2sDWPbQc9cyDWwmd3w3iZGxrM1QiCVBAJWY9oSd9bpZlLngm+1SJ orApb2e2nLrWCLA14wN0jORvJBmbR82RJAkFGhTXPDV9c0Khp2ylp2vvUDz+pF5/vwym B2lrny00lgcgNY5+on1YGR2EJermOnblbez8xrI0h4+P8NkdSj+2CG0ySWUlA9dFJqZs 6c9g== X-Gm-Message-State: AKS2vOz2vpiXRWKKoL5vleahX8LVWjj4fmPMgUnKY2ypOZKeULDgwlmJ ShLs+KN3Kxe3jrB1RTg= X-Received: by 10.233.239.11 with SMTP id d11mr23301079qkg.126.1498766004287; Thu, 29 Jun 2017 12:53:24 -0700 (PDT) Received: from [172.19.36.78] ([72.246.0.14]) by smtp.gmail.com with ESMTPSA id s6sm4502534qki.44.2017.06.29.12.53.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 12:53:23 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Thu, 29 Jun 2017 15:53:22 -0400 Message-ID: <77C2BA95-F95B-4597-9159-7D5FC4068860@gmail.com> In-Reply-To: <3A3686B5-FF60-448E-9E13-4B493B472C6D@gmail.com> References: <3A3686B5-FF60-448E-9E13-4B493B472C6D@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_15D9873A-ACD1-4A84-83C0-2CD7825DA853_=" X-Mailer: MailMate (1.9.6r5356) Archived-At: Subject: Re: [Taps] Prague agenda planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 19:53:27 -0000 --=_MailMate_15D9873A-ACD1-4A84-83C0-2CD7825DA853_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Updated: 1. **`draft-gjessing-taps-minset-05.txt`** * There=E2=80=99s been some interesting discussion on the draft. Are = there = any specific topics we should set aside time to discuss? 2. **Transport Security Protocol Survey**, Tommy - The common features/interface presented by various security = protocols - The ability to separate security handshakes from data encryption 3. **Socket Intents, Concepts & Communication Granularity**, Phillipp 4. **Application- & System-Specified Policy & TAPS**, Brian? Tommy? ____ * Michio Honda HotNets paper =E2=80=9C[PASTE: Network Stacks Must Integra= te = with NVMM = Abstractions](http://www.ht.sfc.keio.ac.jp/~micchie/papers/paste-hotnets1= 6.pdf)=E2=80=9D * *=E2=80=9CThese days I'm working on networking interface for non-vol= atile = main memory (a.k.a. persistent memory and storage-class memory), because = with such devices networking stack/API becomes a bottleneck in the = end-to-end communication that involves persistent media (disk or SSDs = for now). I saw some post-socket discussion in the minutes of the last = meeting, so I wonder if this type of work could give some useful = information to IETFers who design new transport API standards.=E2=80=9D* * Is there interest in this topic? AFAIK, there=E2=80=99s no Internet= = Draft. I will inquire whether Michio intends to submit one. May end up = in TSVAREA --=_MailMate_15D9873A-ACD1-4A84-83C0-2CD7825DA853_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Updated:

  1. draft-gjessing-taps-minset-05.txt

    • There=E2=80=99s been some interesting discussion on the draft. Are t= here any specific topics we should set aside time to discuss?

  2. Transport Security Protocol Surve= y, Tommy

    • The common features/interface presented by various security protocols=
    • The ability to separate security handshakes from data encryption
      • =

  3. Socket Intents, Concepts & Co= mmunication Granularity, Phillipp

  4. Application- & System-Specifi= ed Policy & TAPS, Brian? Tommy?

  • Michio Honda HotNets paper =E2=80=9CP= ASTE: Network Stacks Must Integrate with NVMM Abstractions=E2=80=9D
    • =E2=80=9CThese days I'm working on networking interface for non-v= olatile main memory (a.k.a. persistent memory and storage-class memory), = because with such devices networking stack/API becomes a bottleneck in th= e end-to-end communication that involves persistent media (disk or SSDs f= or now). I saw some post-socket discussion in the minutes of the last me= eting, so I wonder if this type of work could give some useful informatio= n to IETFers who design new transport API standards.=E2=80=9D
    • Is there interest in this topic? AFAIK, there=E2=80=99s no Internet = Draft. I will inquire whether Michio intends to submit one. May end up = in TSVAREA
--=_MailMate_15D9873A-ACD1-4A84-83C0-2CD7825DA853_=-- From nobody Thu Jun 29 13:53:13 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DD712EA53 for ; Thu, 29 Jun 2017 13:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Cl-SbAUE_gsH for ; Thu, 29 Jun 2017 13:53:08 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 59E76129AD5 for ; Thu, 29 Jun 2017 13:53:07 -0700 (PDT) Received: from mail-mx02.uio.no ([129.240.10.43]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dQgQz-0009as-D0; Thu, 29 Jun 2017 22:53:05 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx02.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dQgQy-00047K-Nn; Thu, 29 Jun 2017 22:53:05 +0200 From: Michael Welzl Message-Id: <0E3F9805-5513-40F8-ADB2-D5F550EC771A@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_4F368019-A280-4A33-8BFA-F90CAD44D113" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 29 Jun 2017 22:53:09 +0200 In-Reply-To: <77C2BA95-F95B-4597-9159-7D5FC4068860@gmail.com> Cc: "taps@ietf.org" To: Aaron Falk References: <3A3686B5-FF60-448E-9E13-4B493B472C6D@gmail.com> <77C2BA95-F95B-4597-9159-7D5FC4068860@gmail.com> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 3 sum rcpts/h 4 sum msgs/h 3 total rcpts 56034 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.055, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F2D2F9E1F748BB9DCC36A106DE4D51D4F349F883 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 1655 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] Prague agenda planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 20:53:11 -0000 --Apple-Mail=_4F368019-A280-4A33-8BFA-F90CAD44D113 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, In line: > On Jun 29, 2017, at 9:53 PM, Aaron Falk wrote: >=20 > Updated: >=20 > draft-gjessing-taps-minset-05.txt >=20 > There=E2=80=99s been some interesting discussion on the draft. Are = there any specific topics we should set aside time to discuss? I appreciated this discussion much, but personally I don=E2=80=99t think = know of any specific topic that we need to discuss here - plus, there = seem to be plenty of other good things to talk about which will all need = time. Cheers, Michael >=20 > Transport Security Protocol Survey, Tommy >=20 > The common features/interface presented by various security protocols > The ability to separate security handshakes from data encryption > Socket Intents, Concepts & Communication Granularity, Phillipp >=20 > Application- & System-Specified Policy & TAPS, Brian? Tommy? >=20 > Michio Honda HotNets paper =E2=80=9CPASTE: Network Stacks Must = Integrate with NVMM Abstractions = =E2=80= =9D > =E2=80=9CThese days I'm working on networking interface for = non-volatile main memory (a.k.a. persistent memory and storage-class = memory), because with such devices networking stack/API becomes a = bottleneck in the end-to-end communication that involves persistent = media (disk or SSDs for now). I saw some post-socket discussion in the = minutes of the last meeting, so I wonder if this type of work could give = some useful information to IETFers who design new transport API = standards.=E2=80=9D > Is there interest in this topic? AFAIK, there=E2=80=99s no Internet = Draft. I will inquire whether Michio intends to submit one. May end up = in TSVAREA > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_4F368019-A280-4A33-8BFA-F90CAD44D113 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

In = line:


On = Jun 29, 2017, at 9:53 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

Updated:

  1. draft-gjessing-taps-minset-05.txt

    • There=E2=80=99s been some interesting discussion on the = draft. Are there any specific topics we should set aside time to = discuss?

I appreciated this discussion much, but personally = I don=E2=80=99t think know of any specific topic that we need to discuss = here - plus, there seem to be plenty of other good things to talk about = which will all need time.

Cheers,
Michael

  2. Transport Security Protocol Survey, Tommy

    • The common features/interface presented by various = security protocols
    • The ability to separate security handshakes from data = encryption

  3. Socket Intents, Concepts & Communication = Granularity, Phillipp

  4. Application- & System-Specified Policy & = TAPS, Brian? Tommy?

  • Michio Honda HotNets paper =E2=80=9CPASTE: Network Stacks Must = Integrate with NVMM Abstractions=E2=80=9D
    • =E2=80=9CThese days I'm working on = networking interface for non-volatile main memory (a.k.a. persistent = memory and storage-class memory), because with such devices networking = stack/API becomes a bottleneck in the end-to-end communication that = involves persistent media (disk or SSDs for now). I saw some = post-socket discussion in the minutes of the last meeting, so I wonder = if this type of work could give some useful information to IETFers who = design new transport API standards.=E2=80=9D
    • Is there interest in this topic? AFAIK, there=E2=80=99s = no Internet Draft. I will inquire whether Michio intends to submit one. = May end up in TSVAREA
_______________________________________________
Taps = mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Apple-Mail=_4F368019-A280-4A33-8BFA-F90CAD44D113-- From nobody Thu Jun 29 14:09:55 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739E712EAEE for ; Thu, 29 Jun 2017 14:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ySjDH2YsVx9v for ; Thu, 29 Jun 2017 14:09:52 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 6C512129AD5 for ; Thu, 29 Jun 2017 14:09:52 -0700 (PDT) Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dQghC-000AiO-Rn for taps@ietf.org; Thu, 29 Jun 2017 23:09:50 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx01.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dQghB-0008Tb-Su for taps@ietf.org; Thu, 29 Jun 2017 23:09:50 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_6593CF00-F073-4FE2-B52E-142D962E8147" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 29 Jun 2017 23:09:54 +0200 References: <3A3686B5-FF60-448E-9E13-4B493B472C6D@gmail.com> To: "taps@ietf.org" In-Reply-To: Message-Id: <3EC0F8DD-93C9-4551-AF49-BB440D17A68A@ifi.uio.no> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 4 sum msgs/h 3 total rcpts 56036 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.054, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6CB555ADD196BF1DCC50C9B92CDB2CC8625D0135 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1657 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] Prague agenda planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 21:09:54 -0000 --Apple-Mail=_6593CF00-F073-4FE2-B52E-142D962E8147 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, > On Jun 29, 2017, at 7:09 PM, Tommy Pauly wrote: >=20 >=20 >=20 >> On Jun 29, 2017, at 9:07 AM, Brian Trammell (IETF) = wrote: >>=20 >> hi Aaron, >>=20 >>> On 29 Jun 2017, at 17:36, Aaron Falk wrote: >>>=20 >>> Updating. Our agenda time is much more productive if we can home in = on specific questions to discuss rather than just give document = overviews. Authors & other folk: what=E2=80=99s interesting, unclear, or = controversial here? >>=20 >> I think it's time to level up and have a discussion about "policy" = and how it relates to TAPS. >>=20 >> I'm going to leave the definition of "policy" here deliberately vague = with the hope that we can start to build some terminology around it at = the meeting. >=20 > +1 to having a general discussion on the topic of policy (both = application-specified and system-specified), likely following onto the = presentation of intents. Getting a formal set of definitions would = really help moving forward in our discussions. +1 from me too. BTW, NEAT already has quite an elaborate policy system built in. Naeem = gave a high-level look at it at the last meeting: = https://www.ietf.org/proceedings/98/slides/slides-98-taps-42-neat-naeem-kh= ademi-00.pdf = (slides 6/7) More details are here: = https://www.neat-project.org/wp-content/uploads/2017/03/commag16-accepted-= version.pdf = This says =E2=80=9Cuntil published=E2=80=9D, but I think this has just = happened: http://ieeexplore.ieee.org/document/7945852/ = Cheers, Michael --Apple-Mail=_6593CF00-F073-4FE2-B52E-142D962E8147 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

On = Jun 29, 2017, at 7:09 PM, Tommy Pauly <tpauly@apple.com> = wrote:



On Jun 29, 2017, at 9:07 AM, Brian Trammell (IETF) <ietf@trammell.ch> = wrote:

hi Aaron,

On 29 Jun 2017, at = 17:36, Aaron Falk <aaron.falk@gmail.com> wrote:

Updating. Our agenda time is much more productive if we can = home in on specific questions to discuss rather than just give document = overviews. Authors & other folk: what=E2=80=99s interesting, = unclear, or controversial here?

I think it's time to level up and have a discussion about = "policy" and how it relates to TAPS.

I'm = going to leave the definition of "policy" here deliberately vague with = the hope that we can start to build some terminology around it at the = meeting.

+1 to having a = general discussion on the topic of policy (both application-specified = and system-specified), likely following onto the presentation of = intents. Getting a formal set of definitions would really help moving = forward in our discussions.

+1 = from me too.

BTW, NEAT already has = quite an elaborate policy system built in. Naeem gave a high-level look = at it at the last meeting:

More details are here:
This says =E2=80=9Cuntil = published=E2=80=9D, but I think this has just happened:

Cheers,
Michael

= --Apple-Mail=_6593CF00-F073-4FE2-B52E-142D962E8147-- From nobody Fri Jun 30 05:32:13 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9D51273E2 for ; Fri, 30 Jun 2017 05:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_WP_DIRINDEX=1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 aF87_PcrLBCF for ; Fri, 30 Jun 2017 05:31:56 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6245112F265 for ; Fri, 30 Jun 2017 05:31:47 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id 191so65133408vko.2 for ; Fri, 30 Jun 2017 05:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TJVkRNumqG9ZdjDhnCZbWhR9yOidDcwXW2aChNGbwPA=; b=lmelSml6SSMlhD1kg2fM1koNLrbSLx+BlBI4mmm/a24QN24hCjoUMUv9DcCfWbHaZy tXfIFiJAHRy8v+Rt3n+VWwqYdsGquLT7hVX9D8bUdtxxyLl3OfjDGiSSjBR8XRG1l+BA estzmSwpYpHwJFkLiBRhYw9kYlkZZDJHk5fT1yqmXN6csQ9hgwlTIX28CUDco4FxYd6f nowVe1S+wdd+qrfI6H48iOWAO87y5+GeX+SoUzW0tZq3PalyOQidZVxrw4N+KDox4H9U e0S+gYI5FJknpAS/6EdMorpYRE0dD1/PJ8ey22zZgAfP6IaZuuPdtfOgR4B4D0xNpA0n qkXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TJVkRNumqG9ZdjDhnCZbWhR9yOidDcwXW2aChNGbwPA=; b=sI9Pqn/sxroLow6c1vrkyDSgi2jq6gNCoEAbSamY8g3CTE1LkD15ttQMFArfAj3L0f MNzd58pgjlM2FmgyVVScqj83qpmtfvsJL+NKPL7CWK2okKzEUbsfCztubTMJWbf2pjP7 FNz7P5bWYJf3RuWV9DqcV4IXMvPHkhX74cFY8w5uUOamlw36bw7TDUAezglKBIug9wOW m1XnKguHp7eq3C+2b2gODOnmmD70UlsvEtBH86PaTgi90UMpzAYuRHIrFcPilIql9fzo 4MwA/hIU25evKW1o5nooQkVhCpnE5eCnyfKoDo271xpPC+tDE3jBvCWg7pS/43+VNFS+ xwfw== X-Gm-Message-State: AKS2vOyk9Xq7Fzmxf1p/Kv6ZC0L0MI9e0SCZFIgtMWRhAGp6x4ldOgFc dMWD/AXQEudv1x2obLQPSH8bjDNJydRa X-Received: by 10.31.218.196 with SMTP id r187mr11185908vkg.96.1498825906368; Fri, 30 Jun 2017 05:31:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.87.29 with HTTP; Fri, 30 Jun 2017 05:31:45 -0700 (PDT) In-Reply-To: <3EC0F8DD-93C9-4551-AF49-BB440D17A68A@ifi.uio.no> References: <3A3686B5-FF60-448E-9E13-4B493B472C6D@gmail.com> <3EC0F8DD-93C9-4551-AF49-BB440D17A68A@ifi.uio.no> From: boza Date: Fri, 30 Jun 2017 13:31:45 +0100 Message-ID: To: Michael Welzl Cc: "taps@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07c562bab90305532c996a" Archived-At: Subject: Re: [Taps] Prague agenda planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 12:31:58 -0000 --94eb2c07c562bab90305532c996a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, On Thu, Jun 29, 2017 at 10:09 PM, Michael Welzl wrote: > I think it's time to level up and have a discussion about "policy" and ho= w > it relates to TAPS. > > I'm going to leave the definition of "policy" here deliberately vague wit= h > the hope that we can start to build some terminology around it at the > meeting. > > > +1 to having a general discussion on the topic of policy (both > application-specified and system-specified), likely following onto the > presentation of intents. Getting a formal set of definitions would really > help moving forward in our discussions. > > > +1 from me too. > > BTW, NEAT already has quite an elaborate policy system built in. Naeem > gave a high-level look at it at the last meeting: > https://www.ietf.org/proceedings/98/slides/slides- > 98-taps-42-neat-naeem-khademi-00.pdf (slides 6/7) > > More details are here: > https://www.neat-project.org/wp-content/uploads/2017/03/ > commag16-accepted-version.pdf > This says =E2=80=9Cuntil published=E2=80=9D, but I think this has just ha= ppened: > http://ieeexplore.ieee.org/document/7945852/ > > I'd be happy join the discussion on policy aspects (unfortunately, only remotely). As Michael mentioned, the implemented NEAT policy system is fairly flexible. The most up-to-date documentation can be found on the NEAT GitHub pages. Let me know if you have any questions. Cheers, Zdravko --94eb2c07c562bab90305532c996a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

On Thu, Jun 29, 2017 at 10:09 P= M, Michael Welzl <michawe@ifi.uio.no> wrote:
I thi= nk it's time to level up and have a discussion about "policy"= and how it relates to TAPS.

I'm going to leave the definition o= f "policy" here deliberately vague with the hope that we can star= t to build some terminology around it at the meeting.

+= 1 to having a general discussion on the topic of policy (both application-s= pecified and system-specified), likely following onto the presentation of i= ntents. Getting a formal set of definitions would really help moving forwar= d in our discussions.

+1 from me too.

BTW, NEAT already has quite an e= laborate policy system built in. Naeem gave a high-level look at it at the = last meeting:

More deta= ils are here:
This says =E2=80=9Cuntil published=E2=80=9D, but I= think this has just happened:

I'd be = happy join the discussion on policy aspects (unfortunately, only remotely).= As Michael mentioned, the implemented NEAT policy system is fairly flexibl= e. The most up-to-date documentation can be found on the NEAT=C2=A0GitH= ub=C2=A0pages. Let me know if you have any questions.
Cheers,
Zdravko=C2=A0
--94eb2c07c562bab90305532c996a--