From nobody Sat Jul 2 13:12:18 2016 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 122E712D1A7 for ; Sat, 2 Jul 2016 13:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 QOhfLJb2gNXN for ; Sat, 2 Jul 2016 13:12:15 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95BF612D19E for ; Sat, 2 Jul 2016 13:12:14 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-02-5778201cca0d Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 48.3A.12516.C1028775; Sat, 2 Jul 2016 22:12:12 +0200 (CEST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.294.0; Sat, 2 Jul 2016 22:12:11 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5KVX3kDteDn5pg8d8a14dxpDFE29pbUYgtQOLYk2K68=; b=gbV2d/DqTAwRJf9TmYY5Fy4IBc4E5iVktcVjtU1vQheVg3I4HrSMq81h7bQUq5u0K4FTAP6KG1HvKazppYBspx5pa5PIsvFSwZ8fIpFHJ801KVoD5VE78e6gGUx0T0Y1vGmLp26zsKiyva744ieqZ0hiKOvmzlbsXsIv8DlF9mc= Received: from AM3PR07MB292.eurprd07.prod.outlook.com (10.242.108.153) by AM3PR07MB292.eurprd07.prod.outlook.com (10.242.108.153) with Microsoft SMTP Server (TLS) id 15.1.517.8; Sat, 2 Jul 2016 20:12:10 +0000 Received: from AM3PR07MB292.eurprd07.prod.outlook.com ([fe80::bdec:fa0b:43c6:f05e]) by AM3PR07MB292.eurprd07.prod.outlook.com ([fe80::bdec:fa0b:43c6:f05e%14]) with mapi id 15.01.0517.016; Sat, 2 Jul 2016 20:12:10 +0000 From: Zaheduzzaman Sarker To: "taps@ietf.org" Thread-Topic: modified IETF96 meeting agenda uploaded Thread-Index: AdHUnasoE4E1Ec71TTCgZEd3AQuOwg== Date: Sat, 2 Jul 2016 20:12:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zaheduzzaman.sarker@ericsson.com; x-originating-ip: [95.109.38.59] x-ms-office365-filtering-correlation-id: f531911f-4736-473d-dc79-08d3a2b5268e x-microsoft-exchange-diagnostics: 1; AM3PR07MB292; 6:efT0I3pMr8MdmufPlNQYIrf63TKYbG+kxVz2T6zaacPt5MmQIvjn1fdOFwAkhTrdZRleBAGEPmU6Ms+GfBOkGK46eeXAvlFUDUNgn6Oe2yGyGBo8b/lgkQi8f5AG/1XmaF50vIwQLa7iFYBJRBAqCYeg+dGQDgGKtq9bJRWj0V8B5gibL3r4d7/WJzkFF37HDq8/komXpgXjKKMZU4zUzPdDTFgPZtAkfpP9BIcZC/LGu9Od51A8mgOgHiUP+Z+CJKtxV4YzANPwTQ0EXdAM0lfOV2HAcyu3bZVWW1PjKK36M34N6wbmqmnIV4LKcsYA; 5:rfTkf8WiX6HIKQ6/J1QE9lvVvicljSRwozP0cSCJAS1RGhtbbeae4Jocn6mF1PcDepbw6rcCvaDQzPyArKIUP+nnZyDfQYGIh/bu0FiO/yJ5iBgS8Z718IgD3k1QrdCrQ03/gjIy64/bwHD/kSnJLA==; 24:tjYN2l8ckGvN6jk06o4J2/JYYhR1NRamWbF05HM3nfTw28bMvapAD+JNPPrMFQ9WD2vSP/2nkePyv6YclXq+Ux6+ytAHQsOPZla28tpaVhk=; 7:J3L156YyvknfQtfLDOOSxJOE4NkI4SrtP7ssFxK2zjaVoTHC0adkOuEmlMAc8hfzxE1SV+o9k9RthFttyBQ1RAMvRClveMUtTZhmLhCwAlhSe/BL9jg0PnWCQshfFAJzzucK7hBwUoOIdMZKrynpp6kL1PiZ4K4BMYPJwgi/5Y+nkr0bfZBwNkEMC8xcLYSAnAoEELDU6TDI+ksTRLERgsi6cQpBZYW39BAWmo3nAuOytZlYNBsg6/gzI6KlKUAL x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB292; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AM3PR07MB292; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB292; x-forefront-prvs: 0991CAB7B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(3846002)(5640700001)(9686002)(5250100002)(7696003)(102836003)(3280700002)(6116002)(7736002)(586003)(8936002)(305945005)(76576001)(81166006)(5003600100003)(68736007)(7846002)(2906002)(97736004)(2900100001)(105586002)(2501003)(15975445007)(107886002)(189998001)(11100500001)(1730700003)(66066001)(450100001)(106356001)(86362001)(50986999)(81156014)(8676002)(87936001)(101416001)(74316002)(19580395003)(5002640100001)(92566002)(110136002)(3660700001)(33656002)(2351001)(229853001)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB292; H:AM3PR07MB292.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM3PR07MB2928B70A025B07ABE1750319F260AM3PR07MB292eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2016 20:12:10.7547 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB292 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUyM2K7n66MQkW4wZ93chZ3YhwYPZYs+ckU wBjFZZOSmpNZllqkb5fAlbHi2wKmghbuiob2TawNjI85uxg5OSQETCT+fJrHDmGLSVy4t56t i5GLQ0jgCKPEkmXbmSCc44wSXT9+MYM4LAK9zBKdm24zQ2SuMErMWHYNquwBo8TTn1OAHA4O NgEbiceL/UDmiggoS1zev5ENxBYWMJDom/GWFSJuKvH80k42CFtPYuLMm0wgNouAisScWT/B buIViJJ4OfM4I4jNCHTf91NrwGqYBcQlbj2ZzwRxt4DEkj3nmSFsUYmXj/+xQtQnS0z92soG EVeQuDF9IguE7SvR1XUI7E8JgUZ2ieUb+6CaXSU6PvWzQtiZEhev/odqtpLomHicFaJhLaNE 9+5VUJtlJH7fboJKXGGVuLNlMlhCSCBVYvnaVkaIl6Uk7l7phLJlJF7c2csKCiFmgXyJ38tC JzCqz0Ly0CyEzCyw/wUlTs58wgJRoiOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYhQtTi0u zk03MtZLLcpMLi7Oz9PLSy3ZxAhMMwe3/Nbdwbj6teMhRgEORiUeXgWF8nAh1sSy4srcQ4wS HMxKIrwnpCrChXhTEiurUovy44tKc1KLDzFKc7AoifP6v1QMFxJITyxJzU5NLUgtgskycXBK NTBOu3xPlzXhocaMnhflKxKeSv2ZNrGk7uyc0Ntq9TGfP126/3S1ssfa1UFVk10/LvtkytXH s3vtLb6DrMf36VgfT815Nf/c0gPvJh3btmTTHHHf86//l/+YuXyjwKPwlssxTlelbtyLlz7q HME+S+qrRftyNrv4xmW5B4y3LV8aZ8Gy9Ft5+VYWDiWW4oxEQy3mouJEAGG6buwvAwAA Archived-At: Subject: [Taps] modified IETF96 meeting agenda uploaded X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 20:12:17 -0000 --_000_AM3PR07MB2928B70A025B07ABE1750319F260AM3PR07MB292eurprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A modified version of the agenda for IETF96 meeting has been uploaded https= ://www.ietf.org/proceedings/96/agenda/agenda-96-taps BR Zahed --_000_AM3PR07MB2928B70A025B07ABE1750319F260AM3PR07MB292eurprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
A modified version of the agenda for IETF96 meeting has been uploaded = https://www.ietf.org/proceedings/96/agenda/agenda-96-tap= s
 
BR
 
Zahed
 
 
 
 
--_000_AM3PR07MB2928B70A025B07ABE1750319F260AM3PR07MB292eurprd_-- From nobody Thu Jul 7 07:00:15 2016 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 D9C0C12D7D2; Thu, 7 Jul 2016 07:00:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160707140012.23769.18108.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 07:00:12 -0700 Archived-At: Cc: taps@ietf.org Subject: [Taps] I-D Action: draft-ietf-taps-transports-11.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 14:00:13 -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 : Services provided by IETF transport protocols and congestion control mechanisms Authors : Godred Fairhurst Brian Trammell Mirja Kuehlewind Filename : draft-ietf-taps-transports-11.txt Pages : 53 Date : 2016-07-07 Abstract: This document describes, surveys, classifies and compares the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Realtime Transport Protocol (RTP), File Delivery over Unidirectional Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC), and NACK-Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-taps-transports-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-11 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 Thu Jul 7 07:30:14 2016 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 9395912D759 for ; Thu, 7 Jul 2016 07:30:12 -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 flt4NM2fWZV7 for ; Thu, 7 Jul 2016 07:30:10 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c: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 A417E12D5AB for ; Thu, 7 Jul 2016 07:30:10 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id d67so22374997vkh.1 for ; Thu, 07 Jul 2016 07:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1aIRxfte6RE2NWToUhwkyGt0Hzz2M/ThbQcIsSatvHM=; b=nPU70URHY4zCmCSUFBwZ/F3gNx8TjVQXXyzaqWciVSt981jUhs7kTLlKUrBe41hw+G YKYLrhSun0TCLrJ6UGsLeS8EA9/10VSZdloKjCwak8JOvSXHdEbYMOAOzzOyM6Vy/SDU HoeRGlR7Fl+V1ZbDkK5b8GG41ve7gWTLhLajzjKDDxdqLOGTgFNC9wc7LF4pwr5jtxnM OQNmM7pWuf/apBRG7N/NzaGmHf+SqSyRUyqi6Pyqdt6D1rstHRg40k9u+ssMyCOWeNud XpuuFwEQDLZu8e70sw8ZKYAY4tzIAZRX7GD80xDL07jdgBjQMyYVMvGJxoUWJMpv3v+o 0IQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=1aIRxfte6RE2NWToUhwkyGt0Hzz2M/ThbQcIsSatvHM=; b=J6FyVNi5NL0Ve4bOMUv274vfaGw7yifWeC7nrgsi/lX6VgCDGvgOrDadNa9euxckar BSvl1L8QOY27Ls6nQTfWUoiahXIPmJiGzCC7iZS9ryvQhJaOGNYPRAfsJ8bR61ll6lNa F+9eXGiGOD0lCwFG2JdPxPbcRexfwuxu+QwE+9Gj2pGRIuidrjK0gz0L8Ws0+i4Da9en s2Sz/m12quIVK4RcCwkFZuzt7OlkROnzsdYJlMRV2uguFk6e39oEvZCVd9BebPVcokVX 9EB31Tg6q2fnKG2dee049iwsfbaIMPBxc5SAnRXjbqhzonqYUamRX+QZv/r9kX94sE/p 5NqQ== X-Gm-Message-State: ALyK8tJOryBX/Rlv0J371Kbm4P/GvU4uMioPXD6JX/wSykX8/gr0z10WC6JNQQAmmdjtgMzO/1Azdcl16w+ZUQ== X-Received: by 10.176.5.3 with SMTP id 3mr253653uax.52.1467901809504; Thu, 07 Jul 2016 07:30:09 -0700 (PDT) MIME-Version: 1.0 References: <20160707140012.23769.18108.idtracker@ietfa.amsl.com> In-Reply-To: From: Aaron Falk Date: Thu, 07 Jul 2016 14:30:00 +0000 Message-ID: To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c12518cebd80305370c85c2 Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-11.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 14:30:12 -0000 --94eb2c12518cebd80305370c85c2 Content-Type: text/plain; charset=UTF-8 FYI, this revision is in response to comments from the AD review and consists of minor cleanup and clarification. The curious are encouraged to glance at the diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-11.txt --aaron On Thu, Jul 7, 2016 at 10:00 AM wrote: > > 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 : Services provided by IETF transport protocols > and congestion control mechanisms > Authors : Godred Fairhurst > Brian Trammell > Mirja Kuehlewind > Filename : draft-ietf-taps-transports-11.txt > Pages : 53 > Date : 2016-07-07 > > Abstract: > This document describes, surveys, classifies and compares the > protocol mechanisms provided by existing IETF protocols, as > background for determining a common set of transport services. It > examines the Transmission Control Protocol (TCP), Multipath TCP, the > Stream Control Transmission Protocol (SCTP), the User Datagram > Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol > (DCCP), the Internet Control Message Protocol (ICMP), the Realtime > Transport Protocol (RTP), File Delivery over Unidirectional > Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC), > and NACK-Oriented Reliable Multicast (NORM), Transport Layer Security > (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol > (HTTP), when HTTP is used as a pseudotransport. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-taps-transports-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-11 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > -- --aaron =====Short message from my phone===== -- --aaron =====Short message from my phone===== --94eb2c12518cebd80305370c85c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI, this revi= sion is in response to comments from the AD review and consists of minor cl= eanup and clarification.=C2=A0 The curious are encouraged to glance at the = diff:=C2=A0https://tools.ietf.org/rfcdiff?url2= =3Ddraft-ietf-taps-transports-11.txt

--aaron


On Thu, Jul 7, 2016 at 10:00 AM <internet-drafts@ietf.org> wrote:
=

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Transport Services of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Services provided by IETF transport protocols and congestion control mecha= nisms
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Godr= ed Fairhurst
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Brian Trammell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Mirja Kuehlewind
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-taps-transports-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 53
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-07-07

Abstract:
=C2=A0 =C2=A0This document describes, surveys, classifies and compares the<= br> =C2=A0 =C2=A0protocol mechanisms provided by existing IETF protocols, as =C2=A0 =C2=A0background for determining a common set of transport services.= =C2=A0 It
=C2=A0 =C2=A0examines the Transmission Control Protocol (TCP), Multipath TC= P, the
=C2=A0 =C2=A0Stream Control Transmission Protocol (SCTP), the User Datagram=
=C2=A0 =C2=A0Protocol (UDP), UDP-Lite, the Datagram Congestion Control Prot= ocol
=C2=A0 =C2=A0(DCCP), the Internet Control Message Protocol (ICMP), the Real= time
=C2=A0 =C2=A0Transport Protocol (RTP), File Delivery over Unidirectional =C2=A0 =C2=A0Transport/Asynchronous Layered Coding Reliable Multicast (FLUT= E/ALC),
=C2=A0 =C2=A0and NACK-Oriented Reliable Multicast (NORM), Transport Layer S= ecurity
=C2=A0 =C2=A0(TLS), Datagram TLS (DTLS), and the Hypertext Transport Protoc= ol
=C2=A0 =C2=A0(HTTP), when HTTP is used as a pseudotransport.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-i= etf-taps-transports/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ta= ps-transports-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-taps-transports-11


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

=3D=3D=3D=3D=3DSh= ort message from my phone=3D=3D=3D=3D=3D
--
--aaron

=3D=3D=3D=3D=3DShort message from my phone=3D=3D=3D=3D=3D
--94eb2c12518cebd80305370c85c2-- From nobody Thu Jul 7 13:33:31 2016 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 7A95D12D1F0 for ; Thu, 7 Jul 2016 13:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 8tVfjPpZ2sQi for ; Thu, 7 Jul 2016 13:33:26 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A93212D13D for ; Thu, 7 Jul 2016 13:33:26 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bLFzA-0002kw-CW for taps@ietf.org; Thu, 07 Jul 2016 22:33:24 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.101]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bLFz9-0002Gs-PD for taps@ietf.org; Thu, 07 Jul 2016 22:33:24 +0200 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2016 22:33:23 +0200 References: <20160707202533.23753.29062.idtracker@ietfa.amsl.com> To: "taps@ietf.org" Message-Id: <7BDAB63A-BB9D-4C9E-9F35-28DE59762F1B@ifi.uio.no> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 2 sum msgs/h 2 total rcpts 44185 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 249CCE7CA28C33EE77BC5397BE26E90FE0AC375F X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1543 max/h 15 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [Taps] Fwd: New Version Notification for draft-gjessing-taps-minset-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 20:33:29 -0000 FYI. A relatively minor update: still based on the -00 usage draft = (except for a few corrections that will also make it into its -01 = version)=E2=80=A6 But there ARE a few notable changes - e.g. we added some discussion = about implementation possibilities. I do hope that the prospect of = discussing implementations increases the group=E2=80=99s interest in = this document=E2=80=A6 it would be nice to see some discussion of this = before the meeting! Cheers, Michael > Begin forwarded message: >=20 > From: > Subject: New Version Notification for = draft-gjessing-taps-minset-02.txt > Date: 7. juli 2016 kl. 22.25.33 CEST > To: Stein Gjessing , Michael Welzl = > Resent-From: >=20 >=20 > A new version of I-D, draft-gjessing-taps-minset-02.txt > has been successfully submitted by Michael Welzl and posted to the > IETF repository. >=20 > Name: draft-gjessing-taps-minset > Revision: 02 > Title: A Minimal Set of Transport Services for TAPS = Systems > Document date: 2016-07-07 > Group: Individual Submission > Pages: 15 > URL: = https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-02.txt > Status: = https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/ > Htmlized: = https://tools.ietf.org/html/draft-gjessing-taps-minset-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-gjessing-taps-minset-02 >=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 services given in the TAPS document > draft-ietf-taps-transports-usage-00. >=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 From nobody Fri Jul 8 11:10:36 2016 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 D239512D6AE; Fri, 8 Jul 2016 11:10:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708181034.32189.6339.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 11:10:34 -0700 Archived-At: Cc: taps@ietf.org Subject: [Taps] I-D Action: draft-ietf-taps-transports-usage-01.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 18:10:36 -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 Service Features Provided by IETF Transport Protocols Authors : Michael Welzl Michael Tuexen Naeem Khademi Filename : draft-ietf-taps-transports-usage-01.txt Pages : 32 Date : 2016-07-08 Abstract: This document describes how transport protocols expose services to applications and how an application can configure and use the features of a transport service. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-taps-transports-usage-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-01 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 Jul 8 11:15:00 2016 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 D3E3E12D105 for ; Fri, 8 Jul 2016 11:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 nW8Z-6KKxJsX for ; Fri, 8 Jul 2016 11:14:56 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16DBD12D60F for ; Fri, 8 Jul 2016 11:14:44 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bLaIU-0008Ln-Gp for taps@ietf.org; Fri, 08 Jul 2016 20:14:42 +0200 Received: from mail-ex01.exprod.uio.no ([129.240.52.4]) by mail-mx3.uio.no with esmtps (TLSv1.2:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1bLaIU-0003xx-7U for taps@ietf.org; Fri, 08 Jul 2016 20:14:42 +0200 Received: from mail-ex01.exprod.uio.no (2001:700:100:52::4) by mail-ex01.exprod.uio.no (2001:700:100:52::4) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 8 Jul 2016 20:14:40 +0200 Received: from mail-ex01.exprod.uio.no ([fe80::5c5b:6cfb:485b:6990]) by mail-ex01.exprod.uio.no ([fe80::5c5b:6cfb:485b:6990%19]) with mapi id 15.00.1178.000; Fri, 8 Jul 2016 20:14:40 +0200 From: Naeem Khademi To: "taps@ietf.org" Thread-Topic: [Taps] I-D Action: draft-ietf-taps-transports-usage-01.txt Thread-Index: AQHR2UQIoBuQFbkbtE2VCGAua/6bq6AOtSAA Date: Fri, 8 Jul 2016 18:14:40 +0000 Message-ID: <9B662512-A75A-456D-827F-FC4E453D68C6@ifi.uio.no> References: <20160708181034.32189.6339.idtracker@ietfa.amsl.com> In-Reply-To: <20160708181034.32189.6339.idtracker@ietfa.amsl.com> Accept-Language: en-GB, nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [129.240.169.59] Content-Type: text/plain; charset="us-ascii" Content-ID: <6687EE83F63EE344ADC34D7ECA0AAF61@mail.uio.no> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 1 sum msgs/h 1 total rcpts 6011 max rcpts/h 50 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-7.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-2.138, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C8345274B12369B681322A27F7642D183FAED445 X-UiO-SPAM-Test: remote_host: 129.240.52.4 spam_score: -70 maxlevel 80 minaction 2 bait 0 mail/h: 9 total 1629249 max/h 1407 blacklist 0 greylist 0 ratelimit 0 X-UiOonly: D0ADA97ACF4C79BF3DF69A63EC924E8379357813 Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-usage-01.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 18:14:59 -0000 Hi all This update incorporates MPTCP in the draft. The authors would like to than= k Christoph Paasch for his input on this revision. Comments and feedback ar= e welcome.=20 Cheers, Naeem (on behalf of all authors)=20 > On Jul 8, 2016, at 8:10 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Transport Services of the IETF. >=20 > Title : On the Usage of Transport Service Features Provi= ded by IETF Transport Protocols > Authors : Michael Welzl > Michael Tuexen > Naeem Khademi > Filename : draft-ietf-taps-transports-usage-01.txt > Pages : 32 > Date : 2016-07-08 >=20 > Abstract: > This document describes how transport protocols expose services to > applications and how an application can configure and use the > features of a transport service. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-taps-transports-usage-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-usage-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > 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 Jul 8 11:17:13 2016 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 4BF1F12D0A8 for ; Fri, 8 Jul 2016 11:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 2bPBD5jxHLEg for ; Fri, 8 Jul 2016 11:17:10 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3543A127058 for ; Fri, 8 Jul 2016 11:17:10 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bLaKq-000054-Hx for taps@ietf.org; Fri, 08 Jul 2016 20:17:08 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.101]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bLaKp-0000zB-Ut for taps@ietf.org; Fri, 08 Jul 2016 20:17:08 +0200 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jul 2016 20:17:07 +0200 References: <13734f09-4c78-06eb-7201-8f125097a5e8@uclouvain.be> To: "taps@ietf.org" Message-Id: <8C6CAD06-B916-4092-9E95-926B644EC5FA@ifi.uio.no> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 4 sum rcpts/h 6 sum msgs/h 5 total rcpts 44209 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 756227664F2A2BB6041C368549C31F597F046C93 X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 1561 max/h 15 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [Taps] Fwd: [multipathtcp] Socket API for MPTCP X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 18:17:12 -0000 FYI - probably of interest to this group... > Begin forwarded message: >=20 > From: Olivier Bonaventure > Subject: [multipathtcp] Socket API for MPTCP > Date: 8. juli 2016 kl. 17.56.45 CEST > To: multipathtcp , = "" > Resent-From: > Reply-To: Olivier.Bonaventure@uclouvain.be >=20 > Hello, >=20 > During the last years, we have received on a regular basis questions = from users of Multipath TCP on how they could control the utilisation of = the subflows. In the Linux implementation, the default solution was to = tune the path manager, but this is kernel code and few users actually = managed to change this path manager. >=20 > Benjamin Hesmans has spent some time to think about simple extensions = to the socket API to allow applications to control the underlying = Multipath TCP stack. He has implemented his ideas and has running code. = A first draft describing his API has been submitted to the IETF : >=20 >=20 > Title: A socket API to control Multipath TCP > URL: = https://www.ietf.org/internet-drafts/draft-hesmans-mptcp-socket-00.txt >=20 > Abstract: > This document proposes an enhanced socket API to allow applications > to control the operation of a Multipath TCP stack. >=20 > A related paper will also appear at the ANR workshop : >=20 > https://irtf.org/anrw/2016/anrw16-final16.pdf >=20 >=20 > We have requested a slot to present in Berlin. We expect that agreeing = on a common socket API exposed by Multipath TCP implementations would = help its end-to-end deployment. >=20 >=20 > Olivier and Benjamin >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Sun Jul 17 03:31:45 2016 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 8AA5612D56E for ; Sun, 17 Jul 2016 03:31:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160717103144.16912.84787.idtracker@ietfa.amsl.com> Date: Sun, 17 Jul 2016 03:31:44 -0700 From: IETF Secretariat Archived-At: Subject: [Taps] Milestones changed for taps WG X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 10:31:44 -0000 Changed milestone "Submit an Informational document to the IESG defining a set of services provided by IETF transport protocols and congestion control mechanisms", set due date to November 2016 from December 2015, added draft-ietf-taps-transports-usage to milestone. Changed milestone "Submit an Informational document to the IESG recommending a minimal set of Transport Services that end systems should support", set due date to March 2017 from July 2016. Changed milestone "Submit an Experimental document to the IESG specifying one or more methods to provide applications with the Transport Services identified by the WG", set due date to November 2017 from July 2017. Changed milestone "Recharter or conclude.", set due date to March 2018 from November 2017. URL: https://datatracker.ietf.org/wg/taps/charter/ From nobody Sun Jul 17 04:23:01 2016 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 BFABD12D1AC for ; Sun, 17 Jul 2016 04:22:59 -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 S44vx9d5sY00 for ; Sun, 17 Jul 2016 04:22:49 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c: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 54F1812D593 for ; Sun, 17 Jul 2016 04:22:49 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id i5so82528802wmg.0 for ; Sun, 17 Jul 2016 04:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:cc:to:mime-version; bh=AbQhZea7ejwCQzg+yNKW30FfngI+ylxigxnqXinG/W8=; b=GJysn2txzTQTnAwqyIlM+K77qyPbgUdwQe4lkRdjBTYnNr74eoeXL1pUD8JDELrymJ W8OmvG3qvQ92zO+paoX+EpaSywGLWlQ8GLMrqKyQhiMInODZTE7y6I+Y1vlUgDuD8VAI p4uEXeJeI8wqvuRfMRp9FBe4eAMNT8TM0xI3Yhuoud5dZzQTuhVO9sviZz7nKl3Mv5ql MxFXQ/kn20INAgHwSESejbyTEanFzkuaHBDHxc70LlDwGrgIIj+IiIj8eMobVW7cQmri POhN4araEePDg3eNev0s9WL5VvSgOcBUdZVGtfoavx74NA5d7cpbl70U6JYL2YsknxiP anDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=AbQhZea7ejwCQzg+yNKW30FfngI+ylxigxnqXinG/W8=; b=Igchzhk5/M4xK4FziBxN1JW3SoErDzcoxtiJutqt2o1o63LRvqsjhAXXvlo4W1M3xQ kB9/jrDxxFuqCnsPsbTveVgDiPYHVkHQJleMNZSwUIhmQ7KagNMFb7Pnuke6ot8c16kb 9dDlGRLpUdGSQR1Vok6DJeW0xQUXu3eda8tWrIS+W9bp1TynS4WyvkC2Ddva6WWwEt1G 4OqEMsWgMz4fRzhC1qC6iT/Ps3SpjbeBNQj49OCaDif+4y7liLR40xHDUkFj/TWVtr42 mYF+5OlAXW7mhizKms6EAMJiuXtMxgNiyVpsAUzHtu/ilGXIY14qENp7EWqoO9zAxphR zKAg== X-Gm-Message-State: ALyK8tKbIx81Tt3ozlVdxXi2b9tsQry3tBgtDqWIqCYD1/W968Z+8CykLVayRdLhXiWw5w== X-Received: by 10.28.227.11 with SMTP id a11mr31782002wmh.29.1468754566920; Sun, 17 Jul 2016 04:22:46 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:1d2f:3260:5a7c:1a5? ([2001:67c:370:136:1d2f:3260:5a7c:1a5]) by smtp.gmail.com with ESMTPSA id f4sm7444798wmf.8.2016.07.17.04.22.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 17 Jul 2016 04:22:45 -0700 (PDT) From: Aaron Falk Content-Type: multipart/alternative; boundary="Apple-Mail=_E0AD9D9D-562E-46D2-ACEA-EEDCCD45B9B4" Date: Sun, 17 Jul 2016 13:22:45 +0200 Message-Id: <73A3FD28-F2FE-43BB-9789-8F45E5462175@gmail.com> To: taps@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Stephen McQuistin Subject: [Taps] extending the meeting a few minutes to accommodate another talk X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 11:22:59 -0000 --Apple-Mail=_E0AD9D9D-562E-46D2-ACEA-EEDCCD45B9B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Folks- Yesterday there was an interesting talk at the IRTF/ACM Applied = Networking Research Workshop that is relevant to TAPS. Since our slot = is only an hour and our agenda already full, I would like to propose = extending the meeting 10 minutes to accommodate it. We=E2=80=99ll be = eating into the free time before the Bits-and-Bytes social so I don=E2=80=99= t think anyone will miss any scheduled activities but I am aware that = folks sometimes schedule meetings during the breaks. I hope this = doesn=E2=80=99t inconvenience anyone. =20 Here is the abstract of the ANRW talk and the updated agenda: Implementing Real-Time Transport Services over an Ossified Network Stephen McQuistin (University of Glasgow), Colin Perkins (University of = Glasgow), and Marwan Fayed (University of Stirling) Real-time applications require a set of transport services not currently = provided by widely-deployed transport protocols. Ossification prevents = the deployment of novel protocols, restricting solutions to protocols = using either TCP or UDP as a substrate. We describe the transport = services required by real-time applications. We show that, in the = short-term (i.e., while UDP is blocked at current levels), TCP offers a = feasible substrate for providing these services. Over the longer term, = protocols using UDP may reduce the number of networks blocking UDP, = enabling a shift towards its use as a demultiplexing layer for novel = transport protocols. =20 https://irtf.org/anrw/2016/anrw16-final25.pdf=20 Updated TAPS agenda: 1. Chairs update - 5min 2. Update on draft-ietf-taps-transports-usage - 10 min (Naeem Khademi ) = =E2=80=93 updated draft promised by the authors.=20 3. Update on draft-fairhurst-taps-transports-usage-udp - 5 min (Gorry = Fairhurst) =E2=80=93 already updated. 4. Update on draft-gjessing-taps-minset - 10 min (Michael Welzl) - = updated draft promised by the authors.=20 5. Investigation on the use on happy eyeballs for transport protocol = selection - 10 min (Anna Brunstr=C3=B6m) 6. Post socket - 10 min (Brian Trammell) 7. Socket intents - 5 min (Philipp Tiesel)=20 8. Implementing Real-Time Transport Services over an Ossified Network - = 10 miin (Stephen McQuistin) See you Thursday,=20 =E2=80=94aaron --Apple-Mail=_E0AD9D9D-562E-46D2-ACEA-EEDCCD45B9B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Folks-

Yesterday there was an interesting talk at the IRTF/ACM = Applied Networking Research Workshop that is relevant to TAPS. =  Since our slot is only an hour and our agenda already full, I = would like to propose extending the meeting 10 minutes to accommodate = it.  We=E2=80=99ll be eating into the free time before the = Bits-and-Bytes social so I don=E2=80=99t think anyone will miss any = scheduled activities but I am aware that folks sometimes schedule = meetings during the breaks.  I hope this doesn=E2=80=99t = inconvenience anyone.  

Here is the abstract of the ANRW talk = and the updated agenda:

Implementing = Real-Time Transport Services over an Ossified Network

Stephen = McQuistin (University of Glasgow), Colin Perkins (University = of Glasgow), and Marwan Fayed (University of Stirling)

Real-time applications = require a set of transport services not currently provided by = widely-deployed transport protocols. Ossification prevents the = deployment of novel protocols, restricting solutions to protocols = using either TCP or UDP as a substrate. We describe the transport = services required by real-time applications. We show that, in the = short-term (i.e., while UDP is blocked at current levels), TCP = offers a feasible substrate for providing these services. Over the = longer term, protocols using UDP may reduce the number of networks = blocking UDP, enabling a shift towards its use as a demultiplexing = layer for novel transport protocols.  

https://irtf.org/anrw/2016/anrw16-final25.pdf 


Updated TAPS agenda:

1. Chairs = update - 5min

2. Update on = draft-ietf-taps-transports-usage - 10 min (Naeem Khademi ) =E2=80=93 = updated draft promised by the authors. 

3. Update on draft-fairhurst-taps-transports-usage-udp - 5 = min (Gorry Fairhurst) =E2=80=93 already updated.

4. Update on draft-gjessing-taps-minset - 10 min (Michael = Welzl) - updated draft promised by the authors. 

5. Investigation on the use on happy eyeballs for transport = protocol selection - 10 min (Anna Brunstr=C3=B6m)

6. Post socket - 10 min (Brian Trammell)

7. Socket intents - 5 min (Philipp = Tiesel) 

8. Implementing = Real-Time Transport Services over an Ossified Network - 10 miin (Stephen = McQuistin)

See you Thursday, 

=E2=80=94aaron

= --Apple-Mail=_E0AD9D9D-562E-46D2-ACEA-EEDCCD45B9B4-- From nobody Sun Jul 17 04:27:09 2016 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 3D15712D1AC for ; Sun, 17 Jul 2016 04:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-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 loNYBdVPF-fU for ; Sun, 17 Jul 2016 04:27:05 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5C88B126579 for ; Sun, 17 Jul 2016 04:27:05 -0700 (PDT) Received: from dhcp-b49f.meeting.ietf.org (dhcp-b49f.meeting.ietf.org [31.133.180.159]) by trammell.ch (Postfix) with ESMTPSA id D89CA1A19B3; Sun, 17 Jul 2016 13:27:03 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D7B78C58-C9D1-4C15-90A4-9FC813C967AA"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: <73A3FD28-F2FE-43BB-9789-8F45E5462175@gmail.com> Date: Sun, 17 Jul 2016 13:27:02 +0200 Message-Id: <2FA95D67-B0D3-4B92-95FE-F2B0EA8C66F8@trammell.ch> References: <73A3FD28-F2FE-43BB-9789-8F45E5462175@gmail.com> To: Aaron Falk X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Stephen McQuistin , taps@ietf.org Subject: Re: [Taps] extending the meeting a few minutes to accommodate another talk X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 11:27:08 -0000 --Apple-Mail=_D7B78C58-C9D1-4C15-90A4-9FC813C967AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Aaron, > On 17 Jul 2016, at 13:22, Aaron Falk wrote: >=20 > Hi Folks- >=20 > Yesterday there was an interesting talk at the IRTF/ACM Applied = Networking Research Workshop that is relevant to TAPS. Since our slot = is only an hour and our agenda already full, I would like to propose = extending the meeting 10 minutes to accommodate it. We=E2=80=99ll be = eating into the free time before the Bits-and-Bytes social so I don=E2=80=99= t think anyone will miss any scheduled activities but I am aware that = folks sometimes schedule meetings during the breaks. I hope this = doesn=E2=80=99t inconvenience anyone. >=20 > Here is the abstract of the ANRW talk and the updated agenda: >=20 > Implementing Real-Time Transport Services over an Ossified Network >=20 > Stephen McQuistin (University of Glasgow), Colin Perkins (University = of Glasgow), and Marwan Fayed (University of Stirling) >=20 > Real-time applications require a set of transport services not = currently provided by widely-deployed transport protocols. Ossification = prevents the deployment of novel protocols, restricting solutions to = protocols using either TCP or UDP as a substrate. We describe the = transport services required by real-time applications. We show that, in = the short-term (i.e., while UDP is blocked at current levels), TCP = offers a feasible substrate for providing these services. Over the = longer term, protocols using UDP may reduce the number of networks = blocking UDP, enabling a shift towards its use as a demultiplexing layer = for novel transport protocols. >=20 > https://irtf.org/anrw/2016/anrw16-final25.pdf >=20 >=20 > Updated TAPS agenda: >=20 > 1. Chairs update - 5min >=20 > 2. Update on draft-ietf-taps-transports-usage - 10 min (Naeem Khademi = ) =E2=80=93 updated draft promised by the authors. >=20 > 3. Update on draft-fairhurst-taps-transports-usage-udp - 5 min (Gorry = Fairhurst) =E2=80=93 already updated. >=20 > 4. Update on draft-gjessing-taps-minset - 10 min (Michael Welzl) - = updated draft promised by the authors. >=20 > 5. Investigation on the use on happy eyeballs for transport protocol = selection - 10 min (Anna Brunstr=C3=B6m) >=20 > 6. Post socket - 10 min (Brian Trammell) I can do these as a lightning talk to make this go faster. So, s/10 = min/5 min/.. Cheers, Brian > 7. Socket intents - 5 min (Philipp Tiesel) >=20 > 8. Implementing Real-Time Transport Services over an Ossified Network = - 10 miin (Stephen McQuistin) >=20 > See you Thursday, >=20 > =E2=80=94aaron >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_D7B78C58-C9D1-4C15-90A4-9FC813C967AA 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 iQIcBAEBCgAGBQJXi2uHAAoJEIoSt78L6kajW6QP/0XaWxGyCOUS/5RyzeQY5Gjt TFPp5Hdy5SZWmR/PvN1yLgHJSSFx8vPd8iOUOu5Spf8RtCdYMo3RGi95zsHXm5EA FJzYbSsb24YZ9v+RZ5WcXP7PLYKILgIgsA6nlXfL0AugFMX7U6/9mfg8qVhqOMM+ 25VTJ+65Ds5J2uyxVh+ApNrHZuI6lQ1j51WYh2kle/Xv31Pi7WkOrtXR0iizKuUT rSCiFycpSVcnn61KrA0UaK9dH+LGEsY4dv0t0qM3oOu4+yBVhEXa1ZgNdlAXXbfv SDzs5LZ14SO2T66JFv2n6b5hxzur3LtXgyVI+RiUs12kgNabWRDBGSYoqtP6sYF7 lN/0noCJKHiB7zHSVtrKaTXyq73rnWaKa4+dxGdOT89ZlHzKtP5MFjCYFT/NskJk QVHZXBX31zT6VdIsJRDa9S+ZUGzybH03RI0Oz4cOjlwSscf57bbHn4JAn5YaOxPE AZ1wJlVw6zVbOh84tMIVMhrw4h1wUv7U+Xsn2djrYXIxzobtweKx3fTkoaIjE5wP 4nT+mEAO6c99zcEaFNiipK6icQjrF/NkMHQN2SOY09rdWgLlTwE+jnauaViNxa3u wBHuvqDbvFXQO34Ar5EiA2AVOn5ULqx501M1suwcv01kvQKKpGjZITilmRoFAoA2 j1QihCZ14H1N5OAg4Qrm =JsVz -----END PGP SIGNATURE----- --Apple-Mail=_D7B78C58-C9D1-4C15-90A4-9FC813C967AA-- From nobody Sun Jul 17 04:29:08 2016 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 2241A12D1AC for ; Sun, 17 Jul 2016 04:29:05 -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 n8Dv21Y7W1H5 for ; Sun, 17 Jul 2016 04:29:02 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 5B996126579 for ; Sun, 17 Jul 2016 04:29:02 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id f65so73370836wmi.0 for ; Sun, 17 Jul 2016 04:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=eQzcqf6DtRqjke4hKOmAH2Fh/YGCWXQ2pBjMQpvW6K4=; b=VhCDOMZaZ/vs7HdsSEHBw6PNXIynZCgRY4ythHSsT/K9iwDwadBqVU5b9+9STOsUNP Y242uHlN8fol4nB4iz1CH4K/Ys2vgVKE+/vDiiYvx1rg1CX0w45WbdLQypnF008uOg/w A4sdVzHuawOUTne3rFm/rM3oIMjbFn1v/QHjfjmGQdqu2hBUB4f03OSoYluRW42JGNmF gh0ctHtM7dOf4pRelqm50EWLxu7Hj+ye1WM8WWF9wznUAj1LIJJwrXzspVaD08XKaIoG tAzgB+yejApo0AdiDfRVykNMhTzNcW0YlisTh1IcuM2w4KgApEFjkFkjsfhSbS0R1nbP Q+IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=eQzcqf6DtRqjke4hKOmAH2Fh/YGCWXQ2pBjMQpvW6K4=; b=cwGI4JKUibTAefg2fxVrF+aEGnjsKRC208Pr76t+eYrVNQ0A40LKaV7Qai3LDll+VN 74rG+2U/73am96u9ucvTX3EjH2uzgMonqVAeGtEEo2DyoMeF/adv/aO4jcQ9LOUNdcNY vruTF9x8JpyKq414zKOABhBnXNgByUY5f8pFjIXRPHyFnUdgxM+HK5a+602zSN47a1zU 0nYuK0z80PvGS6Ghoj+pQz5QUR5ykNfSoP0Uv5EUHAG+lCs7R0BT8g6w85vkHGbTVA3h a/DJ9C+CfBrDHr8HUZDzYjbHLcirNAtWwKdly3MexZgepnDsT0gcomxb7pGguv2r30Me QDnw== X-Gm-Message-State: ALyK8tIg2d4K/tkwbxekNOmz6O5ix+MXX0nIX2Qk55MAlzmHHCLle0j0MSs+V13LQFPNxQ== X-Received: by 10.28.182.136 with SMTP id g130mr29293244wmf.21.1468754940892; Sun, 17 Jul 2016 04:29:00 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:1d2f:3260:5a7c:1a5? ([2001:67c:370:136:1d2f:3260:5a7c:1a5]) by smtp.gmail.com with ESMTPSA id p23sm4646833wme.8.2016.07.17.04.29.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 17 Jul 2016 04:29:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DE3C9CA1-DCD2-4A19-A8E7-048CA9E767A7" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Aaron Falk In-Reply-To: <2FA95D67-B0D3-4B92-95FE-F2B0EA8C66F8@trammell.ch> Date: Sun, 17 Jul 2016 13:28:59 +0200 Message-Id: References: <73A3FD28-F2FE-43BB-9789-8F45E5462175@gmail.com> <2FA95D67-B0D3-4B92-95FE-F2B0EA8C66F8@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Stephen McQuistin , taps@ietf.org Subject: Re: [Taps] extending the meeting a few minutes to accommodate another talk X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 11:29:05 -0000 --Apple-Mail=_DE3C9CA1-DCD2-4A19-A8E7-048CA9E767A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OK but information is lost with excessive compression. So, no heroics. = :) =E2=80=94aaron > On Jul 17, 2016, at 1:27 PM, Brian Trammell wrote: >=20 > hi Aaron, >=20 >> On 17 Jul 2016, at 13:22, Aaron Falk wrote: >>=20 >> Hi Folks- >>=20 >> Yesterday there was an interesting talk at the IRTF/ACM Applied = Networking Research Workshop that is relevant to TAPS. Since our slot = is only an hour and our agenda already full, I would like to propose = extending the meeting 10 minutes to accommodate it. We=E2=80=99ll be = eating into the free time before the Bits-and-Bytes social so I don=E2=80=99= t think anyone will miss any scheduled activities but I am aware that = folks sometimes schedule meetings during the breaks. I hope this = doesn=E2=80=99t inconvenience anyone. >>=20 >> Here is the abstract of the ANRW talk and the updated agenda: >>=20 >> Implementing Real-Time Transport Services over an Ossified Network >>=20 >> Stephen McQuistin (University of Glasgow), Colin Perkins (University = of Glasgow), and Marwan Fayed (University of Stirling) >>=20 >> Real-time applications require a set of transport services not = currently provided by widely-deployed transport protocols. Ossification = prevents the deployment of novel protocols, restricting solutions to = protocols using either TCP or UDP as a substrate. We describe the = transport services required by real-time applications. We show that, in = the short-term (i.e., while UDP is blocked at current levels), TCP = offers a feasible substrate for providing these services. Over the = longer term, protocols using UDP may reduce the number of networks = blocking UDP, enabling a shift towards its use as a demultiplexing layer = for novel transport protocols. >>=20 >> https://irtf.org/anrw/2016/anrw16-final25.pdf >>=20 >>=20 >> Updated TAPS agenda: >>=20 >> 1. Chairs update - 5min >>=20 >> 2. Update on draft-ietf-taps-transports-usage - 10 min (Naeem Khademi = ) =E2=80=93 updated draft promised by the authors. >>=20 >> 3. Update on draft-fairhurst-taps-transports-usage-udp - 5 min (Gorry = Fairhurst) =E2=80=93 already updated. >>=20 >> 4. Update on draft-gjessing-taps-minset - 10 min (Michael Welzl) - = updated draft promised by the authors. >>=20 >> 5. Investigation on the use on happy eyeballs for transport protocol = selection - 10 min (Anna Brunstr=C3=B6m) >>=20 >> 6. Post socket - 10 min (Brian Trammell) >=20 > I can do these as a lightning talk to make this go faster. So, s/10 = min/5 min/.. >=20 > Cheers, >=20 > Brian >=20 >=20 >> 7. Socket intents - 5 min (Philipp Tiesel) >>=20 >> 8. Implementing Real-Time Transport Services over an Ossified Network = - 10 miin (Stephen McQuistin) >>=20 >> See you Thursday, >>=20 >> =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 = --Apple-Mail=_DE3C9CA1-DCD2-4A19-A8E7-048CA9E767A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OK but information is lost with excessive compression. =  So, no heroics.  :)

=E2=80=94aaron

On = Jul 17, 2016, at 1:27 PM, Brian Trammell <ietf@trammell.ch> = wrote:

hi Aaron,

On 17 Jul 2016, at 13:22, Aaron Falk <aaron.falk@gmail.com> wrote:

Hi Folks-

Yesterday there was an = interesting talk at the IRTF/ACM Applied Networking Research Workshop = that is relevant to TAPS.  Since our slot is only an hour and our = agenda already full, I would like to propose extending the meeting 10 = minutes to accommodate it.  We=E2=80=99ll be eating into the free = time before the Bits-and-Bytes social so I don=E2=80=99t think anyone = will miss any scheduled activities but I am aware that folks sometimes = schedule meetings during the breaks. I hope this doesn=E2=80=99t = inconvenience anyone.

Here is the abstract = of the ANRW talk and the updated agenda:

Implementing Real-Time Transport Services over an Ossified = Network

Stephen McQuistin (University of = Glasgow), Colin Perkins (University of Glasgow), and Marwan Fayed = (University of Stirling)

Real-time = applications require a set of transport services not currently provided = by widely-deployed transport protocols. Ossification prevents the = deployment of novel protocols, restricting solutions to protocols using = either TCP or UDP as a substrate. We describe the transport services = required by real-time applications. We show that, in the short-term = (i.e., while UDP is blocked at current levels), TCP offers a feasible = substrate for providing these services. Over the longer term, protocols = using UDP may reduce the number of networks blocking UDP, enabling a = shift towards its use as a demultiplexing layer for novel transport = protocols.

https://irtf.org/anrw/2016/anrw16-final25.pdf


Updated TAPS agenda:

1. Chairs update - 5min

2. Update on draft-ietf-taps-transports-usage - 10 min (Naeem = Khademi ) =E2=80=93 updated draft promised by the authors.

3. Update on = draft-fairhurst-taps-transports-usage-udp - 5 min (Gorry Fairhurst) =E2=80= =93 already updated.

4. Update on = draft-gjessing-taps-minset - 10 min (Michael Welzl) - updated draft = promised by the authors.

5. Investigation = on the use on happy eyeballs for transport protocol selection - 10 min = (Anna Brunstr=C3=B6m)

6. Post socket - 10 = min (Brian Trammell)

I can do these as a lightning = talk to make this go faster. So, s/10 min/5 min/..

Cheers,

Brian


7. Socket intents - 5 min (Philipp Tiesel)

8. Implementing Real-Time Transport Services = over an Ossified Network - 10 miin (Stephen McQuistin)

See you Thursday,

=E2=80=94aaron
_______________________________________________
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=_DE3C9CA1-DCD2-4A19-A8E7-048CA9E767A7-- From nobody Sun Jul 17 04:31:16 2016 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 7E38E126579 for ; Sun, 17 Jul 2016 04:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-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 pBwvvXmuIk9k for ; Sun, 17 Jul 2016 04:31:13 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id D0DEB12B031 for ; Sun, 17 Jul 2016 04:31:12 -0700 (PDT) Received: from dhcp-b49f.meeting.ietf.org (dhcp-b49f.meeting.ietf.org [31.133.180.159]) by trammell.ch (Postfix) with ESMTPSA id 9DDB61A04CD; Sun, 17 Jul 2016 13:31:11 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D6EAEEAD-ED32-4EBC-92CA-394E3AA0FEB8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Sun, 17 Jul 2016 13:31:11 +0200 Message-Id: <39E21339-EBB0-4552-8D2D-7F82CC068122@trammell.ch> References: <73A3FD28-F2FE-43BB-9789-8F45E5462175@gmail.com> <2FA95D67-B0D3-4B92-95FE-F2B0EA8C66F8@trammell.ch> To: Aaron Falk X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Stephen McQuistin , taps@ietf.org Subject: Re: [Taps] extending the meeting a few minutes to accommodate another talk X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 11:31:15 -0000 --Apple-Mail=_D6EAEEAD-ED32-4EBC-92CA-394E3AA0FEB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 Jul 2016, at 13:28, Aaron Falk wrote: >=20 > OK but information is lost with excessive compression. So, no = heroics. :) It'll be a lightning talk in the sense of "it's an ad to read the rest = of the slides, and come talk to us if you have questions". Cheers, Brian >=20 > =E2=80=94aaron >=20 >> On Jul 17, 2016, at 1:27 PM, Brian Trammell wrote: >>=20 >> hi Aaron, >>=20 >>> On 17 Jul 2016, at 13:22, Aaron Falk wrote: >>>=20 >>> Hi Folks- >>>=20 >>> Yesterday there was an interesting talk at the IRTF/ACM Applied = Networking Research Workshop that is relevant to TAPS. Since our slot = is only an hour and our agenda already full, I would like to propose = extending the meeting 10 minutes to accommodate it. We=E2=80=99ll be = eating into the free time before the Bits-and-Bytes social so I don=E2=80=99= t think anyone will miss any scheduled activities but I am aware that = folks sometimes schedule meetings during the breaks. I hope this = doesn=E2=80=99t inconvenience anyone. >>>=20 >>> Here is the abstract of the ANRW talk and the updated agenda: >>>=20 >>> Implementing Real-Time Transport Services over an Ossified Network >>>=20 >>> Stephen McQuistin (University of Glasgow), Colin Perkins (University = of Glasgow), and Marwan Fayed (University of Stirling) >>>=20 >>> Real-time applications require a set of transport services not = currently provided by widely-deployed transport protocols. Ossification = prevents the deployment of novel protocols, restricting solutions to = protocols using either TCP or UDP as a substrate. We describe the = transport services required by real-time applications. We show that, in = the short-term (i.e., while UDP is blocked at current levels), TCP = offers a feasible substrate for providing these services. Over the = longer term, protocols using UDP may reduce the number of networks = blocking UDP, enabling a shift towards its use as a demultiplexing layer = for novel transport protocols. >>>=20 >>> https://irtf.org/anrw/2016/anrw16-final25.pdf >>>=20 >>>=20 >>> Updated TAPS agenda: >>>=20 >>> 1. Chairs update - 5min >>>=20 >>> 2. Update on draft-ietf-taps-transports-usage - 10 min (Naeem = Khademi ) =E2=80=93 updated draft promised by the authors. >>>=20 >>> 3. Update on draft-fairhurst-taps-transports-usage-udp - 5 min = (Gorry Fairhurst) =E2=80=93 already updated. >>>=20 >>> 4. Update on draft-gjessing-taps-minset - 10 min (Michael Welzl) - = updated draft promised by the authors. >>>=20 >>> 5. Investigation on the use on happy eyeballs for transport protocol = selection - 10 min (Anna Brunstr=C3=B6m) >>>=20 >>> 6. Post socket - 10 min (Brian Trammell) >>=20 >> I can do these as a lightning talk to make this go faster. So, s/10 = min/5 min/.. >>=20 >> Cheers, >>=20 >> Brian >>=20 >>=20 >>> 7. Socket intents - 5 min (Philipp Tiesel) >>>=20 >>> 8. Implementing Real-Time Transport Services over an Ossified = Network - 10 miin (Stephen McQuistin) >>>=20 >>> See you Thursday, >>>=20 >>> =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=_D6EAEEAD-ED32-4EBC-92CA-394E3AA0FEB8 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 iQIcBAEBCgAGBQJXi2x/AAoJEIoSt78L6kajaZsP/0CA2VBCaLwtyNUypTP7mfao i9zwU2vLbvBeiETcd0WXcfElDYa8pL9EEl+5AnMTki/4dEya4WYXcA0Ug7ht1JRG GpA9piJ+X3EAAfeAMfR+ZhP/s4TOue0+HE5n19JIvHBNchTJHr7fOqo/XFQoqsre H7O8iohI+GU+RkMf1FztC6ATf2hFKK/7NtOywpY1xZePNtmtijxCrRSJWdPRpUVo CfUzpSB8QNdky6hN9UxUaT4ZOC8buhcMKTzGU6COeBE5xtow2BYHcMIdhs8L+gNE eWNGCeUZ7PI6E4JaWKah3JGURfKp0q4CSaL+e4ke/i4c+yY7rvXYoCRqkeuXDXw3 KiutYonM7GiTzrskfCjVAvEg+4j79NfSLZEPml5qHu6tvyMQZXA3D0dlhVEvrrmN 6M0t5ijLykq5pzzd2BcZn/UlxIHC2ab61VRGDtgBUhuKWSRv0Uuo5LbOSsldt0qf ukAxwRlc7E6w1nwNF8R1FGtLo50XY9mecbfvF1Pzk36Wqxhrtm0rauvsa86e1HKw QGDQPaEkAQNnQhA1FWLa4pBfflbHsaCtFrUNyIcF7txm9j9cO1f/8GQjP3N7K7N4 GuznbPnObl+01fVbSc1aqHi/DHoIlkoo4UhzJTSmJ7aH8X4O74Mh1aRj3IMMtKhh 7IFD1Nz4hdByd4ZcuLB/ =/kI1 -----END PGP SIGNATURE----- --Apple-Mail=_D6EAEEAD-ED32-4EBC-92CA-394E3AA0FEB8-- From nobody Sun Jul 17 04:55:28 2016 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 AD46212B013 for ; Sun, 17 Jul 2016 04:55:26 -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 zZf5Zs2Mjjd1 for ; Sun, 17 Jul 2016 04:55:24 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 2AC30127058 for ; Sun, 17 Jul 2016 04:55:24 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id y188so6167202ywf.0 for ; Sun, 17 Jul 2016 04:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kzI9kvlU7KR20taeqWr47MIh4mQxbg33kaXgo5OpPeU=; b=EwHcF2aUIvGu6NdQx0QZPJ9zplzEUwsWHhgbalZ9Fr1PKEmFrAbcNe2N1HktURvj7/ 5yzVa34s+DBbFMAEosQppyv0cMuHJrUvyHpEEkCcbje2grS9gG+xjLKxk4tqZQicP5xX 6f+APESzbbsUe1343wxbQC4+P+ADZqRFW3AIxXFWLaBsf9EfdOd6utOqpX1gOrl13vrF 5xfW64Vmm5gdJT0CvZ5j7hjp28oGckzP8WeCItLK2l+PEYEwRcrW31wDqvFuypKsaz0c zKBd4kfNh54mWzbpk1IBvuHrvapJjtjj3eTxfqCNcANb+0/2uuWW+apMwxcSYDzAx9T7 aLRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kzI9kvlU7KR20taeqWr47MIh4mQxbg33kaXgo5OpPeU=; b=N3U2JOptulTywYBhqRxsaSW9Hw1LkCF8ufRghXkVIj/kzVqIebH33kV8oWiqdIVUjS JKml08vtblAT+TqZrV/gsgiR4/EOw5UHHVSioIsyCejSFL8vTwDC3a7Z56POnYitNbRK epETu5kFxej30k+2Dp0MAOJlNVqOu8yjDdtAqRyXEdOy91aUSqH5hTYb+EGeesyINN51 i2b4g3NDXN3N6H/1LZGVvksprh9v6TwAlRxOrOAdbLrViaSnIaeE9xBn3MgVszEphD8b Qzxj9Mh0AfxXmP5SyoR5J2H6lLcoYS/m5NdcMRbijoxxAf909XTTvmpqvC4lxmG6cEda jieg== X-Gm-Message-State: ALyK8tKCVHEA6yPkb6l2xzAIyr7UZz4WDn4utPm6QlnsOH619mpuMnfj3xfP4xH0B7IkXiclKHOIFEk/vyGv7Q== X-Received: by 10.129.105.136 with SMTP id e130mr19367317ywc.176.1468756523381; Sun, 17 Jul 2016 04:55:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.231.20 with HTTP; Sun, 17 Jul 2016 04:55:22 -0700 (PDT) In-Reply-To: <39E21339-EBB0-4552-8D2D-7F82CC068122@trammell.ch> References: <73A3FD28-F2FE-43BB-9789-8F45E5462175@gmail.com> <2FA95D67-B0D3-4B92-95FE-F2B0EA8C66F8@trammell.ch> <39E21339-EBB0-4552-8D2D-7F82CC068122@trammell.ch> From: Spencer Dawkins at IETF Date: Sun, 17 Jul 2016 13:55:22 +0200 Message-ID: To: Brian Trammell Content-Type: multipart/alternative; boundary=001a114715eed6974a0537d38677 Archived-At: Cc: Aaron Falk , Stephen McQuistin , "taps@ietf.org" Subject: Re: [Taps] extending the meeting a few minutes to accommodate another talk X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 11:55:27 -0000 --001a114715eed6974a0537d38677 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Aaron, On Sun, Jul 17, 2016 at 1:31 PM, Brian Trammell wrote: > > > On 17 Jul 2016, at 13:28, Aaron Falk wrote: > > > > OK but information is lost with excessive compression. So, no heroics. > :) > > It'll be a lightning talk in the sense of "it's an ad to read the rest of > the slides, and come talk to us if you have questions". > > Cheers, > > Brian > > > > > =E2=80=94aaron > > > >> On Jul 17, 2016, at 1:27 PM, Brian Trammell wrote: > >> > >> hi Aaron, > >> > >>> On 17 Jul 2016, at 13:22, Aaron Falk wrote: > >>> > >>> Hi Folks- > >>> > >>> Yesterday there was an interesting talk at the IRTF/ACM Applied > Networking Research Workshop that is relevant to TAPS. Since our slot is > only an hour and our agenda already full, I would like to propose extendi= ng > the meeting 10 minutes to accommodate it. We=E2=80=99ll be eating into t= he free > time before the Bits-and-Bytes social so I don=E2=80=99t think anyone wil= l miss any > scheduled activities but I am aware that folks sometimes schedule meeting= s > during the breaks. I hope this doesn=E2=80=99t inconvenience anyone. > Could you chat with the folks at MEETECHO and ask them not to cut off recording when your slot ends on the agenda? Thanks, Spencer > >>> Here is the abstract of the ANRW talk and the updated agenda: > >>> > >>> Implementing Real-Time Transport Services over an Ossified Network > >>> > >>> Stephen McQuistin (University of Glasgow), Colin Perkins (University > of Glasgow), and Marwan Fayed (University of Stirling) > >>> > >>> Real-time applications require a set of transport services not > currently provided by widely-deployed transport protocols. Ossification > prevents the deployment of novel protocols, restricting solutions to > protocols using either TCP or UDP as a substrate. We describe the transpo= rt > services required by real-time applications. We show that, in the > short-term (i.e., while UDP is blocked at current levels), TCP offers a > feasible substrate for providing these services. Over the longer term, > protocols using UDP may reduce the number of networks blocking UDP, > enabling a shift towards its use as a demultiplexing layer for novel > transport protocols. > >>> > >>> https://irtf.org/anrw/2016/anrw16-final25.pdf > >>> > >>> > >>> Updated TAPS agenda: > >>> > >>> 1. Chairs update - 5min > >>> > >>> 2. Update on draft-ietf-taps-transports-usage - 10 min (Naeem Khademi > ) =E2=80=93 updated draft promised by the authors. > >>> > >>> 3. Update on draft-fairhurst-taps-transports-usage-udp - 5 min (Gorry > Fairhurst) =E2=80=93 already updated. > >>> > >>> 4. Update on draft-gjessing-taps-minset - 10 min (Michael Welzl) - > updated draft promised by the authors. > >>> > >>> 5. Investigation on the use on happy eyeballs for transport protocol > selection - 10 min (Anna Brunstr=C3=B6m) > >>> > >>> 6. Post socket - 10 min (Brian Trammell) > >> > >> I can do these as a lightning talk to make this go faster. So, s/10 > min/5 min/.. > >> > >> Cheers, > >> > >> Brian > >> > >> > >>> 7. Socket intents - 5 min (Philipp Tiesel) > >>> > >>> 8. Implementing Real-Time Transport Services over an Ossified Network > - 10 miin (Stephen McQuistin) > >>> > >>> See you Thursday, > >>> > >>> =E2=80=94aaron > >>> > >>> _______________________________________________ > >>> Taps mailing list > >>> Taps@ietf.org > >>> https://www.ietf.org/mailman/listinfo/taps > >> > >> _______________________________________________ > >> Taps mailing list > >> Taps@ietf.org > >> https://www.ietf.org/mailman/listinfo/taps > > > > _______________________________________________ > > Taps mailing list > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > > --001a114715eed6974a0537d38677 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Aaron,

On Sun, Jul 17, 2016 at 1:31 PM, Brian Trammell <ietf@trammell.ch= > wrote:
<= br> > On 17 Jul 2016, at 13:28, Aaron Falk <aaron.falk@gmail.com> wrote:
>
> OK but information is lost with excessive compression.=C2=A0 So, no he= roics.=C2=A0 :)

It'll be a lightning talk in the sense of "it's an ad t= o read the rest of the slides, and come talk to us if you have questions&qu= ot;.

Cheers,

Brian

>
> =E2=80=94aaron
>
>> On Jul 17, 2016, at 1:27 PM, Brian Trammell <ietf@trammell.ch> wrote:
>>
>> hi Aaron,
>>
>>> On 17 Jul 2016, at 13:22, Aaron Falk <aaron.falk@gmail.com> wrote:
>>>
>>> Hi Folks-
>>>
>>> Yesterday there was an interesting talk at the IRTF/ACM Applie= d Networking Research Workshop that is relevant to TAPS.=C2=A0 Since our sl= ot is only an hour and our agenda already full, I would like to propose ext= ending the meeting 10 minutes to accommodate it.=C2=A0 We=E2=80=99ll be eat= ing into the free time before the Bits-and-Bytes social so I don=E2=80=99t = think anyone will miss any scheduled activities but I am aware that folks s= ometimes schedule meetings during the breaks. I hope this doesn=E2=80=99t i= nconvenience anyone.

Could = you chat with the folks at MEETECHO and ask them not to cut off recording w= hen your slot ends on the agenda?

Thanks,

Spencer
=C2=A0
>>> Here is the abstract of the ANRW talk and the updated agenda:<= br> >>>
>>> Implementing Real-Time Transport Services over an Ossified Net= work
>>>
>>> Stephen McQuistin (University of Glasgow), Colin Perkins (Univ= ersity of Glasgow), and Marwan Fayed (University of Stirling)
>>>
>>> Real-time applications require a set of transport services not= currently provided by widely-deployed transport protocols. Ossification pr= events the deployment of novel protocols, restricting solutions to protocol= s using either TCP or UDP as a substrate. We describe the transport service= s required by real-time applications. We show that, in the short-term (i.e.= , while UDP is blocked at current levels), TCP offers a feasible substrate = for providing these services. Over the longer term, protocols using UDP may= reduce the number of networks blocking UDP, enabling a shift towards its u= se as a demultiplexing layer for novel transport protocols.
>>>
>>> https://irtf.org/anrw/2016/anrw16-final25= .pdf
>>>
>>>
>>> Updated TAPS agenda:
>>>
>>> 1. Chairs update - 5min
>>>
>>> 2. Update on draft-ietf-taps-transports-usage - 10 min (Naeem = Khademi ) =E2=80=93 updated draft promised by the authors.
>>>
>>> 3. Update on draft-fairhurst-taps-transports-usage-udp - 5 min= (Gorry Fairhurst) =E2=80=93 already updated.
>>>
>>> 4. Update on draft-gjessing-taps-minset - 10 min (Michael Welz= l) - updated draft promised by the authors.
>>>
>>> 5. Investigation on the use on happy eyeballs for transport pr= otocol selection - 10 min (Anna Brunstr=C3=B6m)
>>>
>>> 6. Post socket - 10 min (Brian Trammell)
>>
>> I can do these as a lightning talk to make this go faster. So, s/1= 0 min/5 min/..
>>
>> Cheers,
>>
>> Brian
>>
>>
>>> 7. Socket intents - 5 min (Philipp Tiesel)
>>>
>>> 8. Implementing Real-Time Transport Services over an Ossified = Network - 10 miin (Stephen McQuistin)
>>>
>>> See you Thursday,
>>>
>>> =E2=80=94aaron
>>>
>>> _______________________________________________
>>> Taps mailing list
>>> Taps@ietf.org
>>> https://www.ietf.org/mailman/listinfo/taps
>>
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps >
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps


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


--001a114715eed6974a0537d38677-- From nobody Mon Jul 18 00:22:58 2016 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 5672212D14D for ; Mon, 18 Jul 2016 00:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 8c6Xhr5pZVTo for ; Mon, 18 Jul 2016 00:22:54 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23A812D0D3 for ; Mon, 18 Jul 2016 00:22:53 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bP2t9-0005Fy-SL for taps@ietf.org; Mon, 18 Jul 2016 09:22:51 +0200 Received: from w3prod-wm04.uio.no ([129.240.15.71] helo=webmail.uio.no) by mail-mx1.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.80) (envelope-from ) id 1bP2t9-0006ST-Bv for taps@ietf.org; Mon, 18 Jul 2016 09:22:51 +0200 Received: from [46.189.28.92] by webmail.uio.no with HTTP (HTTP/1.1 POST); Mon, 18 Jul 2016 09:22:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 18 Jul 2016 09:22:51 +0200 From: Michael Welzl To: taps@ietf.org Message-ID: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> X-Sender: michawe@ifi.uio.no User-Agent: Roundcube Webmail/xbXItLeZa6o/uio-1.1.2 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 6 sum msgs/h 4 total rcpts 44567 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-7.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-2.138, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 819B28127CB51AC7B6158D981100CDD1E6370B86 X-UiO-SPAM-Test: remote_host: 129.240.15.71 spam_score: -70 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 47158 max/h 180 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [Taps] Abstracting away multi-streaming and usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 07:22:56 -0000 Hi, draft-gjessing-taps-minset-02 suggests that all transport service features related to multi-streaming and usage of multiple paths are “automatable”. The rationale is given in Section 4: https://tools.ietf.org/html/draft-gjessing-taps-minset-02#section-4 (this particular section says “removed” which is a mistake, to be fixed in the next update; sorry! - read as “classified as automatable”) Note that abstraction always comes with loss of some control, that’s inevitable. It has to hurt a little bit :-) - our thinking is that none of these transport service features require application-specific knowledge and hence shouldn’t be exposed. Thoughts? Cheers, Michael From nobody Tue Jul 19 00:49:52 2016 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 6AC3112D0B8 for ; Tue, 19 Jul 2016 00:49:50 -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 017xrOpc8v3c for ; Tue, 19 Jul 2016 00:49:48 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 49BC712D099 for ; Tue, 19 Jul 2016 00:49:48 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id w127so13737610vkh.2 for ; Tue, 19 Jul 2016 00:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HTw8yPHTYfRuOlPeM6JNr9y1mMFq39EeJAbBEPlhKOw=; b=mAq4cZLbtEWGZW64PTE4A629aFtFxlJnHDYfcThAkWAFN2ZbQukorLYPTUaX5ZWd6C GZzQvsrETJgH4UQuhjouwT3cg2WaayhMri4H7a2lvXhfnnxx6iRp7rwUmfZHztUJNibL XWZAhoUbfSOr9qox1i/cluQYJrhr/1A68R0yKlvVEvSMCdo+85Ar5ZO2OhzNqOcoJ1aw Xvg3B+UILbdIO+tpZdz4wUWGlv0ed9ivYQypj+iVgm5I/nSl09K6TOUFN8EvMGNoSdSr XmB4OWgn2odrGRXg8iiErdUd3XPOdnPksoMgCY/xuwlW6b0J9N3WDrOvxhZzQIwzEdhB L0SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HTw8yPHTYfRuOlPeM6JNr9y1mMFq39EeJAbBEPlhKOw=; b=NTdFd6OeHHAEm12zZLojUePuRof4hbyi8oWnIqpXe3tWABCXxcvp+ZuBNgij5MJ5L3 3zzkuSHIx0qpMyKfqyj33SJ/gIVbiq8k3eu9I2Cper4l0a5jmIg8KnMcVZ4v8JOeSJmp JIhwtctJNtJfI/LbgSZovlxzU58+sOkQAujCD/KRbqJrLDbjDL19AjQ+YHyvGOja5CNE x/2+QSFtZmEPrPZqOGpjZpo0oBOSjK9f/pWmCIgrhRLfEtV9iGiwqDzUh1yawXlzihyY g6QpVmB+PpNQvWf26X3G6TjYPIwyHYy6V3+GETP1KWv643j/trAK+BIv+gMwH34oAx5o 6Okg== X-Gm-Message-State: ALyK8tLsf7fN9i8a8GV87l0kc8pvipr7aUQvNywqA6i247hWOA6QvMCFFuJOf+Cp0s+XUmGN2bSFqy916WhPrQ== X-Received: by 10.31.167.129 with SMTP id q123mr20431374vke.155.1468914587429; Tue, 19 Jul 2016 00:49:47 -0700 (PDT) MIME-Version: 1.0 References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> In-Reply-To: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> From: Aaron Falk Date: Tue, 19 Jul 2016 07:49:38 +0000 Message-ID: To: Michael Welzl , taps@ietf.org Content-Type: multipart/alternative; boundary=001a1142595a30700d0537f85460 Archived-At: Subject: Re: [Taps] Abstracting away multi-streaming and usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 07:49:50 -0000 --001a1142595a30700d0537f85460 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Michael- It seems to me that one could answer the question separately whether the upper layer should be able to control the use of multi-streaming or multi-paths vs. know whether multi-streaming or multi-paths are in use. I would think that there no reason to hide this information from apps. would you agree? --aaron On Mon, Jul 18, 2016 at 9:22 AM Michael Welzl wrote: > Hi, > > draft-gjessing-taps-minset-02 suggests that all transport service > features related to multi-streaming and usage of multiple paths are > =E2=80=9Cautomatable=E2=80=9D. The rationale is given in Section 4: > https://tools.ietf.org/html/draft-gjessing-taps-minset-02#section-4 > (this particular section says =E2=80=9Cremoved=E2=80=9D which is a mistak= e, to be fixed > in the next update; sorry! - read as =E2=80=9Cclassified as automatable= =E2=80=9D) > > Note that abstraction always comes with loss of some control, that=E2=80= =99s > inevitable. It has to hurt a little bit :-) > - our thinking is that none of these transport service features require > application-specific knowledge and hence shouldn=E2=80=99t be exposed. > > Thoughts? > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --=20 --aaron =3D=3D=3D=3D=3DShort message from my phone=3D=3D=3D=3D=3D --001a1142595a30700d0537f85460 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael-

It seems to me that one cou= ld answer the question separately whether the upper layer should be able to= control the use of multi-streaming or multi-paths vs. know whether multi-s= treaming or multi-paths are in use.=C2=A0 I would think that there no reaso= n to hide this information from apps. =C2=A0would you agree?

=
--aaron

On Mon, Jul 18, 2016 at 9:22 AM Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,

draft-gjessing-taps-minset-02 suggests that all transport service
features related to multi-streaming and usage of multiple paths are
=E2=80=9Cautomatable=E2=80=9D. The rationale is given in Section 4:
https://tools.ietf.org/html/draft= -gjessing-taps-minset-02#section-4
(this particular section says =E2=80=9Cremoved=E2=80=9D which is a mistake,= to be fixed
in the next update; sorry! - read as =E2=80=9Cclassified as automatable=E2= =80=9D)

Note that abstraction always comes with loss of some control, that=E2=80=99= s
inevitable. It has to hurt a little bit=C2=A0 :-)
- our thinking is that none of these transport service features require
application-specific knowledge and hence shouldn=E2=80=99t be exposed.

Thoughts?

Cheers,
Michael

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

=3D=3D=3D=3D=3DShort message = from my phone=3D=3D=3D=3D=3D
--001a1142595a30700d0537f85460-- From nobody Tue Jul 19 04:02:58 2016 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 609B712D179 for ; Tue, 19 Jul 2016 04:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 uHk9dUlfXUtj for ; Tue, 19 Jul 2016 04:02:53 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D0712D12E for ; Tue, 19 Jul 2016 04:02:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3E857D930E; Tue, 19 Jul 2016 13:02:52 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZsNfKD9+MO03; Tue, 19 Jul 2016 13:02:52 +0200 (MEST) Received: from dhcp-b040.meeting.ietf.org (dhcp-b040.meeting.ietf.org [31.133.176.64]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E18D0D930B; Tue, 19 Jul 2016 13:02:51 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Tue, 19 Jul 2016 13:02:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> To: Aaron Falk , Michael Welzl X-Mailer: Apple Mail (2.3124) Archived-At: Cc: taps WG Subject: Re: [Taps] Abstracting away multi-streaming and usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 11:02:56 -0000 Hi Michael, hi all, I believe there is actually quite a bit of discussion currently in MPTCP = about how important it probably is to have an interface to the = application and get input about upper layer preferences. Maybe ask on = the mptcp list for input? Mirja > Am 19.07.2016 um 09:49 schrieb Aaron Falk : >=20 > Hi Michael- >=20 > It seems to me that one could answer the question separately whether = the upper layer should be able to control the use of multi-streaming or = multi-paths vs. know whether multi-streaming or multi-paths are in use. = I would think that there no reason to hide this information from apps. = would you agree? >=20 > --aaron >=20 > On Mon, Jul 18, 2016 at 9:22 AM Michael Welzl = wrote: > Hi, >=20 > draft-gjessing-taps-minset-02 suggests that all transport service > features related to multi-streaming and usage of multiple paths are > =E2=80=9Cautomatable=E2=80=9D. The rationale is given in Section 4: > https://tools.ietf.org/html/draft-gjessing-taps-minset-02#section-4 > (this particular section says =E2=80=9Cremoved=E2=80=9D which is a = mistake, to be fixed > in the next update; sorry! - read as =E2=80=9Cclassified as = automatable=E2=80=9D) >=20 > Note that abstraction always comes with loss of some control, that=E2=80= =99s > inevitable. It has to hurt a little bit :-) > - our thinking is that none of these transport service features = require > application-specific knowledge and hence shouldn=E2=80=99t be exposed. >=20 > Thoughts? >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --=20 > --aaron >=20 > =3D=3D=3D=3D=3DShort message from my phone=3D=3D=3D=3D=3D > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Jul 19 05:27:35 2016 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 E43D112D63A for ; Tue, 19 Jul 2016 05:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 p0EnqGmVFqsJ for ; Tue, 19 Jul 2016 05:27:31 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23A012D62E for ; Tue, 19 Jul 2016 05:27:30 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bPU7U-0001kM-3s; Tue, 19 Jul 2016 14:27:28 +0200 Received: from dhcp-a1b7.meeting.ietf.org ([31.133.161.183]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bPU7J-0004Gx-5w; Tue, 19 Jul 2016 14:27:28 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> Date: Tue, 19 Jul 2016 14:27:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 9 sum msgs/h 5 total rcpts 44663 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 20D23315F7177330958A339ED6BC636FE08B54CE X-UiO-SPAM-Test: remote_host: 31.133.161.183 spam_score: -49 maxlevel 80 minaction 2 bait 0 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , "taps@ietf.org" Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 12:27:34 -0000 Thanks - I agree, it=E2=80=99s on the agenda for tomorrow=E2=80=99s = MPTCP session, and TAPS is the day after, which fits nicely. Note, I phrased this controversial on purpose to generate a bit of list = discussion: =E2=80=9Cabstracting away=E2=80=9D something like usage of = multiple paths should get some people to disagree?! Regarding the = primitives we have so far, there doesn=E2=80=99t seem to be a compelling = need for a TAPS system to expose them to an application I think. = (again, such abstraction always comes with loss of some control - at one = end of this, you want to be in control of which transport protocol is = used, which we don=E2=80=99t want here). Decisions need to be made... Multi-streaming seems to me to be an easier case: I can=E2=80=99t see = any reason why an application would need to be in control of this. = Mapping communication channels between the same end hosts onto the same = transport connection (whatever protocol provides it) should always be = beneficial. Cheers, Michael > On 19. jul. 2016, at 13.02, Mirja K=C3=BChlewind = wrote: >=20 > Hi Michael, hi all, >=20 > I believe there is actually quite a bit of discussion currently in = MPTCP about how important it probably is to have an interface to the = application and get input about upper layer preferences. Maybe ask on = the mptcp list for input? >=20 > Mirja >=20 >=20 >> Am 19.07.2016 um 09:49 schrieb Aaron Falk : >>=20 >> Hi Michael- >>=20 >> It seems to me that one could answer the question separately whether = the upper layer should be able to control the use of multi-streaming or = multi-paths vs. know whether multi-streaming or multi-paths are in use. = I would think that there no reason to hide this information from apps. = would you agree? >>=20 >> --aaron >>=20 >> On Mon, Jul 18, 2016 at 9:22 AM Michael Welzl = wrote: >> Hi, >>=20 >> draft-gjessing-taps-minset-02 suggests that all transport service >> features related to multi-streaming and usage of multiple paths are >> =E2=80=9Cautomatable=E2=80=9D. The rationale is given in Section 4: >> https://tools.ietf.org/html/draft-gjessing-taps-minset-02#section-4 >> (this particular section says =E2=80=9Cremoved=E2=80=9D which is a = mistake, to be fixed >> in the next update; sorry! - read as =E2=80=9Cclassified as = automatable=E2=80=9D) >>=20 >> Note that abstraction always comes with loss of some control, = that=E2=80=99s >> inevitable. It has to hurt a little bit :-) >> - our thinking is that none of these transport service features = require >> application-specific knowledge and hence shouldn=E2=80=99t be = exposed. >>=20 >> Thoughts? >>=20 >> Cheers, >> Michael >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> --=20 >> --aaron >>=20 >> =3D=3D=3D=3D=3DShort message from my phone=3D=3D=3D=3D=3D >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 From nobody Tue Jul 19 08:51:30 2016 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 833D212D606 for ; Tue, 19 Jul 2016 08:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 rSUA7CAappDh for ; Tue, 19 Jul 2016 08:51:27 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 302C412B071 for ; Tue, 19 Jul 2016 08:41:20 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u6JFeosp027601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Jul 2016 08:40:52 -0700 (PDT) To: Michael Welzl , =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> From: Joe Touch Message-ID: <578E4A03.8000006@isi.edu> Date: Tue, 19 Jul 2016 08:40:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Aaron Falk , "taps@ietf.org" Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 15:51:28 -0000 On 7/19/2016 5:27 AM, Michael Welzl wrote: > Thanks - I agree, it’s on the agenda for tomorrow’s MPTCP session, and TAPS is the day after, which fits nicely. > > Note, I phrased this controversial on purpose to generate a bit of list discussion: “abstracting away” something like usage of multiple paths should get some people to disagree?! Regarding the primitives we have so far, there doesn’t seem to be a compelling need for a TAPS system to expose them to an application I think. (again, such abstraction always comes with loss of some control - at one end of this, you want to be in control of which transport protocol is used, which we don’t want here). Decisions need to be made... > > > Multi-streaming seems to me to be an easier case: I can’t see any reason why an application would need to be in control of this. Mapping communication channels between the same end hosts onto the same transport connection (whatever protocol provides it) should always be beneficial. I'm not sure I understand how an app can/should know about any of this. It strikes me as involving the app deep in "how" things are done in other layers, rather than indicating a preference on behavior it sees (it really shouldn't "see" any of this directly, IMO). I.e., this would be a good place to take a lesson from QoS - the key is to indicate a preference to the net based on "application visible behavior", not to try to map things so directly based on semantics. Joe From nobody Tue Jul 19 08:59:53 2016 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 7FB0A12B065 for ; Tue, 19 Jul 2016 08:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 pkEOAWryytLk for ; Tue, 19 Jul 2016 08:59:50 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7886312D8A0 for ; Tue, 19 Jul 2016 08:49:53 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bPXHK-0001FJ-KC; Tue, 19 Jul 2016 17:49:50 +0200 Received: from [46.189.28.92] (helo=[10.24.255.5]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bPXHK-0006vl-20; Tue, 19 Jul 2016 17:49:50 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: <578E4A03.8000006@isi.edu> Date: Tue, 19 Jul 2016 17:49:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> <578E4A03.8000006@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 11 sum msgs/h 5 total rcpts 44678 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 852616D8DB3A367972409BB2CC2CE024EC0B1948 X-UiO-SPAM-Test: remote_host: 46.189.28.92 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 71 max/h 10 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , =?utf-8?Q?Mirja_K=C3=BChlewind?= , "taps@ietf.org" Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 15:59:52 -0000 > On 19. jul. 2016, at 17.40, Joe Touch wrote: >=20 >=20 >=20 > On 7/19/2016 5:27 AM, Michael Welzl wrote: >> Thanks - I agree, it=E2=80=99s on the agenda for tomorrow=E2=80=99s = MPTCP session, and TAPS is the day after, which fits nicely. >>=20 >> Note, I phrased this controversial on purpose to generate a bit of = list discussion: =E2=80=9Cabstracting away=E2=80=9D something like usage = of multiple paths should get some people to disagree?! Regarding the = primitives we have so far, there doesn=E2=80=99t seem to be a compelling = need for a TAPS system to expose them to an application I think. = (again, such abstraction always comes with loss of some control - at one = end of this, you want to be in control of which transport protocol is = used, which we don=E2=80=99t want here). Decisions need to be made... >>=20 >>=20 >> Multi-streaming seems to me to be an easier case: I can=E2=80=99t see = any reason why an application would need to be in control of this. = Mapping communication channels between the same end hosts onto the same = transport connection (whatever protocol provides it) should always be = beneficial. >=20 > I'm not sure I understand how an app can/should know about any of = this. > It strikes me as involving the app deep in "how" things are done in > other layers, rather than indicating a preference on behavior it sees > (it really shouldn't "see" any of this directly, IMO). >=20 > I.e., this would be a good place to take a lesson from QoS - the key = is > to indicate a preference to the net based on "application visible > behavior", not to try to map things so directly based on semantics. This sounds like a misunderstanding, maybe I didn=E2=80=99t make myself = clear enough - because I think we agree: an application can / should not know about any of this, IMO. It should = just see a communication channel. So mapping these channels onto a transport connection is what I thought = a TAPS system underneath the application could do, and the application = won=E2=80=99t need to be bothered. Cheers, Michael From nobody Tue Jul 19 09:02:55 2016 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 0720012D660 for ; Tue, 19 Jul 2016 09:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 qgT-IXJb3kMx for ; Tue, 19 Jul 2016 09:02:50 -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 A1D2612D8F5 for ; Tue, 19 Jul 2016 08:53:41 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6JFqw7B017095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Jul 2016 08:53:08 -0700 (PDT) To: Michael Welzl References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> <578E4A03.8000006@isi.edu> From: Joe Touch Message-ID: <578E4CDB.6000201@isi.edu> Date: Tue, 19 Jul 2016 08:52:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Aaron Falk , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , "taps@ietf.org" Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:02:54 -0000 On 7/19/2016 8:49 AM, Michael Welzl wrote: >> On 19. jul. 2016, at 17.40, Joe Touch wrote: >> >> >> >> On 7/19/2016 5:27 AM, Michael Welzl wrote: >>> Thanks - I agree, it’s on the agenda for tomorrow’s MPTCP session, and TAPS is the day after, which fits nicely. >>> >>> Note, I phrased this controversial on purpose to generate a bit of list discussion: “abstracting away” something like usage of multiple paths should get some people to disagree?! Regarding the primitives we have so far, there doesn’t seem to be a compelling need for a TAPS system to expose them to an application I think. (again, such abstraction always comes with loss of some control - at one end of this, you want to be in control of which transport protocol is used, which we don’t want here). Decisions need to be made... >>> >>> >>> Multi-streaming seems to me to be an easier case: I can’t see any reason why an application would need to be in control of this. Mapping communication channels between the same end hosts onto the same transport connection (whatever protocol provides it) should always be beneficial. >> I'm not sure I understand how an app can/should know about any of this. >> It strikes me as involving the app deep in "how" things are done in >> other layers, rather than indicating a preference on behavior it sees >> (it really shouldn't "see" any of this directly, IMO). >> >> I.e., this would be a good place to take a lesson from QoS - the key is >> to indicate a preference to the net based on "application visible >> behavior", not to try to map things so directly based on semantics. > This sounds like a misunderstanding, maybe I didn’t make myself clear enough - because I think we agree: > an application can / should not know about any of this, IMO. It should just see a communication channel. > > So mapping these channels onto a transport connection is what I thought a TAPS system underneath the application could do, and the application won’t need to be bothered. I was speaking to the broader point of this thread and generalizing your point about multi-streaming to the multiple path case as well. (I didn't know if you felt that both cases should be handled the same way or whether you were using multi-streaming as an easier case to argue) Joe From nobody Tue Jul 19 09:06:46 2016 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 4D4E112D0CA for ; Tue, 19 Jul 2016 09:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 PE9axli0L3nk for ; Tue, 19 Jul 2016 09:06:43 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A747112D7D6 for ; Tue, 19 Jul 2016 08:59:04 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bPXQD-0008Iw-6d; Tue, 19 Jul 2016 17:59:01 +0200 Received: from [46.189.28.92] (helo=[10.24.255.5]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bPXQC-0000wz-PJ; Tue, 19 Jul 2016 17:59:01 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: <578E4CDB.6000201@isi.edu> Date: Tue, 19 Jul 2016 17:59:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <39EE3663-F7B4-4C82-98CF-03FA118B5FCC@ifi.uio.no> References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> <578E4A03.8000006@isi.edu> <578E4CDB.6000201@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 14 msgs/h 5 sum rcpts/h 19 sum msgs/h 8 total rcpts 44686 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 4E2747666E41516F9D86A12457F3A21996C64259 X-UiO-SPAM-Test: remote_host: 46.189.28.92 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 74 max/h 10 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , =?utf-8?Q?Mirja_K=C3=BChlewind?= , "taps@ietf.org" Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:06:45 -0000 > On 19. jul. 2016, at 17.52, Joe Touch wrote: >=20 >=20 >=20 > On 7/19/2016 8:49 AM, Michael Welzl wrote: >>> On 19. jul. 2016, at 17.40, Joe Touch wrote: >>>=20 >>>=20 >>>=20 >>> On 7/19/2016 5:27 AM, Michael Welzl wrote: >>>> Thanks - I agree, it=E2=80=99s on the agenda for tomorrow=E2=80=99s = MPTCP session, and TAPS is the day after, which fits nicely. >>>>=20 >>>> Note, I phrased this controversial on purpose to generate a bit of = list discussion: =E2=80=9Cabstracting away=E2=80=9D something like usage = of multiple paths should get some people to disagree?! Regarding the = primitives we have so far, there doesn=E2=80=99t seem to be a compelling = need for a TAPS system to expose them to an application I think. = (again, such abstraction always comes with loss of some control - at one = end of this, you want to be in control of which transport protocol is = used, which we don=E2=80=99t want here). Decisions need to be made... >>>>=20 >>>>=20 >>>> Multi-streaming seems to me to be an easier case: I can=E2=80=99t = see any reason why an application would need to be in control of this. = Mapping communication channels between the same end hosts onto the same = transport connection (whatever protocol provides it) should always be = beneficial. >>> I'm not sure I understand how an app can/should know about any of = this. >>> It strikes me as involving the app deep in "how" things are done in >>> other layers, rather than indicating a preference on behavior it = sees >>> (it really shouldn't "see" any of this directly, IMO). >>>=20 >>> I.e., this would be a good place to take a lesson from QoS - the key = is >>> to indicate a preference to the net based on "application visible >>> behavior", not to try to map things so directly based on semantics. >> This sounds like a misunderstanding, maybe I didn=E2=80=99t make = myself clear enough - because I think we agree: >> an application can / should not know about any of this, IMO. It = should just see a communication channel. >>=20 >> So mapping these channels onto a transport connection is what I = thought a TAPS system underneath the application could do, and the = application won=E2=80=99t need to be bothered. > I was speaking to the broader point of this thread and generalizing > your point about multi-streaming to the multiple path case as well. >=20 > (I didn't know if you felt that both cases should be handled the same > way or whether you were using multi-streaming as an easier case to = argue) I focused on multi-streaming now as an easier case to argue :-) Let=E2=80=99s focus on this one first and then get to multipath. Sorry = for the mixup! Michael From nobody Tue Jul 19 09:11:27 2016 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 D2B8A12D8E4 for ; Tue, 19 Jul 2016 09:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 hOCrpM1gEAcO for ; Tue, 19 Jul 2016 09:11:23 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C3912D928 for ; Tue, 19 Jul 2016 09:05:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 38D65D930B; Tue, 19 Jul 2016 18:05:12 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8eo42Nj9lsvn; Tue, 19 Jul 2016 18:05:12 +0200 (MEST) Received: from dhcp-b040.meeting.ietf.org (dhcp-b040.meeting.ietf.org [31.133.176.64]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E53C0D9309; Tue, 19 Jul 2016 18:05:11 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <578E4CDB.6000201@isi.edu> Date: Tue, 19 Jul 2016 18:05:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <04A6CE8D-9F26-4E9E-B01B-1A0C73A692F6@tik.ee.ethz.ch> References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> <578E4A03.8000006@isi.edu> <578E4CDB.6000201@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Aaron Falk , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:11:26 -0000 Hi, for multicast there is the simple example where one access network is = more expensive to use than the other (in the sense where the user gets a = bill at the end). In this case the user would potentially rather except = a disconnect for a short time than sending data unnecessary over the = expensive links (and the link should only be used if no other one is = available). Please go to the mptcp list and ask people there about their use cases = because these (at least not all of these) people might not be subscribed = to this list. Mirja > Am 19.07.2016 um 17:52 schrieb Joe Touch : >=20 >=20 >=20 > On 7/19/2016 8:49 AM, Michael Welzl wrote: >>> On 19. jul. 2016, at 17.40, Joe Touch wrote: >>>=20 >>>=20 >>>=20 >>> On 7/19/2016 5:27 AM, Michael Welzl wrote: >>>> Thanks - I agree, it=E2=80=99s on the agenda for tomorrow=E2=80=99s = MPTCP session, and TAPS is the day after, which fits nicely. >>>>=20 >>>> Note, I phrased this controversial on purpose to generate a bit of = list discussion: =E2=80=9Cabstracting away=E2=80=9D something like usage = of multiple paths should get some people to disagree?! Regarding the = primitives we have so far, there doesn=E2=80=99t seem to be a compelling = need for a TAPS system to expose them to an application I think. = (again, such abstraction always comes with loss of some control - at one = end of this, you want to be in control of which transport protocol is = used, which we don=E2=80=99t want here). Decisions need to be made... >>>>=20 >>>>=20 >>>> Multi-streaming seems to me to be an easier case: I can=E2=80=99t = see any reason why an application would need to be in control of this. = Mapping communication channels between the same end hosts onto the same = transport connection (whatever protocol provides it) should always be = beneficial. >>> I'm not sure I understand how an app can/should know about any of = this. >>> It strikes me as involving the app deep in "how" things are done in >>> other layers, rather than indicating a preference on behavior it = sees >>> (it really shouldn't "see" any of this directly, IMO). >>>=20 >>> I.e., this would be a good place to take a lesson from QoS - the key = is >>> to indicate a preference to the net based on "application visible >>> behavior", not to try to map things so directly based on semantics. >> This sounds like a misunderstanding, maybe I didn=E2=80=99t make = myself clear enough - because I think we agree: >> an application can / should not know about any of this, IMO. It = should just see a communication channel. >>=20 >> So mapping these channels onto a transport connection is what I = thought a TAPS system underneath the application could do, and the = application won=E2=80=99t need to be bothered. > I was speaking to the broader point of this thread and generalizing > your point about multi-streaming to the multiple path case as well. >=20 > (I didn't know if you felt that both cases should be handled the same > way or whether you were using multi-streaming as an easier case to = argue) >=20 > Joe From nobody Tue Jul 19 09:11:46 2016 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 0432712D846 for ; Tue, 19 Jul 2016 09:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 M_hT-mgP5u21 for ; Tue, 19 Jul 2016 09:11:43 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16FE412D807 for ; Tue, 19 Jul 2016 09:05:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id CF866D930B; Tue, 19 Jul 2016 18:05:54 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6Cel0jTZ6+q0; Tue, 19 Jul 2016 18:05:54 +0200 (MEST) Received: from dhcp-b040.meeting.ietf.org (dhcp-b040.meeting.ietf.org [31.133.176.64]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 6CE0FD9309; Tue, 19 Jul 2016 18:05:54 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <04A6CE8D-9F26-4E9E-B01B-1A0C73A692F6@tik.ee.ethz.ch> Date: Tue, 19 Jul 2016 18:05:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4C307CE1-E455-4CBB-9FAA-605382C057EE@tik.ee.ethz.ch> References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> <578E4A03.8000006@isi.edu> <578E4CDB.6000201@isi.edu> <04A6CE8D-9F26-4E9E-B01B-1A0C73A692F6@tik.ee.ethz.ch> To: Joe Touch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Aaron Falk , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:11:45 -0000 Sorry=E2=80=A6 s/multicast/multipath/ (stupid auto-correct) > Am 19.07.2016 um 18:05 schrieb Mirja K=C3=BChlewind = : >=20 > Hi, >=20 > for multicast there is the simple example where one access network is = more expensive to use than the other (in the sense where the user gets a = bill at the end). In this case the user would potentially rather except = a disconnect for a short time than sending data unnecessary over the = expensive links (and the link should only be used if no other one is = available). >=20 > Please go to the mptcp list and ask people there about their use cases = because these (at least not all of these) people might not be subscribed = to this list. >=20 > Mirja >=20 >=20 >> Am 19.07.2016 um 17:52 schrieb Joe Touch : >>=20 >>=20 >>=20 >> On 7/19/2016 8:49 AM, Michael Welzl wrote: >>>> On 19. jul. 2016, at 17.40, Joe Touch wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On 7/19/2016 5:27 AM, Michael Welzl wrote: >>>>> Thanks - I agree, it=E2=80=99s on the agenda for tomorrow=E2=80=99s = MPTCP session, and TAPS is the day after, which fits nicely. >>>>>=20 >>>>> Note, I phrased this controversial on purpose to generate a bit of = list discussion: =E2=80=9Cabstracting away=E2=80=9D something like usage = of multiple paths should get some people to disagree?! Regarding the = primitives we have so far, there doesn=E2=80=99t seem to be a compelling = need for a TAPS system to expose them to an application I think. = (again, such abstraction always comes with loss of some control - at one = end of this, you want to be in control of which transport protocol is = used, which we don=E2=80=99t want here). Decisions need to be made... >>>>>=20 >>>>>=20 >>>>> Multi-streaming seems to me to be an easier case: I can=E2=80=99t = see any reason why an application would need to be in control of this. = Mapping communication channels between the same end hosts onto the same = transport connection (whatever protocol provides it) should always be = beneficial. >>>> I'm not sure I understand how an app can/should know about any of = this. >>>> It strikes me as involving the app deep in "how" things are done in >>>> other layers, rather than indicating a preference on behavior it = sees >>>> (it really shouldn't "see" any of this directly, IMO). >>>>=20 >>>> I.e., this would be a good place to take a lesson from QoS - the = key is >>>> to indicate a preference to the net based on "application visible >>>> behavior", not to try to map things so directly based on semantics. >>> This sounds like a misunderstanding, maybe I didn=E2=80=99t make = myself clear enough - because I think we agree: >>> an application can / should not know about any of this, IMO. It = should just see a communication channel. >>>=20 >>> So mapping these channels onto a transport connection is what I = thought a TAPS system underneath the application could do, and the = application won=E2=80=99t need to be bothered. >> I was speaking to the broader point of this thread and generalizing >> your point about multi-streaming to the multiple path case as well. >>=20 >> (I didn't know if you felt that both cases should be handled the same >> way or whether you were using multi-streaming as an easier case to = argue) >>=20 >> Joe >=20 From nobody Tue Jul 19 09:12:12 2016 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 C16A412D8F5 for ; Tue, 19 Jul 2016 09:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 UHEoyRqpbdna for ; Tue, 19 Jul 2016 09:12:08 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id CBEEE12D6AC for ; Tue, 19 Jul 2016 09:06:28 -0700 (PDT) Received: from dhcp-974a.meeting.ietf.org (unknown [IPv6:2001:67c:370:136:e8ad:4526:8a5f:736c]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 78EC81B00255; Tue, 19 Jul 2016 17:06:23 +0100 (BST) Message-ID: <578E5002.4050405@erg.abdn.ac.uk> Date: Tue, 19 Jul 2016 18:06:26 +0200 From: G Fairhurst User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Michael Welzl References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> <578E4A03.8000006@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Aaron Falk , "taps@ietf.org" , =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= , Joe Touch Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:12:11 -0000 On 19/07/2016, 17:49, Michael Welzl wrote: >> On 19. jul. 2016, at 17.40, Joe Touch wrote: >> >> >> >> On 7/19/2016 5:27 AM, Michael Welzl wrote: >>> Thanks - I agree, it’s on the agenda for tomorrow’s MPTCP session, and TAPS is the day after, which fits nicely. >>> >>> Note, I phrased this controversial on purpose to generate a bit of list discussion: “abstracting away” something like usage of multiple paths should get some people to disagree?! Regarding the primitives we have so far, there doesn’t seem to be a compelling need for a TAPS system to expose them to an application I think. (again, such abstraction always comes with loss of some control - at one end of this, you want to be in control of which transport protocol is used, which we don’t want here). Decisions need to be made... >>> >>> >>> Multi-streaming seems to me to be an easier case: I can’t see any reason why an application would need to be in control of this. Mapping communication channels between the same end hosts onto the same transport connection (whatever protocol provides it) should always be beneficial. >> I'm not sure I understand how an app can/should know about any of this. >> It strikes me as involving the app deep in "how" things are done in >> other layers, rather than indicating a preference on behavior it sees >> (it really shouldn't "see" any of this directly, IMO). >> >> I.e., this would be a good place to take a lesson from QoS - the key is >> to indicate a preference to the net based on "application visible >> behavior", not to try to map things so directly based on semantics. > This sounds like a misunderstanding, maybe I didn’t make myself clear enough - because I think we agree: > an application can / should not know about any of this, IMO. It should just see a communication channel. > > So mapping these channels onto a transport connection is what I thought a TAPS system underneath the application could do, and the application won’t need to be bothered. > > Cheers, > Michael I can agree that applications should be encouraged to let the system figure out how best to do these things. A few applications will always want finer control (of QoS and flow scheduling) - presumably because they believe they understand what they actually need. I suggest even these apps can benefit from system-learned information about what the network can actually offer. Gorry > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Jul 19 09:16:04 2016 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 2EF9D12D0E1 for ; Tue, 19 Jul 2016 09:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.486 X-Spam-Level: X-Spam-Status: No, score=-5.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 qUJgpyr_RU9k for ; Tue, 19 Jul 2016 09:16:01 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030FF12D0B4 for ; Tue, 19 Jul 2016 09:12:13 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bPXcx-0001N8-Vd; Tue, 19 Jul 2016 18:12:11 +0200 Received: from dhcp-8e1b.meeting.ietf.org ([31.133.142.27]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bPXcx-0003wB-6a; Tue, 19 Jul 2016 18:12:11 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Michael Welzl X-Mailer: iPhone Mail (13F69) In-Reply-To: <4C307CE1-E455-4CBB-9FAA-605382C057EE@tik.ee.ethz.ch> Date: Tue, 19 Jul 2016 18:12:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> <578E4A03.8000006@isi.edu> <578E4CDB.6000201@isi.edu> <04A6CE8D-9F26-4E9E-B01B-1A0C73A692F6@tik.ee.ethz.ch> <4C307CE1-E455-4CBB-9FAA-605382C057EE@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 13 sum msgs/h 4 total rcpts 44690 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8AF13B26D5B53F7D75D79B3DCB554293B9EA9950 X-UiO-SPAM-Test: remote_host: 31.133.142.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1 max/h 1 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , "taps@ietf.org" , Joe Touch Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:16:03 -0000 will do (list). about your example: on my phone it's the os deciding, not th= e app... which is my point :) Sent from my iPhone > On 19. jul. 2016, at 18.05, Mirja K=C3=BChlewind wrote: >=20 > Sorry=E2=80=A6 s/multicast/multipath/ (stupid auto-correct) >=20 >=20 >> Am 19.07.2016 um 18:05 schrieb Mirja K=C3=BChlewind : >>=20 >> Hi, >>=20 >> for multicast there is the simple example where one access network is mor= e expensive to use than the other (in the sense where the user gets a bill a= t the end). In this case the user would potentially rather except a disconne= ct for a short time than sending data unnecessary over the expensive links (= and the link should only be used if no other one is available). >>=20 >> Please go to the mptcp list and ask people there about their use cases be= cause these (at least not all of these) people might not be subscribed to th= is list. >>=20 >> Mirja >>=20 >>=20 >>> Am 19.07.2016 um 17:52 schrieb Joe Touch : >>>=20 >>>=20 >>>=20 >>> On 7/19/2016 8:49 AM, Michael Welzl wrote: >>>>> On 19. jul. 2016, at 17.40, Joe Touch wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On 7/19/2016 5:27 AM, Michael Welzl wrote: >>>>>> Thanks - I agree, it=E2=80=99s on the agenda for tomorrow=E2=80=99s M= PTCP session, and TAPS is the day after, which fits nicely. >>>>>>=20 >>>>>> Note, I phrased this controversial on purpose to generate a bit of li= st discussion: =E2=80=9Cabstracting away=E2=80=9D something like usage of mu= ltiple paths should get some people to disagree?! Regarding the primitives w= e have so far, there doesn=E2=80=99t seem to be a compelling need for a TAPS= system to expose them to an application I think. (again, such abstraction a= lways comes with loss of some control - at one end of this, you want to be i= n control of which transport protocol is used, which we don=E2=80=99t want h= ere). Decisions need to be made... >>>>>>=20 >>>>>>=20 >>>>>> Multi-streaming seems to me to be an easier case: I can=E2=80=99t see= any reason why an application would need to be in control of this. Mapping c= ommunication channels between the same end hosts onto the same transport con= nection (whatever protocol provides it) should always be beneficial. >>>>> I'm not sure I understand how an app can/should know about any of this= . >>>>> It strikes me as involving the app deep in "how" things are done in >>>>> other layers, rather than indicating a preference on behavior it sees >>>>> (it really shouldn't "see" any of this directly, IMO). >>>>>=20 >>>>> I.e., this would be a good place to take a lesson from QoS - the key i= s >>>>> to indicate a preference to the net based on "application visible >>>>> behavior", not to try to map things so directly based on semantics. >>>> This sounds like a misunderstanding, maybe I didn=E2=80=99t make myself= clear enough - because I think we agree: >>>> an application can / should not know about any of this, IMO. It should j= ust see a communication channel. >>>>=20 >>>> So mapping these channels onto a transport connection is what I thought= a TAPS system underneath the application could do, and the application won=E2= =80=99t need to be bothered. >>> I was speaking to the broader point of this thread and generalizing >>> your point about multi-streaming to the multiple path case as well. >>>=20 >>> (I didn't know if you felt that both cases should be handled the same >>> way or whether you were using multi-streaming as an easier case to argue= ) >>>=20 >>> Joe >=20 From nobody Tue Jul 19 10:39:05 2016 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 7BA8A12D0E3 for ; Tue, 19 Jul 2016 10:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 8GlpaocNBppf for ; Tue, 19 Jul 2016 10:39:03 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 1C05012B010 for ; Tue, 19 Jul 2016 10:39:03 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6JHcFqL004209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Jul 2016 10:38:15 -0700 (PDT) To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> <578E4A03.8000006@isi.edu> <578E4CDB.6000201@isi.edu> <04A6CE8D-9F26-4E9E-B01B-1A0C73A692F6@tik.ee.ethz.ch> From: Joe Touch Message-ID: <6ff8f8fe-18e0-e0af-d703-3122981a8a6a@isi.edu> Date: Tue, 19 Jul 2016 10:38:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <04A6CE8D-9F26-4E9E-B01B-1A0C73A692F6@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MailScanner-ID: u6JHcFqL004209 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Aaron Falk , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 17:39:04 -0000 On 7/19/2016 9:05 AM, Mirja Kühlewind wrote: > Hi, > > for multicast there is the simple example where one access network is more expensive to use than the other (in the sense where the user gets a bill at the end). In this case the user would potentially rather except a disconnect for a short time than sending data unnecessary over the expensive links (and the link should only be used if no other one is available). That's a great example - expense is the application criteria. That criteria is enough for the net to make a decision without needing the app to be involved. Joe From nobody Tue Jul 19 14:05:33 2016 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 1C93312D8F0 for ; Tue, 19 Jul 2016 14:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 YuFsXs25l7oE for ; Tue, 19 Jul 2016 14:05:29 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D6A12D8EA for ; Tue, 19 Jul 2016 14:05:29 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bPcCl-0002kd-Ed; Tue, 19 Jul 2016 23:05:27 +0200 Received: from [46.189.28.92] (helo=[10.24.255.5]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bPcCh-0004UF-HH; Tue, 19 Jul 2016 23:05:27 +0200 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <8230F063-8EF2-4B05-BF90-AB1E8832968E@ifi.uio.no> Date: Tue, 19 Jul 2016 23:05:19 +0200 To: mptcp-chairs@tools.ietf.org, "taps@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 5 sum msgs/h 2 total rcpts 44695 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D048F44F871B644ACB1FD89A39056E568244F131 X-UiO-SPAM-Test: remote_host: 46.189.28.92 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 77 max/h 10 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [Taps] MPTCP Socket API and TAPS X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 21:05:32 -0000 [ Please discuss on the NEAT mailing list ] Hi, The TAPS WG is trying to identify which services transport protocols = offer, and then identify which of these services should be exposed to an = application that tries to communicate while being agnostic to the = transport protocol below. A TAPS system should then make a choice about = the right transport protocol and configure it autonomously, and = implement e.g. protocol fall-backs and such. Some transport services must be exposed or else they could never be used = (e.g. unordered message delivery). Some can optimize performance if they = are exposed and cannot be used without application involvement, but = won=E2=80=99t make an application fail if they are not used (e.g. = turning the Nagle algorithm on/off). The remaining ones could be = =E2=80=9Cautomatized=E2=80=9D, i.e. a TAPS protocol could potentially = make a decision on its own about them. Note that this raises the abstraction level of the API applications use = to talk to the network. As always, this comes with benefits (of = automatizing more things, and not requiring one specific transport = protocol, ..), but also with reduced control over the available = resources. As an extreme example, nobody in their right mind would write = wireshark over TAPS :-) One proposal is to consider everything related to the usage of multiple = paths automatable. That is, not expose it as a TAPS service. What do people here think about this? Cheers, Michael From nobody Tue Jul 19 14:08:28 2016 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 7E9AC12D8CE for ; Tue, 19 Jul 2016 14:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 bHuGpasb4M9r for ; Tue, 19 Jul 2016 14:08:24 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA4212D899 for ; Tue, 19 Jul 2016 14:08:24 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bPcFX-0001vF-5u; Tue, 19 Jul 2016 23:08:19 +0200 Received: from [46.189.28.92] (helo=[10.24.255.5]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bPcFR-0004ZO-BW; Tue, 19 Jul 2016 23:08:19 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: <578E5002.4050405@erg.abdn.ac.uk> Date: Tue, 19 Jul 2016 23:08:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> <578E4A03.8000006@isi.edu> <578E5002.4050405@erg.abdn.ac.uk> To: " Fairhurst" X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 10 sum msgs/h 3 total rcpts 44700 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 78F0FFDF7EE7906B70657A48EE9C2A9963733C28 X-UiO-SPAM-Test: remote_host: 46.189.28.92 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 78 max/h 10 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , "taps@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 21:08:27 -0000 > On 19. jul. 2016, at 18.06, G Fairhurst wrote: >=20 > On 19/07/2016, 17:49, Michael Welzl wrote: >>> On 19. jul. 2016, at 17.40, Joe Touch wrote: >>>=20 >>>=20 >>>=20 >>> On 7/19/2016 5:27 AM, Michael Welzl wrote: >>>> Thanks - I agree, it=E2=80=99s on the agenda for tomorrow=E2=80=99s = MPTCP session, and TAPS is the day after, which fits nicely. >>>>=20 >>>> Note, I phrased this controversial on purpose to generate a bit of = list discussion: =E2=80=9Cabstracting away=E2=80=9D something like usage = of multiple paths should get some people to disagree?! Regarding the = primitives we have so far, there doesn=E2=80=99t seem to be a compelling = need for a TAPS system to expose them to an application I think. = (again, such abstraction always comes with loss of some control - at one = end of this, you want to be in control of which transport protocol is = used, which we don=E2=80=99t want here). Decisions need to be made... >>>>=20 >>>>=20 >>>> Multi-streaming seems to me to be an easier case: I can=E2=80=99t = see any reason why an application would need to be in control of this. = Mapping communication channels between the same end hosts onto the same = transport connection (whatever protocol provides it) should always be = beneficial. >>> I'm not sure I understand how an app can/should know about any of = this. >>> It strikes me as involving the app deep in "how" things are done in >>> other layers, rather than indicating a preference on behavior it = sees >>> (it really shouldn't "see" any of this directly, IMO). >>>=20 >>> I.e., this would be a good place to take a lesson from QoS - the key = is >>> to indicate a preference to the net based on "application visible >>> behavior", not to try to map things so directly based on semantics. >> This sounds like a misunderstanding, maybe I didn=E2=80=99t make = myself clear enough - because I think we agree: >> an application can / should not know about any of this, IMO. It = should just see a communication channel. >>=20 >> So mapping these channels onto a transport connection is what I = thought a TAPS system underneath the application could do, and the = application won=E2=80=99t need to be bothered. >>=20 >> Cheers, >> Michael > I can agree that applications should be encouraged to let the system = figure out how best to do these things. >=20 > A few applications will always want finer control (of QoS and flow = scheduling) - presumably because they believe they understand what they = actually need. I suggest even these apps can benefit from system-learned = information about what the network can actually offer. Sounds like you=E2=80=99re suggesting to *not* expose these transport = services too? I=E2=80=99d agree. We can=E2=80=99t make a =E2=80=9Cperfect=E2=80=9D decision here, it=E2=80=99= s a trade-off: this is the part of TAPS where we can=E2=80=99t work with = simple rules anymore but we have to make some deliberate design choices. Cheers, Michael From nobody Tue Jul 19 14:09:41 2016 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 5B1A112D8F0 for ; Tue, 19 Jul 2016 14:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 sPFXa30NGLDn for ; Tue, 19 Jul 2016 14:09:36 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3578212D903 for ; Tue, 19 Jul 2016 14:09:28 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bPcGc-0001zI-HK; Tue, 19 Jul 2016 23:09:26 +0200 Received: from [46.189.28.92] (helo=[10.24.255.5]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bPcGb-0004AW-U9; Tue, 19 Jul 2016 23:09:26 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: <8230F063-8EF2-4B05-BF90-AB1E8832968E@ifi.uio.no> Date: Tue, 19 Jul 2016 23:09:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8230F063-8EF2-4B05-BF90-AB1E8832968E@ifi.uio.no> To: mptcp@tools.ietf.org, "taps@ietf.org" X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 3 sum rcpts/h 12 sum msgs/h 4 total rcpts 44702 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EEDE70F43A2B9877AD524ADDF9F3EEC146F6E617 X-UiO-SPAM-Test: remote_host: 46.189.28.92 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 79 max/h 10 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] MPTCP Socket API and TAPS X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 21:09:38 -0000 OMG! Typo below - NEAT is the a research project implementing TAPS, and I = wrote this email after the social=E2=80=A6 enough said=E2=80=A6 very sorry: I meant to say: please discuss on the TAPS mailing list. > On 19. jul. 2016, at 23.05, Michael Welzl wrote: >=20 > [ Please discuss on the NEAT mailing list ] >=20 >=20 > Hi, >=20 > The TAPS WG is trying to identify which services transport protocols = offer, and then identify which of these services should be exposed to an = application that tries to communicate while being agnostic to the = transport protocol below. A TAPS system should then make a choice about = the right transport protocol and configure it autonomously, and = implement e.g. protocol fall-backs and such. >=20 > Some transport services must be exposed or else they could never be = used (e.g. unordered message delivery). Some can optimize performance if = they are exposed and cannot be used without application involvement, but = won=E2=80=99t make an application fail if they are not used (e.g. = turning the Nagle algorithm on/off). The remaining ones could be = =E2=80=9Cautomatized=E2=80=9D, i.e. a TAPS protocol could potentially = make a decision on its own about them. >=20 > Note that this raises the abstraction level of the API applications = use to talk to the network. As always, this comes with benefits (of = automatizing more things, and not requiring one specific transport = protocol, ..), but also with reduced control over the available = resources. As an extreme example, nobody in their right mind would write = wireshark over TAPS :-) >=20 > One proposal is to consider everything related to the usage of = multiple paths automatable. That is, not expose it as a TAPS service. >=20 > What do people here think about this? >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Jul 19 14:10:47 2016 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 5BF3612D8B9; Tue, 19 Jul 2016 14:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 Ta0q7OD4eC8M; Tue, 19 Jul 2016 14:10:41 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9021712D88B; Tue, 19 Jul 2016 14:10:41 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bPcHn-00027e-Tf; Tue, 19 Jul 2016 23:10:39 +0200 Received: from [46.189.28.92] (helo=[10.24.255.5]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bPcHn-0004cT-9A; Tue, 19 Jul 2016 23:10:39 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Tue, 19 Jul 2016 23:10:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9E2B315F-C916-4292-A1C0-BA8C90976E86@ifi.uio.no> References: <8230F063-8EF2-4B05-BF90-AB1E8832968E@ifi.uio.no> To: multipathtcp@ietf.org, "taps@ietf.org" X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 4 sum rcpts/h 14 sum msgs/h 5 total rcpts 44704 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D91FCB212C552FA7F305F5629ED2B3EFAB2B8003 X-UiO-SPAM-Test: remote_host: 46.189.28.92 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 80 max/h 10 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] MPTCP Socket API and TAPS X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 21:10:43 -0000 and now it seems I can=E2=80=99t get the MPTCP group=E2=80=99s email = address right=E2=80=A6 Sorry folks! > On 19. jul. 2016, at 23.09, Michael Welzl wrote: >=20 > OMG! > Typo below - NEAT is the a research project implementing TAPS, and I = wrote this email after the social=E2=80=A6 enough said=E2=80=A6 >=20 > very sorry: I meant to say: please discuss on the TAPS mailing list. >=20 >=20 >> On 19. jul. 2016, at 23.05, Michael Welzl wrote: >>=20 >> [ Please discuss on the NEAT mailing list ] >>=20 >>=20 >> Hi, >>=20 >> The TAPS WG is trying to identify which services transport protocols = offer, and then identify which of these services should be exposed to an = application that tries to communicate while being agnostic to the = transport protocol below. A TAPS system should then make a choice about = the right transport protocol and configure it autonomously, and = implement e.g. protocol fall-backs and such. >>=20 >> Some transport services must be exposed or else they could never be = used (e.g. unordered message delivery). Some can optimize performance if = they are exposed and cannot be used without application involvement, but = won=E2=80=99t make an application fail if they are not used (e.g. = turning the Nagle algorithm on/off). The remaining ones could be = =E2=80=9Cautomatized=E2=80=9D, i.e. a TAPS protocol could potentially = make a decision on its own about them. >>=20 >> Note that this raises the abstraction level of the API applications = use to talk to the network. As always, this comes with benefits (of = automatizing more things, and not requiring one specific transport = protocol, ..), but also with reduced control over the available = resources. As an extreme example, nobody in their right mind would write = wireshark over TAPS :-) >>=20 >> One proposal is to consider everything related to the usage of = multiple paths automatable. That is, not expose it as a TAPS service. >>=20 >> What do people here think about this? >>=20 >> Cheers, >> Michael >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Jul 20 00:22:29 2016 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 253FD12DADF for ; Wed, 20 Jul 2016 00:22:28 -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, RCVD_IN_DNSWL_MED=-2.3] 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 X7_m1JqkJUb3 for ; Wed, 20 Jul 2016 00:22:25 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (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 2B05312D5A3 for ; Wed, 20 Jul 2016 00:22:25 -0700 (PDT) X-Spam-Processed: mail.kau.se, Wed, 20 Jul 2016 09:22:21 +0200 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 31.133.140.202 X-MDArrival-Date: Wed, 20 Jul 2016 09:22:21 +0200 X-Authenticated-Sender: anna.brunstrom@kau.se X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: taps@ietf.org To: taps@ietf.org References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> <578E4A03.8000006@isi.edu> <578E4CDB.6000201@isi.edu> <39EE3663-F7B4-4C82-98CF-03FA118B5FCC@ifi.uio.no> From: Anna Brunstrom Message-ID: <0b55ae56-eb27-2a12-a2a2-9703f272996c@kau.se> Date: Wed, 20 Jul 2016 09:22:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <39EE3663-F7B4-4C82-98CF-03FA118B5FCC@ifi.uio.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 07:22:28 -0000 On 2016-07-19 17:59, Michael Welzl wrote: >> On 19. jul. 2016, at 17.52, Joe Touch wrote: >> >> >> >> On 7/19/2016 8:49 AM, Michael Welzl wrote: >>>> On 19. jul. 2016, at 17.40, Joe Touch wrote: >>>> >>>> >>>> >>>> On 7/19/2016 5:27 AM, Michael Welzl wrote: >>>>> Thanks - I agree, it’s on the agenda for tomorrow’s MPTCP session, and TAPS is the day after, which fits nicely. >>>>> >>>>> Note, I phrased this controversial on purpose to generate a bit of list discussion: “abstracting away” something like usage of multiple paths should get some people to disagree?! Regarding the primitives we have so far, there doesn’t seem to be a compelling need for a TAPS system to expose them to an application I think. (again, such abstraction always comes with loss of some control - at one end of this, you want to be in control of which transport protocol is used, which we don’t want here). Decisions need to be made... >>>>> >>>>> >>>>> Multi-streaming seems to me to be an easier case: I can’t see any reason why an application would need to be in control of this. Mapping communication channels between the same end hosts onto the same transport connection (whatever protocol provides it) should always be beneficial. >>>> I'm not sure I understand how an app can/should know about any of this. >>>> It strikes me as involving the app deep in "how" things are done in >>>> other layers, rather than indicating a preference on behavior it sees >>>> (it really shouldn't "see" any of this directly, IMO). >>>> >>>> I.e., this would be a good place to take a lesson from QoS - the key is >>>> to indicate a preference to the net based on "application visible >>>> behavior", not to try to map things so directly based on semantics. >>> This sounds like a misunderstanding, maybe I didn’t make myself clear enough - because I think we agree: >>> an application can / should not know about any of this, IMO. It should just see a communication channel. >>> >>> So mapping these channels onto a transport connection is what I thought a TAPS system underneath the application could do, and the application won’t need to be bothered. >> I was speaking to the broader point of this thread and generalizing >> your point about multi-streaming to the multiple path case as well. >> >> (I didn't know if you felt that both cases should be handled the same >> way or whether you were using multi-streaming as an easier case to argue) > I focused on multi-streaming now as an easier case to argue :-) > > Let’s focus on this one first and then get to multipath. Sorry for the mixup! The thing multi-streaming gives that I see could be useful for an application is the ability to give different priorities to different streams/flows. You could abstract that in different ways, but you need some scope for what streams/flows you prioritize between that multi-streaming gives you. Cheers, Anna > > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Jul 20 01:01:59 2016 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 B5FC912D0CD for ; Wed, 20 Jul 2016 01:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 BqRNEkCziTJX for ; Wed, 20 Jul 2016 01:01:55 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDF9612D0A3 for ; Wed, 20 Jul 2016 01:01:54 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bPmS0-0000Oe-Rf; Wed, 20 Jul 2016 10:01:52 +0200 Received: from dhcp-a140.meeting.ietf.org ([31.133.161.64]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bPmS0-0001kl-7p; Wed, 20 Jul 2016 10:01:52 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: <0b55ae56-eb27-2a12-a2a2-9703f272996c@kau.se> Date: Wed, 20 Jul 2016 10:01:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> <578E4A03.8000006@isi.edu> <578E4CDB.6000201@isi.edu> <39EE3663-F7B4-4C82-98CF-03FA118B5FCC@ifi.uio.no> <0b55ae56-eb27-2a12-a2a2-9703f272996c@kau.se> To: Anna Brunstrom X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 5 sum msgs/h 2 total rcpts 44727 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 9C8D0DED47B7C8CE8A297626F34B742EEE5ADB2B X-UiO-SPAM-Test: remote_host: 31.133.161.64 spam_score: -49 maxlevel 80 minaction 2 bait 0 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 08:01:58 -0000 > On 20. jul. 2016, at 09.22, Anna Brunstrom = wrote: >=20 > On 2016-07-19 17:59, Michael Welzl wrote: >=20 >>> On 19. jul. 2016, at 17.52, Joe Touch wrote: >>>=20 >>>=20 >>>=20 >>> On 7/19/2016 8:49 AM, Michael Welzl wrote: >>>>> On 19. jul. 2016, at 17.40, Joe Touch wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 7/19/2016 5:27 AM, Michael Welzl wrote: >>>>>> Thanks - I agree, it=E2=80=99s on the agenda for tomorrow=E2=80=99s= MPTCP session, and TAPS is the day after, which fits nicely. >>>>>>=20 >>>>>> Note, I phrased this controversial on purpose to generate a bit = of list discussion: =E2=80=9Cabstracting away=E2=80=9D something like = usage of multiple paths should get some people to disagree?! Regarding = the primitives we have so far, there doesn=E2=80=99t seem to be a = compelling need for a TAPS system to expose them to an application I = think. (again, such abstraction always comes with loss of some control = - at one end of this, you want to be in control of which transport = protocol is used, which we don=E2=80=99t want here). Decisions need to = be made... >>>>>>=20 >>>>>>=20 >>>>>> Multi-streaming seems to me to be an easier case: I can=E2=80=99t = see any reason why an application would need to be in control of this. = Mapping communication channels between the same end hosts onto the same = transport connection (whatever protocol provides it) should always be = beneficial. >>>>> I'm not sure I understand how an app can/should know about any of = this. >>>>> It strikes me as involving the app deep in "how" things are done = in >>>>> other layers, rather than indicating a preference on behavior it = sees >>>>> (it really shouldn't "see" any of this directly, IMO). >>>>>=20 >>>>> I.e., this would be a good place to take a lesson from QoS - the = key is >>>>> to indicate a preference to the net based on "application visible >>>>> behavior", not to try to map things so directly based on = semantics. >>>> This sounds like a misunderstanding, maybe I didn=E2=80=99t make = myself clear enough - because I think we agree: >>>> an application can / should not know about any of this, IMO. It = should just see a communication channel. >>>>=20 >>>> So mapping these channels onto a transport connection is what I = thought a TAPS system underneath the application could do, and the = application won=E2=80=99t need to be bothered. >>> I was speaking to the broader point of this thread and generalizing >>> your point about multi-streaming to the multiple path case as well. >>>=20 >>> (I didn't know if you felt that both cases should be handled the = same >>> way or whether you were using multi-streaming as an easier case to = argue) >> I focused on multi-streaming now as an easier case to argue :-) >>=20 >> Let=E2=80=99s focus on this one first and then get to multipath. = Sorry for the mixup! >=20 > The thing multi-streaming gives that I see could be useful for an = application is the ability to give different priorities to different = streams/flows. You could abstract that in different ways, but you need = some scope for what streams/flows you prioritize between that = multi-streaming gives you. I agree - but I haven=E2=80=99t yet stumbled over prioritization as a = service to the application in one of the SCTP RFCs=E2=80=A6 probably = it=E2=80=99s there somewhere. If it exists, wouldn=E2=80=99t the concept of prioritization within a = definable group of flows be better to expose than multi-streaming as = such? (e.g. this could just as well be mapped down to methods that couple the = congestion control of multiple connections instead of real = multi-streaming) =20 Cheers, Michael From nobody Wed Jul 20 01:27:53 2016 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 B653B12B004 for ; Wed, 20 Jul 2016 01:27:50 -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, RCVD_IN_DNSWL_MED=-2.3] 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 1ESg7gArDRco for ; Wed, 20 Jul 2016 01:27:48 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15CB12B039 for ; Wed, 20 Jul 2016 01:27:44 -0700 (PDT) Received: from [2001:67c:370:152:a0bb:2468:bce:8f02] (port=52050) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bPmqx-0003jg-MH; Wed, 20 Jul 2016 09:27:40 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <578E5002.4050405@erg.abdn.ac.uk> Date: Wed, 20 Jul 2016 10:27:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> <578E4A03.8000006@isi.edu> <578E5002.4050405@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Aaron Falk , Joe Touch , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 08:27:51 -0000 > On 19 Jul 2016, at 18:06, G Fairhurst wrote: > On 19/07/2016, 17:49, Michael Welzl wrote: >>> On 19. jul. 2016, at 17.40, Joe Touch wrote: >>> On 7/19/2016 5:27 AM, Michael Welzl wrote: >>>> Thanks - I agree, it=E2=80=99s on the agenda for tomorrow=E2=80=99s = MPTCP session, and TAPS is the day after, which fits nicely. >>>>=20 >>>> Note, I phrased this controversial on purpose to generate a bit of = list discussion: =E2=80=9Cabstracting away=E2=80=9D something like usage = of multiple paths should get some people to disagree?! Regarding the = primitives we have so far, there doesn=E2=80=99t seem to be a compelling = need for a TAPS system to expose them to an application I think. = (again, such abstraction always comes with loss of some control - at one = end of this, you want to be in control of which transport protocol is = used, which we don=E2=80=99t want here). Decisions need to be made... >>>>=20 >>>>=20 >>>> Multi-streaming seems to me to be an easier case: I can=E2=80=99t = see any reason why an application would need to be in control of this. = Mapping communication channels between the same end hosts onto the same = transport connection (whatever protocol provides it) should always be = beneficial. >>> I'm not sure I understand how an app can/should know about any of = this. >>> It strikes me as involving the app deep in "how" things are done in >>> other layers, rather than indicating a preference on behavior it = sees >>> (it really shouldn't "see" any of this directly, IMO). >>>=20 >>> I.e., this would be a good place to take a lesson from QoS - the key = is >>> to indicate a preference to the net based on "application visible >>> behavior", not to try to map things so directly based on semantics. >> This sounds like a misunderstanding, maybe I didn=E2=80=99t make = myself clear enough - because I think we agree: >> an application can / should not know about any of this, IMO. It = should just see a communication channel. >>=20 >> So mapping these channels onto a transport connection is what I = thought a TAPS system underneath the application could do, and the = application won=E2=80=99t need to be bothered. >>=20 >> Cheers, >> Michael > I can agree that applications should be encouraged to let the system = figure out how best to do these things. >=20 > A few applications will always want finer control (of QoS and flow = scheduling) - presumably because they believe they understand what they = actually need. I suggest even these apps can benefit from system-learned = information about what the network can actually offer. Agree - exposing system-learned knowledge is clearly useful. I=E2=80=99m = all for automating things where possible, but there are applications = that can make use of additional knowledge to tune transport to better = suit the application. Hide by default, sure, but allow tuning. --=20 Colin Perkins https://csperkins.org/ From nobody Wed Jul 20 01:38:35 2016 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 4054E12D0B3 for ; Wed, 20 Jul 2016 01:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 u7gTBypr5TpF for ; Wed, 20 Jul 2016 01:38:32 -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 AB0C212B037 for ; Wed, 20 Jul 2016 01:38:31 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bPn1P-00084V-Co; Wed, 20 Jul 2016 10:38:27 +0200 Received: from dhcp-a140.meeting.ietf.org ([31.133.161.64]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bPn1O-0002yj-Lj; Wed, 20 Jul 2016 10:38:27 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Wed, 20 Jul 2016 10:38:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <963EA6F4-DAE7-47A9-A75A-7CDDC5683B4F@ifi.uio.no> References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> <578E4A03.8000006@isi.edu> <578E5002.4050405@erg.abdn.ac.uk> To: Colin Perkins X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 12 msgs/h 5 sum rcpts/h 15 sum msgs/h 6 total rcpts 44737 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 594CD51C7D74D503A3B31BA11EA66F225ECE7ACC X-UiO-SPAM-Test: remote_host: 31.133.161.64 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 4 max/h 4 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: " Fairhurst" , Aaron Falk , Joe Touch , =?utf-8?Q?Mirja_K=C3=BChlewind?= , "taps@ietf.org" Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 08:38:34 -0000 > On 20. jul. 2016, at 10.27, Colin Perkins wrote: >=20 >> On 19 Jul 2016, at 18:06, G Fairhurst wrote: >> On 19/07/2016, 17:49, Michael Welzl wrote: >>>> On 19. jul. 2016, at 17.40, Joe Touch wrote: >>>> On 7/19/2016 5:27 AM, Michael Welzl wrote: >>>>> Thanks - I agree, it=E2=80=99s on the agenda for tomorrow=E2=80=99s = MPTCP session, and TAPS is the day after, which fits nicely. >>>>>=20 >>>>> Note, I phrased this controversial on purpose to generate a bit of = list discussion: =E2=80=9Cabstracting away=E2=80=9D something like usage = of multiple paths should get some people to disagree?! Regarding the = primitives we have so far, there doesn=E2=80=99t seem to be a compelling = need for a TAPS system to expose them to an application I think. = (again, such abstraction always comes with loss of some control - at one = end of this, you want to be in control of which transport protocol is = used, which we don=E2=80=99t want here). Decisions need to be made... >>>>>=20 >>>>>=20 >>>>> Multi-streaming seems to me to be an easier case: I can=E2=80=99t = see any reason why an application would need to be in control of this. = Mapping communication channels between the same end hosts onto the same = transport connection (whatever protocol provides it) should always be = beneficial. >>>> I'm not sure I understand how an app can/should know about any of = this. >>>> It strikes me as involving the app deep in "how" things are done in >>>> other layers, rather than indicating a preference on behavior it = sees >>>> (it really shouldn't "see" any of this directly, IMO). >>>>=20 >>>> I.e., this would be a good place to take a lesson from QoS - the = key is >>>> to indicate a preference to the net based on "application visible >>>> behavior", not to try to map things so directly based on semantics. >>> This sounds like a misunderstanding, maybe I didn=E2=80=99t make = myself clear enough - because I think we agree: >>> an application can / should not know about any of this, IMO. It = should just see a communication channel. >>>=20 >>> So mapping these channels onto a transport connection is what I = thought a TAPS system underneath the application could do, and the = application won=E2=80=99t need to be bothered. >>>=20 >>> Cheers, >>> Michael >> I can agree that applications should be encouraged to let the system = figure out how best to do these things. >>=20 >> A few applications will always want finer control (of QoS and flow = scheduling) - presumably because they believe they understand what they = actually need. I suggest even these apps can benefit from system-learned = information about what the network can actually offer. >=20 > Agree - exposing system-learned knowledge is clearly useful. I=E2=80=99m= all for automating things where possible, but there are applications = that can make use of additional knowledge to tune transport to better = suit the application. Hide by default, sure, but allow tuning. So in TAPS it seems to me that we=E2=80=99ll ALWAYS have someone saying = =E2=80=9Cbut there can be a benefit if an application can do X, Y, Z=E2=80= =9D. And these always true statements. Everything that=E2=80=99s now there is = there for a reason, so whatever you remove will always come with an = example of an application that can make good use of it. In the end, we = have the same API as today and nothing has been achieved. So: sure a good TAPS API should allow applications to tune everything. = Let=E2=80=99s make this clear once and for all, for all things that we = potentially =E2=80=9Cautomatize=E2=80=9D, =E2=80=9Chide=E2=80=9D or = whatever you to call it. But: I do think the point here is to identify which things should be = =E2=80=9Chidden by default=E2=80=9D (to stay with your language, it = doesn=E2=80=99t really matter what we call it). Cheers, Michael From nobody Wed Jul 20 01:42:58 2016 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 25DFF12DAEC for ; Wed, 20 Jul 2016 01:42:57 -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, RCVD_IN_DNSWL_MED=-2.3] 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 DqzAxzTe7JUV for ; Wed, 20 Jul 2016 01:42:54 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E90012B037 for ; Wed, 20 Jul 2016 01:42:46 -0700 (PDT) Received: from [2001:67c:370:152:a0bb:2468:bce:8f02] (port=52469) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bPn5V-0005SI-FU; Wed, 20 Jul 2016 09:42:42 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <963EA6F4-DAE7-47A9-A75A-7CDDC5683B4F@ifi.uio.no> Date: Wed, 20 Jul 2016 10:42:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> <578E4A03.8000006@isi.edu> <578E5002.4050405@erg.abdn.ac.uk> <963EA6F4-DAE7-47A9-A75A-7CDDC5683B4F@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Gorry Fairhurst , Aaron Falk , Joe Touch , =?utf-8?Q?Mirja_K=C3=BChlewind?= , "taps@ietf.org" Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 08:42:57 -0000 > On 20 Jul 2016, at 10:38, Michael Welzl wrote: >=20 >>=20 >> On 20. jul. 2016, at 10.27, Colin Perkins wrote: >>=20 >>> On 19 Jul 2016, at 18:06, G Fairhurst wrote: >>> On 19/07/2016, 17:49, Michael Welzl wrote: >>>>> On 19. jul. 2016, at 17.40, Joe Touch wrote: >>>>> On 7/19/2016 5:27 AM, Michael Welzl wrote: >>>>>> Thanks - I agree, it=E2=80=99s on the agenda for tomorrow=E2=80=99s= MPTCP session, and TAPS is the day after, which fits nicely. >>>>>>=20 >>>>>> Note, I phrased this controversial on purpose to generate a bit = of list discussion: =E2=80=9Cabstracting away=E2=80=9D something like = usage of multiple paths should get some people to disagree?! Regarding = the primitives we have so far, there doesn=E2=80=99t seem to be a = compelling need for a TAPS system to expose them to an application I = think. (again, such abstraction always comes with loss of some control = - at one end of this, you want to be in control of which transport = protocol is used, which we don=E2=80=99t want here). Decisions need to = be made... >>>>>>=20 >>>>>>=20 >>>>>> Multi-streaming seems to me to be an easier case: I can=E2=80=99t = see any reason why an application would need to be in control of this. = Mapping communication channels between the same end hosts onto the same = transport connection (whatever protocol provides it) should always be = beneficial. >>>>> I'm not sure I understand how an app can/should know about any of = this. >>>>> It strikes me as involving the app deep in "how" things are done = in >>>>> other layers, rather than indicating a preference on behavior it = sees >>>>> (it really shouldn't "see" any of this directly, IMO). >>>>>=20 >>>>> I.e., this would be a good place to take a lesson from QoS - the = key is >>>>> to indicate a preference to the net based on "application visible >>>>> behavior", not to try to map things so directly based on = semantics. >>>> This sounds like a misunderstanding, maybe I didn=E2=80=99t make = myself clear enough - because I think we agree: >>>> an application can / should not know about any of this, IMO. It = should just see a communication channel. >>>>=20 >>>> So mapping these channels onto a transport connection is what I = thought a TAPS system underneath the application could do, and the = application won=E2=80=99t need to be bothered. >>>>=20 >>>> Cheers, >>>> Michael >>> I can agree that applications should be encouraged to let the system = figure out how best to do these things. >>>=20 >>> A few applications will always want finer control (of QoS and flow = scheduling) - presumably because they believe they understand what they = actually need. I suggest even these apps can benefit from system-learned = information about what the network can actually offer. >>=20 >> Agree - exposing system-learned knowledge is clearly useful. I=E2=80=99= m all for automating things where possible, but there are applications = that can make use of additional knowledge to tune transport to better = suit the application. Hide by default, sure, but allow tuning. >=20 > So in TAPS it seems to me that we=E2=80=99ll ALWAYS have someone = saying =E2=80=9Cbut there can be a benefit if an application can do X, = Y, Z=E2=80=9D. > And these always true statements. Everything that=E2=80=99s now there = is there for a reason, so whatever you remove will always come with an = example of an application that can make good use of it. In the end, we = have the same API as today and nothing has been achieved. Surely you have a better API, with well-thought out hooks for tuning? > So: sure a good TAPS API should allow applications to tune everything. = Let=E2=80=99s make this clear once and for all, for all things that we = potentially =E2=80=9Cautomatize=E2=80=9D, =E2=80=9Chide=E2=80=9D or = whatever you to call it. >=20 > But: I do think the point here is to identify which things should be = =E2=80=9Chidden by default=E2=80=9D (to stay with your language, it = doesn=E2=80=99t really matter what we call it). Agree. I=E2=80=99m just reacting to =E2=80=9Cyou=E2=80=99re suggesting = to *not* expose these transport services too? I=E2=80=99d agree=E2=80=9D = which suggests something a little different. --=20 Colin Perkins https://csperkins.org/ From nobody Wed Jul 20 01:45:01 2016 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 1AA9412D0B3 for ; Wed, 20 Jul 2016 01:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 7ptHhsmh2ftR for ; Wed, 20 Jul 2016 01:44:57 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD9B12D099 for ; Wed, 20 Jul 2016 01:44:57 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bPn7d-0005em-Fu; Wed, 20 Jul 2016 10:44:53 +0200 Received: from dhcp-a140.meeting.ietf.org ([31.133.161.64]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bPn7c-0005Sv-DR; Wed, 20 Jul 2016 10:44:53 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Wed, 20 Jul 2016 10:44:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> <578E4A03.8000006@isi.edu> <578E5002.4050405@erg.abdn.ac.uk> <963EA6F4-DAE7-47A9-A75A-7CDDC5683B4F@ifi.uio.no> To: Colin Perkins X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 21 msgs/h 8 sum rcpts/h 24 sum msgs/h 9 total rcpts 44746 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 91B1C1B7B89B2E744F747416FD48367B89C2ABF0 X-UiO-SPAM-Test: remote_host: 31.133.161.64 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 7 total 7 max/h 7 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: " Fairhurst" , Aaron Falk , Joe Touch , =?utf-8?Q?Mirja_K=C3=BChlewind?= , "taps@ietf.org" Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 08:45:00 -0000 > On 20. jul. 2016, at 10.42, Colin Perkins wrote: >=20 >=20 >> On 20 Jul 2016, at 10:38, Michael Welzl wrote: >>=20 >>>=20 >>> On 20. jul. 2016, at 10.27, Colin Perkins wrote: >>>=20 >>>> On 19 Jul 2016, at 18:06, G Fairhurst wrote: >>>> On 19/07/2016, 17:49, Michael Welzl wrote: >>>>>> On 19. jul. 2016, at 17.40, Joe Touch wrote: >>>>>> On 7/19/2016 5:27 AM, Michael Welzl wrote: >>>>>>> Thanks - I agree, it=E2=80=99s on the agenda for tomorrow=E2=80=99= s MPTCP session, and TAPS is the day after, which fits nicely. >>>>>>>=20 >>>>>>> Note, I phrased this controversial on purpose to generate a bit = of list discussion: =E2=80=9Cabstracting away=E2=80=9D something like = usage of multiple paths should get some people to disagree?! Regarding = the primitives we have so far, there doesn=E2=80=99t seem to be a = compelling need for a TAPS system to expose them to an application I = think. (again, such abstraction always comes with loss of some control = - at one end of this, you want to be in control of which transport = protocol is used, which we don=E2=80=99t want here). Decisions need to = be made... >>>>>>>=20 >>>>>>>=20 >>>>>>> Multi-streaming seems to me to be an easier case: I can=E2=80=99t = see any reason why an application would need to be in control of this. = Mapping communication channels between the same end hosts onto the same = transport connection (whatever protocol provides it) should always be = beneficial. >>>>>> I'm not sure I understand how an app can/should know about any of = this. >>>>>> It strikes me as involving the app deep in "how" things are done = in >>>>>> other layers, rather than indicating a preference on behavior it = sees >>>>>> (it really shouldn't "see" any of this directly, IMO). >>>>>>=20 >>>>>> I.e., this would be a good place to take a lesson from QoS - the = key is >>>>>> to indicate a preference to the net based on "application visible >>>>>> behavior", not to try to map things so directly based on = semantics. >>>>> This sounds like a misunderstanding, maybe I didn=E2=80=99t make = myself clear enough - because I think we agree: >>>>> an application can / should not know about any of this, IMO. It = should just see a communication channel. >>>>>=20 >>>>> So mapping these channels onto a transport connection is what I = thought a TAPS system underneath the application could do, and the = application won=E2=80=99t need to be bothered. >>>>>=20 >>>>> Cheers, >>>>> Michael >>>> I can agree that applications should be encouraged to let the = system figure out how best to do these things. >>>>=20 >>>> A few applications will always want finer control (of QoS and flow = scheduling) - presumably because they believe they understand what they = actually need. I suggest even these apps can benefit from system-learned = information about what the network can actually offer. >>>=20 >>> Agree - exposing system-learned knowledge is clearly useful. I=E2=80=99= m all for automating things where possible, but there are applications = that can make use of additional knowledge to tune transport to better = suit the application. Hide by default, sure, but allow tuning. >>=20 >> So in TAPS it seems to me that we=E2=80=99ll ALWAYS have someone = saying =E2=80=9Cbut there can be a benefit if an application can do X, = Y, Z=E2=80=9D. >> And these always true statements. Everything that=E2=80=99s now there = is there for a reason, so whatever you remove will always come with an = example of an application that can make good use of it. In the end, we = have the same API as today and nothing has been achieved. >=20 > Surely you have a better API, with well-thought out hooks for tuning? A good TAPS implementation should! For now, with our =E2=80=9Cminset=E2=80=9D draft, TAPS is only = identifying which things could be =E2=80=9Chidden=E2=80=9D = (automatized). >> So: sure a good TAPS API should allow applications to tune = everything. Let=E2=80=99s make this clear once and for all, for all = things that we potentially =E2=80=9Cautomatize=E2=80=9D, =E2=80=9Chide=E2=80= =9D or whatever you to call it. >>=20 >> But: I do think the point here is to identify which things should be = =E2=80=9Chidden by default=E2=80=9D (to stay with your language, it = doesn=E2=80=99t really matter what we call it). >=20 > Agree. I=E2=80=99m just reacting to =E2=80=9Cyou=E2=80=99re suggesting = to *not* expose these transport services too? I=E2=80=99d agree=E2=80=9D = which suggests something a little different. Ah. Ok - have to be careful with language=E2=80=A6 =E2=80=9Cnot = expose=E2=80=9D is stricter than what I meant. Cheers, Michael From nobody Thu Jul 21 15:21:55 2016 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 9ABC412D7DE for ; Thu, 21 Jul 2016 15:21:53 -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, RCVD_IN_DNSWL_MED=-2.3] 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 JmebBsboHYx4 for ; Thu, 21 Jul 2016 15:21:50 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (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 BA5B712D871 for ; Thu, 21 Jul 2016 15:21:50 -0700 (PDT) X-Spam-Processed: mail.kau.se, Fri, 22 Jul 2016 00:21:46 +0200 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 31.133.140.202 X-MDArrival-Date: Fri, 22 Jul 2016 00:21:46 +0200 X-Authenticated-Sender: anna.brunstrom@kau.se X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: taps@ietf.org To: taps@ietf.org From: Anna Brunstrom Message-ID: <64622ecb-6526-c408-8c07-b62161b12aff@kau.se> Date: Fri, 22 Jul 2016 00:21:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Taps] Happy Eyeballs references X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 22:21:53 -0000 Hi all, I realized that I never showed you my last slide with the reference to the paper when presenting our happy eyeballs results in the taps session today. If you want to see the details of the evaluation, the paper is available at https://irtf.org/anrw/2016/anrw16-final27.pdf. And our initial happy eyeballs draft is available at https://datatracker.ietf.org/doc/draft-grinnemo-taps-he/. Cheers, Anna From nobody Fri Jul 22 01:28:10 2016 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 798A312D5EB for ; Fri, 22 Jul 2016 01:28:08 -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, RCVD_IN_DNSWL_MED=-2.3] 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 4jBHGUdFsi0P for ; Fri, 22 Jul 2016 01:28:06 -0700 (PDT) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (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 115F512D1A4 for ; Fri, 22 Jul 2016 01:28:05 -0700 (PDT) X-Spam-Processed: mail.kau.se, Fri, 22 Jul 2016 10:28:02 +0200 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 31.133.152.127 X-MDArrival-Date: Fri, 22 Jul 2016 10:28:02 +0200 X-Authenticated-Sender: anna.brunstrom@kau.se X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se To: Michael Welzl References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> <578E4A03.8000006@isi.edu> <578E4CDB.6000201@isi.edu> <39EE3663-F7B4-4C82-98CF-03FA118B5FCC@ifi.uio.no> <0b55ae56-eb27-2a12-a2a2-9703f272996c@kau.se> From: Anna Brunstrom Message-ID: Date: Fri, 22 Jul 2016 10:27:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 08:28:08 -0000 On 2016-07-20 10:01, Michael Welzl wrote: >> On 20. jul. 2016, at 09.22, Anna Brunstrom wrote: >> >> On 2016-07-19 17:59, Michael Welzl wrote: >> >>>> On 19. jul. 2016, at 17.52, Joe Touch wrote: >>>> >>>> >>>> >>>> On 7/19/2016 8:49 AM, Michael Welzl wrote: >>>>>> On 19. jul. 2016, at 17.40, Joe Touch wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 7/19/2016 5:27 AM, Michael Welzl wrote: >>>>>>> Thanks - I agree, it’s on the agenda for tomorrow’s MPTCP session, and TAPS is the day after, which fits nicely. >>>>>>> >>>>>>> Note, I phrased this controversial on purpose to generate a bit of list discussion: “abstracting away” something like usage of multiple paths should get some people to disagree?! Regarding the primitives we have so far, there doesn’t seem to be a compelling need for a TAPS system to expose them to an application I think. (again, such abstraction always comes with loss of some control - at one end of this, you want to be in control of which transport protocol is used, which we don’t want here). Decisions need to be made... >>>>>>> >>>>>>> >>>>>>> Multi-streaming seems to me to be an easier case: I can’t see any reason why an application would need to be in control of this. Mapping communication channels between the same end hosts onto the same transport connection (whatever protocol provides it) should always be beneficial. >>>>>> I'm not sure I understand how an app can/should know about any of this. >>>>>> It strikes me as involving the app deep in "how" things are done in >>>>>> other layers, rather than indicating a preference on behavior it sees >>>>>> (it really shouldn't "see" any of this directly, IMO). >>>>>> >>>>>> I.e., this would be a good place to take a lesson from QoS - the key is >>>>>> to indicate a preference to the net based on "application visible >>>>>> behavior", not to try to map things so directly based on semantics. >>>>> This sounds like a misunderstanding, maybe I didn’t make myself clear enough - because I think we agree: >>>>> an application can / should not know about any of this, IMO. It should just see a communication channel. >>>>> >>>>> So mapping these channels onto a transport connection is what I thought a TAPS system underneath the application could do, and the application won’t need to be bothered. >>>> I was speaking to the broader point of this thread and generalizing >>>> your point about multi-streaming to the multiple path case as well. >>>> >>>> (I didn't know if you felt that both cases should be handled the same >>>> way or whether you were using multi-streaming as an easier case to argue) >>> I focused on multi-streaming now as an easier case to argue :-) >>> >>> Let’s focus on this one first and then get to multipath. Sorry for the mixup! >> The thing multi-streaming gives that I see could be useful for an application is the ability to give different priorities to different streams/flows. You could abstract that in different ways, but you need some scope for what streams/flows you prioritize between that multi-streaming gives you. > I agree - but I haven’t yet stumbled over prioritization as a service to the application in one of the SCTP RFCs… probably it’s there somewhere. The ndata draft that I guess will be a RFC fairly soon has a priority scheduler as part of it. > If it exists, wouldn’t the concept of prioritization within a definable group of flows be better to expose than multi-streaming as such? Yes, I agree that this would be a more general abstraction. Cheers, Anna > (e.g. this could just as well be mapped down to methods that couple the congestion control of multiple connections instead of real multi-streaming) > > Cheers, > Michael > From nobody Fri Jul 22 01:30:27 2016 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 A6CC912D1A4 for ; Fri, 22 Jul 2016 01:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 tTpxW5WnFlqC for ; Fri, 22 Jul 2016 01:30:23 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9AD912DA5B for ; Fri, 22 Jul 2016 01:30:22 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bQVqe-0002Aq-Mw; Fri, 22 Jul 2016 10:30:20 +0200 Received: from dhcp-a3aa.meeting.ietf.org ([31.133.163.170]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bQVqe-0001aW-3Q; Fri, 22 Jul 2016 10:30:20 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Fri, 22 Jul 2016 10:30:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5A4B3BF1-E975-4262-93D0-59F05690188D@ifi.uio.no> References: <998665cac1e6f16a8623e12e27a1faa3@ulrik.uio.no> <3D0FE67E-F7D9-49A0-B442-7468E1608BFA@tik.ee.ethz.ch> <578E4A03.8000006@isi.edu> <578E4CDB.6000201@isi.edu> <39EE3663-F7B4-4C82-98CF-03FA118B5FCC@ifi.uio.no> <0b55ae56-eb27-2a12-a2a2-9703f272996c@kau.se> To: Anna Brunstrom X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 4 sum rcpts/h 7 sum msgs/h 5 total rcpts 44870 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6C7A752247903D46DB101913FDC8C40F4030F5C0 X-UiO-SPAM-Test: remote_host: 31.133.163.170 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 14 max/h 9 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] Abstracting away multi-streaming usage of multiple paths X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 08:30:26 -0000 > On 22. jul. 2016, at 10.27, Anna Brunstrom = wrote: >=20 > On 2016-07-20 10:01, Michael Welzl wrote: >=20 >>> On 20. jul. 2016, at 09.22, Anna Brunstrom = wrote: >>>=20 >>> On 2016-07-19 17:59, Michael Welzl wrote: >>>=20 >>>>> On 19. jul. 2016, at 17.52, Joe Touch wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 7/19/2016 8:49 AM, Michael Welzl wrote: >>>>>>> On 19. jul. 2016, at 17.40, Joe Touch wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 7/19/2016 5:27 AM, Michael Welzl wrote: >>>>>>>> Thanks - I agree, it=E2=80=99s on the agenda for tomorrow=E2=80=99= s MPTCP session, and TAPS is the day after, which fits nicely. >>>>>>>>=20 >>>>>>>> Note, I phrased this controversial on purpose to generate a bit = of list discussion: =E2=80=9Cabstracting away=E2=80=9D something like = usage of multiple paths should get some people to disagree?! Regarding = the primitives we have so far, there doesn=E2=80=99t seem to be a = compelling need for a TAPS system to expose them to an application I = think. (again, such abstraction always comes with loss of some control = - at one end of this, you want to be in control of which transport = protocol is used, which we don=E2=80=99t want here). Decisions need to = be made... >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Multi-streaming seems to me to be an easier case: I can=E2=80=99t= see any reason why an application would need to be in control of this. = Mapping communication channels between the same end hosts onto the same = transport connection (whatever protocol provides it) should always be = beneficial. >>>>>>> I'm not sure I understand how an app can/should know about any = of this. >>>>>>> It strikes me as involving the app deep in "how" things are done = in >>>>>>> other layers, rather than indicating a preference on behavior it = sees >>>>>>> (it really shouldn't "see" any of this directly, IMO). >>>>>>>=20 >>>>>>> I.e., this would be a good place to take a lesson from QoS - the = key is >>>>>>> to indicate a preference to the net based on "application = visible >>>>>>> behavior", not to try to map things so directly based on = semantics. >>>>>> This sounds like a misunderstanding, maybe I didn=E2=80=99t make = myself clear enough - because I think we agree: >>>>>> an application can / should not know about any of this, IMO. It = should just see a communication channel. >>>>>>=20 >>>>>> So mapping these channels onto a transport connection is what I = thought a TAPS system underneath the application could do, and the = application won=E2=80=99t need to be bothered. >>>>> I was speaking to the broader point of this thread and = generalizing >>>>> your point about multi-streaming to the multiple path case as = well. >>>>>=20 >>>>> (I didn't know if you felt that both cases should be handled the = same >>>>> way or whether you were using multi-streaming as an easier case to = argue) >>>> I focused on multi-streaming now as an easier case to argue :-) >>>>=20 >>>> Let=E2=80=99s focus on this one first and then get to multipath. = Sorry for the mixup! >>> The thing multi-streaming gives that I see could be useful for an = application is the ability to give different priorities to different = streams/flows. You could abstract that in different ways, but you need = some scope for what streams/flows you prioritize between that = multi-streaming gives you. >> I agree - but I haven=E2=80=99t yet stumbled over prioritization as a = service to the application in one of the SCTP RFCs=E2=80=A6 probably = it=E2=80=99s there somewhere. >=20 > The ndata draft that I guess will be a RFC fairly soon has a priority = scheduler as part of it. Ah! Cool, thanks for the pointer >> If it exists, wouldn=E2=80=99t the concept of prioritization within a = definable group of flows be better to expose than multi-streaming as = such? >=20 > Yes, I agree that this would be a more general abstraction. We can make that happen in the minset draft :-) Very helpful, thank you! Cheers, Michael