From jmpolk@cisco.com Thu Aug 1 12:43:03 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB8B21E820D for ; Thu, 1 Aug 2013 12:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucbB9VxMiU8m for ; Thu, 1 Aug 2013 12:42:58 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C55AB21E80CB for ; Thu, 1 Aug 2013 12:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1029; q=dns/txt; s=iport; t=1375386170; x=1376595770; h=message-id:date:to:from:subject:mime-version; bh=a9+q12Ikc2NAnZVGcF9BvSl0SeE8CZhTBgKtgTxLa+o=; b=DCD0/M45wh8jzGHhxBmwBi5yOdQWfY21mDNAD9oUDVLFArGAGHU3FyMN R8ihgKS0HxFz6K1f472pheWW1oNTASKiZRnEmB8t6XmW9cIUrLmqOBKN4 OZIXhM8OIPXjr9L3I0R+B8d8HPyvQpfoPItSr5gG9mFdfDIjCI4scvXS0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACi5+lGtJV2Y/2dsb2JhbABbgwY1wDkWdIJjAlYlFR8KiGcMmUegNZAkg3YDiSqPX5AkgzIe X-IronPort-AV: E=Sophos;i="4.89,796,1367971200"; d="scan'208";a="242240533" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 01 Aug 2013 19:42:49 +0000 Received: from jmpolk-WS.cisco.com ([10.89.8.39]) (authenticated bits=0) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r71Jgnb4020044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Aug 2013 19:42:49 GMT Message-Id: <201308011942.r71Jgnb4020044@rcdn-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 01 Aug 2013 14:42:44 -0500 To: tsvwg@ietf.org From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: [tsvwg] Start of WGLC on draft-ietf-tsvwg-rsvp-pcn X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 19:43:03 -0000 TSVWG This is the start of the WGLC on "Generic Aggregated RSVP for IPv4 and IPv6 Reservations Over PCN Domains" http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-pcn/ This WGLC will last until Friday, August 23rd, 2013, which is 3 weeks after the conclusion of this IETF. The chairs reserve the right to keep any discussion going and prolong the end of the WGLC if the chairs see _value_ in "ongoing and active discussions" around the 23rd. Once those specific discussions are concluded - or stalled - the WGLC will conclude. A good note to the list is "I have read this version of the draft, and I approve (or support) its progression to RFC". The chairs request at least a couple of notes to the list showing support to get a sense of the WG. Of course, you can ask for alternate text (where you supply the actual replacement text, or convey the meaning sufficiently to the authors) for anywhere in the document that you find unclear or troublesome. James/Gorry/David TSVWG chairs From internet-drafts@ietf.org Thu Aug 1 22:52:22 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D34D11E8221; Thu, 1 Aug 2013 22:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHpdrOeI1Bkt; Thu, 1 Aug 2013 22:52:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C21711E8167; Thu, 1 Aug 2013 22:52:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130802055220.19045.65951.idtracker@ietfa.amsl.com> Date: Thu, 01 Aug 2013 22:52:20 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-byte-pkt-congest-11.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 05:52:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : Byte and Packet Congestion Notification Author(s) : Bob Briscoe Jukka Manner Filename : draft-ietf-tsvwg-byte-pkt-congest-11.txt Pages : 46 Date : 2013-08-01 Abstract: This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, including random early detection (RED), BLUE, pre- congestion notification (PCN) and newer schemes such as CoDel and PIE. We give three strong recommendations: (1) packet size should be taken into account when transports detect and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) in the specific case of RED, the byte-mode packet drop variant that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-byte-pkt-congest There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-byte-pkt-congest-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-byte-pkt-congest-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 bob.briscoe@bt.com Thu Aug 1 23:07:43 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B77211E823D for ; Thu, 1 Aug 2013 23:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjJa+BM9LUkh for ; Thu, 1 Aug 2013 23:07:37 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id F3E1A11E824D for ; Thu, 1 Aug 2013 23:07:36 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 2 Aug 2013 07:07:35 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 2 Aug 2013 07:07:34 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.342.3; Fri, 2 Aug 2013 07:07:34 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.168.8]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r7267VAP023914; Fri, 2 Aug 2013 07:07:32 +0100 Message-ID: <201308020607.r7267VAP023914@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 2 Aug 2013 07:04:10 +0100 To: Martin Stiemerling From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tsvwg IETF list , "BLACK, David" , Fred Baker Subject: [tsvwg] New Version - draft-ietf-tsvwg-byte-pkt-congest-11.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 06:07:44 -0000 X-List-Received-Date: Fri, 02 Aug 2013 06:07:44 -0000 Martin, Following all the useful wg last call comments, we (Jukka & I) have posted an update to byte-pkt that has been passed by the doc shepherd (Gorry). I assume you now take it back through the IESG. Thanks particularly to Gorry, Fred Baker, David Black & Dave Taht this time round. Full diffs at Also, diffs summarised in an appendix and below: From -10 to -11: Following a further WGLC: * Abstract: clarified that advice applies to all AQMs including newer ones * Abstract & Intro: changed 'read' to 'detect', because you don't read losses, you detect them. * S.1. Introduction: Disambiguated summary of advice on queue measurement. * Clarified that the doc deprecates any preference based solely on packet size, it's not only against preferring smaller packets. * S.4.1.2. Congestion Measurement without a Queue: Explained that a queue of TXOPs represents a queue into spectrum congested by too many bits. * S.5.2: Bit- & Packet-congestible Network: Referred to explanation in S.4.1.2 to make the point that TXOPs are not a primary unit of workload like bits and packets are, even though you get queues of TXOPs. * 6. Security: Disambiguated 'bias towards'. * 8. Conclusions: Made consistent with recommendation to use time if possible for queue measurement. Bob >From: >To: , > , > >Date: Thu, 1 Aug 2013 22:52:21 -0700 >Subject: New Version Notification - draft-ietf-tsvwg-byte-pkt-congest-11.txt > > >A new version (-11) has been submitted for draft-ietf-tsvwg-byte-pkt-congest: >http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-byte-pkt-congest-11.txt > > >The IETF datatracker page for this Internet-Draft is: >https://datatracker.ietf.org/doc/draft-ietf-tsvwg-byte-pkt-congest/ > >Diff from previous version: >http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-byte-pkt-congest-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. > >IETF Secretariat. ________________________________________________________________ Bob Briscoe, BT From gorry@erg.abdn.ac.uk Sun Aug 4 09:04:24 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BBE21F9BA4; Sun, 4 Aug 2013 09:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.571 X-Spam-Level: X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1zxFgv4p5oW; Sun, 4 Aug 2013 09:04:17 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBCB21F9B58; Sun, 4 Aug 2013 09:04:14 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 794402B44BB; Sun, 4 Aug 2013 17:04:13 +0100 (BST) Received: from ra-gorry.erg.abdn.ac.uk (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 94A6B2B4356; Sun, 4 Aug 2013 17:04:12 +0100 (BST) Message-ID: <51FE7B7B.5050500@erg.abdn.ac.uk> Date: Sun, 04 Aug 2013 18:04:11 +0200 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tsvwg-chairs@ietf.org Subject: [tsvwg] WGLC Announcement for draft-ietf-tsvwg-byte-pkt-congest-11 - end 19th August X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 16:04:24 -0000 This email announces the start of a working group last call to confirm publication of draft-ietf-tsvwg-byte-pkt-congest-11, "Byte and Packet Congestion Notification". This document was returned to the WG after IESG review and has been updated in response to feedback. It is now thought to be ready to proceed to be published as a BCP. Please send any comments to the TSVWG list. The draft is available at: http://tools.ietf.org/html/draft-ietf-tsvwg-byte-pkt-congest-11 The last call will run for TWO weeks, ending 19th August. James, David, and Gorry (TSVWG Chairs) tsvwg-chairs@ietf.org From michael.scharf@alcatel-lucent.com Tue Aug 6 01:26:05 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C67621F9D07; Tue, 6 Aug 2013 01:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.521 X-Spam-Level: X-Spam-Status: No, score=-10.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qdNTHTD8d4E; Tue, 6 Aug 2013 01:25:59 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D1F0721F8AA1; Tue, 6 Aug 2013 01:25:58 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r768Pr0e023369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Aug 2013 03:25:54 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r768Pqmq023644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 10:25:52 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 6 Aug 2013 10:25:52 +0200 From: "Scharf, Michael (Michael)" To: Roberto Peon , HTTP Working Group , "tsvwg@ietf.org" Thread-Topic: The List (of application-layer desired features) Thread-Index: AQHOkn1KzYd49rHxbUOlPV1nhDLm1JmHs8IAgAAjuFA= Date: Tue, 6 Aug 2013 08:25:52 +0000 Message-ID: <655C07320163294895BBADA28372AF5D07EE42@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "tcpm@ietf.org" Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 08:26:05 -0000 Well, part of this is also related to TCPM, but for simplicity I am fine wi= th keeping the discussion on the TSVWG list right now. The community is mos= tly the same anyway... Michael > -----Original Message----- > From: Roberto Peon [mailto:grmocg@gmail.com]=20 > Sent: Tuesday, August 06, 2013 10:16 AM > To: HTTP Working Group; tsvwg@ietf.org > Subject: Re: The List (of application-layer desired features) >=20 > Actually sending to the right list for TSVWG... >=20 > -=3DR >=20 >=20 > On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon wrote: >=20 >=20 > For those of you who missed it, at the HTTPBis/TSVG=20 > joint session, a question about what applications want from=20 > the transport (I really want to put quotes around that) came up. >=20 > Here is a rendition of what was on the note that I=20 > jotted down in response to this question, and which I passed=20 > to people at the mic. >=20 > (Apps-folks want the following) Deployed in 1996: > ----------------------------------------- > - Prioritization > - Partial Reliability > - "Shared" congestion between multiple streams > - Security > - No HOL blocking on stream X when loss on stream Y > - Cheap/Fast channel/connection setup > - Wide, "safe" deployment > - Competes with TCP/HTTP/1.1 (performance-wise) > - Multipath/roaming robustness, i.e. the "driveway" problem >=20 >=20 > I'll reiterate that by far the most important feature=20 > is "is deployed". > Nothing else matters until that is true, at least at=20 > the application-layer. > =09 > -=3DR > =09 >=20 >=20 >=20 >=20 > = From iesg-secretary@ietf.org Mon Aug 12 09:51:53 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C8021F9BC9; Mon, 12 Aug 2013 09:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUSoRfeJC23G; Mon, 12 Aug 2013 09:51:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFF211E81AB; Mon, 12 Aug 2013 09:31:05 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Sender: Message-ID: <20130812163105.2269.72123.idtracker@ietfa.amsl.com> Date: Mon, 12 Aug 2013 09:31:05 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] Last Call: (SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol) to Proposed Standard X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 16:51:53 -0000 The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-08-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates RFC 4960 by defining a method for the sender of a DATA chunk to indicate that the corresponding SACK chunk should be sent back immediately and not be delayed. It is done by specifying a bit in the DATA chunk header, called the I-bit, which can get set either by the SCTP implementation or by the application using an SCTP stack. Since unknown flags in chunk headers are ignored by SCTP implementations, this extension does not introduce any interoperability problems. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-sack-immediately/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-sack-immediately/ballot/ No IPR declarations have been submitted directly on this I-D. From david.black@emc.com Mon Aug 19 16:32:20 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251D911E8194 for ; Mon, 19 Aug 2013 16:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9k5tngRDkfh for ; Mon, 19 Aug 2013 16:32:16 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id DEBBB11E8172 for ; Mon, 19 Aug 2013 16:32:15 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7JNW2RX016034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 19:32:02 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 19 Aug 2013 19:31:39 -0400 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7JNVdKX011896; Mon, 19 Aug 2013 19:31:39 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Mon, 19 Aug 2013 19:31:39 -0400 From: "Black, David" To: James Polk , "tsvwg@ietf.org" Date: Mon, 19 Aug 2013 19:31:37 -0400 Thread-Topic: WGLC on draft-ietf-tsvwg-rsvp-pcn Thread-Index: Ac6dNEAQ4pqzyHphRN6c1PsTi1g8Eg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE7129C489579@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [tsvwg] WGLC on draft-ietf-tsvwg-rsvp-pcn X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 23:32:20 -0000 As an individual contributor : "I have read this version of the draft, and I support its progression to RFC" Thanks, --David > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > James Polk > Sent: Thursday, August 01, 2013 3:43 PM > To: tsvwg@ietf.org > Subject: [tsvwg] Start of WGLC on draft-ietf-tsvwg-rsvp-pcn >=20 > TSVWG >=20 > This is the start of the WGLC on "Generic Aggregated RSVP for IPv4 > and IPv6 Reservations Over PCN Domains" >=20 > http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-pcn/ >=20 > This WGLC will last until Friday, August 23rd, 2013, which is 3 weeks > after the conclusion of this IETF. The chairs reserve the right to > keep any discussion going and prolong the end of the WGLC if the > chairs see _value_ in "ongoing and active discussions" around the > 23rd. Once those specific discussions are concluded - or stalled - > the WGLC will conclude. >=20 > A good note to the list is "I have read this version of the draft, > and I approve (or support) its progression to RFC". The chairs > request at least a couple of notes to the list showing support to get > a sense of the WG. >=20 > Of course, you can ask for alternate text (where you supply the > actual replacement text, or convey the meaning sufficiently to the > authors) for anywhere in the document that you find unclear or troublesom= e. >=20 > James/Gorry/David > TSVWG chairs >=20 From john@jlc.net Mon Aug 19 19:53:42 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1612911E8199; Mon, 19 Aug 2013 19:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.061 X-Spam-Level: X-Spam-Status: No, score=-106.061 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qya3ypltZHEi; Mon, 19 Aug 2013 19:53:35 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2504311E811D; Mon, 19 Aug 2013 19:53:22 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id B305D33C21; Mon, 19 Aug 2013 22:53:18 -0400 (EDT) Date: Mon, 19 Aug 2013 22:53:18 -0400 From: John Leslie To: Martin & Spencer Message-ID: <20130820025318.GN68553@verdi> References: <51FE7B7B.5050500@erg.abdn.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51FE7B7B.5050500@erg.abdn.ac.uk> User-Agent: Mutt/1.4.1i Cc: tsvwg@ietf.org, tsvwg-chairs@ietf.org Subject: Re: [tsvwg] WGLC Announcement for draft-ietf-tsvwg-byte-pkt-congest-11 - end 19th August X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 02:53:42 -0000 X-List-Received-Date: Tue, 20 Aug 2013 02:53:42 -0000 Gorry Fairhurst wrote: > > This email announces the start of a working group last call to > confirm publication of draft-ietf-tsvwg-byte-pkt-congest-11, > "Byte and Packet Congestion Notification". This document was > returned to the WG after IESG review and has been updated > in response to feedback. It is now thought to be ready to > proceed to be published as a BCP. The document continues to be improved by each iteration. :^) Indeed, after this latest iteration, I undertook to draft a rewrite of the introduction, to bring it into the form I believe is needed for a Best Current Practice. But, on reflection, I refrained from posting that. This document fundamentally is what it is -- an academic study of a narrow question about a particular Active Queue Management practice. It cannot be turned into an appropriate Best Current Practice without violence to its nature. It remains a good document to be published as Informational; and while I remain willing to help mold it into BCP form, I must advise against trying. The decision, years ago, to change the charter item to call for publication as a BCP was apparently taken at an IETF week which I did not attend. When I learned of this decision, I asked on-list to discuss on-list the reason(s) for that change. Such discusison never happened. We have, with my quite-grudging consent, fulfilled the charter item. We did " " Submit 'Byte and Packet Congestion Notification' to IESG for " consideration as a Best Current Practice RFC It's done. The question of BCP status was discussed by the IESG, which deferred it to the Responsible AD, Martin Stiemerling. This WG can express opinions about BCP vs. Informational, but it is really up to Martin and/or Spencer. My recommendation remains strong that this be Informational. I also remain willing to put forth the effort to make a document deserving BCP status. But this document isn't a best _current_ practice: it is perhaps a best five-year-old practice. But the issue involved really doesn't justify the effort to reach a best _current_ practice. -- John Leslie From gorry@erg.abdn.ac.uk Wed Aug 21 03:07:09 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE3A21F9D28; Wed, 21 Aug 2013 03:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.577 X-Spam-Level: X-Spam-Status: No, score=-105.577 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIEFknjM7M7M; Wed, 21 Aug 2013 03:07:04 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id AD3B311E8393; Wed, 21 Aug 2013 03:07:00 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id DFA842B44B5; Wed, 21 Aug 2013 11:06:56 +0100 (BST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 6A1ED2B436A; Wed, 21 Aug 2013 11:06:55 +0100 (BST) Message-ID: <5214913B.8090001@erg.abdn.ac.uk> Date: Wed, 21 Aug 2013 11:06:51 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <51FE7B7B.5050500@erg.abdn.ac.uk> In-Reply-To: <51FE7B7B.5050500@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, tsvwg-chairs@ietf.org Subject: [tsvwg] Conclusion of WGLC for draft-ietf-tsvwg-byte-pkt-congest-11 - end 19th August X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 10:07:09 -0000 This email concludes the WGLC. Comments were received after this document were returned to the WG from John Leslie, Fred Baker, Gory Fairhurst, Ruediger Geib, Wes Eddy, Lars Eggert, Dave Taht, and David Black. Thanks to everyone who commented. I saw one comment during the WGLC, which confirmed the contents, but questioned the intended status. We now plan to resubmit the document to our AD. Gorry On 04/08/2013 17:04, Gorry Fairhurst wrote: > This email announces the start of a working group last call to > confirm publication of draft-ietf-tsvwg-byte-pkt-congest-11, > "Byte and Packet Congestion Notification". This document was > returned to the WG after IESG review and has been updated > in response to feedback. It is now thought to be ready to > proceed to be published as a BCP. > > Please send any comments to the TSVWG list. > > The draft is available at: > http://tools.ietf.org/html/draft-ietf-tsvwg-byte-pkt-congest-11 > > The last call will run for TWO weeks, ending 19th August. > > > James, David, and Gorry > (TSVWG Chairs) > tsvwg-chairs@ietf.org > > > > > -- Prof Gorry Fairhurst, School of Engineering, University of Aberdeen. The University of Aberdeen is a charity registered in Scotland, No SC013683. From carlberg@g11.org.uk Wed Aug 21 03:56:30 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8445611E8386 for ; Wed, 21 Aug 2013 03:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHS-NNpdGBBf for ; Wed, 21 Aug 2013 03:56:26 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id F05E511E8208 for ; Wed, 21 Aug 2013 03:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=M0Qbg0buhHFft2G9FN1FXKwV17AbY27UBKtpso0O6aM=; b=Xypx87HDgQU5X7U4oLgGrpfgVRz9oD56t/bPWJM1mjLkb4KwO05FSLkxNipuE0sVbPOiZ0+Y/6slAREebuLXa9bHFdN0vpYHGH/FOkHyadtKXjQKmIfU1EFDR7JEfh6gI/7Jq3FtZ+wtyK2qHjvt1j6z7yhEWi3vj5YkZI7EELo=; Received: from c-98-218-170-72.hsd1.va.comcast.net ([98.218.170.72]:48741 helo=[10.0.1.20]) by portland.eukhosting.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VC65N-001pRD-5S; Wed, 21 Aug 2013 11:56:21 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: ken carlberg In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7129C489579@MX15A.corp.emc.com> Date: Wed, 21 Aug 2013 06:56:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4DA0B3CE-A60F-4835-B781-D13D86784695@g11.org.uk> References: <8D3D17ACE214DC429325B2B98F3AE7129C489579@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Get-Message-Sender-Via: portland.eukhosting.net: acl_c_relayhosts_text_entry: carlberg@g11.org.uk|g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: James Polk , "tsvwg@ietf.org" Subject: Re: [tsvwg] WGLC on draft-ietf-tsvwg-rsvp-pcn X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 10:56:30 -0000 I have reread the draft and it responds to the earlier comments I have = made. I support its progression to RFC -ken On Aug 19, 2013, at 7:31 PM, "Black, David" wrote: > As an individual contributor : >=20 > "I have read this version of the draft, > and I support its progression to RFC" >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On = Behalf Of >> James Polk >> Sent: Thursday, August 01, 2013 3:43 PM >> To: tsvwg@ietf.org >> Subject: [tsvwg] Start of WGLC on draft-ietf-tsvwg-rsvp-pcn >>=20 >> TSVWG >>=20 >> This is the start of the WGLC on "Generic Aggregated RSVP for IPv4 >> and IPv6 Reservations Over PCN Domains" >>=20 >> http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-pcn/ >>=20 >> This WGLC will last until Friday, August 23rd, 2013, which is 3 weeks >> after the conclusion of this IETF. The chairs reserve the right to >> keep any discussion going and prolong the end of the WGLC if the >> chairs see _value_ in "ongoing and active discussions" around the >> 23rd. Once those specific discussions are concluded - or stalled - >> the WGLC will conclude. >>=20 >> A good note to the list is "I have read this version of the draft, >> and I approve (or support) its progression to RFC". The chairs >> request at least a couple of notes to the list showing support to get >> a sense of the WG. >>=20 >> Of course, you can ask for alternate text (where you supply the >> actual replacement text, or convey the meaning sufficiently to the >> authors) for anywhere in the document that you find unclear or = troublesome. >>=20 >> James/Gorry/David >> TSVWG chairs >>=20 >=20 From flefauch@cisco.com Fri Aug 23 08:25:59 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D28E11E8105 for ; Fri, 23 Aug 2013 08:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7sdOUxGbWF1 for ; Fri, 23 Aug 2013 08:25:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE6A11E81B8 for ; Fri, 23 Aug 2013 08:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2999; q=dns/txt; s=iport; t=1377271548; x=1378481148; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rvKTJIcxP2mXhVnun9HVm+93FGB3AvRXG6Bs0NILbQs=; b=eCMRkYDbSJPsh/E2fAWlwriunC5oI0A0rNXzuUBMhKfjqJY4h9mftH19 gjn5WlNrbG/c7tHlPNGaRjSXQ2Gh0MYF2K7W5lN7aoBd7x/1UUAh79vqe SDuLXnGjOM3QlOGVi6BiNmPMtrRCz/+D2Y0J25T4LUOgUVKSLIfNMqaz/ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAKV+F1KtJV2Z/2dsb2JhbABagwc1RQy/d4EgFnSCJAEBAQMBOj8FBwQCAQgRBAEBAQoUCQcyFAkIAQEEDgUIh3MGDLcZkD0CBisHBoMWfAOZF5Axgx6CKg X-IronPort-AV: E=Sophos;i="4.89,941,1367971200"; d="scan'208";a="250959754" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 23 Aug 2013 15:25:37 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7NFPbDL002538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Aug 2013 15:25:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.8]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Fri, 23 Aug 2013 10:25:36 -0500 From: "Francois Le Faucheur (flefauch)" To: "James Polk (jmpolk)" Thread-Topic: [tsvwg] WGLC on draft-ietf-tsvwg-rsvp-pcn Thread-Index: Ac6dNEAQ4pqzyHphRN6c1PsTi1g8EgBUrquAAG38WIA= Date: Fri, 23 Aug 2013 15:25:36 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE7129C489579@MX15A.corp.emc.com> <4DA0B3CE-A60F-4835-B781-D13D86784695@g11.org.uk> In-Reply-To: <4DA0B3CE-A60F-4835-B781-D13D86784695@g11.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: text/plain; charset="us-ascii" Content-ID: <5A81B2E7146E0844BA53E6B5A52DCDA7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tsvwg@ietf.org WG" Subject: Re: [tsvwg] WGLC on draft-ietf-tsvwg-rsvp-pcn X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 15:25:59 -0000 Folks, I had another look at the draft.=20 It reflects well the discussion we had regarding the choice of using aggreg= ate reservations.=20 In general I support it going forward but there is one aspect I am trying t= o clarify with the authors (ie regarding the split of functionality between= ingress node and egress node) before I give my full support fro publicatio= n. This may take a few days. In the mean time I have a few minor comments/suggestions: *** section 1.1: expand the PBAC acronym in Introduction ***section 1.2: OLD: "This is also the reason of choosing Approach (1)" NEW: "This is the reason for choosing Approach (1)" *** section 6: I recommend you expand the text to indicate to IANA that they need to alloc= ate all the C-Types defined in section 4.1. You probably also need to indic= ate the policy for allocating additional C-Types. *** I would also consider adding an example message flow in an Appendix, si= milar to Appendix A of RFC4860. This considerably helps getting the general= idea in a short time. Francois On 21 Aug 2013, at 12:56, ken carlberg wrote: > I have reread the draft and it responds to the earlier comments I have ma= de. I support its progression to RFC >=20 > -ken >=20 >=20 > On Aug 19, 2013, at 7:31 PM, "Black, David" wrote: >=20 >> As an individual contributor : >>=20 >> "I have read this version of the draft, >> and I support its progression to RFC" >>=20 >> Thanks, >> --David >>=20 >>> -----Original Message----- >>> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf = Of >>> James Polk >>> Sent: Thursday, August 01, 2013 3:43 PM >>> To: tsvwg@ietf.org >>> Subject: [tsvwg] Start of WGLC on draft-ietf-tsvwg-rsvp-pcn >>>=20 >>> TSVWG >>>=20 >>> This is the start of the WGLC on "Generic Aggregated RSVP for IPv4 >>> and IPv6 Reservations Over PCN Domains" >>>=20 >>> http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-pcn/ >>>=20 >>> This WGLC will last until Friday, August 23rd, 2013, which is 3 weeks >>> after the conclusion of this IETF. The chairs reserve the right to >>> keep any discussion going and prolong the end of the WGLC if the >>> chairs see _value_ in "ongoing and active discussions" around the >>> 23rd. Once those specific discussions are concluded - or stalled - >>> the WGLC will conclude. >>>=20 >>> A good note to the list is "I have read this version of the draft, >>> and I approve (or support) its progression to RFC". The chairs >>> request at least a couple of notes to the list showing support to get >>> a sense of the WG. >>>=20 >>> Of course, you can ask for alternate text (where you supply the >>> actual replacement text, or convey the meaning sufficiently to the >>> authors) for anywhere in the document that you find unclear or troubles= ome. >>>=20 >>> James/Gorry/David >>> TSVWG chairs >>>=20 >>=20 >=20 From rs@netapp.com Mon Aug 26 03:25:56 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF0B11E8183; Mon, 26 Aug 2013 03:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKyc6k5nay86; Mon, 26 Aug 2013 03:25:50 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id C792121F9B08; Mon, 26 Aug 2013 03:25:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,957,1367996400"; d="scan'208";a="44323219" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 26 Aug 2013 03:25:48 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.122]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Mon, 26 Aug 2013 03:25:37 -0700 From: "Scheffenegger, Richard" To: "aqm@ietf.org" , "iccrg@irtf.org" , "tsvwg@ietf.org" Thread-Topic: [aqm] Status after the IETF Thread-Index: AQHOlETyQn1xxH5YR0eYo6aA+VirqJmMUsUAgABBBGCAGs94sA== Date: Mon, 26 Aug 2013 10:25:37 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25CE081A@SACEXCMBX02-PRD.hq.netapp.com> References: <5203AD0F.5030907@neclab.eu> <20130808220232.GG3328@verdi> <012C3117EDDB3C4781FD802A8C27DD4F25C8D2ED@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25C8D2ED@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tsvwg] [aqm] Status after the IETF X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 10:25:56 -0000 Hi group, we, the BoF chairs, have asked for a tentative slot for AQM, assuming that = AQM will be chartered as a WG by the time of IETF88. Our responsible AD did= start the necessary preparations already! At this time, this is just a heads-up. To plan a proper slot, we'd like to = encourage early feedback. Best regards, Richard Scheffenegger From grmocg@gmail.com Tue Aug 6 01:15:48 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EE521F9F80 for ; Tue, 6 Aug 2013 01:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cMApbRr9PNM for ; Tue, 6 Aug 2013 01:15:47 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4864721F9FF3 for ; Tue, 6 Aug 2013 01:15:39 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id l10so161748oag.33 for ; Tue, 06 Aug 2013 01:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=aEGVy5DYePm3yxAwcqasaXtxQl8rlIYDIlv27bh1z3o=; b=qxUMIjIZzHEnnYQTMZ4YZ0K9MGXYeCoVrwe3Uro6arMMFhZQBxPYt9EgQE0BBNE9RH 2CcZiuSuaa8QPj6vvyEdFVFzkoLQXf9C4/ZIHS4JMCGvVaCzfow0oDe2+Vag9uNRBYLZ jsd2/t3HmhZJxUF18C0vNK2y8z++pScVW9Lr+oa1ega0p465rxaeUnaaI+/IZCm8kLHX XuENyVWTpDj52/iCr5IXvfTrQuRsPRhPjqbvyqfCD8XN04QHH7qZizD9rZw7ol2geqvr cMt9Ymxb20SI5b7HNzKeFFGsqS2c5iVanNCm5IoyzoU78oVtu40MDOC9VB3gTYix9chz 6erA== MIME-Version: 1.0 X-Received: by 10.60.149.202 with SMTP id uc10mr156131oeb.12.1375776938622; Tue, 06 Aug 2013 01:15:38 -0700 (PDT) Received: by 10.76.91.229 with HTTP; Tue, 6 Aug 2013 01:15:38 -0700 (PDT) In-Reply-To: References: Message-ID: From: Roberto Peon To: HTTP Working Group , tsvwg@ietf.org Content-Type: multipart/alternative; boundary=047d7b41c580b7853a04e34307d7 X-Mailman-Approved-At: Tue, 27 Aug 2013 02:12:35 -0700 Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 06 Aug 2013 08:15:48 -0000 X-Original-Date: Tue, 6 Aug 2013 01:15:38 -0700 X-List-Received-Date: Tue, 06 Aug 2013 08:15:48 -0000 --047d7b41c580b7853a04e34307d7 Content-Type: text/plain; charset=ISO-8859-1 Actually sending to the right list for TSVWG... -=R On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon wrote: > For those of you who missed it, at the HTTPBis/TSVG joint session, a > question about what applications want from the transport (I really want to > put quotes around that) came up. > > Here is a rendition of what was on the note that I jotted down in response > to this question, and which I passed to people at the mic. > > (Apps-folks want the following) Deployed in 1996: > ----------------------------------------- > - Prioritization > - Partial Reliability > - "Shared" congestion between multiple streams > - Security > - No HOL blocking on stream X when loss on stream Y > - Cheap/Fast channel/connection setup > - Wide, "safe" deployment > - Competes with TCP/HTTP/1.1 (performance-wise) > - Multipath/roaming robustness, i.e. the "driveway" problem > > > I'll reiterate that by far the most important feature is "is deployed". > Nothing else matters until that is true, at least at the application-layer. > -=R > > > --047d7b41c580b7853a04e34307d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Actually sending to the right list for TSVWG...

-=3DR


On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon <grmocg@gmail.com= > wrote:
For those of you who m= issed it, at the HTTPBis/TSVG joint session, a question about what applicat= ions want from the transport (I really want to put quotes around that) came= up.

Here is a rendition of what was on the note that I jotted down in response = to this question, and which I passed to people at the mic.

(Apps-folks want the following) Deployed in 1996:
-----------------------------------------
- Prioritization
<= div>- Partial Reliability
- "Shared" congestion between= multiple streams
- Security
- No HOL blocking on strea= m X when loss on stream Y
- Cheap/Fast =A0channel/connection setup
- Wide, "safe&= quot; deployment
- Competes with TCP/HTTP/1.1 (performance-wise)<= /div>
- Multipath/roaming robustness, i.e. the "driveway" pro= blem


I'll reiterate that by far the= most important feature is "is deployed".
Nothing else = matters until that is true, at least at the application-layer.
-=3DR



--047d7b41c580b7853a04e34307d7-- From grmocg@gmail.com Tue Aug 6 01:30:42 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1426021F9A14 for ; Tue, 6 Aug 2013 01:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrPrUUC1Awoy for ; Tue, 6 Aug 2013 01:30:41 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 49F3A21F99DC for ; Tue, 6 Aug 2013 01:30:41 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id eh20so171277obb.1 for ; Tue, 06 Aug 2013 01:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yf103lndtYVhwYc2/VMCy+j0pi4nDyC1IXqHF6ye1lo=; b=vq2n8IwR641IxGkqeNxoHth7QNaLn5hxiIwbWnnk1xP938e75+G+dPq6s9bQfc+Y6H Txqgm40dB0U0ALsG8LPY8erSY8PGkQfBdNftiHEC7d1STGkQhzJR7lcNb0TaiRGbO2pp HIqsv8+88AfH5cyMuRdNA0gynBe9fWAL/Hx2enjdnp5PueAM4f8nFWAKneefnGW6p75j XES/zwor6XP+HrHVhr2JIqtacEr7dKiTvlHavVU8CscEFJNiMALSMrxGsgIl0VynHIR3 pG6ieKof+v87d5mo7nTZ/DMqMfvPcyappND1ZSRm8PVfSTPqDM2mZ9Umu0w7wn68FKJC 2SMQ== MIME-Version: 1.0 X-Received: by 10.60.149.202 with SMTP id uc10mr194319oeb.12.1375777840721; Tue, 06 Aug 2013 01:30:40 -0700 (PDT) Received: by 10.76.91.229 with HTTP; Tue, 6 Aug 2013 01:30:40 -0700 (PDT) In-Reply-To: References: Message-ID: From: Roberto Peon To: HTTP Working Group , tsvwg@ietf.org Content-Type: multipart/alternative; boundary=047d7b41c5807c78c604e3433d68 X-Mailman-Approved-At: Tue, 27 Aug 2013 02:12:36 -0700 Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 06 Aug 2013 08:30:42 -0000 X-Original-Date: Tue, 6 Aug 2013 01:30:40 -0700 X-List-Received-Date: Tue, 06 Aug 2013 08:30:42 -0000 --047d7b41c5807c78c604e3433d68 Content-Type: text/plain; charset=ISO-8859-1 The most interesting part of this list, for me, was that I was nearly 100% sure that every item on this list had been discussed and designed by folks participating in TSVWG. The part that I'm unsure that people realized is the extent of the hunger to have something deployed "yesterday" so that the features could be reliably used today. A colleague reminded me that "prioritization" means different things in the different areas (thanks, and thanks Allison for pointing it out in your preso!). On this note, it meant both QoS like things and hints to the application layer. Something which I also failed to describe well was that "cheap"/"fast" channel/connection setup to CPU/mem, yes, but perhaps more importantly to the importance of minimizing latency in connection/channel setup, especially while including features like security. -=R On Tue, Aug 6, 2013 at 1:15 AM, Roberto Peon wrote: > Actually sending to the right list for TSVWG... > > -=R > > > On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon wrote: > >> For those of you who missed it, at the HTTPBis/TSVG joint session, a >> question about what applications want from the transport (I really want to >> put quotes around that) came up. >> >> Here is a rendition of what was on the note that I jotted down in >> response to this question, and which I passed to people at the mic. >> >> (Apps-folks want the following) Deployed in 1996: >> ----------------------------------------- >> - Prioritization >> - Partial Reliability >> - "Shared" congestion between multiple streams >> - Security >> - No HOL blocking on stream X when loss on stream Y >> - Cheap/Fast channel/connection setup >> - Wide, "safe" deployment >> - Competes with TCP/HTTP/1.1 (performance-wise) >> - Multipath/roaming robustness, i.e. the "driveway" problem >> >> >> I'll reiterate that by far the most important feature is "is deployed". >> Nothing else matters until that is true, at least at the >> application-layer. >> -=R >> >> >> > --047d7b41c5807c78c604e3433d68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The most interesting part of this list, for me, was that I= was nearly 100% sure that every item on this list had been discussed and d= esigned by folks participating in TSVWG.
The part that I'm unsure t= hat people realized is the extent of the hunger to have something deployed = "yesterday" so that the features could be reliably used today.

A colleague reminded me that "prioritization"= means different things in the different areas (thanks, and thanks Allison = for pointing it out in your preso!). On this note, it meant both QoS like t= hings and hints to the application layer.

Something which I also failed to describe well was that= "cheap"/"fast" channel/connection setup to CPU/mem, ye= s, but perhaps more importantly to the importance of minimizing latency in = connection/channel setup, especially while including features like security= .
-=3DR


On Tue, Aug 6, 2013 at 1:15 AM, Roberto Peon <= ;grmocg@gmail.com= > wrote:
Actually sending to the rig= ht list for TSVWG...
-=3DR


On Tue, Aug = 6, 2013 at 1:14 AM, Roberto Peon <grmocg@gmail.com> wrote:
For those of you who m= issed it, at the HTTPBis/TSVG joint session, a question about what applicat= ions want from the transport (I really want to put quotes around that) came= up.

Here is a rendition of what was on the note that I jotted down in response = to this question, and which I passed to people at the mic.

(Apps-folks want the following) Deployed in 1996:
-----------------------------------------
- Prioritization
<= div>- Partial Reliability
- "Shared" congestion between= multiple streams
- Security
- No HOL blocking on strea= m X when loss on stream Y
- Cheap/Fast =A0channel/connection setup
- Wide, "safe&= quot; deployment
- Competes with TCP/HTTP/1.1 (performance-wise)<= /div>
- Multipath/roaming robustness, i.e. the "driveway" pro= blem


I'll reiterate that by far the= most important feature is "is deployed".
Nothing else = matters until that is true, at least at the application-layer.
<= font color=3D"#888888">
-=3DR




--047d7b41c5807c78c604e3433d68-- From mike@belshe.com Tue Aug 6 02:30:42 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB66921F9D17 for ; Tue, 6 Aug 2013 02:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe6Ssop9rZ6l for ; Tue, 6 Aug 2013 02:30:37 -0700 (PDT) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by ietfa.amsl.com (Postfix) with ESMTP id 26F0821F9C8E for ; Tue, 6 Aug 2013 02:30:36 -0700 (PDT) Received: by mail-bk0-f52.google.com with SMTP id e11so59547bkh.25 for ; Tue, 06 Aug 2013 02:30:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h9KopDXgFOmPYHQLS4UtXhKcbGmkllp6SN7Thb2MVo8=; b=MfTVvgCi+MpEPUB+K8SPjYuOA1h47cAYIcSomXrCKw1AJ5Yb6y5ZjbHRz/854ouv/3 woLHngBqeug3kGyRRp1G2zUbQeH9OLyAd8a9kMhf+mlGFqCkHX5x7Q/9ZptYlf64thL+ GEofSD1Upu88/cqCIyA4xQ+Q7I7XserGtjihP75maWR6pCPLynv/Jb1vgCJK+545qgnM Y/+JDai2v4n03aMXST8raDDBGQlB4Mp2R86rabMFxfWBZqBcBmka57mPiBHMTZCapwHw bqIGvRUQlnoCLfYByQVAehuqODN6CK2hWZs45r4R/Ugb11Roc+n6R6eVcHvadKiFKInh MxGg== X-Gm-Message-State: ALoCoQk7BzQiCz6WtgxXJVeAGHuKXZzD435YhGGhQ3oe018Fwfq6YHdNyjkNqci2AjWhz0/Zy2FB MIME-Version: 1.0 X-Received: by 10.204.162.12 with SMTP id t12mr142254bkx.67.1375781435945; Tue, 06 Aug 2013 02:30:35 -0700 (PDT) Received: by 10.204.168.130 with HTTP; Tue, 6 Aug 2013 02:30:35 -0700 (PDT) In-Reply-To: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> Message-ID: From: Mike Belshe To: Yoav Nir Content-Type: multipart/alternative; boundary=bcaec52d55f7c7728104e3441385 X-Mailman-Approved-At: Tue, 27 Aug 2013 02:12:56 -0700 Cc: HTTP Working Group , "tsvwg@ietf.org" Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 06 Aug 2013 09:30:42 -0000 X-Original-Date: Tue, 6 Aug 2013 11:30:35 +0200 X-List-Received-Date: Tue, 06 Aug 2013 09:30:42 -0000 --bcaec52d55f7c7728104e3441385 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Aug 6, 2013 at 10:49 AM, Yoav Nir wrote: > I think most of that is addressed in SCTP. Except the deployment part. > Standards people can=92t force vendors of operating systems or Linux > distributions to include any feature. So we have a lot of =93version 2=94= s in > the IETF that take a very long time to get deployed. **** > > ** ** > > It=92s also much more attractive to define a new thing (like SCTP) than t= o > make something old work a little better. SCTP was sexier than TCPM.**** > > ** ** > > So it took ages to get deployment of IPv6, IKEv2, TLS 1.2, and all three > are still used far less than IPv4, IKEv1 and TLS 1.0. SCTP is used almost > never. HTTP/2 will likely fare better because the vendors are more involv= ed > and committed, but it=92s hard to make predictions, especially about the > future. > You're right, SCTP is non-deployable, which makes it a non-starter. SCTP also does not address handshake issues or TLS issues. I don't mean to sound inflammatory - but for all intents and purposes, the next generation transport will need to be in user space and run on top of UDP. There simply is no other deployable option on the table. QUIC is already reasonably far at exploring these issues: http://en.wikipedia.org/wiki/QUIC Mike > **** > > ** ** > > Yoav**** > > ** ** > > *From:* Roberto Peon [mailto:grmocg@gmail.com] > *Sent:* Tuesday, August 06, 2013 11:16 AM > > *To:* HTTP Working Group; tsvwg@ietf.org > *Subject:* Re: The List (of application-layer desired features)**** > > ** ** > > Actually sending to the right list for TSVWG...**** > > ** ** > > -=3DR**** > > ** ** > > On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon wrote:***= * > > For those of you who missed it, at the HTTPBis/TSVG joint session, a > question about what applications want from the transport (I really want t= o > put quotes around that) came up.**** > > ** ** > > Here is a rendition of what was on the note that I jotted down in respons= e > to this question, and which I passed to people at the mic.**** > > ** ** > > (Apps-folks want the following) Deployed in 1996:**** > > -----------------------------------------**** > > - Prioritization**** > > - Partial Reliability**** > > - "Shared" congestion between multiple streams**** > > - Security**** > > - No HOL blocking on stream X when loss on stream Y**** > > - Cheap/Fast channel/connection setup**** > > - Wide, "safe" deployment**** > > - Competes with TCP/HTTP/1.1 (performance-wise)**** > > - Multipath/roaming robustness, i.e. the "driveway" problem**** > > ** ** > > ** ** > > I'll reiterate that by far the most important feature is "is deployed".**= * > * > > Nothing else matters until that is true, at least at the application-laye= r. > **** > > -=3DR**** > > ** ** > > ** ** > > ** ** > > > > Email secured by Check Point **** > --bcaec52d55f7c7728104e3441385 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 6, 2013 at 10:49 AM, Yoav Nir <ynir@checkpoint.com> wrote:

I think most of that is addressed in SCTP. =A0Except = the deployment part. Standards people can=92t force vendors of operating sy= stems or Linux distributions to include any feature. So we have a lot of =93version 2=94s in the IETF that= take a very long time to get deployed.

=A0

It=92s also much more attractive to define a new thin= g (like SCTP) than to make something old work a little better. SCTP was sex= ier than TCPM.

=A0

So it took ages to get deployment of IPv6, IKEv2, TLS= 1.2, and all three are still used far less than IPv4, IKEv1 and TLS 1.0. S= CTP is used almost never. HTTP/2 will likely fare better because the vendors are more involved and committe= d, but it=92s hard to make predictions, especially about the future.=


You're right, SCTP is = non-deployable, which makes it a non-starter. =A0SCTP also does not address= handshake issues or TLS issues.

Mike



=

=A0

=A0

Yoav

=A0

From: Roberto Peon [mailto:grmocg@gmail.com]
Sent: Tuesday, August 06, 2013 11:16 AM

=
To: HTTP Working Group; tsvwg@ietf.org
Subject: Re: The List (of application-layer desired features)=

=A0

Actually sending to the right list for TSVWG...=

=A0

-=3DR

=A0

On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon <grmocg@gmail.com> wrote:

For those of you who missed it, at the HTTPBis/TSVG joint ses= sion, a question about what applications want from the transport (I really = want to put quotes around that) came up.

=A0

Here is a rendition of what was on the note that I jotted dow= n in response to this question, and which I passed to people at the mic.=

=A0

(Apps-folks want the following) Deployed in 1996:

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

- Prioritization

- Partial Reliability

- "Shared" congestion between multiple streams

- Security

- No HOL blocking on stream X when loss on stream Y=

- Cheap/Fast =A0channel/connection setup

- Wide, "safe" deployment

- Competes with TCP/HTTP/1.1 (performance-wise)=

- Multipath/roaming robustness, i.e. the "driveway"= problem

=A0

=A0

I'll reiterate that by far the most important feature is = "is deployed".

Nothing else matters until that is true, at least at the appl= ication-layer.

-=3DR

=A0

=A0

=A0



Email secured by Check Point


--bcaec52d55f7c7728104e3441385-- From willchan@google.com Tue Aug 6 03:48:26 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064B921F9DC6 for ; Tue, 6 Aug 2013 03:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.503 X-Spam-Level: X-Spam-Status: No, score=-1.503 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiwSi1l3ZbPz for ; Tue, 6 Aug 2013 03:48:25 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0634E21F9DB8 for ; Tue, 6 Aug 2013 03:48:24 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id er7so430973obc.3 for ; Tue, 06 Aug 2013 03:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qvHDdMaDxbZA9t4Gndk3xXGWNGYvSu5havUNT0l6I24=; b=Sz51FyayNGN6lfEbgEU+ORlBCi4Wb1QVHA153V+uBv2DMSQSvHsqHNjyzJl9osPTyd gqynj7M8fat8SBZ3zOAtowB5GSPakxBN5YrzBrnlETteihCD2Wu1pQ1I97mMOFUINTke lmswj0S1LsleT4vL75Hq6KGnoq6+55BQzQGFt8vM/TfSDUyI50yFuzDTp+FAO8NgRrCt SMZyoSuRbatE2HlKZybFN51S6A96xzetxHaxUnTOzC+iJOZo78XTTx8gfL+X5Q8U+6Hk y1kXiMA6A3pjLdluTrew1YBIUwludnOi6M+LbZJgJHb3REz745qUnJMXjFKWd+ua5Evr 1vBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qvHDdMaDxbZA9t4Gndk3xXGWNGYvSu5havUNT0l6I24=; b=YwNU7e4fTecEHKvVdvAMLOCZn17/RPnq0EUlltLpNZ1gcNXIpV1yYs/+AaR8uxO3Ct yin8rzJbfYtnnKV3rf3xFL9LAF/vH9OYID9yoH5gbaA3XT8rfdsyXwaLgDBSRyiY9Q/A +5a4AiBU+zI/gH852FUn84CKuryxQKKSjy3HA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qvHDdMaDxbZA9t4Gndk3xXGWNGYvSu5havUNT0l6I24=; b=QpQ5K+qxcSaMeqS9sP9JsAO6Pu1CvV13nNpn+/38o7Bc019Vz+IOXrsJ3WQcRVtgHt tnxZZjvqzzLhmCS418Z2oPk0hipYJr8LVe7npd8bThXdTtfprw0A8kAzPy314/D1cpev CwR/d20wFXIqqPn9hTaZ4b2nonoPuLMcf8crGDOzb3ghNLAtT2uCZgeMJWB7MWVjM9D2 AobjwB1yJsDg3BuAZrgz/PSrWdkgNMgVwE4ZmA+Ta5cX6WTOCdLs7Cy+MkOEv3SQTjYa Wcn8RwrHMZ4PkJtEkknEHVxgiKV4XGrwxQFkuY0TzluQ0F9JIsAeDIsDZYZ0/f3cWjGz Uyyw== X-Gm-Message-State: ALoCoQnBxiVCsbp4V3Yuz54wQ/Qug/EikPe2wJbM7SIxkk2M28EdpoZIz+36ewcO4m8O4VuQLC3ywP84ufsZ15AqkEDQj7C2dRO50mlW2BPHnvPrG3E557zIs9tm7XA1LbeFAEslVXvuzcia6PXLDSJsiprxArX8fA7sIZiszTHFhzJaYIlhdE61SgTEyEDoZunsb9HPnl0L MIME-Version: 1.0 X-Received: by 10.50.102.68 with SMTP id fm4mr61071igb.45.1375786104392; Tue, 06 Aug 2013 03:48:24 -0700 (PDT) Sender: willchan@google.com Received: by 10.64.23.7 with HTTP; Tue, 6 Aug 2013 03:48:24 -0700 (PDT) In-Reply-To: References: X-Google-Sender-Auth: jzuDyG-a-dSYMeYO8Yl93rfVqsk Message-ID: From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= To: Roberto Peon Content-Type: multipart/alternative; boundary=047d7b10c9f90a398104e3452a14 X-Mailman-Approved-At: Tue, 27 Aug 2013 02:13:13 -0700 Cc: HTTP Working Group , tsvwg@ietf.org Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 06 Aug 2013 10:48:26 -0000 X-Original-Date: Tue, 6 Aug 2013 03:48:24 -0700 X-List-Received-Date: Tue, 06 Aug 2013 10:48:26 -0000 --047d7b10c9f90a398104e3452a14 Content-Type: text/plain; charset=ISO-8859-1 Another thing that I think Roberto implied but didn't explicitly call out is mitigating application incentives to open multiple connections On Tue, Aug 6, 2013 at 1:30 AM, Roberto Peon wrote: > The most interesting part of this list, for me, was that I was nearly 100% > sure that every item on this list had been discussed and designed by folks > participating in TSVWG. > The part that I'm unsure that people realized is the extent of the hunger > to have something deployed "yesterday" so that the features could be > reliably used today. > > A colleague reminded me that "prioritization" means different things in > the different areas (thanks, and thanks Allison for pointing it out in your > preso!). On this note, it meant both QoS like things and hints to the > application layer. > Prioritization also includes stuff sitting in socket buffers. > > Something which I also failed to describe well was that "cheap"/"fast" > channel/connection setup to CPU/mem, yes, but perhaps more importantly to > the importance of minimizing latency in connection/channel setup, > especially while including features like security. > -=R > > > On Tue, Aug 6, 2013 at 1:15 AM, Roberto Peon wrote: > >> Actually sending to the right list for TSVWG... >> >> -=R >> >> >> On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon wrote: >> >>> For those of you who missed it, at the HTTPBis/TSVG joint session, a >>> question about what applications want from the transport (I really want to >>> put quotes around that) came up. >>> >>> Here is a rendition of what was on the note that I jotted down in >>> response to this question, and which I passed to people at the mic. >>> >>> (Apps-folks want the following) Deployed in 1996: >>> ----------------------------------------- >>> - Prioritization >>> - Partial Reliability >>> - "Shared" congestion between multiple streams >>> - Security >>> - No HOL blocking on stream X when loss on stream Y >>> - Cheap/Fast channel/connection setup >>> - Wide, "safe" deployment >>> - Competes with TCP/HTTP/1.1 (performance-wise) >>> - Multipath/roaming robustness, i.e. the "driveway" problem >>> >>> >>> I'll reiterate that by far the most important feature is "is deployed". >>> Nothing else matters until that is true, at least at the >>> application-layer. >>> -=R >>> >>> >>> >> > --047d7b10c9f90a398104e3452a14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Another thing that I think Roberto implied but didn&#= 39;t explicitly call out is mitigating application incentives to open multi= ple connections

On Tue, Aug 6, 2013 at 1:30 AM, Roberto= Peon <grmocg@gmail.com> wrote:
The most interesting part of this list, for me, = was that I was nearly 100% sure that every item on this list had been discu= ssed and designed by folks participating in TSVWG.
The part that I'm unsure that people realized is the extent of the hung= er to have something deployed "yesterday" so that the features co= uld be reliably used today.

A colleague reminded me that "prioritization"= means different things in the different areas (thanks, and thanks Allison = for pointing it out in your preso!). On this note, it meant both QoS like t= hings and hints to the application layer.

Prioritization also includes stuff s= itting in socket buffers.
=A0

Something which I also failed to describe well was that= "cheap"/"fast" channel/connection setup to CPU/mem, ye= s, but perhaps more importantly to the importance of minimizing latency in = connection/channel setup, especially while including features like security= .
-=3DR


On Tue, Aug = 6, 2013 at 1:15 AM, Roberto Peon <grmocg@gmail.com>= wrote:
Actually sending to the rig= ht list for TSVWG...

-=3DR

On Tue, Aug 6, 2013 at 1:14 AM, Roberto Pe= on <grmocg@gmail.com> wrote:
For those of you who m= issed it, at the HTTPBis/TSVG joint session, a question about what applicat= ions want from the transport (I really want to put quotes around that) came= up.

Here is a rendition of what was on the note that I jotted down in response = to this question, and which I passed to people at the mic.

(Apps-folks want the following) Deployed in 1996:
-----------------------------------------
- Prioritization
<= div>- Partial Reliability
- "Shared" congestion between= multiple streams
- Security
- No HOL blocking on strea= m X when loss on stream Y
- Cheap/Fast =A0channel/connection setup
- Wide, "safe&= quot; deployment
- Competes with TCP/HTTP/1.1 (performance-wise)<= /div>
- Multipath/roaming robustness, i.e. the "driveway" pro= blem


I'll reiterate that by far the= most important feature is "is deployed".
Nothing else = matters until that is true, at least at the application-layer.
<= font color=3D"#888888">
-=3DR





--047d7b10c9f90a398104e3452a14-- From Michael.Tuexen@lurchi.franken.de Tue Aug 27 02:47:52 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9B721E80D6 for ; Tue, 27 Aug 2013 02:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9OSsZX3iNrh for ; Tue, 27 Aug 2013 02:47:52 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8E421E80CF for ; Tue, 27 Aug 2013 02:47:51 -0700 (PDT) Received: from [192.168.1.200] (p508F3337.dip0.t-ipconnect.de [80.143.51.55]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 4BCAA1C0C0692; Tue, 27 Aug 2013 11:47:48 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Tuexen In-Reply-To: Date: Tue, 27 Aug 2013 11:47:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <081D0F76-F4AE-42D5-B354-795BE4910D23@lurchi.franken.de> References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> To: Mike Belshe X-Mailer: Apple Mail (2.1508) Cc: Yoav Nir , HTTP Working Group , "tsvwg@ietf.org" Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 09:47:53 -0000 On Aug 6, 2013, at 11:30 AM, Mike Belshe wrote: >=20 >=20 >=20 > On Tue, Aug 6, 2013 at 10:49 AM, Yoav Nir wrote: > I think most of that is addressed in SCTP. Except the deployment = part. Standards people can=92t force vendors of operating systems or = Linux distributions to include any feature. So we have a lot of =93version= 2=94s in the IETF that take a very long time to get deployed. >=20 > =20 >=20 > It=92s also much more attractive to define a new thing (like SCTP) = than to make something old work a little better. SCTP was sexier than = TCPM. >=20 > =20 >=20 > So it took ages to get deployment of IPv6, IKEv2, TLS 1.2, and all = three are still used far less than IPv4, IKEv1 and TLS 1.0. SCTP is used = almost never. HTTP/2 will likely fare better because the vendors are = more involved and committed, but it=92s hard to make predictions, = especially about the future. >=20 >=20 > You're right, SCTP is non-deployable, which makes it a non-starter. = SCTP also does not address handshake issues or TLS issues. I agree that SCTP over IP can't be deployed now due to missing NAT = support. But why can't SCTP/UDP/IP (RFC 6951) be deployed now? Also SCTP as = specified now is not optimised for fast setup. It needs an RTT before it can send the = first user message. However, I think one can easily extend it to provide a = fast association setup... >=20 > I don't mean to sound inflammatory - but for all intents and purposes, = the next generation transport will need to be in user space and run on = top of UDP. There simply is no other deployable option on the table. = QUIC is already reasonably far at=20 And why does "be in user space and run on top of UDP" exclude SCTP? = There is also a userland implementation supporting it. It also supports SCTP/DTLS/UDP = and is included in Firefox (for RTCWeb support). Best regards Michael > exploring these issues: http://en.wikipedia.org/wiki/QUIC >=20 > Mike >=20 >=20 >=20 >=20 > =20 >=20 > =20 >=20 > Yoav >=20 > =20 >=20 > From: Roberto Peon [mailto:grmocg@gmail.com]=20 > Sent: Tuesday, August 06, 2013 11:16 AM >=20 >=20 > To: HTTP Working Group; tsvwg@ietf.org > Subject: Re: The List (of application-layer desired features) >=20 > =20 >=20 > Actually sending to the right list for TSVWG... >=20 > =20 >=20 > -=3DR >=20 > =20 >=20 > On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon wrote: >=20 > For those of you who missed it, at the HTTPBis/TSVG joint session, a = question about what applications want from the transport (I really want = to put quotes around that) came up. >=20 > =20 >=20 > Here is a rendition of what was on the note that I jotted down in = response to this question, and which I passed to people at the mic. >=20 > =20 >=20 > (Apps-folks want the following) Deployed in 1996: >=20 > ----------------------------------------- >=20 > - Prioritization >=20 > - Partial Reliability >=20 > - "Shared" congestion between multiple streams >=20 > - Security >=20 > - No HOL blocking on stream X when loss on stream Y >=20 > - Cheap/Fast channel/connection setup >=20 > - Wide, "safe" deployment >=20 > - Competes with TCP/HTTP/1.1 (performance-wise) >=20 > - Multipath/roaming robustness, i.e. the "driveway" problem >=20 > =20 >=20 > =20 >=20 > I'll reiterate that by far the most important feature is "is = deployed". >=20 > Nothing else matters until that is true, at least at the = application-layer. >=20 > -=3DR >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 >=20 > Email secured by Check Point >=20 >=20 From mthornbu@adobe.com Tue Aug 27 14:46:46 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FC711E822E for ; Tue, 27 Aug 2013 14:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iw3b9cYvL6XS for ; Tue, 27 Aug 2013 14:46:41 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAC911E8227 for ; Tue, 27 Aug 2013 14:46:40 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUh0eHRV9qpZ/XoCAIfsnxVOHpNEgJetp@postini.com; Tue, 27 Aug 2013 14:46:41 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r7RLgWiH023335; Tue, 27 Aug 2013 14:42:32 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r7RLk4w7005330; Tue, 27 Aug 2013 14:46:04 -0700 (PDT) Received: from nambx08.corp.adobe.com ([10.8.189.94]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Tue, 27 Aug 2013 14:46:04 -0700 From: Michael Thornburgh To: Mike Belshe , Yoav Nir Date: Tue, 27 Aug 2013 14:46:01 -0700 Thread-Topic: [tsvwg] The List (of application-layer desired features) Thread-Index: Ac6jBaKY9C1oaQ+cR92r+ukvW2dXcQAYxtpg Message-ID: References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D9D602D39A98E34D9C43E965BEC7439826988809nambx08corpadob_" MIME-Version: 1.0 Cc: HTTP Working Group , "tsvwg@ietf.org" Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 21:46:46 -0000 --_000_D9D602D39A98E34D9C43E965BEC7439826988809nambx08corpadob_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable if you're bringing up something like QUIC, i'll point out that RTMFP addres= ses almost every point on The List, and is currently widely deployed in the= Internet (in Flash Player) with 5+ years of deployment experience. RTMFP = is a general-purpose transport protocol that runs on top of UDP and provide= s prioritization, parallel message channels ("flows"), partial reliability,= shared congestion control, a generalized security framework, independent f= low control for every flow/channel, no flow-flow HOL blocking, IP address m= obility, and more. RTMFP sessions start in 2 RTT, and arbitrary numbers of= unidirectional flows in that session can be started in 0 RTT. flows are n= amed with arbitrary/opaque-to-RTMFP metadata instead of port or stream numb= ers. "return flow association" generalizes bidirectional communication to = arbitrarily complex trees of flows, which can more naturally model structur= ed data transport (such as request/multiple-response). RTMFP is described here: http://tools.ietf.org/html/draft-thornburgh-adobe-rtmfp and is currently in the RFC Editor's queue for publication as an Informatio= nal RFC. note that while SCTP might not technically have HOL blocking stream-stream,= the structure of its acknowledgements and the Transmission Sequence Number= semantics can cause a priority inversion during periods of congestion. SC= TP does not have independent flow control for each stream. some thoughts on "fast channel startup with no state at the server": 1) you will typically want some kind of handshake with the server to esta= blish that the client is actually at the address it appears to be coming fr= om, to avoid TCP's "SYN flood" problem. that means at least one RTT when y= ou have no current state at the server for a client. 2) when designing RTMFP, we rejected a "connection reset" message that co= uld be sent by a server to a client that thought it had a connection when n= o connection existed in the server (for example, if the server rebooted or = timed out the connection but the client didn't know), as that would be an a= busable denial-of-service vector. 3) if you're willing to maintain some state at a server, you can leave an= RTMFP session open for a long time, and use the "address mobility" capabil= ity to handle the case when a client changes addresses (for example, on get= ting a new translation in a NAT after a quiet period). the method describe= d in Section 3.5.4.2 of the RTMFP spec currently has a 1 RTT cost to verify= the address change. that method could be modified to allow a provisional = change of address immediately, with a switch back to the old address if the= verification fails. 4) if you've been idle for long enough to time out a session (minutes?), = then establishing a new session (even at a cost of a couple RTTs) shouldn't= perceptually be a big deal. -michael thornburgh From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of M= ike Belshe Sent: Tuesday, August 06, 2013 2:31 AM To: Yoav Nir Cc: HTTP Working Group; tsvwg@ietf.org Subject: Re: [tsvwg] The List (of application-layer desired features) On Tue, Aug 6, 2013 at 10:49 AM, Yoav Nir > wrote: I think most of that is addressed in SCTP. Except the deployment part. Sta= ndards people can't force vendors of operating systems or Linux distributio= ns to include any feature. So we have a lot of "version 2"s in the IETF tha= t take a very long time to get deployed. It's also much more attractive to define a new thing (like SCTP) than to ma= ke something old work a little better. SCTP was sexier than TCPM. So it took ages to get deployment of IPv6, IKEv2, TLS 1.2, and all three ar= e still used far less than IPv4, IKEv1 and TLS 1.0. SCTP is used almost nev= er. HTTP/2 will likely fare better because the vendors are more involved an= d committed, but it's hard to make predictions, especially about the future= . You're right, SCTP is non-deployable, which makes it a non-starter. SCTP a= lso does not address handshake issues or TLS issues. I don't mean to sound inflammatory - but for all intents and purposes, the = next generation transport will need to be in user space and run on top of U= DP. There simply is no other deployable option on the table. QUIC is alre= ady reasonably far at exploring these issues: http://en.wikipedia.org/wiki/= QUIC Mike Yoav From: Roberto Peon [mailto:grmocg@gmail.com] Sent: Tuesday, August 06, 2013 11:16 AM To: HTTP Working Group; tsvwg@ietf.org Subject: Re: The List (of application-layer desired features) Actually sending to the right list for TSVWG... -=3DR On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon > wrote: For those of you who missed it, at the HTTPBis/TSVG joint session, a questi= on about what applications want from the transport (I really want to put qu= otes around that) came up. Here is a rendition of what was on the note that I jotted down in response = to this question, and which I passed to people at the mic. (Apps-folks want the following) Deployed in 1996: ----------------------------------------- - Prioritization - Partial Reliability - "Shared" congestion between multiple streams - Security - No HOL blocking on stream X when loss on stream Y - Cheap/Fast channel/connection setup - Wide, "safe" deployment - Competes with TCP/HTTP/1.1 (performance-wise) - Multipath/roaming robustness, i.e. the "driveway" problem I'll reiterate that by far the most important feature is "is deployed". Nothing else matters until that is true, at least at the application-layer. -=3DR Email secured by Check Point --_000_D9D602D39A98E34D9C43E965BEC7439826988809nambx08corpadob_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

if you= 217;re bringing up something like QUIC, i’ll point out that RTMFP add= resses almost every point on The List, and is currently widely deployed in = the Internet (in Flash Player) with 5+ years of deployment experience. = ; RTMFP is a general-purpose transport protocol that runs on top of UDP and= provides prioritization, parallel message channels (“flows”), = partial reliability, shared congestion control, a generalized security fram= ework, independent flow control for every flow/channel, no flow-flow HOL bl= ocking, IP address mobility, and more.  RTMFP sessions start in 2 RTT,= and arbitrary numbers of unidirectional flows in that session can be start= ed in 0 RTT.  flows are named with arbitrary/opaque-to-RTMFP metadata = instead of port or stream numbers.  “return flow associationR= 21; generalizes bidirectional communication to arbitrarily complex trees of= flows, which can more naturally model structured data transport (such as r= equest/multiple-response).

 

RTMFP is described= here:

 

  http://tools.ietf.org/html/draft-thorn= burgh-adobe-rtmfp

 

and is currently in the= RFC Editor’s queue for publication as an Informational RFC.

 

note that while SCTP might not technically have HOL b= locking stream-stream, the structure of its acknowledgements and the Transm= ission Sequence Number semantics can cause a priority inversion during peri= ods of congestion.  SCTP does not have independent flow control for ea= ch stream.

 

some thoughts on “fast chann= el startup with no state at the server”:

 

  1) you will typically want some kind of handshake with the server = to establish that the client is actually at the address it appears to be co= ming from, to avoid TCP’s “SYN flood” problem.  that= means at least one RTT when you have no current state at the server for a = client.

 <= /span>

  2) when designing RTMFP, we re= jected a “connection reset” message that could be sent by a ser= ver to a client that thought it had a connection when no connection existed= in the server (for example, if the server rebooted or timed out the connec= tion but the client didn’t know), as that would be an abusable denial= -of-service vector.

 

  3) if you’= re willing to maintain some state at a server, you can leave an RTMFP sessi= on open for a long time, and use the “address mobility” capabil= ity to handle the case when a client changes addresses (for example, on get= ting a new translation in a NAT after a quiet period).  the method des= cribed in Section 3.5.4.2 of the RTMFP spec currently has a 1 RTT cost to v= erify the address change.  that method could be modified to allow a pr= ovisional change of address immediately, with a switch back to the old addr= ess if the verification fails.

 

  4) if y= ou’ve been idle for long enough to time out a session (minutes?), the= n establishing a new session (even at a cost of a couple RTTs) shouldn̵= 7;t perceptually be a big deal.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

-michael thor= nburgh

 

 

From: tsvwg-bounces@ietf.org [mailto:tsvwg-bo= unces@ietf.org] On Behalf Of Mike Belshe
Sent: Tuesday, Au= gust 06, 2013 2:31 AM
To: Yoav Nir
Cc: HTTP Working Gro= up; tsvwg@ietf.org
Subject: Re: [tsvwg] The List (of application-= layer desired features)

 

 

 

<= div>

On Tue, Aug 6, 2013 at 10:49 AM, Yoav Nir <ynir@checkpoint.com> wrote:

 

Mike

 

&n= bsp;

 

 

 

 

Yoa= v

 

<= b>From:<= /span> Roberto Peon [mailto:grmocg@gmail.com]
Sent: Tuesday, August 06, 2013 11:16 AM=

 

&nb= sp;

On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon = <grmocg@gmail.com<= /a>> wrote:

 



Email secured by Check Point

 

= --_000_D9D602D39A98E34D9C43E965BEC7439826988809nambx08corpadob_-- From grmocg@gmail.com Tue Aug 27 15:22:52 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EFF11E80E3 for ; Tue, 27 Aug 2013 15:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.144 X-Spam-Level: X-Spam-Status: No, score=-0.144 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNh-YubNaVv9 for ; Tue, 27 Aug 2013 15:22:50 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAD921F93BA for ; Tue, 27 Aug 2013 15:22:47 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so6703831oag.1 for ; Tue, 27 Aug 2013 15:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DqbsbmC/zoCO0Z3c8sIX9TSdt3+RDGQfdxHaJLNocsw=; b=BD1QGx0VhdFaxwnTCeYyJ8A/AvufsZovL0QsUq3fy5gIcCbIkGGDfN0Q6imfL/Vqf/ fsGKwz79owHkRK7spXQrQVsChwR/wByKwkCkQLVGw+X65NEZnQbAH44EaVP8dUjEu5N/ CjQnWdc3ukilOsjmq7rRgA6VHkAbECoo4mtJGWRpZGC+droS5mcRnztwE0RnviPqg7e2 AiVelxcuvUrmtYBE062jvM1smhxvBh1rqC7qDWf6jve+UlvSxBmiD1VJ3F3FqykY0Ht1 tS+bF0UZGRRMM2+CDP46RLuLARLd5+CxNd9MeudT14s5ovVOQHOvsZx2TOMZtG0s3LXo dwZw== MIME-Version: 1.0 X-Received: by 10.182.18.102 with SMTP id v6mr4107147obd.71.1377642167180; Tue, 27 Aug 2013 15:22:47 -0700 (PDT) Received: by 10.76.20.109 with HTTP; Tue, 27 Aug 2013 15:22:47 -0700 (PDT) In-Reply-To: References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> Date: Tue, 27 Aug 2013 15:22:47 -0700 Message-ID: From: Roberto Peon To: Mike Belshe Content-Type: multipart/alternative; boundary=001a11c339e600a44604e4f550a3 Cc: "tsvwg@ietf.org" , Yoav Nir , HTTP Working Group Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 22:22:52 -0000 --001a11c339e600a44604e4f550a3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 0-additional-RTTs whenever safe means LOTS of money, actually. Latency and latency variance are highly correlated with bounce rates, etc. I should have probably added "free to use" to the list of requirements, but other than that, if it gets results, it is something which should be examined and iterated upon. I am personally quite agnostic to the name, format, company, etc. of who develops and deploys the next better thing. The important part is that we keep moving forward. "Keep moving forward" implies that we're willing to continue to try the next better thing, which we can do only be lowering the barrier to entry (in safe ways). -=3DR On Tue, Aug 27, 2013 at 3:12 PM, Mike Belshe wrote: > > > > On Tue, Aug 27, 2013 at 2:46 PM, Michael Thornburgh w= rote: > >> if you=92re bringing up something like QUIC, i=92ll point out that RTMFP >> addresses almost every point on The List, and is currently widely deploy= ed >> in the Internet (in Flash Player) with 5+ years of deployment experience= . >> RTMFP is a general-purpose transport protocol that runs on top of UDP an= d >> provides prioritization, parallel message channels (=93flows=94), partia= l >> reliability, shared congestion control, a generalized security framework= , >> independent flow control for every flow/channel, no flow-flow HOL blocki= ng, >> IP address mobility, and more. RTMFP sessions start in 2 RTT, and >> arbitrary numbers of unidirectional flows in that session can be started= in >> 0 RTT. flows are named with arbitrary/opaque-to-RTMFP metadata instead = of >> port or stream numbers. =93return flow association=94 generalizes >> bidirectional communication to arbitrarily complex trees of flows, which >> can more naturally model structured data transport (such as >> request/multiple-response).**** >> >> ** ** >> >> RTMFP is described here:**** >> >> ** ** >> >> http://tools.ietf.org/html/draft-thornburgh-adobe-rtmfp**** >> >> ** ** >> >> and is currently in the RFC Editor=92s queue for publication as an >> Informational RFC. >> > > Sounds cool. Why don't you benchmark it in a browser? If it does all > this stuff, it should be faster today. > > > >> **** >> >> ** ** >> >> note that while SCTP might not technically have HOL blocking >> stream-stream, the structure of its acknowledgements and the Transmissio= n >> Sequence Number semantics can cause a priority inversion during periods = of >> congestion. SCTP does not have independent flow control for each stream= . >> **** >> >> ** ** >> >> some thoughts on =93fast channel startup with no state at the server=94:= **** >> >> ** ** >> >> 1) you will typically want some kind of handshake with the server to >> establish that the client is actually at the address it appears to be >> coming from, to avoid TCP=92s =93SYN flood=94 problem. that means at le= ast one >> RTT when you have no current state at the server for a client. >> > > When at Google, we devised several systems to counteract this. The > winning candidate (never implemented) was a hybrid solution: you let the > first one in for free (no RTT), and require RTTs for the secondary parall= el > requests until confidence is established. This gives you most of the per= f > benefit. > > > >> **** >> >> ** ** >> >> 2) when designing RTMFP, we rejected a =93connection reset=94 message = that >> could be sent by a server to a client that thought it had a connection w= hen >> no connection existed in the server (for example, if the server rebooted= or >> timed out the connection but the client didn=92t know), as that would be= an >> abusable denial-of-service vector. >> > > Not if it ran atop a secured, encrypted channel :-) > > > > > >> **** >> >> ** ** >> >> 3) if you=92re willing to maintain some state at a server, you can lea= ve >> an RTMFP session open for a long time, and use the =93address mobility= =94 >> capability to handle the case when a client changes addresses (for examp= le, >> on getting a new translation in a NAT after a quiet period). the method >> described in Section 3.5.4.2 of the RTMFP spec currently has a 1 RTT cos= t >> to verify the address change. that method could be modified to allow a >> provisional change of address immediately, with a switch back to the old >> address if the verification fails. >> > > Maybe, but generally, I think that doesn't scales enough or as well as it > could.... I was thinking client state, but happy to be proven wrong. > > >> **** >> >> ** ** >> >> 4) if you=92ve been idle for long enough to time out a session >> (minutes?), then establishing a new session (even at a cost of a couple >> RTTs) shouldn=92t perceptually be a big deal. >> > > I disagree :-) RTTs are still 100+ms. Thats money. > > Mike > > > > > >> **** >> >> ** ** >> >> -michael thornburgh**** >> >> ** ** >> >> ** ** >> >> *From:* tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] *On >> Behalf Of *Mike Belshe >> *Sent:* Tuesday, August 06, 2013 2:31 AM >> *To:* Yoav Nir >> *Cc:* HTTP Working Group; tsvwg@ietf.org >> *Subject:* Re: [tsvwg] The List (of application-layer desired features)*= * >> ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> On Tue, Aug 6, 2013 at 10:49 AM, Yoav Nir wrote:**= * >> * >> >> I think most of that is addressed in SCTP. Except the deployment part. >> Standards people can=92t force vendors of operating systems or Linux >> distributions to include any feature. So we have a lot of =93version 2= =94s in >> the IETF that take a very long time to get deployed. **** >> >> **** >> >> It=92s also much more attractive to define a new thing (like SCTP) than = to >> make something old work a little better. SCTP was sexier than TCPM.**** >> >> **** >> >> So it took ages to get deployment of IPv6, IKEv2, TLS 1.2, and all three >> are still used far less than IPv4, IKEv1 and TLS 1.0. SCTP is used almos= t >> never. HTTP/2 will likely fare better because the vendors are more invol= ved >> and committed, but it=92s hard to make predictions, especially about the >> future.**** >> >> ** ** >> >> You're right, SCTP is non-deployable, which makes it a non-starter. SCT= P >> also does not address handshake issues or TLS issues.**** >> >> ** ** >> >> I don't mean to sound inflammatory - but for all intents and purposes, >> the next generation transport will need to be in user space and run on t= op >> of UDP. There simply is no other deployable option on the table. QUIC = is >> already reasonably far at exploring these issues: >> http://en.wikipedia.org/wiki/QUIC**** >> >> ** ** >> >> Mike**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> **** >> >> **** >> >> Yoav**** >> >> **** >> >> *From:* Roberto Peon [mailto:grmocg@gmail.com] >> *Sent:* Tuesday, August 06, 2013 11:16 AM**** >> >> >> *To:* HTTP Working Group; tsvwg@ietf.org >> *Subject:* Re: The List (of application-layer desired features)**** >> >> **** >> >> Actually sending to the right list for TSVWG...**** >> >> **** >> >> -=3DR**** >> >> **** >> >> On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon wrote:**= * >> * >> >> For those of you who missed it, at the HTTPBis/TSVG joint session, a >> question about what applications want from the transport (I really want = to >> put quotes around that) came up.**** >> >> **** >> >> Here is a rendition of what was on the note that I jotted down in >> response to this question, and which I passed to people at the mic.**** >> >> **** >> >> (Apps-folks want the following) Deployed in 1996:**** >> >> -----------------------------------------**** >> >> - Prioritization**** >> >> - Partial Reliability**** >> >> - "Shared" congestion between multiple streams**** >> >> - Security**** >> >> - No HOL blocking on stream X when loss on stream Y**** >> >> - Cheap/Fast channel/connection setup**** >> >> - Wide, "safe" deployment**** >> >> - Competes with TCP/HTTP/1.1 (performance-wise)**** >> >> - Multipath/roaming robustness, i.e. the "driveway" problem**** >> >> **** >> >> **** >> >> I'll reiterate that by far the most important feature is "is deployed".*= * >> ** >> >> Nothing else matters until that is true, at least at the >> application-layer.**** >> >> -=3DR**** >> >> **** >> >> **** >> >> **** >> >> >> >> Email secured by Check Point **** >> >> ** ** >> > > --001a11c339e600a44604e4f550a3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
0-additional-RTTs whenever safe means LOTS of money, actua= lly.
Latency and latency variance are highly correlated with bounce rat= es, etc.

I should have probably added "free t= o use" to the list of requirements, but other than that, if it gets re= sults, it is something which should be examined and iterated upon.
I am personally quite agnostic to the name, format, company= , etc. of who develops and deploys the next better thing. The important par= t is that we keep moving forward.

"Keep= moving forward" implies that we're willing to continue to try the= next better thing, which we can do only be lowering the barrier to entry (= in safe ways).

-=3DR


On Tue, Aug 27, 2013 at 3:12 PM, Mike Belshe <mike@b= elshe.com> wrote:



On Tue, Aug 27, 20= 13 at 2:46 PM, Michael Thornburgh <mthornbu@adobe.com> wrot= e:

if you=92re bringing up something like QUIC, i=92ll point out that = RTMFP addresses almost every point on The List, and is currently widely dep= loyed in the Internet (in Flash Player) with 5+ years of deployment experie= nce.=A0 RTMFP is a general-purpose transport protocol that runs on top of U= DP and provides prioritization, parallel message channels (=93flows=94), pa= rtial reliability, shared congestion control, a generalized security framew= ork, independent flow control for every flow/channel, no flow-flow HOL bloc= king, IP address mobility, and more.=A0 RTMFP sessions start in 2 RTT, and = arbitrary numbers of unidirectional flows in that session can be started in= 0 RTT.=A0 flows are named with arbitrary/opaque-to-RTMFP metadata instead = of port or stream numbers.=A0 =93return flow association=94 generalizes bid= irectional communication to arbitrarily complex trees of flows, which can m= ore naturally model structured data transport (such as request/multiple-res= ponse).

=A0

RTMFP is described here:<= u>

=A0

=A0 http://too= ls.ietf.org/html/draft-thornburgh-adobe-rtmfp

=A0

and is currently in the R= FC Editor=92s queue for publication as an Informational RFC.


Sounds cool. =A0Why don't you bench= mark it in a browser? =A0If it does all this stuff, it should be faster tod= ay.

=A0

=A0

note that while SCTP might not technically have HOL blocking str= eam-stream, the structure of its acknowledgements and the Transmission Sequ= ence Number semantics can cause a priority inversion during periods of cong= estion.=A0 SCTP does not have independent flow control for each stream.<= /u>

=A0

some thoughts on =93fast = channel startup with no state at the server=94:

=A0

=A0 1) you will typically= want some kind of handshake with the server to establish that the client i= s actually at the address it appears to be coming from, to avoid TCP=92s = =93SYN flood=94 problem.=A0 that means at least one RTT when you have no cu= rrent state at the server for a client.


When at Google, we devised several syst= ems to counteract this. =A0The winning candidate (never implemented) was a = hybrid solution: =A0you let the first one in for free (no RTT), and require= RTTs for the secondary parallel requests until confidence is established. = =A0This gives you most of the perf benefit.

=A0

=A0

=A0 2) when designing RTMFP, we rejected a =93connection reset= =94 message that could be sent by a server to a client that thought it had = a connection when no connection existed in the server (for example, if the = server rebooted or timed out the connection but the client didn=92t know), = as that would be an abusable denial-of-service vector.


Not if it ran atop a secured, encrypted chan= nel :-)



=A0

=A0

=A0 3) if you=92re willing to maintain some state at a server, y= ou can leave an RTMFP session open for a long time, and use the =93address = mobility=94 capability to handle the case when a client changes addresses (= for example, on getting a new translation in a NAT after a quiet period).= =A0 the method described in Section 3.5.4.2 of the RTMFP spec currently has= a 1 RTT cost to verify the address change.=A0 that method could be modifie= d to allow a provisional change of address immediately, with a switch back = to the old address if the verification fails.


Maybe, but generally, I think that doesn'= t scales enough or as well as it could.... =A0I was thinking client state, = but happy to be proven wrong.
=A0

<= u>

=A0

=A0 4) if you=92ve been idle for long enough to time out a sessi= on (minutes?), then establishing a new session (even at a cost of a couple = RTTs) shouldn=92t perceptually be a big deal.


I disagree :-) RTTs are still 100+ms. =A0That= s money.

Mike



=A0

=A0

-michael thornburgh

= =A0

=A0

From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org= ] On Behalf Of Mike Belshe
Sent: Tuesday, August 06, 2013 2:31 AM
To: Yoav Nir
= Cc: HTTP Working Group; tsvwg@ietf.org
Subject: Re: [tsvwg] The List (of applica= tion-layer desired features)

=A0

=A0

=

=A0

On Tue, A= ug 6, 2013 at 10:49 AM, Yoav Nir <ynir@checkpoint.com> wrote:

I think most of that is addressed in SCTP. =A0Except t= he deployment part. Standards people can=92t force vendors of operating sys= tems or Linux distributions to include any feature. So we have a lot of =93= version 2=94s in the IETF that take a very long time to get deployed.

=A0

It=92s also much more att= ractive to define a new thing (like SCTP) than to make something old work a= little better. SCTP was sexier than TCPM.

=A0

So it took ages to get de= ployment of IPv6, IKEv2, TLS 1.2, and all three are still used far less tha= n IPv4, IKEv1 and TLS 1.0. SCTP is used almost never. HTTP/2 will likely fa= re better because the vendors are more involved and committed, but it=92s h= ard to make predictions, especially about the future.<= /p>

=A0

You're right, SC= TP is non-deployable, which makes it a non-starter. =A0SCTP also does not a= ddress handshake issues or TLS issues.

=A0

I don't mean to sound inflam= matory - but for all intents and purposes, the next generation transport wi= ll need to be in user space and run on top of UDP. =A0There simply is no ot= her deployable option on the table. =A0QUIC is already reasonably far at ex= ploring these issues:=A0http://en.wikipedia.org/wiki/QUIC

=A0

Mike

=A0

=A0

=A0

=A0

=A0

=A0

Yoav<= /u>

=A0

From: Roberto Peon [mailto:grmocg@gmail.com]
Sent: Tuesday, August 06, 2013 11:16 AM


To: HTTP Working Group; tsvwg@ietf.org
Subject: Re: The List (of appl= ication-layer desired features)

=A0

Actually sending to the right list fo= r TSVWG...

=A0

-=3D= R

=A0

On Tue, A= ug 6, 2013 at 1:14 AM, Roberto Peon <grmocg@gmail.com> wrote:

For those of you who missed it, at the HTTPBis/TSVG joint sess= ion, a question about what applications want from the transport (I really w= ant to put quotes around that) came up.

=A0

Here is a rendition of what was = on the note that I jotted down in response to this question, and which I pa= ssed to people at the mic.

=A0

(Apps-folks want the following) = Deployed in 1996:

--------------------------= ---------------

- Prioritization

- Partial Reliability

- "Shared" congestion between multiple = streams

- Security

- No HOL blocking on stream X when loss on stream Y=

- Cheap/Fast =A0channel/connection setup

- Wide, "safe" deployment

- Competes with TCP/HTTP/1.1 (performance-wise)=

- Multipath/roaming robustness, i.e. the "driveway&q= uot; problem

=A0

=A0

I'= ;ll reiterate that by far the most important feature is "is deployed&q= uot;.

Nothing else matters until that is tru= e, at least at the application-layer.

-=3DR=

=A0<= /u>

=A0

=A0



Email secured by Check Point

=A0


--001a11c339e600a44604e4f550a3-- From internet-drafts@ietf.org Wed Aug 28 00:13:20 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4919A11E8160; Wed, 28 Aug 2013 00:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhiV+JrD0Mjj; Wed, 28 Aug 2013 00:13:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 383FA11E8147; Wed, 28 Aug 2013 00:13:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130828071318.6864.64635.idtracker@ietfa.amsl.com> Date: Wed, 28 Aug 2013 00:13:18 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-sack-immediately-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 07:13:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : SACK-IMMEDIATELY Extension for the Stream Control Transm= ission Protocol Author(s) : Michael Tuexen Irene Ruengeler Randall R. Stewart Filename : draft-ietf-tsvwg-sctp-sack-immediately-04.txt Pages : 8 Date : 2013-08-28 Abstract: This document updates RFC 4960 by defining a method for the sender of a DATA chunk to indicate that the corresponding SACK chunk should be sent back immediately and not be delayed. It is done by specifying a bit in the DATA chunk header, called the I-bit, which can get set either by the SCTP implementation or by the application using an SCTP stack. Since unknown flags in chunk headers are ignored by SCTP implementations, this extension does not introduce any interoperability problems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-sack-immediately There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-sack-immediately-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-sack-immediately-04 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 michawe@ifi.uio.no Wed Aug 28 00:59:23 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBFA21F88A9 for ; Wed, 28 Aug 2013 00:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CM6nxIxxuumY for ; Wed, 28 Aug 2013 00:59:18 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id A36DA21F88BA for ; Wed, 28 Aug 2013 00:59:16 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VEaee-0006Wh-8i; Wed, 28 Aug 2013 09:59:04 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VEaed-0003XT-PT; Wed, 28 Aug 2013 09:59:04 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_AC5868A3-9012-4B32-9DD9-7310065CEBFB" From: Michael Welzl In-Reply-To: <081D0F76-F4AE-42D5-B354-795BE4910D23@lurchi.franken.de> Date: Wed, 28 Aug 2013 09:58:59 +0200 Message-Id: <2ADDC87F-8E20-4D7D-B0A0-20CE3DD12B81@ifi.uio.no> References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> <081D0F76-F4AE-42D5-B354-795BE4910D23@lurchi.franken.de> To: Michael Tuexen X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 6 sum msgs/h 2 total rcpts 6944 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.9, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.94, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 994ED6C647D93FC5799AD630002704E7779D2B29 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -68 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 2766 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: "tsvwg@ietf.org" , Yoav Nir , Mike Belshe , HTTP Working Group Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 07:59:23 -0000 --Apple-Mail=_AC5868A3-9012-4B32-9DD9-7310065CEBFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, I agree 100% with Michael Tuexen here... just one thing, in line: >> You're right, SCTP is non-deployable, which makes it a non-starter. = SCTP also does not address handshake issues or TLS issues. > I agree that SCTP over IP can't be deployed now due to missing NAT = support. Indeed that's not an argument against SCTP/UDP/IP, but I also wonder = why, instead of saying "can't be deployed", people don't just go ahead = and use it whenever it's there and works, with a fall-back to TCP? This = could be done with (this version of) Happy Eyeballs: http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02 Good reasons against doing this are... what? Anyone? Cheers, Michael --Apple-Mail=_AC5868A3-9012-4B32-9DD9-7310065CEBFB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
You're right, SCTP is = non-deployable, which makes it a non-starter.  SCTP also does not = address handshake issues or TLS issues.
I agree that = SCTP over IP can't be deployed now due to missing NAT = support.

Indeed that's not an = argument against SCTP/UDP/IP, but I also wonder why, instead of saying = "can't be deployed", people don't just go ahead and use it whenever it's = there and works, with a fall-back to TCP? This could be done with (this = version of) Happy Eyeballs:
http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02

Good reasons against doing this are... what? = Anyone?

Cheers,
Michael

<= /div>
= --Apple-Mail=_AC5868A3-9012-4B32-9DD9-7310065CEBFB-- From michawe@ifi.uio.no Wed Aug 28 04:54:12 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F44E21F9929 for ; Wed, 28 Aug 2013 04:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.9 X-Spam-Level: X-Spam-Status: No, score=-103.9 tagged_above=-999 required=5 tests=[AWL=-2.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9TmbdzSDsLG for ; Wed, 28 Aug 2013 04:54:07 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id BDDAE21F9E88 for ; Wed, 28 Aug 2013 04:53:59 -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 1VEeJY-0005w0-1k; Wed, 28 Aug 2013 13:53:32 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VEeJX-0001rY-8l; Wed, 28 Aug 2013 13:53:31 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_012F4437-F617-4C95-90CD-8305644C7705" From: Michael Welzl In-Reply-To: Date: Wed, 28 Aug 2013 13:53:29 +0200 Message-Id: <07FF0072-DA3F-4E4A-9418-F2C4CF918817@ifi.uio.no> References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> <081D0F76-F4AE-42D5-B354-795BE4910D23@lurchi.franken.de> <2ADDC87F-8E20-4D7D-B0A0-20CE3DD12B81@ifi.uio.no> To: willchan@google.com X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 1 sum rcpts/h 7 sum msgs/h 1 total rcpts 6953 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.9, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-1.94, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EF9E70F37F3500DABB00633F0ABDD2B3974F6092 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -68 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 2768 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: Michael Tuexen , "tsvwg@ietf.org" , Yoav Nir , Mike Belshe , HTTP Working Group Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 11:54:12 -0000 --Apple-Mail=_012F4437-F617-4C95-90CD-8305644C7705 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 28. aug. 2013, at 11:53, William Chan (=E9=99=88=E6=99=BA=E6=98=8C) = wrote: > On Aug 28, 2013 4:01 PM, "Michael Welzl" wrote: > > > > Hi, > > > > I agree 100% with Michael Tuexen here... just one thing, in line: > > > > > >>> You're right, SCTP is non-deployable, which makes it a = non-starter. SCTP also does not address handshake issues or TLS issues. > >> > >> I agree that SCTP over IP can't be deployed now due to missing NAT = support. > > > > > > Indeed that's not an argument against SCTP/UDP/IP, but I also wonder = why, instead of saying "can't be deployed", people don't just go ahead = and use it whenever it's there and works, with a fall-back to TCP? This = could be done with (this version of) Happy Eyeballs: > > http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02 > > > > Good reasons against doing this are... what? Anyone? >=20 > Implementation usefulness. Why bother adding code that barely gets = used (and that is unlikely to improve in the near future), adds = complexity, code bloat, etc...? >=20 Fair point. That's why I think the OS should in fact do Happy Eyeballs = for you! > SCTP/UDP has a much higher likelihood of usefulness. But as Roberto = has mentioned, it still has deficiencies, mostly around RTTs (connection = + DTLS setup). If they can be fixed, great. Let's do it. >=20 Why shouldn't it be possible to fix SCTP to do whatever you want? Anyway = it sounds to me like a simpler approach than building a whole new = protocol. Of course, SCTP++ isn't the nicest acronym... then again, = RTMFP isn't either, if you ask me, sounds almost like RTFM... QUIC is = great though! Cheers, Michael --Apple-Mail=_012F4437-F617-4C95-90CD-8305644C7705 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 28, 2013 4:01 PM, "Michael Welzl" = <michawe@ifi.uio.no> = wrote:
>
> Hi,
>
> I agree 100% with Michael Tuexen here... just one thing, in = line:
>
>
>>> You're right, SCTP is non-deployable, which makes it a = non-starter.  SCTP also does not address handshake issues or TLS = issues.
>>
>> I agree that SCTP over IP can't be deployed now due to missing = NAT support.
>
>
> Indeed that's not an argument against SCTP/UDP/IP, but I also = wonder why, instead of saying "can't be deployed", people don't just go = ahead and use it whenever it's there and works, with a fall-back to TCP? = This could be done with (this version of) Happy Eyeballs:
> http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02 >
> Good reasons against doing this are... what? Anyone?

Implementation usefulness. Why bother adding code that = barely gets used (and that is unlikely to improve in the near future), = adds complexity, code bloat, etc...?

Fair point. = That's why I think the OS should in fact do Happy Eyeballs for = you!

SCTP/UDP has a = much higher likelihood of usefulness. But as Roberto has mentioned, it = still has deficiencies, mostly around RTTs (connection + DTLS setup). If = they can be fixed, great. Let's do it.

Why shouldn't it be possible to fix SCTP to do = whatever you want? Anyway it sounds to me like a simpler approach than = building a whole new protocol. Of course, SCTP++ isn't the nicest = acronym...  then again, RTMFP isn't either, if you ask me, sounds = almost like RTFM...  QUIC is great = though!

Cheers,
Michael

<= /body>= --Apple-Mail=_012F4437-F617-4C95-90CD-8305644C7705-- From Michael.Tuexen@lurchi.franken.de Wed Aug 28 06:41:43 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEF711E819E for ; Wed, 28 Aug 2013 06:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkE6Bn-W5b10 for ; Wed, 28 Aug 2013 06:41:42 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 8401211E81A4 for ; Wed, 28 Aug 2013 06:41:40 -0700 (PDT) Received: from [192.168.1.100] (p508F0592.dip0.t-ipconnect.de [80.143.5.146]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A24DF1C0C0692; Wed, 28 Aug 2013 15:41:37 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Tuexen In-Reply-To: Date: Wed, 28 Aug 2013 15:41:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <34074BE6-2402-4228-8601-3AF51808F879@lurchi.franken.de> References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> <081D0F76-F4AE-42D5-B354-795BE4910D23@lurchi.franken.de> <2ADDC87F-8E20-4D7D-B0A0-20CE3DD12B81@ifi.uio.no> <07FF0072-DA3F-4E4A-9418-F2C4CF918817@ifi.uio.no> To: willchan@google.com X-Mailer: Apple Mail (2.1508) Cc: "tsvwg@ietf.org" , Yoav Nir , Mike Belshe , Michael Welzl , HTTP Working Group Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 13:41:43 -0000 On Aug 28, 2013, at 3:34 PM, William Chan (=E9=99=88=E6=99=BA=E6=98=8C) = wrote: > On Wed, Aug 28, 2013 at 7:53 PM, Michael Welzl = wrote: >=20 > On 28. aug. 2013, at 11:53, William Chan (=E9=99=88=E6=99=BA=E6=98=8C) = wrote: >=20 >> On Aug 28, 2013 4:01 PM, "Michael Welzl" wrote: >> > >> > Hi, >> > >> > I agree 100% with Michael Tuexen here... just one thing, in line: >> > >> > >> >>> You're right, SCTP is non-deployable, which makes it a = non-starter. SCTP also does not address handshake issues or TLS issues. >> >> >> >> I agree that SCTP over IP can't be deployed now due to missing NAT = support. >> > >> > >> > Indeed that's not an argument against SCTP/UDP/IP, but I also = wonder why, instead of saying "can't be deployed", people don't just go = ahead and use it whenever it's there and works, with a fall-back to TCP? = This could be done with (this version of) Happy Eyeballs: >> > http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02 >> > >> > Good reasons against doing this are... what? Anyone? >>=20 >> Implementation usefulness. Why bother adding code that barely gets = used (and that is unlikely to improve in the near future), adds = complexity, code bloat, etc...? >>=20 > Fair point. That's why I think the OS should in fact do Happy Eyeballs = for you! >=20 >=20 > I'm not sure if you're trolling me. In case you aren't, you may want = to look at the graph at: = http://gs.statcounter.com/#os-ww-monthly-201207-201307. Windows XP = (released in 2001) is still around 20% of browser usage. If you have the = ability to get Microsoft to backport SCTP/IP onto their XP stack, I'd = love to know. We're not going to ignore large segments of our user base = when we could use UDP and deploy for all relevant OSes. That may be = acceptable for some applications, but not for the browser I work on. You can build SCTP in your browser and run it on top of UDP. This is = what is done in RTCWeb. They use SCTP over DTLS over UDP with SCTP and DTLS running = in the application layer. This is available in recent versions of Firefox and = running on Windows XP... Best regards Michael >=20 > This is why Roberto said: > """ > Wide, "safe" deployment > """ >> SCTP/UDP has a much higher likelihood of usefulness. But as Roberto = has mentioned, it still has deficiencies, mostly around RTTs (connection = + DTLS setup). If they can be fixed, great. Let's do it. >>=20 > Why shouldn't it be possible to fix SCTP to do whatever you want? = Anyway it sounds to me like a simpler approach than building a whole new = protocol. Of course, SCTP++ isn't the nicest acronym... then again, = RTMFP isn't either, if you ask me, sounds almost like RTFM... QUIC is = great though! >=20 > I have no attachments to the protocol name or frame format or = whatever. Look at what we're doing in HTTP/2 which was inspired by SPDY = but now has undergone substantial changes. We're serious about this. As = long as the transport provides all the features we need, we'll use it. = This conversation got started because tsvwg asked httpbis what the = application layer wants from the transport. We're telling you. I think = the constructive next step is for tsvwg folks to ask for clarification = on any requirement they don't understand, discuss whether or not the = requirements are reasonable, and discuss what may need to be done to = address them. > =20 >=20 > Cheers, > Michael >=20 >=20 From Michael.Tuexen@lurchi.franken.de Wed Aug 28 07:31:25 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC03A21F9EE9 for ; Wed, 28 Aug 2013 07:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwEm26FaB503 for ; Wed, 28 Aug 2013 07:31:24 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 742C921F9B18 for ; Wed, 28 Aug 2013 07:31:23 -0700 (PDT) Received: from [192.168.1.100] (p508F0592.dip0.t-ipconnect.de [80.143.5.146]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id AC4241C0C0693; Wed, 28 Aug 2013 16:31:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Tuexen In-Reply-To: Date: Wed, 28 Aug 2013 16:31:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8BC0FBF2-459F-4172-B63F-2D58B7C32E2E@lurchi.franken.de> References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> <081D0F76-F4AE-42D5-B354-795BE4910D23@lurchi.franken.de> <2ADDC87F-8E20-4D7D-B0A0-20CE3DD12B81@ifi.uio.no> <07FF0072-DA3F-4E4A-9418-F2C4CF918817@ifi.uio.no> <34074BE6-2402-4228-8601-3AF51808F879@lurchi.franken.de> To: willchan@google.com X-Mailer: Apple Mail (2.1508) Cc: "tsvwg@ietf.org" , Yoav Nir , Mike Belshe , Michael Welzl , HTTP Working Group Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 14:31:25 -0000 On Aug 28, 2013, at 3:44 PM, William Chan (=E9=99=88=E6=99=BA=E6=98=8C) = wrote: > On Wed, Aug 28, 2013 at 9:41 PM, Michael Tuexen = wrote: > On Aug 28, 2013, at 3:34 PM, William Chan (=E9=99=88=E6=99=BA=E6=98=8C) = wrote: >=20 > > On Wed, Aug 28, 2013 at 7:53 PM, Michael Welzl = wrote: > > > > On 28. aug. 2013, at 11:53, William Chan (=E9=99=88=E6=99=BA=E6=98=8C)= wrote: > > > >> On Aug 28, 2013 4:01 PM, "Michael Welzl" = wrote: > >> > > >> > Hi, > >> > > >> > I agree 100% with Michael Tuexen here... just one thing, in line: > >> > > >> > > >> >>> You're right, SCTP is non-deployable, which makes it a = non-starter. SCTP also does not address handshake issues or TLS issues. > >> >> > >> >> I agree that SCTP over IP can't be deployed now due to missing = NAT support. > >> > > >> > > >> > Indeed that's not an argument against SCTP/UDP/IP, but I also = wonder why, instead of saying "can't be deployed", people don't just go = ahead and use it whenever it's there and works, with a fall-back to TCP? = This could be done with (this version of) Happy Eyeballs: > >> > = http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02 > >> > > >> > Good reasons against doing this are... what? Anyone? > >> > >> Implementation usefulness. Why bother adding code that barely gets = used (and that is unlikely to improve in the near future), adds = complexity, code bloat, etc...? > >> > > Fair point. That's why I think the OS should in fact do Happy = Eyeballs for you! > > > > > > I'm not sure if you're trolling me. In case you aren't, you may want = to look at the graph at: = http://gs.statcounter.com/#os-ww-monthly-201207-201307. Windows XP = (released in 2001) is still around 20% of browser usage. If you have the = ability to get Microsoft to backport SCTP/IP onto their XP stack, I'd = love to know. We're not going to ignore large segments of our user base = when we could use UDP and deploy for all relevant OSes. That may be = acceptable for some applications, but not for the browser I work on. > You can build SCTP in your browser and run it on top of UDP. This is = what is done > in RTCWeb. They use SCTP over DTLS over UDP with SCTP and DTLS running = in the > application layer. This is available in recent versions of Firefox and = running > on Windows XP... >=20 > You may have missed the fact that Michael Welzl was talking about = SCTP/IP and I was responding to that. You may also have missed my note = below about SCTP over UDP where I said: "SCTP/UDP has a much higher = likelihood of usefulness." Ahh, OK. Thanks for the clarification. Best regards Michael >=20 > Cheers. > =20 >=20 > Best regards > Michael > > > > This is why Roberto said: > > """ > > Wide, "safe" deployment > > """ > >> SCTP/UDP has a much higher likelihood of usefulness. But as Roberto = has mentioned, it still has deficiencies, mostly around RTTs (connection = + DTLS setup). If they can be fixed, great. Let's do it. > >> > > Why shouldn't it be possible to fix SCTP to do whatever you want? = Anyway it sounds to me like a simpler approach than building a whole new = protocol. Of course, SCTP++ isn't the nicest acronym... then again, = RTMFP isn't either, if you ask me, sounds almost like RTFM... QUIC is = great though! > > > > I have no attachments to the protocol name or frame format or = whatever. Look at what we're doing in HTTP/2 which was inspired by SPDY = but now has undergone substantial changes. We're serious about this. As = long as the transport provides all the features we need, we'll use it. = This conversation got started because tsvwg asked httpbis what the = application layer wants from the transport. We're telling you. I think = the constructive next step is for tsvwg folks to ask for clarification = on any requirement they don't understand, discuss whether or not the = requirements are reasonable, and discuss what may need to be done to = address them. > > > > > > Cheers, > > Michael > > > > >=20 >=20 From trammell@tik.ee.ethz.ch Wed Aug 28 08:34:37 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E8E11E819E for ; Wed, 28 Aug 2013 08:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKlK9zxvQ+1X for ; Wed, 28 Aug 2013 08:34:33 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 8995121F91BF for ; Wed, 28 Aug 2013 08:34:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0A745D9309; Wed, 28 Aug 2013 17:34:28 +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 ZRMnRiBC3QtA; Wed, 28 Aug 2013 17:34:27 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id B85B6D9303; Wed, 28 Aug 2013 17:34:27 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <07FF0072-DA3F-4E4A-9418-F2C4CF918817@ifi.uio.no> Date: Wed, 28 Aug 2013 17:34:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> <081D0F76-F4AE-42D5-B354-795BE4910D23@lurchi.franken.de> <2ADDC87F-8E20-4D7D-B0A0-20CE3DD12B81@ifi.uio.no> <07FF0072-DA3F-4E4A-9418-F2C4CF918817@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1508) Cc: "tsvwg@ietf.org" , Yoav Nir , Mike Belshe , HTTP Working Group , willchan@google.com, Michael Tuexen Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 15:34:37 -0000 hi Michael, all, On 28 Aug 2013, at 13:53 , Michael Welzl wrote: >=20 > On 28. aug. 2013, at 11:53, William Chan (=E9=99=88=E6=99=BA=E6=98=8C) = wrote: >=20 >> On Aug 28, 2013 4:01 PM, "Michael Welzl" wrote: >> > >> > Hi, >> > >> > I agree 100% with Michael Tuexen here... just one thing, in line: >> > >> > >> >>> You're right, SCTP is non-deployable, which makes it a = non-starter. SCTP also does not address handshake issues or TLS issues. >> >> >> >> I agree that SCTP over IP can't be deployed now due to missing NAT = support. >> > >> > >> > Indeed that's not an argument against SCTP/UDP/IP, but I also = wonder why, instead of saying "can't be deployed", people don't just go = ahead and use it whenever it's there and works, with a fall-back to TCP? = This could be done with (this version of) Happy Eyeballs: >> > http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02 >> > >> > Good reasons against doing this are... what? Anyone? >>=20 >> Implementation usefulness. Why bother adding code that barely gets = used (and that is unlikely to improve in the near future), adds = complexity, code bloat, etc...? >>=20 > Fair point. That's why I think the OS should in fact do Happy Eyeballs = for you! My only concern here -- and I say this as someone who's a big fan of the = general approach of endpoints being smart in how they work around = deficiency in the network -- is that SCTP and TCP provide different = services. This is unlike the case with IPv4 and IPv6, the differences = between which are completely hidden behind the API (in the common case, = in the modern world, anyway).=20 So even if the OS handles the fallback (which it should), the = application still has to determine whether the SCTP features it wants to = use are available, unless the OS also provides SOCK_SEQPACKET (or = equivalent) service with partial reliability and/or multihoming and/or = streams over TCP. >> SCTP/UDP has a much higher likelihood of usefulness. But as Roberto = has mentioned, it still has deficiencies, mostly around RTTs (connection = + DTLS setup). If they can be fixed, great. Let's do it. >>=20 > Why shouldn't it be possible to fix SCTP to do whatever you want? = Anyway it sounds to me like a simpler approach than building a whole new = protocol. This, absolutely. But in order for it to take off, we need to make it as = simple as possible for application developers to adapt to the = availability different transport capabilities and services, which is = more an API than a protocol issue. Cheers, Brian From scott.brim@gmail.com Wed Aug 28 08:52:59 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873F111E81C3 for ; Wed, 28 Aug 2013 08:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.058 X-Spam-Level: X-Spam-Status: No, score=-102.058 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3LXw5IEZw13 for ; Wed, 28 Aug 2013 08:52:58 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7F16A11E81B4 for ; Wed, 28 Aug 2013 08:52:58 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id uz19so6939754obc.35 for ; Wed, 28 Aug 2013 08:52:58 -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:content-type; bh=LgxCmp6P0eLTRgnnSXU5d29+D3qjqylVcvVjBFfUiN4=; b=bYTRqaJy8JqDk/5vGD2vGM6SsUnN27RBlK/Sn6tNSEERtaGeukWPzUMlPXgeq8GcbN tF4HpAxuJdRXeap5UHqRG2pCgmzZUe2pXuyN3ugHyHTRG1dTmegcdSRIMdkbzmGzKs+W pskaOqCFGBEm4x60psSQkqSRIPxraVrnir0h1+wVHpKIeRF54Y9MuAkMT5kiX3vM6L/5 JZLGDqRY9fMiwxc0kJIRR2i6kB2uymrCEQyVb/0WAmRv2vqPDNtis3j7KRww8abVwyyM v02C7R3F+KuJe1ILdzernY0C7+rA0z7GlXwrT3gQbBjXRT6vYfr14j98tLRJTgBBZKGM 8yyA== X-Received: by 10.182.250.163 with SMTP id zd3mr24000240obc.20.1377705178082; Wed, 28 Aug 2013 08:52:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.44.105 with HTTP; Wed, 28 Aug 2013 08:52:37 -0700 (PDT) In-Reply-To: References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> <081D0F76-F4AE-42D5-B354-795BE4910D23@lurchi.franken.de> <2ADDC87F-8E20-4D7D-B0A0-20CE3DD12B81@ifi.uio.no> <07FF0072-DA3F-4E4A-9418-F2C4CF918817@ifi.uio.no> From: Scott Brim Date: Wed, 28 Aug 2013 11:52:37 -0400 Message-ID: To: Brian Trammell Content-Type: multipart/alternative; boundary=089e01634ec2beb74504e503fb6e Cc: "tsvwg@ietf.org" , Michael Welzl , Yoav Nir , Mike Belshe , HTTP Working Group , willchan@google.com, Michael Tuexen Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 15:52:59 -0000 --089e01634ec2beb74504e503fb6e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 28, 2013 at 11:34 AM, Brian Trammell wrote: > My only concern here -- and I say this as someone who's a big fan of the > general approach of endpoints being smart in how they work around > deficiency in the network -- is that SCTP and TCP provide different > services. ... > > So even if the OS handles the fallback (which it should), the application > still has to determine whether the SCTP features it wants to use are > available > Brian, this has been the case since (at least) IBM access method assembler macros. Somehow the apps that want to do adjust, if you give them the hooks to do so. We don't need to make it simple for everyone, just simple for those who want to use it. Scott --089e01634ec2beb74504e503fb6e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 28, 2013 at 11:34 AM, Brian Trammell <t= rammell@tik.ee.ethz.ch> wrote:
=
My only concern here -- and I say this as so= meone who's a big fan of the general approach of endpoints being smart = in how they work around deficiency in the network -- is that SCTP and TCP p= rovide different services. ...

So even if the OS handles the fallback (which it should), the application s= till has to determine whether the SCTP features it wants to use are availab= le

Brian, this has been the case since = (at least) IBM access method assembler macros. =A0Somehow the apps that wan= t to do adjust, if you give them the hooks to do so.

We don't need to make it simple for everyone, just = simple for those who want to use it.

Scott
--089e01634ec2beb74504e503fb6e-- From mthornbu@adobe.com Wed Aug 28 10:24:24 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E055721F93C4 for ; Wed, 28 Aug 2013 10:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=-2.228, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WY+EQk7LIj0i for ; Wed, 28 Aug 2013 10:24:17 -0700 (PDT) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id ED8E821F883D for ; Wed, 28 Aug 2013 10:24:09 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUh4yGx7dQwHHaSGNaWlJqmbMH31q+MP1@postini.com; Wed, 28 Aug 2013 10:24:10 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r7SHK6iH004674; Wed, 28 Aug 2013 10:20:06 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r7SHLawI004620; Wed, 28 Aug 2013 10:23:37 -0700 (PDT) Received: from nambx08.corp.adobe.com ([10.8.189.94]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Wed, 28 Aug 2013 10:23:33 -0700 From: Michael Thornburgh To: Roberto Peon , Mike Belshe Date: Wed, 28 Aug 2013 10:23:31 -0700 Thread-Topic: [tsvwg] The List (of application-layer desired features) Thread-Index: Ac6jdEuY3eFi1ZlLTDqC7+xi2wf5LwAnkW6Q Message-ID: References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D9D602D39A98E34D9C43E965BEC743982698893Enambx08corpadob_" MIME-Version: 1.0 Cc: Yoav Nir , HTTP Working Group , "tsvwg@ietf.org" Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 17:24:24 -0000 --_000_D9D602D39A98E34D9C43E965BEC743982698893Enambx08corpadob_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable in case there's confusion, RTMFP is free to use: https://datatracker.ietf.org/ipr/1942/ (section VI) (disclaimer: i'm not a lawyer! but that's our intention) i agree that 0 additional RTTs when safe is highly valuable. i'm apparently= more conservative in what "safe" means than several posters on this thread= . :) -michael thornburgh From: Roberto Peon [mailto:grmocg@gmail.com] Sent: Tuesday, August 27, 2013 3:23 PM To: Mike Belshe Cc: Michael Thornburgh; Yoav Nir; HTTP Working Group; tsvwg@ietf.org Subject: Re: [tsvwg] The List (of application-layer desired features) 0-additional-RTTs whenever safe means LOTS of money, actually. Latency and latency variance are highly correlated with bounce rates, etc. I should have probably added "free to use" to the list of requirements, but= other than that, if it gets results, it is something which should be exami= ned and iterated upon. I am personally quite agnostic to the name, format, company, etc. of who de= velops and deploys the next better thing. The important part is that we kee= p moving forward. "Keep moving forward" implies that we're willing to continue to try the nex= t better thing, which we can do only be lowering the barrier to entry (in s= afe ways). -=3DR On Tue, Aug 27, 2013 at 3:12 PM, Mike Belshe > wrote: On Tue, Aug 27, 2013 at 2:46 PM, Michael Thornburgh > wrote: if you're bringing up something like QUIC, i'll point out that RTMFP addres= ses almost every point on The List, and is currently widely deployed in the= Internet (in Flash Player) with 5+ years of deployment experience. RTMFP = is a general-purpose transport protocol that runs on top of UDP and provide= s prioritization, parallel message channels ("flows"), partial reliability,= shared congestion control, a generalized security framework, independent f= low control for every flow/channel, no flow-flow HOL blocking, IP address m= obility, and more. RTMFP sessions start in 2 RTT, and arbitrary numbers of= unidirectional flows in that session can be started in 0 RTT. flows are n= amed with arbitrary/opaque-to-RTMFP metadata instead of port or stream numb= ers. "return flow association" generalizes bidirectional communication to = arbitrarily complex trees of flows, which can more naturally model structur= ed data transport (such as request/multiple-response). RTMFP is described here: http://tools.ietf.org/html/draft-thornburgh-adobe-rtmfp and is currently in the RFC Editor's queue for publication as an Informatio= nal RFC. Sounds cool. Why don't you benchmark it in a browser? If it does all this= stuff, it should be faster today. note that while SCTP might not technically have HOL blocking stream-stream,= the structure of its acknowledgements and the Transmission Sequence Number= semantics can cause a priority inversion during periods of congestion. SC= TP does not have independent flow control for each stream. some thoughts on "fast channel startup with no state at the server": 1) you will typically want some kind of handshake with the server to esta= blish that the client is actually at the address it appears to be coming fr= om, to avoid TCP's "SYN flood" problem. that means at least one RTT when y= ou have no current state at the server for a client. When at Google, we devised several systems to counteract this. The winning= candidate (never implemented) was a hybrid solution: you let the first on= e in for free (no RTT), and require RTTs for the secondary parallel request= s until confidence is established. This gives you most of the perf benefit= . 2) when designing RTMFP, we rejected a "connection reset" message that co= uld be sent by a server to a client that thought it had a connection when n= o connection existed in the server (for example, if the server rebooted or = timed out the connection but the client didn't know), as that would be an a= busable denial-of-service vector. Not if it ran atop a secured, encrypted channel :-) 3) if you're willing to maintain some state at a server, you can leave an= RTMFP session open for a long time, and use the "address mobility" capabil= ity to handle the case when a client changes addresses (for example, on get= ting a new translation in a NAT after a quiet period). the method describe= d in Section 3.5.4.2 of the RTMFP spec currently has a 1 RTT cost to verify= the address change. that method could be modified to allow a provisional = change of address immediately, with a switch back to the old address if the= verification fails. Maybe, but generally, I think that doesn't scales enough or as well as it c= ould.... I was thinking client state, but happy to be proven wrong. 4) if you've been idle for long enough to time out a session (minutes?), = then establishing a new session (even at a cost of a couple RTTs) shouldn't= perceptually be a big deal. I disagree :-) RTTs are still 100+ms. Thats money. Mike -michael thornburgh From: tsvwg-bounces@ietf.org [mailto:tsvwg-b= ounces@ietf.org] On Behalf Of Mike Belshe Sent: Tuesday, August 06, 2013 2:31 AM To: Yoav Nir Cc: HTTP Working Group; tsvwg@ietf.org Subject: Re: [tsvwg] The List (of application-layer desired features) On Tue, Aug 6, 2013 at 10:49 AM, Yoav Nir > wrote: I think most of that is addressed in SCTP. Except the deployment part. Sta= ndards people can't force vendors of operating systems or Linux distributio= ns to include any feature. So we have a lot of "version 2"s in the IETF tha= t take a very long time to get deployed. It's also much more attractive to define a new thing (like SCTP) than to ma= ke something old work a little better. SCTP was sexier than TCPM. So it took ages to get deployment of IPv6, IKEv2, TLS 1.2, and all three ar= e still used far less than IPv4, IKEv1 and TLS 1.0. SCTP is used almost nev= er. HTTP/2 will likely fare better because the vendors are more involved an= d committed, but it's hard to make predictions, especially about the future= . You're right, SCTP is non-deployable, which makes it a non-starter. SCTP a= lso does not address handshake issues or TLS issues. I don't mean to sound inflammatory - but for all intents and purposes, the = next generation transport will need to be in user space and run on top of U= DP. There simply is no other deployable option on the table. QUIC is alre= ady reasonably far at exploring these issues: http://en.wikipedia.org/wiki/= QUIC Mike Yoav From: Roberto Peon [mailto:grmocg@gmail.com] Sent: Tuesday, August 06, 2013 11:16 AM To: HTTP Working Group; tsvwg@ietf.org Subject: Re: The List (of application-layer desired features) Actually sending to the right list for TSVWG... -=3DR On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon > wrote: For those of you who missed it, at the HTTPBis/TSVG joint session, a questi= on about what applications want from the transport (I really want to put qu= otes around that) came up. Here is a rendition of what was on the note that I jotted down in response = to this question, and which I passed to people at the mic. (Apps-folks want the following) Deployed in 1996: ----------------------------------------- - Prioritization - Partial Reliability - "Shared" congestion between multiple streams - Security - No HOL blocking on stream X when loss on stream Y - Cheap/Fast channel/connection setup - Wide, "safe" deployment - Competes with TCP/HTTP/1.1 (performance-wise) - Multipath/roaming robustness, i.e. the "driveway" problem I'll reiterate that by far the most important feature is "is deployed". Nothing else matters until that is true, at least at the application-layer. -=3DR Email secured by Check Point --_000_D9D602D39A98E34D9C43E965BEC743982698893Enambx08corpadob_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

in case t= here’s confusion, RTMFP is free to use:

 

  https://datatrac= ker.ietf.org/ipr/1942/ (section VI)

 

(dis= claimer: i’m not a lawyer! but that’s our intention)=

 

i agree that 0 additional RTTs when safe is highly valu= able. i’m apparently more conservative in what “safe” mea= ns than several posters on this thread.  :)

 

-michael thornburgh

 

 

From: Roberto Peon [mailto:g= rmocg@gmail.com]
Sent: Tuesday, August 27, 2013 3:23 PM
To= : Mike Belshe
Cc: Michael Thornburgh; Yoav Nir; HTTP Working = Group; tsvwg@ietf.org
Subject: Re: [tsvwg] The List (of applicati= on-layer desired features)

 

0-additional-RTTs when= ever safe means LOTS of money, actually.

Latency and latency variance are highly correlated with bounce rates,= etc.

 

I should have probably added "free to us= e" to the list of requirements, but other than that, if it gets result= s, it is something which should be examined and iterated upon.

I am personally quite agnostic to th= e name, format, company, etc. of who develops and deploys the next better t= hing. The important part is that we keep moving forward.

 

"Keep moving forward" implies that we're willing to = continue to try the next better thing, which we can do only be lowering the= barrier to entry (in safe ways).

 

-=3DR<= /p>

 

On Tue, Aug 27, 2013 at 3:12 PM= , Mike Belshe <mike= @belshe.com> wrote:

&nb= sp;

=  

On Tue, Aug 27, 2013 at 2:46= PM, Michael Thornburgh <mthornbu@adobe.com> wrote:

if youR= 17;re bringing up something like QUIC, i’ll point out that RTMFP addr= esses almost every point on The List, and is currently widely deployed in t= he Internet (in Flash Player) with 5+ years of deployment experience. = RTMFP is a general-purpose transport protocol that runs on top of UDP and = provides prioritization, parallel message channels (“flows”), p= artial reliability, shared congestion control, a generalized security frame= work, independent flow control for every flow/channel, no flow-flow HOL blo= cking, IP address mobility, and more.  RTMFP sessions start in 2 RTT, = and arbitrary numbers of unidirectional flows in that session can be starte= d in 0 RTT.  flows are named with arbitrary/opaque-to-RTMFP metadata i= nstead of port or stream numbers.  “return flow association̶= 1; generalizes bidirectional communication to arbitrarily complex trees of = flows, which can more naturally model structured data transport (such as re= quest/multiple-response).

 =

RTMFP is described here:

 

  http://tools.ietf.= org/html/draft-thornburgh-adobe-rtmfp

&n= bsp;

and is currently in the RFC Editor̵= 7;s queue for publication as an Informational RFC.

 

=

Sounds cool.  Why don't you benchmark it in a b= rowser?  If it does all this stuff, it should be faster today.<= o:p>

 

 

 

note that while SCTP might not technically have HOL block= ing stream-stream, the structure of its acknowledgements and the Transmissi= on Sequence Number semantics can cause a priority inversion during periods = of congestion.  SCTP does not have independent flow control for each s= tream.

 

some thoughts on “fast channel startup with no state at the server&#= 8221;:

 

  1) you will typically want some kind of handshake with the server t= o establish that the client is actually at the address it appears to be com= ing from, to avoid TCP’s “SYN flood” problem.  that = means at least one RTT when you have no current state at the server for a c= lient.

 

When at Google, we d= evised several systems to counteract this.  The winning candidate (nev= er implemented) was a hybrid solution:  you let the first one in for f= ree (no RTT), and require RTTs for the secondary parallel requests until co= nfidence is established.  This gives you most of the perf benefit.

 

 

 =

  2) when designing RTMFP, we rejected a “co= nnection reset” message that could be sent by a server to a client th= at thought it had a connection when no connection existed in the server (fo= r example, if the server rebooted or timed out the connection but the clien= t didn’t know), as that would be an abusable denial-of-service vector= .

<= o:p> 

Not if it ran atop a secured, e= ncrypted channel :-)

&n= bsp;

 

 

&nbs= p;

=

 

  3) if you&= #8217;re willing to maintain some state at a server, you can leave an RTMFP= session open for a long time, and use the “address mobility” c= apability to handle the case when a client changes addresses (for example, = on getting a new translation in a NAT after a quiet period).  the meth= od described in Section 3.5.4.2 of the RTMFP spec currently has a 1 RTT cos= t to verify the address change.  that method could be modified to allo= w a provisional change of address immediately, with a switch back to the ol= d address if the verification fails.

 

Maybe, but generally, I think that doesn't scales enough or as wel= l as it could....  I was thinking client state, but happy to be proven= wrong.

 

=

 

  4) if you’= ;ve been idle for long enough to time out a session (minutes?), then establ= ishing a new session (even at a cost of a couple RTTs) shouldn’t perc= eptually be a big deal.

=

 

I di= sagree :-) RTTs are still 100+ms.  Thats money.

<= /div>

 

=

Mike

 

=  

 

=

 

 <= /p>

-michael thornburgh

 

 

F= rom: tsvwg-b= ounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of Mike BelsheSent: Tuesday, August 06, 2013 2:31 AM
To: Yoav Nir
Cc: HTTP Working Group; tsvwg@ietf.org
Subject: Re: [tsvwg] The List (of applic= ation-layer desired features)

 

 

 

On Tue, Aug 6, 2013 at 10:49 AM= , Yoav Nir <yni= r@checkpoint.com> wrote:

I think m= ost of that is addressed in SCTP.  Except the deployment part. Standar= ds people can’t force vendors of operating systems or Linux distribut= ions to include any feature. So we have a lot of “version 2”s i= n the IETF that take a very long time to get deployed.

 

It’s also much more= attractive to define a new thing (like SCTP) than to make something old wo= rk a little better. SCTP was sexier than TCPM.

 

So it took ages to get deployment = of IPv6, IKEv2, TLS 1.2, and all three are still used far less than IPv4, I= KEv1 and TLS 1.0. SCTP is used almost never. HTTP/2 will likely fare better= because the vendors are more involved and committed, but it’s hard t= o make predictions, especially about the future.

 

You're right, SCTP is non= -deployable, which makes it a non-starter.  SCTP also does not address= handshake issues or TLS issues.

 

I don't mean to sound inflammatory - but for all inten= ts and purposes, the next generation transport will need to be in user spac= e and run on top of UDP.  There simply is no other deployable option o= n the table.  QUIC is already reasonably far at exploring these issues= : http= ://en.wikipedia.org/wiki/QUIC

 

Mike

 

 

 

 

 

 

Yoav=

 

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Roberto = Peon [mailto:grmocg@g= mail.com]
Sent: Tuesday, August 06, 2013 11:16 AM


To: HTTP Working Group; tsvwg@ietf.org
Subject: Re: Th= e List (of application-layer desired features)

 = ;

Actually sending to the right list for TSVWG...

 

-=3DR

<= /div>

 

On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon <grmocg@gmail.com> wrote:

For those of you who missed it, at the HTTPBis/TS= VG joint session, a question about what applications want from the transpor= t (I really want to put quotes around that) came up.

 

Here is a rendition of what was on= the note that I jotted down in response to this question, and which I pass= ed to people at the mic.

 

<= /div>

(Apps-folks want the following) Deployed in 1996:

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

- Prioritization

- Partial Reli= ability

- "Shared" congestion between= multiple streams

- Security

- No HOL blocking on stream X when loss on stream Y

- Cheap/Fast  channel/connection setup

- Wide, "safe" deployment

- Competes with TCP/HTTP/1.1 (performance-wise)

<= p>- Multipath/roaming robustness, i.e. the "driveway" problem

 

 

I'll reiterate that by far the most important fea= ture is "is deployed".

Nothing else m= atters until that is true, at least at the application-layer.

-=3DR

 

=

 

 



Email secured by Check Point

<= /blockquote>

 

 

 

= --_000_D9D602D39A98E34D9C43E965BEC743982698893Enambx08corpadob_-- From mthornbu@adobe.com Wed Aug 28 10:42:33 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD2C11E8278 for ; Wed, 28 Aug 2013 10:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.757 X-Spam-Level: X-Spam-Status: No, score=-5.757 tagged_above=-999 required=5 tests=[AWL=-1.613, BAYES_00=-2.599, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjw9jhHDCBZ4 for ; Wed, 28 Aug 2013 10:42:16 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFCE11E81B9 for ; Wed, 28 Aug 2013 10:42:16 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUh42Wv0x/G+9DF+ab4rExZ73DosR2wC3@postini.com; Wed, 28 Aug 2013 10:42:16 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r7SHcEiH007075; Wed, 28 Aug 2013 10:38:14 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r7SHfkw7016797; Wed, 28 Aug 2013 10:41:46 -0700 (PDT) Received: from nambx08.corp.adobe.com ([10.8.189.94]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Wed, 28 Aug 2013 10:41:46 -0700 From: Michael Thornburgh To: Mike Belshe Date: Wed, 28 Aug 2013 10:41:44 -0700 Thread-Topic: [tsvwg] The List (of application-layer desired features) Thread-Index: Ac6jcpiGUWUPTsyzRbmgx12zgGUK+AAoSFMA Message-ID: References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Yoav Nir , HTTP Working Group , "tsvwg@ietf.org" Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 17:42:33 -0000 replies inline. > -----Original Message----- > From: Mike Belshe [mailto:mike@belshe.com] > Sent: Tuesday, August 27, 2013 3:12 PM >=20 >=20 > On Tue, Aug 27, 2013 at 2:46 PM, Michael Thornburgh = wrote: >=20 >=20 > if you're bringing up something like QUIC, i'll point out that RTMFP add= resses almost every > point on The List, and is currently widely deployed in the Internet (in F= lash Player) with 5+ years of > deployment experience. RTMFP is a general-purpose transport protocol tha= t runs on top of UDP and > provides prioritization, parallel message channels ("flows"), partial rel= iability, shared congestion > control, a generalized security framework, independent flow control for e= very flow/channel, no flow- > flow HOL blocking, IP address mobility, and more. RTMFP sessions start i= n 2 RTT, and arbitrary > numbers of unidirectional flows in that session can be started in 0 RTT. = flows are named with > arbitrary/opaque-to-RTMFP metadata instead of port or stream numbers. "r= eturn flow association" > generalizes bidirectional communication to arbitrarily complex trees of f= lows, which can more > naturally model structured data transport (such as request/multiple-respo= nse). >=20 >=20 >=20 > RTMFP is described here: >=20 >=20 >=20 > http://tools.ietf.org/html/draft-thornburgh-adobe-rtmfp >=20 >=20 >=20 > and is currently in the RFC Editor's queue for publication as an Informa= tional RFC. >=20 >=20 > Sounds cool. Why don't you benchmark it in a browser? If it does all th= is stuff, it should be faster > today. i'll add that to the list. =20 > note that while SCTP might not technically have HOL blocking stream-stre= am, the structure of its > acknowledgements and the Transmission Sequence Number semantics can cause= a priority inversion during > periods of congestion. SCTP does not have independent flow control for e= ach stream. >=20 >=20 >=20 > some thoughts on "fast channel startup with no state at the server": >=20 >=20 >=20 > 1) you will typically want some kind of handshake with the server to e= stablish that the client > is actually at the address it appears to be coming from, to avoid TCP's "= SYN flood" problem. that > means at least one RTT when you have no current state at the server for a= client. >=20 >=20 > When at Google, we devised several systems to counteract this. The winni= ng candidate (never > implemented) was a hybrid solution: you let the first one in for free (n= o RTT), and require RTTs for > the secondary parallel requests until confidence is established. This gi= ves you most of the perf > benefit. i don't understand how that approach addresses the "a bad person initiates = 100M one-packet connection attempts from different [forged/pwned] addresses= and doesn't follow through" SYN flood problem, where every packet coming i= n would be "the first one", thereby creating connection state in the server= . > 2) when designing RTMFP, we rejected a "connection reset" message that= could be sent by a > server to a client that thought it had a connection when no connection ex= isted in the server (for > example, if the server rebooted or timed out the connection but the clien= t didn't know), as that would > be an abusable denial-of-service vector. >=20 >=20 > Not if it ran atop a secured, encrypted channel :-) the issue here is there is no secured, encrypted channel over which to send= a connection reset message, from a server with no connection state to a cl= ient with a connection state. if you were going to go to the PK/CPU troubl= e to compute new session keys at the server just to send a reset, you might= as well not reset and just continue with the session. RTMFP does have an = in-session "abrupt close" mechanism, and flows in a session can be rejected= at any time by the receiver. > 3) if you're willing to maintain some state at a server, you can leave= an RTMFP session open > for a long time, and use the "address mobility" capability to handle the = case when a client changes > addresses (for example, on getting a new translation in a NAT after a qui= et period). the method > described in Section 3.5.4.2 of the RTMFP spec currently has a 1 RTT cost= to verify the address > change. that method could be modified to allow a provisional change of a= ddress immediately, with a > switch back to the old address if the verification fails. >=20 >=20 > Maybe, but generally, I think that doesn't scales enough or as well as it= could.... I was thinking > client state, but happy to be proven wrong. >=20 >=20 > 4) if you've been idle for long enough to time out a session (minutes?= ), then establishing a > new session (even at a cost of a couple RTTs) shouldn't perceptually be a= big deal. >=20 >=20 > I disagree :-) RTTs are still 100+ms. Thats money. there's no reason a timeout couldn't be tuned (per site? and communicated t= o the client to behave accordingly) to balance resource use at the servers = for idle connections with expected users' idle periods between accesses to = the site. >=20 > Mike -michael thornburgh >=20 > -michael thornburgh >=20 >=20 > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf O= f Mike Belshe > Sent: Tuesday, August 06, 2013 2:31 AM > To: Yoav Nir > Cc: HTTP Working Group; tsvwg@ietf.org > Subject: Re: [tsvwg] The List (of application-layer desired features) >=20 >=20 >=20 > On Tue, Aug 6, 2013 at 10:49 AM, Yoav Nir wrote: >=20 > I think most of that is addressed in SCTP. Except the deployment part. = Standards people can't > force vendors of operating systems or Linux distributions to include any = feature. So we have a lot of > "version 2"s in the IETF that take a very long time to get deployed. >=20 >=20 >=20 > It's also much more attractive to define a new thing (like SCTP) than to= make something old work > a little better. SCTP was sexier than TCPM. >=20 >=20 >=20 > So it took ages to get deployment of IPv6, IKEv2, TLS 1.2, and all three= are still used far less > than IPv4, IKEv1 and TLS 1.0. SCTP is used almost never. HTTP/2 will like= ly fare better because the > vendors are more involved and committed, but it's hard to make prediction= s, especially about the > future. >=20 >=20 >=20 > You're right, SCTP is non-deployable, which makes it a non-starter. SCT= P also does not address > handshake issues or TLS issues. >=20 >=20 >=20 > I don't mean to sound inflammatory - but for all intents and purposes, t= he next generation > transport will need to be in user space and run on top of UDP. There sim= ply is no other deployable > option on the table. QUIC is already reasonably far at exploring these i= ssues: > http://en.wikipedia.org/wiki/QUIC >=20 >=20 >=20 > Mike >=20 >=20 >=20 > Yoav >=20 >=20 >=20 > From: Roberto Peon [mailto:grmocg@gmail.com] > Sent: Tuesday, August 06, 2013 11:16 AM >=20 >=20 > To: HTTP Working Group; tsvwg@ietf.org > Subject: Re: The List (of application-layer desired features) >=20 >=20 >=20 > Actually sending to the right list for TSVWG... >=20 >=20 >=20 > -=3DR >=20 >=20 >=20 > On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon wrote: >=20 > For those of you who missed it, at the HTTPBis/TSVG joint session, a qu= estion about what > applications want from the transport (I really want to put quotes around = that) came up. >=20 >=20 >=20 > Here is a rendition of what was on the note that I jotted down in respo= nse to this > question, and which I passed to people at the mic. >=20 >=20 >=20 > (Apps-folks want the following) Deployed in 1996: >=20 > ----------------------------------------- >=20 > - Prioritization >=20 > - Partial Reliability >=20 > - "Shared" congestion between multiple streams >=20 > - Security >=20 > - No HOL blocking on stream X when loss on stream Y >=20 > - Cheap/Fast channel/connection setup >=20 > - Wide, "safe" deployment >=20 > - Competes with TCP/HTTP/1.1 (performance-wise) >=20 > - Multipath/roaming robustness, i.e. the "driveway" problem >=20 >=20 >=20 >=20 >=20 > I'll reiterate that by far the most important feature is "is deployed". >=20 > Nothing else matters until that is true, at least at the application-la= yer. >=20 > -=3DR >=20 >=20 > Email secured by Check Point >=20 From ted.ietf@gmail.com Tue Aug 27 15:08:46 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2EE11E83A9 for ; Tue, 27 Aug 2013 15:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMbHXx7PFMoy for ; Tue, 27 Aug 2013 15:08:46 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 221D211E8236 for ; Tue, 27 Aug 2013 15:08:46 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so6691448oag.29 for ; Tue, 27 Aug 2013 15:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yGyz2NFk40wi/+WYG2BxYPTCtJRaur55AZLAn3BRYJg=; b=Oo8UslGDGXpbzJo64Q6SeukeQFC0iGvQ1LUe11ma7ke5waROU15M/CebANyADgORZg qwR/TRcS9jXl2enbsJdX9xEykp6oYasTtSbh4EzAealxjPvBKNF/Nx7aNT9/IFUDRsza VgMpv/M+jERvL/wTTs5R2dCIypN7x6XfktpaQ0UKzIqRmc0pYjmS8N3Muq2K+ycaDYPB 2nA/93RfgyOmhzr7ZWm3dR5AmVjJuUjp4XFbT1BhWaLhA0QhDHtBcUGS4vsI4J7+phi9 y3OMXAFxaFCuqQSiD2gkIj52oTD91gPE0DRjh9zDP0jTizsJsX1hnsw/eTMEzt9eDYlm 4ddw== MIME-Version: 1.0 X-Received: by 10.50.4.68 with SMTP id i4mr10841210igi.29.1377641325694; Tue, 27 Aug 2013 15:08:45 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Tue, 27 Aug 2013 15:08:45 -0700 (PDT) In-Reply-To: References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> Date: Tue, 27 Aug 2013 15:08:45 -0700 Message-ID: From: Ted Hardie To: Michael Thornburgh Content-Type: multipart/alternative; boundary=001a11c30f78d894b204e4f51dba X-Mailman-Approved-At: Wed, 28 Aug 2013 11:49:11 -0700 Cc: "tsvwg@ietf.org" , Yoav Nir , Mike Belshe , HTTP Working Group Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 22:08:46 -0000 --001a11c30f78d894b204e4f51dba Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Aug 27, 2013 at 2:46 PM, Michael Thornburgh wro= te: > RTMFP is described here:**** > > ** ** > > http://tools.ietf.org/html/draft-thornburgh-adobe-rtmfp**** > > ** ** > > and is currently in the RFC Editor=92s queue for publication as an > Informational RFC.**** > > ** > Those reviewing that document may also wish to review: https://datatracker.ietf.org/ipr/1942/ regards, Ted Hardie --001a11c30f78d894b204e4f51dba Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Tue, Aug 27, 2013 at 2:4= 6 PM, Michael Thornburgh <mthornbu@adobe.com> wrote:

RTMFP is described here:

=A0

=A0 http://tools.i= etf.org/html/draft-thornburgh-adobe-rtmfp

=A0

<= p class=3D"">and is currently in the RFC Ed= itor=92s queue for publication as an Informational RFC.

=A0


Those reviewing that document may also= wish to review:

https://datatracker.= ietf.org/ipr/1942/


re= gards,

Ted Hardie
--001a11c30f78d894b204e4f51dba-- From gorry@erg.abdn.ac.uk Wed Aug 28 01:11:48 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6931111E820B; Wed, 28 Aug 2013 01:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.918 X-Spam-Level: X-Spam-Status: No, score=-105.918 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnNRnEzn2l5g; Wed, 28 Aug 2013 01:11:29 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFD511E815E; Wed, 28 Aug 2013 01:11:27 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 6A3E42B44D7; Wed, 28 Aug 2013 09:11:26 +0100 (BST) Received: from ra-gorry.erg.abdn.ac.uk (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id E56252B4356; Wed, 28 Aug 2013 09:11:15 +0100 (BST) Message-ID: <521DB09D.1080107@erg.abdn.ac.uk> Date: Wed, 28 Aug 2013 09:11:09 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: tsvwg-chairs@ietf.org, iesg-secretary@ietf.org, mls.ietf@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 28 Aug 2013 11:49:11 -0700 Subject: [tsvwg] Document writeup for draft-ietf-tsvwg-byte-pkt-congest-11 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 08:11:48 -0000 TSVWG: Byte and Packet Congestion Notification This email completes the WG process requesting resubmission of the above document to the IESD with a request to publish this document. See below. Gorry (tsvwg WG Co-Chair ------------- As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document is intended as BCP. (This was discussed at IETF-81 and that the status changed from Informational to BCP, because the draft provides guidance to implementors and people configuring routers and hosts). The BCP status was confirmed on the tsvwg list prior to resubmission to the IESG, only one comment was noted requesting informational status. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, including random early detection (RED), BLUE, pre- congestion notification (PCN) and newer schemes such as CoDel and PIE. We give three strong recommendations: (1) packet size should be taken into account when transports detect and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) in the specific case of RED, the byte-mode packet drop variant that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms. Working Group Summary There was consensus to publish this as a WG document and agreement at IETF-82 that the document was now complete. Since then there have been a number of revisions to address WG feedback. Document Quality Annexe A summarises a survey by the original authors showing deployment of the techniques by router vendors. The recommendations are thought to be in line with that of IETF groups, such as TSVWG, TCPM, PCN, and are considered good advice for use in the general Internet. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? I am the document shepherd, G Fairhurst. The responsible AD is Martin Stiemerling (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document was presented at IEWTF-82 (Taipei), with a request for WGLC. The first WGLC concluded with some discussion and suggested changes on Friday 30th March 2012. The changes were discussed on the list, and have been implemented in a revised draft. Major edits were applied to correct comments after the document left the WG. Comments were received from 8 people after this document were returned to the WG. The changes were confirmed in a WG draft, draft-ietf-tsvwg-byte-pkt-congest-11, with a WGLC ending on 19th August 2013. This WGLC concluded with no additional comments. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. This has already completed one IESG review. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been submitted directly on draft-ietf-tsvwg-byte-pkt-congest. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has WG support and there is consensus to publish. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. One update is listed, RFC 2309, informational - replaced by this BCP. It deprecates deliberate preferential treatment of small packets in AQM algorithms. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Not applicable. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. From willchan@google.com Wed Aug 28 02:53:56 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CED21E805A for ; Wed, 28 Aug 2013 02:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf-GC2CSEF+o for ; Wed, 28 Aug 2013 02:53:55 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7442721E804E for ; Wed, 28 Aug 2013 02:53:55 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so8601031ied.0 for ; Wed, 28 Aug 2013 02:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=AEMbHpptqq7uDe4eyZL/vCIsk7vrqggemHepPP+i7fM=; b=FAo0FbIXbJ3jP/bAIrfykmK+T0fdexbIaQf2Sr+QuFssHwZqgCwFD8jo6alUwinc+A ZL/nXzwoVVq4tzoGWF32QSQOfnY4OXv6C908kEADZUwmIiw/vpmOtAWb4yfJ66MzXvhK 4UlnLichhM2rXaxng8jPtVSEgrKukKhSkgFV2ITAMJD6o1RdXkNZCFOGbBwYT5O3gkyB OcoC8cS+kTlVdJT8xzOQ+e54RJ87Fu0viQiCNIqz0YQFtai3MUy7GnikMf/Jnz6hYKbs N69FIaUb9XxrD+Vz/76LAChgkuUJAPEsiPDEJfQNWGZaON5EHZ5DsuFotlQzk8i48XA6 t+cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=AEMbHpptqq7uDe4eyZL/vCIsk7vrqggemHepPP+i7fM=; b=e9Aa8JpKnUZlHu7xcFPM9mB53IYbprUji5IXg5jZjDQleSiYkylgi+i4jV0cc+74D+ L1PTYWWZ3uNgiCKeGunZppjAbe3Ac2oVLYGbJW6Ilr1mfQAAq90QQGTBd7eES2Pb1oNh F/EW7qPxqGfo9Skih2NOGQZZ6OdymlxDSh280i5AyiDbJodRv27rOYnK49nA6r9XacBX uDB7mRT4Eh2dL79hlN7HTsmjyTVamCDA2eCGR6DXTZgAOKY7n9gtyqbxHv22GhYzdISj m0EoZF9KcPkXbrPQesKPnJwJYbygoDIW3KJ5R0nrI5hKmakqyiP9+Tml+wEM1tKpRcf0 ExIw== X-Gm-Message-State: ALoCoQmWZC1baNyP8ZipjV6mLUZBbmuUYKR7HKFKBnNI7cq3og6/VmU7ig9cECIlqnGqWfydzGnp+SYUBbBOPnRT9dRBnN8NOkvMHiHZ8e4BWmawE0f2CluuSYR+TAKi2QLUtNFM3D7hRIMGiYlhXNn+6uXl5xlymvw6W9Bd7rWxjBgJRXXZPXS1QVG6bTIx//F0ws8+XidS MIME-Version: 1.0 X-Received: by 10.50.50.104 with SMTP id b8mr12101614igo.1.1377683634932; Wed, 28 Aug 2013 02:53:54 -0700 (PDT) Received: by 10.231.69.132 with HTTP; Wed, 28 Aug 2013 02:53:54 -0700 (PDT) Received: by 10.231.69.132 with HTTP; Wed, 28 Aug 2013 02:53:54 -0700 (PDT) In-Reply-To: <2ADDC87F-8E20-4D7D-B0A0-20CE3DD12B81@ifi.uio.no> References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> <081D0F76-F4AE-42D5-B354-795BE4910D23@lurchi.franken.de> <2ADDC87F-8E20-4D7D-B0A0-20CE3DD12B81@ifi.uio.no> Date: Wed, 28 Aug 2013 17:53:54 +0800 Message-ID: From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= To: Michael Welzl Content-Type: multipart/alternative; boundary=089e01183d16ac8b4b04e4fef70a X-Mailman-Approved-At: Wed, 28 Aug 2013 11:49:11 -0700 Cc: Michael Tuexen , "tsvwg@ietf.org" , Yoav Nir , Mike Belshe , HTTP Working Group Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: willchan@google.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 09:53:56 -0000 --089e01183d16ac8b4b04e4fef70a Content-Type: text/plain; charset=ISO-8859-1 On Aug 28, 2013 4:01 PM, "Michael Welzl" wrote: > > Hi, > > I agree 100% with Michael Tuexen here... just one thing, in line: > > >>> You're right, SCTP is non-deployable, which makes it a non-starter. SCTP also does not address handshake issues or TLS issues. >> >> I agree that SCTP over IP can't be deployed now due to missing NAT support. > > > Indeed that's not an argument against SCTP/UDP/IP, but I also wonder why, instead of saying "can't be deployed", people don't just go ahead and use it whenever it's there and works, with a fall-back to TCP? This could be done with (this version of) Happy Eyeballs: > http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02 > > Good reasons against doing this are... what? Anyone? Implementation usefulness. Why bother adding code that barely gets used (and that is unlikely to improve in the near future), adds complexity, code bloat, etc...? SCTP/UDP has a much higher likelihood of usefulness. But as Roberto has mentioned, it still has deficiencies, mostly around RTTs (connection + DTLS setup). If they can be fixed, great. Let's do it. --089e01183d16ac8b4b04e4fef70a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Aug 28, 2013 4:01 PM, "Michael Welzl" <michawe@ifi.uio.no> wrote:
>
> Hi,
>
> I agree 100% with Michael Tuexen here... just one thing, in line:
>
>
>>> You're right, SCTP is non-deployable, which makes it a non= -starter. =A0SCTP also does not address handshake issues or TLS issues.
>>
>> I agree that SCTP over IP can't be deployed now due to missing= NAT support.
>
>
> Indeed that's not an argument against SCTP/UDP/IP, but I also wond= er why, instead of saying "can't be deployed", people don'= ;t just go ahead and use it whenever it's there and works, with a fall-= back to TCP? This could be done with (this version of) Happy Eyeballs:
> http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02=
>
> Good reasons against doing this are... what? Anyone?

Implementation usefulness. Why bother adding code that barel= y gets used (and that is unlikely to improve in the near future), adds comp= lexity, code bloat, etc...?

SCTP/UDP has a much higher likelihood of usefulness. But as = Roberto has mentioned, it still has deficiencies, mostly around RTTs (conne= ction + DTLS setup). If they can be fixed, great. Let's do it.

--089e01183d16ac8b4b04e4fef70a-- From willchan@google.com Wed Aug 28 06:34:55 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D184921F9F00 for ; Wed, 28 Aug 2013 06:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1tH4xqU-GSp for ; Wed, 28 Aug 2013 06:34:55 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id CB00221F9EEE for ; Wed, 28 Aug 2013 06:34:54 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id a14so8896990iee.12 for ; Wed, 28 Aug 2013 06:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zhqc2qFLOXIfNPOVoh8SZIwjC/gnVz+mdySowqvHASo=; b=l6UWNkwmX6QT39qQal4PCMhbgAs0tercAR9+iLn0b9+K2464AHCHla36ffYM0/qREc JYL0tg9rTmV/IouBbPm1Leqw7rmfNbNIouZetyFmtVK2qXN3GSLJVstXHv+s5gF9F5HE 4e0F2mjO0h5j/Odg0+EF/C3spwSq+MsljMA9cpr/BYu5pQmIyCGlqETPTu1E/LWPd9/O p2xTCrygMDyTy3+Vx8KUOgA6zUjmHpUVZaM48L4QRigpE1HETVuC6Hv0koFGnKbC1KJS Mdlff2quAXlrx9Hc2VpBoiZQyUCnwSnUT580PYFarteKU2EdWSVAVHcZPJCrRKDCIFAD 7kRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zhqc2qFLOXIfNPOVoh8SZIwjC/gnVz+mdySowqvHASo=; b=Jyb/0LtjaYhVrr47F3cwfuZTFjvDN80Cb3w3oTDOtnUq+KmLTbLFmpG8rjNIWQNYcO ysJ8vo8aiEI8OxS/QKH/ryH2UrE2fgsNKQ3TsrnjUL8S1/5ItX9A5cNgYf8X1HBSI6J0 sGDKWSIiUKhM1zvGXlU+mi8ISXwgwIqXP4aRXi3Rxe3JW1h7GJ3vPJ0ICBNK7ZKUPMk2 LfJYccgYQkLmUFKCbG/MLhxvPKhiGlrhSzREvz25EBgsNpzvFVM2/0LG4RX28qPMGQYi VZnkXryyzW9Sd3H0Wcnqv92YiHMxBej3LtYfWIKcy36v06aBgTmsBoksgULLtEXAl4Zs X1IQ== X-Gm-Message-State: ALoCoQlNhyOSnnwOjI8oTDtdE0+X+40oDVWS/nA3xSpSKOooTfICoIUDBnaIhSXjVwu/J0Zl4wWl1EJZ6Tc07B31na76BFRQaepamb74AROcm8Bt0e4qsoVkhJq4XJQlxYjjd0ucZGZXhhShbImxtoL6dzVcJ2VxY7EwCRySDBI5xFPo4qO0NKDyDHNcqOeMHVkqefgZWbnS MIME-Version: 1.0 X-Received: by 10.43.172.138 with SMTP id ny10mr12201525icc.11.1377696893232; Wed, 28 Aug 2013 06:34:53 -0700 (PDT) Received: by 10.231.69.132 with HTTP; Wed, 28 Aug 2013 06:34:53 -0700 (PDT) In-Reply-To: <07FF0072-DA3F-4E4A-9418-F2C4CF918817@ifi.uio.no> References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> <081D0F76-F4AE-42D5-B354-795BE4910D23@lurchi.franken.de> <2ADDC87F-8E20-4D7D-B0A0-20CE3DD12B81@ifi.uio.no> <07FF0072-DA3F-4E4A-9418-F2C4CF918817@ifi.uio.no> Date: Wed, 28 Aug 2013 21:34:53 +0800 Message-ID: From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= To: Michael Welzl Content-Type: multipart/alternative; boundary=001a11c3b1fcee2f9204e5020deb X-Mailman-Approved-At: Wed, 28 Aug 2013 11:49:11 -0700 Cc: Michael Tuexen , "tsvwg@ietf.org" , Yoav Nir , Mike Belshe , HTTP Working Group Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: willchan@google.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 13:34:56 -0000 --001a11c3b1fcee2f9204e5020deb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 28, 2013 at 7:53 PM, Michael Welzl wrote: > > On 28. aug. 2013, at 11:53, William Chan (=E9=99=88=E6=99=BA=E6=98=8C) wr= ote: > > On Aug 28, 2013 4:01 PM, "Michael Welzl" wrote: > > > > Hi, > > > > I agree 100% with Michael Tuexen here... just one thing, in line: > > > > > >>> You're right, SCTP is non-deployable, which makes it a non-starter. > SCTP also does not address handshake issues or TLS issues. > >> > >> I agree that SCTP over IP can't be deployed now due to missing NAT > support. > > > > > > Indeed that's not an argument against SCTP/UDP/IP, but I also wonder > why, instead of saying "can't be deployed", people don't just go ahead an= d > use it whenever it's there and works, with a fall-back to TCP? This could > be done with (this version of) Happy Eyeballs: > > http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02 > > > > Good reasons against doing this are... what? Anyone? > > Implementation usefulness. Why bother adding code that barely gets used > (and that is unlikely to improve in the near future), adds complexity, co= de > bloat, etc...? > > Fair point. That's why I think the OS should in fact do Happy Eyeballs fo= r > you! > > I'm not sure if you're trolling me. In case you aren't, you may want to look at the graph at: http://gs.statcounter.com/#os-ww-monthly-201207-20130= 7. Windows XP (released in 2001) is still around 20% of browser usage. If you have the ability to get Microsoft to backport SCTP/IP onto their XP stack, I'd love to know. We're not going to ignore large segments of our user base when we could use UDP and deploy for all relevant OSes. That may be acceptable for some applications, but not for the browser I work on. This is why Roberto said: """ Wide, "safe" deployment """ > SCTP/UDP has a much higher likelihood of usefulness. But as Roberto has > mentioned, it still has deficiencies, mostly around RTTs (connection + DT= LS > setup). If they can be fixed, great. Let's do it. > > Why shouldn't it be possible to fix SCTP to do whatever you want? Anyway > it sounds to me like a simpler approach than building a whole new protoco= l. > Of course, SCTP++ isn't the nicest acronym... then again, RTMFP isn't > either, if you ask me, sounds almost like RTFM... QUIC is great though! > I have no attachments to the protocol name or frame format or whatever. Look at what we're doing in HTTP/2 which was inspired by SPDY but now has undergone substantial changes. We're serious about this. As long as the transport provides all the features we need, we'll use it. This conversation got started because tsvwg asked httpbis what the application layer wants from the transport. We're telling you. I think the constructive next step is for tsvwg folks to ask for clarification on any requirement they don't understand, discuss whether or not the requirements are reasonable, and discuss what may need to be done to address them. > > Cheers, > Michael > > --001a11c3b1fcee2f9204e5020deb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 28, 2013 at 7:53 PM, Michael Welzl <michawe@ifi.uio.no> wrote:

On 28. aug. 2013, at 11:53, William Chan (=E9=99=88=E6=99=BA=E6=98=8C)= wrote:

On Aug 28, 2013 4= :01 PM, "Michael Welzl" <michawe@ifi.uio.no> wrote:
>
> Hi,
>
> I agree 100% with Michael Tuexen here... just one thing, in line:
>
>
>>> You're right, SCTP is non-deployable, which makes it a non= -starter. =C2=A0SCTP also does not address handshake issues or TLS issues.<= br> >>
>> I agree that SCTP over IP can't be deployed now due to missing= NAT support.
>
>
> Indeed that's not an argument against SCTP/UDP/IP, but I also wond= er why, instead of saying "can't be deployed", people don'= ;t just go ahead and use it whenever it's there and works, with a fall-= back to TCP? This could be done with (this version of) Happy Eyeballs:
> http://tools.ietf.org/html/draf= t-wing-tsvwg-happy-eyeballs-sctp-02
>
> Good reasons against doing this are... what? Anyone?

Implementation usefulness. Why bother adding code that barely gets used (a= nd that is unlikely to improve in the near future), adds complexity, code b= loat, etc...?

Fair point. That's why I think the OS should in= fact do Happy Eyeballs for you!


I'm not sure if you're trolling= me. In case you aren't, you may want to look at the graph at: http://gs.statc= ounter.com/#os-ww-monthly-201207-201307. Windows XP (released in 2001) = is still around 20% of browser usage. If you have the ability to get Micros= oft to backport SCTP/IP onto their XP stack, I'd love to know. We'r= e not going to ignore large segments of our user base when we could use UDP= and deploy for all relevant OSes. That may be acceptable for some applicat= ions, but not for the browser I work on.

This is why Roberto said:
"""<= /div>
Wide, "safe" deployment
"""= ;

SCTP/UDP has a much higher likelihood of usefulnes= s. But as Roberto has mentioned, it still has deficiencies, mostly around R= TTs (connection + DTLS setup). If they can be fixed, great. Let's do it= .

Why shouldn't it be possible to fix SCTP to do= whatever you want? Anyway it sounds to me like a simpler approach than bui= lding a whole new protocol. Of course, SCTP++ isn't the nicest acronym.= .. =C2=A0then again, RTMFP isn't either, if you ask me, sounds almost l= ike RTFM... =C2=A0QUIC is great though!

I have no attachments to the protocol name= or frame format or whatever. Look at what we're doing in HTTP/2 which = was inspired by SPDY but now has undergone substantial changes. We're s= erious about this. As long as the transport provides all the features we ne= ed, we'll use it. This conversation got started because tsvwg asked htt= pbis what the application layer wants from the transport. We're telling= you. I think the constructive next step is for tsvwg folks to ask for clar= ification on any requirement they don't understand, discuss whether or = not the requirements are reasonable, and discuss what may need to be done t= o address them.
=C2=A0
=
Cheers,
Michael


--001a11c3b1fcee2f9204e5020deb-- From willchan@google.com Wed Aug 28 06:44:41 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A983521F9C29 for ; Wed, 28 Aug 2013 06:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjGNqTeNjVc8 for ; Wed, 28 Aug 2013 06:44:40 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEC121F9C8E for ; Wed, 28 Aug 2013 06:44:40 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id m16so5915874ieq.10 for ; Wed, 28 Aug 2013 06:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zsDjEey01Cu0wbwl6oMbF0yZmgINCb9L1cGeABwXNZU=; b=JpC2lW5Ods4zBlBfAyRiNS6uhAA3uLzr4v8yDe2Z2i57WZvUzYT4TPJWPK055MY+RO qUsf3sOjPPriiIELyB2mUHa5IlTkVU6ZkQq+czjZPvJgrPMJvItkBgyWwTO3cZmnxyb0 lH+3qf5AAw2gRN8pGpz86eDZCjJRzBFC5jy0TwCHoDv6vQsifqCgkJ49v1yN4OnC4nWO S/KQLcbta4HgqlJq3x17mIKow86fpGjMngGn8moWpwX2jFEGa4IRNI8zO0v3IJR0UBA/ jGGPvlTQcaBWE35s2mRxzMJq0VncmoDTAh8L94IsfZzxP9RIhdw3bWoAq10nezu1XWLx 1Tfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zsDjEey01Cu0wbwl6oMbF0yZmgINCb9L1cGeABwXNZU=; b=LCamAhPuCbFPH/cHYmboCi4tz+wzZO6nFr/AXUHj8BNfuTQvcgNhBQt9iYeKACuq1E 9vnGyifU5AqM1z6IV2Tn5H6ZiU+osBnogKUTH8xcQGzMh8g2KqUH5A+2VUyMQHTSOVyZ Vv+DsQbDxqJa718qAzKOgOdrHKPI7rd+SjLOynbZsxLBp2G8MC28SGE3+wAOHQpyBOR5 S+PZVG22txH6M57SGbup6OyIWg9AXeIzPJHSZLDvyz153JLAYp4r497Kuaiqk5koo+fv looINSwOTUFrHOv8WPWlL0n+oviCHfcwK72SVUSoD7O4u8f5QWyDIPlbqDRHQSnHF0f3 6l5g== X-Gm-Message-State: ALoCoQlD2Rq3Wqvx7Kb/Tyx5z+Y+VdZt5XYIyb3OEFG6yYDkk0pT+IjsOSu4DFsa5+krsvLW8UOXooBSa3aiUWvJ6cv+HmGcDx9hazO2+0KPw6bjjcSeszNmqtEeG+x+Ol8jfd4xRn8rA+lln7TEu3MQpbTy9PuMErvc9pSkejq8Xh8FuiNETS+ao8QXiDNK4eB4K+x08yBW MIME-Version: 1.0 X-Received: by 10.50.117.40 with SMTP id kb8mr12280388igb.60.1377697478968; Wed, 28 Aug 2013 06:44:38 -0700 (PDT) Received: by 10.231.69.132 with HTTP; Wed, 28 Aug 2013 06:44:38 -0700 (PDT) In-Reply-To: <34074BE6-2402-4228-8601-3AF51808F879@lurchi.franken.de> References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> <081D0F76-F4AE-42D5-B354-795BE4910D23@lurchi.franken.de> <2ADDC87F-8E20-4D7D-B0A0-20CE3DD12B81@ifi.uio.no> <07FF0072-DA3F-4E4A-9418-F2C4CF918817@ifi.uio.no> <34074BE6-2402-4228-8601-3AF51808F879@lurchi.franken.de> Date: Wed, 28 Aug 2013 21:44:38 +0800 Message-ID: From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= To: Michael Tuexen Content-Type: multipart/alternative; boundary=089e0115f49ad7b44d04e50230b1 X-Mailman-Approved-At: Wed, 28 Aug 2013 11:49:11 -0700 Cc: "tsvwg@ietf.org" , Yoav Nir , Mike Belshe , Michael Welzl , HTTP Working Group Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: willchan@google.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 13:44:41 -0000 --089e0115f49ad7b44d04e50230b1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 28, 2013 at 9:41 PM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > On Aug 28, 2013, at 3:34 PM, William Chan (=E9=99=88=E6=99=BA=E6=98=8C) <= willchan@google.com> > wrote: > > > On Wed, Aug 28, 2013 at 7:53 PM, Michael Welzl > wrote: > > > > On 28. aug. 2013, at 11:53, William Chan (=E9=99=88=E6=99=BA=E6=98=8C) = wrote: > > > >> On Aug 28, 2013 4:01 PM, "Michael Welzl" wrote: > >> > > >> > Hi, > >> > > >> > I agree 100% with Michael Tuexen here... just one thing, in line: > >> > > >> > > >> >>> You're right, SCTP is non-deployable, which makes it a non-starter= . > SCTP also does not address handshake issues or TLS issues. > >> >> > >> >> I agree that SCTP over IP can't be deployed now due to missing NAT > support. > >> > > >> > > >> > Indeed that's not an argument against SCTP/UDP/IP, but I also wonder > why, instead of saying "can't be deployed", people don't just go ahead an= d > use it whenever it's there and works, with a fall-back to TCP? This could > be done with (this version of) Happy Eyeballs: > >> > http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02 > >> > > >> > Good reasons against doing this are... what? Anyone? > >> > >> Implementation usefulness. Why bother adding code that barely gets use= d > (and that is unlikely to improve in the near future), adds complexity, co= de > bloat, etc...? > >> > > Fair point. That's why I think the OS should in fact do Happy Eyeballs > for you! > > > > > > I'm not sure if you're trolling me. In case you aren't, you may want to > look at the graph at: > http://gs.statcounter.com/#os-ww-monthly-201207-201307. Windows XP > (released in 2001) is still around 20% of browser usage. If you have the > ability to get Microsoft to backport SCTP/IP onto their XP stack, I'd lov= e > to know. We're not going to ignore large segments of our user base when w= e > could use UDP and deploy for all relevant OSes. That may be acceptable fo= r > some applications, but not for the browser I work on. > You can build SCTP in your browser and run it on top of UDP. This is what > is done > in RTCWeb. They use SCTP over DTLS over UDP with SCTP and DTLS running in > the > application layer. This is available in recent versions of Firefox and > running > on Windows XP... > You may have missed the fact that Michael Welzl was talking about SCTP/IP and I was responding to that. You may also have missed my note below about SCTP over UDP where I said: "SCTP/UDP has a much higher likelihood of usefulness." Cheers. > > Best regards > Michael > > > > This is why Roberto said: > > """ > > Wide, "safe" deployment > > """ > >> SCTP/UDP has a much higher likelihood of usefulness. But as Roberto ha= s > mentioned, it still has deficiencies, mostly around RTTs (connection + DT= LS > setup). If they can be fixed, great. Let's do it. > >> > > Why shouldn't it be possible to fix SCTP to do whatever you want? Anywa= y > it sounds to me like a simpler approach than building a whole new protoco= l. > Of course, SCTP++ isn't the nicest acronym... then again, RTMFP isn't > either, if you ask me, sounds almost like RTFM... QUIC is great though! > > > > I have no attachments to the protocol name or frame format or whatever. > Look at what we're doing in HTTP/2 which was inspired by SPDY but now has > undergone substantial changes. We're serious about this. As long as the > transport provides all the features we need, we'll use it. This > conversation got started because tsvwg asked httpbis what the application > layer wants from the transport. We're telling you. I think the constructi= ve > next step is for tsvwg folks to ask for clarification on any requirement > they don't understand, discuss whether or not the requirements are > reasonable, and discuss what may need to be done to address them. > > > > > > Cheers, > > Michael > > > > > > --089e0115f49ad7b44d04e50230b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 28, 2013 at 9:41 PM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wr= ote:
On Aug 28, 2013, at 3:34 PM, William Chan (=E9=99=88=E6=99=BA=E6=98=8C) <= ;willchan@google.co= m> wrote:

> On Wed, Aug 28, 2013 at 7:53 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
>
> On 28. aug. 2013, at 11:53, William Chan (=E9=99=88=E6=99=BA=E6=98=8C)= wrote:
>
>> On Aug 28, 2013 4:01 PM, "Michael Welzl" <michawe@ifi.uio.no> wrot= e:
>> >
>> > Hi,
>> >
>> > I agree 100% with Michael Tuexen here... just one thing, in l= ine:
>> >
>> >
>> >>> You're right, SCTP is non-deployable, which makes= it a non-starter. =C2=A0SCTP also does not address handshake issues or TLS= issues.
>> >>
>> >> I agree that SCTP over IP can't be deployed now due t= o missing NAT support.
>> >
>> >
>> > Indeed that's not an argument against SCTP/UDP/IP, but I = also wonder why, instead of saying "can't be deployed", peopl= e don't just go ahead and use it whenever it's there and works, wit= h a fall-back to TCP? This could be done with (this version of) Happy Eyeba= lls:
>> > http://tools.ietf.org/= html/draft-wing-tsvwg-happy-eyeballs-sctp-02
>> >
>> > Good reasons against doing this are... what? Anyone?
>>
>> Implementation usefulness. Why bother adding code that barely gets= used (and that is unlikely to improve in the near future), adds complexity= , code bloat, etc...?
>>
> Fair point. That's why I think the OS should in fact do Happy Eyeb= alls for you!
>
>
> I'm not sure if you're trolling me. In case you aren't, yo= u may want to look at the graph at: http://gs.st= atcounter.com/#os-ww-monthly-201207-201307. Windows XP (released in 200= 1) is still around 20% of browser usage. If you have the ability to get Mic= rosoft to backport SCTP/IP onto their XP stack, I'd love to know. We= 9;re not going to ignore large segments of our user base when we could use = UDP and deploy for all relevant OSes. That may be acceptable for some appli= cations, but not for the browser I work on.
You can build SCTP in your browser and run it on top of UDP. This is = what is done
in RTCWeb. They use SCTP over DTLS over UDP with SCTP and DTLS running in t= he
application layer. This is available in recent versions of Firefox and runn= ing
on Windows XP...

You may have missed th= e fact that Michael Welzl was talking about SCTP/IP and I was responding to= that. You may also have missed my note below about SCTP over UDP where I s= aid: "SCTP/UDP has a much higher likelihood of usefulness."

Cheers.
=C2=A0

Best regards
Michael
>
> This is why Roberto said:
> """
> Wide, "safe" deployment
> """
>> SCTP/UDP has a much higher likelihood of usefulness. But as Robert= o has mentioned, it still has deficiencies, mostly around RTTs (connection = + DTLS setup). If they can be fixed, great. Let's do it.
>>
> Why shouldn't it be possible to fix SCTP to do whatever you want? = Anyway it sounds to me like a simpler approach than building a whole new pr= otocol. Of course, SCTP++ isn't the nicest acronym... =C2=A0then again,= RTMFP isn't either, if you ask me, sounds almost like RTFM... =C2=A0QU= IC is great though!
>
> I have no attachments to the protocol name or frame format or whatever= . Look at what we're doing in HTTP/2 which was inspired by SPDY but now= has undergone substantial changes. We're serious about this. As long a= s the transport provides all the features we need, we'll use it. This c= onversation got started because tsvwg asked httpbis what the application la= yer wants from the transport. We're telling you. I think the constructi= ve next step is for tsvwg folks to ask for clarification on any requirement= they don't understand, discuss whether or not the requirements are rea= sonable, and discuss what may need to be done to address them.
>
>
> Cheers,
> Michael
>
>


--089e0115f49ad7b44d04e50230b1-- From mike@belshe.com Tue Aug 27 15:12:30 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E6121E80A3 for ; Tue, 27 Aug 2013 15:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=-4.178, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jft70cS1dNXP for ; Tue, 27 Aug 2013 15:12:27 -0700 (PDT) Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by ietfa.amsl.com (Postfix) with ESMTP id 57A6C21E8099 for ; Tue, 27 Aug 2013 15:12:26 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id r7so1817237bkg.36 for ; Tue, 27 Aug 2013 15:12:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HnnfmfAk6e25pyEmrR+kSvrvY+6Wwdo1P1nHgeUNkM8=; b=jjX7Wh0VB/FkvM1jXppu42KriEsALbdEdUOSvhjdKMWU2D75gQbKYVoFneoU61LdXF Q7CTrjtCYi4KjQ609FjY4e8UCpODJ9+Dwb3HmUFrrHf5DBCEsJieeJQzRPaa+SKPh69l YcudXXZuhWnJpSQ38pKNWxCQzvPtO1476KCyy3dvBwy/3ulRxb+wX9944aUx3R1G2TnL hEwSbJA3O48AaKtP4HztOJLG6QlzlKQsjbhGrTfORd4YeRcm6isW5lSfOo7XfBCAKE9+ XZ63WqAdLpchtUq4Lhh5m16Iq5rrL+kuTfudEhrDuXOLLuJ69PYvhgsAv5Yp/8UOmJq8 gi6g== X-Gm-Message-State: ALoCoQl9/D6dQ76paUr3aPrjoCJeK4mxHl/XyRFZ+tuy2+JzqOHOatif20pAsLsdBqWPdgVyswvr MIME-Version: 1.0 X-Received: by 10.205.7.6 with SMTP id om6mr16447187bkb.18.1377641545194; Tue, 27 Aug 2013 15:12:25 -0700 (PDT) Received: by 10.204.168.130 with HTTP; Tue, 27 Aug 2013 15:12:25 -0700 (PDT) In-Reply-To: References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> Date: Tue, 27 Aug 2013 15:12:25 -0700 Message-ID: From: Mike Belshe To: Michael Thornburgh Content-Type: multipart/alternative; boundary=20cf30223901ee1ac704e4f52a14 X-Mailman-Approved-At: Wed, 28 Aug 2013 11:49:17 -0700 Cc: Yoav Nir , HTTP Working Group , "tsvwg@ietf.org" Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 22:12:30 -0000 --20cf30223901ee1ac704e4f52a14 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Aug 27, 2013 at 2:46 PM, Michael Thornburgh wro= te: > if you=92re bringing up something like QUIC, i=92ll point out that RTMFP > addresses almost every point on The List, and is currently widely deploye= d > in the Internet (in Flash Player) with 5+ years of deployment experience. > RTMFP is a general-purpose transport protocol that runs on top of UDP and > provides prioritization, parallel message channels (=93flows=94), partial > reliability, shared congestion control, a generalized security framework, > independent flow control for every flow/channel, no flow-flow HOL blockin= g, > IP address mobility, and more. RTMFP sessions start in 2 RTT, and > arbitrary numbers of unidirectional flows in that session can be started = in > 0 RTT. flows are named with arbitrary/opaque-to-RTMFP metadata instead o= f > port or stream numbers. =93return flow association=94 generalizes > bidirectional communication to arbitrarily complex trees of flows, which > can more naturally model structured data transport (such as > request/multiple-response).**** > > ** ** > > RTMFP is described here:**** > > ** ** > > http://tools.ietf.org/html/draft-thornburgh-adobe-rtmfp**** > > ** ** > > and is currently in the RFC Editor=92s queue for publication as an > Informational RFC. > Sounds cool. Why don't you benchmark it in a browser? If it does all this stuff, it should be faster today. > **** > > ** ** > > note that while SCTP might not technically have HOL blocking > stream-stream, the structure of its acknowledgements and the Transmission > Sequence Number semantics can cause a priority inversion during periods o= f > congestion. SCTP does not have independent flow control for each stream.= * > *** > > ** ** > > some thoughts on =93fast channel startup with no state at the server=94:*= *** > > ** ** > > 1) you will typically want some kind of handshake with the server to > establish that the client is actually at the address it appears to be > coming from, to avoid TCP=92s =93SYN flood=94 problem. that means at lea= st one > RTT when you have no current state at the server for a client. > When at Google, we devised several systems to counteract this. The winning candidate (never implemented) was a hybrid solution: you let the first one in for free (no RTT), and require RTTs for the secondary parallel requests until confidence is established. This gives you most of the perf benefit. > **** > > ** ** > > 2) when designing RTMFP, we rejected a =93connection reset=94 message t= hat > could be sent by a server to a client that thought it had a connection wh= en > no connection existed in the server (for example, if the server rebooted = or > timed out the connection but the client didn=92t know), as that would be = an > abusable denial-of-service vector. > Not if it ran atop a secured, encrypted channel :-) > **** > > ** ** > > 3) if you=92re willing to maintain some state at a server, you can leav= e > an RTMFP session open for a long time, and use the =93address mobility=94 > capability to handle the case when a client changes addresses (for exampl= e, > on getting a new translation in a NAT after a quiet period). the method > described in Section 3.5.4.2 of the RTMFP spec currently has a 1 RTT cost > to verify the address change. that method could be modified to allow a > provisional change of address immediately, with a switch back to the old > address if the verification fails. > Maybe, but generally, I think that doesn't scales enough or as well as it could.... I was thinking client state, but happy to be proven wrong. > **** > > ** ** > > 4) if you=92ve been idle for long enough to time out a session (minutes= ?), > then establishing a new session (even at a cost of a couple RTTs) shouldn= =92t > perceptually be a big deal. > I disagree :-) RTTs are still 100+ms. Thats money. Mike > **** > > ** ** > > -michael thornburgh**** > > ** ** > > ** ** > > *From:* tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] *On Behalf > Of *Mike Belshe > *Sent:* Tuesday, August 06, 2013 2:31 AM > *To:* Yoav Nir > *Cc:* HTTP Working Group; tsvwg@ietf.org > *Subject:* Re: [tsvwg] The List (of application-layer desired features)**= * > * > > ** ** > > ** ** > > ** ** > > On Tue, Aug 6, 2013 at 10:49 AM, Yoav Nir wrote:***= * > > I think most of that is addressed in SCTP. Except the deployment part. > Standards people can=92t force vendors of operating systems or Linux > distributions to include any feature. So we have a lot of =93version 2=94= s in > the IETF that take a very long time to get deployed. **** > > **** > > It=92s also much more attractive to define a new thing (like SCTP) than t= o > make something old work a little better. SCTP was sexier than TCPM.**** > > **** > > So it took ages to get deployment of IPv6, IKEv2, TLS 1.2, and all three > are still used far less than IPv4, IKEv1 and TLS 1.0. SCTP is used almost > never. HTTP/2 will likely fare better because the vendors are more involv= ed > and committed, but it=92s hard to make predictions, especially about the > future.**** > > ** ** > > You're right, SCTP is non-deployable, which makes it a non-starter. SCTP > also does not address handshake issues or TLS issues.**** > > ** ** > > I don't mean to sound inflammatory - but for all intents and purposes, th= e > next generation transport will need to be in user space and run on top of > UDP. There simply is no other deployable option on the table. QUIC is > already reasonably far at exploring these issues: > http://en.wikipedia.org/wiki/QUIC**** > > ** ** > > Mike**** > > ** ** > > ** ** > > ** ** > > ** ** > > **** > > **** > > Yoav**** > > **** > > *From:* Roberto Peon [mailto:grmocg@gmail.com] > *Sent:* Tuesday, August 06, 2013 11:16 AM**** > > > *To:* HTTP Working Group; tsvwg@ietf.org > *Subject:* Re: The List (of application-layer desired features)**** > > **** > > Actually sending to the right list for TSVWG...**** > > **** > > -=3DR**** > > **** > > On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon wrote:***= * > > For those of you who missed it, at the HTTPBis/TSVG joint session, a > question about what applications want from the transport (I really want t= o > put quotes around that) came up.**** > > **** > > Here is a rendition of what was on the note that I jotted down in respons= e > to this question, and which I passed to people at the mic.**** > > **** > > (Apps-folks want the following) Deployed in 1996:**** > > -----------------------------------------**** > > - Prioritization**** > > - Partial Reliability**** > > - "Shared" congestion between multiple streams**** > > - Security**** > > - No HOL blocking on stream X when loss on stream Y**** > > - Cheap/Fast channel/connection setup**** > > - Wide, "safe" deployment**** > > - Competes with TCP/HTTP/1.1 (performance-wise)**** > > - Multipath/roaming robustness, i.e. the "driveway" problem**** > > **** > > **** > > I'll reiterate that by far the most important feature is "is deployed".**= * > * > > Nothing else matters until that is true, at least at the application-laye= r. > **** > > -=3DR**** > > **** > > **** > > **** > > > > Email secured by Check Point **** > > ** ** > --20cf30223901ee1ac704e4f52a14 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 27, 2013 at 2:46 PM, Michael Thornburgh <mthornbu@ado= be.com> wrote:
if you=92re bringing up something like QUIC, i=92ll point out that = RTMFP addresses almost every point on The List, and is currently widely dep= loyed in the Internet (in Flash Player) with 5+ years of deployment experie= nce.=A0 RTMFP is a general-purpose transport protocol that runs on top of U= DP and provides prioritization, parallel message channels (=93flows=94), pa= rtial reliability, shared congestion control, a generalized security framew= ork, independent flow control for every flow/channel, no flow-flow HOL bloc= king, IP address mobility, and more.=A0 RTMFP sessions start in 2 RTT, and = arbitrary numbers of unidirectional flows in that session can be started in= 0 RTT.=A0 flows are named with arbitrary/opaque-to-RTMFP metadata instead = of port or stream numbers.=A0 =93return flow association=94 generalizes bid= irectional communication to arbitrarily complex trees of flows, which can m= ore naturally model structured data transport (such as request/multiple-res= ponse).

=A0

RTM= FP is described here:

=A0

=A0= http://tools.ietf.org/html/draft-thornburgh-adobe-rtmfp<= /u>

=A0

and= is currently in the RFC Editor=92s queue for publication as an Information= al RFC.


Sounds cool. =A0Why don't you benchmark i= t in a browser? =A0If it does all this stuff, it should be faster today.

=A0

<= u>=A0

note that while SCTP might not technically have HOL b= locking stream-stream, the structure of its acknowledgements and the Transm= ission Sequence Number semantics can cause a priority inversion during peri= ods of congestion.=A0 SCTP does not have independent flow control for each = stream.

=A0

som= e thoughts on =93fast channel startup with no state at the server=94:

=A0

=A0= 1) you will typically want some kind of handshake with the server to estab= lish that the client is actually at the address it appears to be coming fro= m, to avoid TCP=92s =93SYN flood=94 problem.=A0 that means at least one RTT= when you have no current state at the server for a client.


When at Google, we devised several systems to= counteract this. =A0The winning candidate (never implemented) was a hybrid= solution: =A0you let the first one in for free (no RTT), and require RTTs = for the secondary parallel requests until confidence is established. =A0Thi= s gives you most of the perf benefit.

=A0

<= u>=A0

=A0 2) when designing RTMFP, we rejected a =93connect= ion reset=94 message that could be sent by a server to a client that though= t it had a connection when no connection existed in the server (for example= , if the server rebooted or timed out the connection but the client didn=92= t know), as that would be an abusable denial-of-service vector.


Not if it ran atop a secured, encrypted channel :-= )


=A0

<= u>=A0

=A0 3) if you=92re willing to maintain some state at = a server, you can leave an RTMFP session open for a long time, and use the = =93address mobility=94 capability to handle the case when a client changes = addresses (for example, on getting a new translation in a NAT after a quiet= period).=A0 the method described in Section 3.5.4.2 of the RTMFP spec curr= ently has a 1 RTT cost to verify the address change.=A0 that method could b= e modified to allow a provisional change of address immediately, with a swi= tch back to the old address if the verification fails.


Maybe, but generally, I think that doesn't scal= es enough or as well as it could.... =A0I was thinking client state, but ha= ppy to be proven wrong.
=A0

=A0<= /p>

=A0 4) if you=92ve been idle for long enough to time = out a session (minutes?), then establishing a new session (even at a cost o= f a couple RTTs) shouldn=92t perceptually be a big deal.


I disagree :-) RTTs are still 100+ms. =A0Thats mone= y.

Mike


=

=A0

<= u>=A0

-michael thornburgh

=A0

=A0

From: tsvwg-bounces@ietf.org [mailto:= tsvwg-bounces@i= etf.org] On Behalf Of Mike Belshe
Sent: Tuesday, August 06, 2013 2:31 AM
To: Yoav Nir
= Cc: HTTP Working Group; tsvwg@ietf.org
Subject: Re: [tsvwg] The List (of applica= tion-layer desired features)

=A0

=

=A0

=A0

On Tue, Aug 6, 2013 at 10:4= 9 AM, Yoav Nir <ynir@checkpoint.com> wrote:

I think most of that is addressed in SCTP. = =A0Except the deployment part. Standards people can=92t force vendors of op= erating systems or Linux distributions to include any feature. So we have a= lot of =93version 2=94s in the IETF that take a very long time to get depl= oyed.

=A0

It= =92s also much more attractive to define a new thing (like SCTP) than to ma= ke something old work a little better. SCTP was sexier than TCPM.=

=A0

So = it took ages to get deployment of IPv6, IKEv2, TLS 1.2, and all three are s= till used far less than IPv4, IKEv1 and TLS 1.0. SCTP is used almost never.= HTTP/2 will likely fare better because the vendors are more involved and c= ommitted, but it=92s hard to make predictions, especially about the future.=

=A0

You're right, SCTP is non-deployable, which makes it a non-starter. = =A0SCTP also does not address handshake issues or TLS issues.=

=A0

I don'= t mean to sound inflammatory - but for all intents and purposes, the next g= eneration transport will need to be in user space and run on top of UDP. = =A0There simply is no other deployable option on the table. =A0QUIC is alre= ady reasonably far at exploring these issues:=A0http://en.wikipedia.org/wiki/QUIC<= u>

=A0

Mike=

=A0

=

=A0

=A0

=A0

=A0

=A0

<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73= ,125)">Yoav

=A0

From: Roberto Peon [mailt= o:grmocg@gmail.com]
Sent: Tuesday, August 06, 2013 11:16 AM


To: HTTP Working Group; tsvwg@ietf.org
Subject: Re: The Li= st (of application-layer desired features)

=A0

Actually sendin= g to the right list for TSVWG...

=A0=

-=3DR

=

=A0

<= p class=3D"">On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon <grmocg@gmail.com> wrote:=

For those of you who missed it, at the HTTPBis/TSVG= joint session, a question about what applications want from the transport = (I really want to put quotes around that) came up.

=A0

Here is a = rendition of what was on the note that I jotted down in response to this qu= estion, and which I passed to people at the mic.

=A0

(Apps-folk= s want the following) Deployed in 1996:

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

- Prioritization

- Partial Reliab= ility

- "Shared" conges= tion between multiple streams

- S= ecurity

- No HOL blocking on stream X when loss on stream = Y

- Cheap/Fast =A0channel/connect= ion setup

- Wide, "safe"= ; deployment

- Competes with TCP/HTTP/1.1 (performance-wise)=

- Multipath/roaming robustness, i.e= . the "driveway" problem

=A0

=A0

I'll reiterate that by far the most important feature = is "is deployed".

Nothi= ng else matters until that is true, at least at the application-layer.

-=3DR

=A0

=A0

=A0



Email secured by Check Point=

=A0<= u>


--20cf30223901ee1ac704e4f52a14-- From mike@belshe.com Wed Aug 28 11:13:35 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B3821E8050 for ; Wed, 28 Aug 2013 11:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.005 X-Spam-Level: X-Spam-Status: No, score=-4.005 tagged_above=-999 required=5 tests=[AWL=-3.484, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkCyXrURL4ZB for ; Wed, 28 Aug 2013 11:13:32 -0700 (PDT) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id E925921E804D for ; Wed, 28 Aug 2013 11:13:31 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id jt11so6557567pbb.38 for ; Wed, 28 Aug 2013 11:13:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QR8HPhlS5FIF5y1rImds1vmBaszB9Jrw1FB0+bZYXs8=; b=cBPsxWxthbnIb4nxMWGWk75Qpb16ntNXB+8RwyVw52fcaKd/7zGGO7BvXYgg6hAcec L235o2AcNCvrMYU3X6a/Asp6abJ6Bi6RPBiW7SXDAfJ7n7IUy1e3UR0mdkJewSuMgO3c u6IUZ+shYnMYuBCM5jFulXJMut29zFocVaJO+gkzuw4HGDw5T+f0yhEGhnerqUdV3bPj h6OtSTIKBOEax/dTNNbwm5be2PS+a4eumhWhM0h/prvJgOaWlDlrhi2DwqPAuCFVRhSG oshfVOhLaEn3P/1mseNQ4nb3hJpBVdRxJBwWWcZEaaM4Rbg7/BsXGaXigi1Yj9MV1QrO F/nA== X-Gm-Message-State: ALoCoQkuJG1l0gSM+ImUMVkYOzQ5141aRYd4xOwPYyIh56wQz5cLf1/ASSNvLm8phDZStUV5X5me MIME-Version: 1.0 X-Received: by 10.68.131.168 with SMTP id on8mr28910481pbb.97.1377713611211; Wed, 28 Aug 2013 11:13:31 -0700 (PDT) Received: by 10.68.48.36 with HTTP; Wed, 28 Aug 2013 11:13:30 -0700 (PDT) In-Reply-To: References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> Date: Wed, 28 Aug 2013 11:13:30 -0700 Message-ID: From: Mike Belshe To: Michael Thornburgh Content-Type: multipart/alternative; boundary=001a11c35c6066174904e505f21d X-Mailman-Approved-At: Wed, 28 Aug 2013 11:49:17 -0700 Cc: Yoav Nir , HTTP Working Group , "tsvwg@ietf.org" Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 18:13:36 -0000 --001a11c35c6066174904e505f21d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 28, 2013 at 10:41 AM, Michael Thornburgh wrote: > replies inline. > > > -----Original Message----- > > From: Mike Belshe [mailto:mike@belshe.com] > > Sent: Tuesday, August 27, 2013 3:12 PM > > > > > > On Tue, Aug 27, 2013 at 2:46 PM, Michael Thornburgh > wrote: > > > > > > if you're bringing up something like QUIC, i'll point out that > RTMFP addresses almost every > > point on The List, and is currently widely deployed in the Internet (in > Flash Player) with 5+ years of > > deployment experience. RTMFP is a general-purpose transport protocol > that runs on top of UDP and > > provides prioritization, parallel message channels ("flows"), partial > reliability, shared congestion > > control, a generalized security framework, independent flow control for > every flow/channel, no flow- > > flow HOL blocking, IP address mobility, and more. RTMFP sessions start > in 2 RTT, and arbitrary > > numbers of unidirectional flows in that session can be started in 0 RTT. > flows are named with > > arbitrary/opaque-to-RTMFP metadata instead of port or stream numbers. > "return flow association" > > generalizes bidirectional communication to arbitrarily complex trees of > flows, which can more > > naturally model structured data transport (such as > request/multiple-response). > > > > > > > > RTMFP is described here: > > > > > > > > http://tools.ietf.org/html/draft-thornburgh-adobe-rtmfp > > > > > > > > and is currently in the RFC Editor's queue for publication as an > Informational RFC. > > > > > > Sounds cool. Why don't you benchmark it in a browser? If it does all > this stuff, it should be faster > > today. > > i'll add that to the list. > > > note that while SCTP might not technically have HOL blocking > stream-stream, the structure of its > > acknowledgements and the Transmission Sequence Number semantics can > cause a priority inversion during > > periods of congestion. SCTP does not have independent flow control for > each stream. > > > > > > > > some thoughts on "fast channel startup with no state at the > server": > > > > > > > > 1) you will typically want some kind of handshake with the > server to establish that the client > > is actually at the address it appears to be coming from, to avoid TCP's > "SYN flood" problem. that > > means at least one RTT when you have no current state at the server for > a client. > > > > > > When at Google, we devised several systems to counteract this. The > winning candidate (never > > implemented) was a hybrid solution: you let the first one in for free > (no RTT), and require RTTs for > > the secondary parallel requests until confidence is established. This > gives you most of the perf > > benefit. > > i don't understand how that approach addresses the "a bad person initiates > 100M one-packet connection attempts from different [forged/pwned] addresses > and doesn't follow through" SYN flood problem, where every packet coming in > would be "the first one", thereby creating connection state in the server. > > > 2) when designing RTMFP, we rejected a "connection reset" > message that could be sent by a > > server to a client that thought it had a connection when no connection > existed in the server (for > > example, if the server rebooted or timed out the connection but the > client didn't know), as that would > > be an abusable denial-of-service vector. > > > > > > Not if it ran atop a secured, encrypted channel :-) > > the issue here is there is no secured, encrypted channel over which to > send a connection reset message, from a server with no connection state to > a client with a connection state. if you were going to go to the PK/CPU > trouble to compute new session keys at the server just to send a reset, you > might as well not reset and just continue with the session. RTMFP does > have an in-session "abrupt close" mechanism, and flows in a session can be > rejected at any time by the receiver. > > > 3) if you're willing to maintain some state at a server, you can > leave an RTMFP session open > > for a long time, and use the "address mobility" capability to handle the > case when a client changes > > addresses (for example, on getting a new translation in a NAT after a > quiet period). the method > > described in Section 3.5.4.2 of the RTMFP spec currently has a 1 RTT > cost to verify the address > > change. that method could be modified to allow a provisional change of > address immediately, with a > > switch back to the old address if the verification fails. > > > > > > Maybe, but generally, I think that doesn't scales enough or as well as > it could.... I was thinking > > client state, but happy to be proven wrong. > > > > > > 4) if you've been idle for long enough to time out a session > (minutes?), then establishing a > > new session (even at a cost of a couple RTTs) shouldn't perceptually be > a big deal. > > > > > > I disagree :-) RTTs are still 100+ms. Thats money. > > there's no reason a timeout couldn't be tuned (per site? and communicated > to the client to behave accordingly) to balance resource use at the servers > for idle connections with expected users' idle periods between accesses to > the site. > At this point, I think we're going in circles - this all sounds great. I encourage you and others to continue down this path. At this point we need to move the discussion from theory to execution. I hear statements like this one all the time - "there is no reason a timeout couldn't be.....". You're right, no reason except the devil of the details when you put it all together and realize you forgot something :-) It needs to be put to practice in real product, benchmarked, documented, tested, and iterated. The first person to actually implement, rather than theorize, will be the one who defines the next protocol. If that person borrows mostly from SCTP or RTMFP or QUIC or something else doesn't matter. Theory is nothing - execution is everything. :-) Mike > > > > > Mike > > -michael thornburgh > > > > > -michael thornburgh > > > > > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On > Behalf Of Mike Belshe > > Sent: Tuesday, August 06, 2013 2:31 AM > > To: Yoav Nir > > Cc: HTTP Working Group; tsvwg@ietf.org > > Subject: Re: [tsvwg] The List (of application-layer desired > features) > > > > > > > > On Tue, Aug 6, 2013 at 10:49 AM, Yoav Nir > wrote: > > > > I think most of that is addressed in SCTP. Except the deployment > part. Standards people can't > > force vendors of operating systems or Linux distributions to include any > feature. So we have a lot of > > "version 2"s in the IETF that take a very long time to get deployed. > > > > > > > > It's also much more attractive to define a new thing (like SCTP) > than to make something old work > > a little better. SCTP was sexier than TCPM. > > > > > > > > So it took ages to get deployment of IPv6, IKEv2, TLS 1.2, and all > three are still used far less > > than IPv4, IKEv1 and TLS 1.0. SCTP is used almost never. HTTP/2 will > likely fare better because the > > vendors are more involved and committed, but it's hard to make > predictions, especially about the > > future. > > > > > > > > You're right, SCTP is non-deployable, which makes it a > non-starter. SCTP also does not address > > handshake issues or TLS issues. > > > > > > > > I don't mean to sound inflammatory - but for all intents and > purposes, the next generation > > transport will need to be in user space and run on top of UDP. There > simply is no other deployable > > option on the table. QUIC is already reasonably far at exploring these > issues: > > http://en.wikipedia.org/wiki/QUIC > > > > > > > > Mike > > > > > > > > Yoav > > > > > > > > From: Roberto Peon [mailto:grmocg@gmail.com] > > Sent: Tuesday, August 06, 2013 11:16 AM > > > > > > To: HTTP Working Group; tsvwg@ietf.org > > Subject: Re: The List (of application-layer desired > features) > > > > > > > > Actually sending to the right list for TSVWG... > > > > > > > > -=R > > > > > > > > On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon < > grmocg@gmail.com> wrote: > > > > For those of you who missed it, at the HTTPBis/TSVG joint > session, a question about what > > applications want from the transport (I really want to put quotes around > that) came up. > > > > > > > > Here is a rendition of what was on the note that I jotted > down in response to this > > question, and which I passed to people at the mic. > > > > > > > > (Apps-folks want the following) Deployed in 1996: > > > > ----------------------------------------- > > > > - Prioritization > > > > - Partial Reliability > > > > - "Shared" congestion between multiple streams > > > > - Security > > > > - No HOL blocking on stream X when loss on stream Y > > > > - Cheap/Fast channel/connection setup > > > > - Wide, "safe" deployment > > > > - Competes with TCP/HTTP/1.1 (performance-wise) > > > > - Multipath/roaming robustness, i.e. the "driveway" problem > > > > > > > > > > > > I'll reiterate that by far the most important feature is > "is deployed". > > > > Nothing else matters until that is true, at least at the > application-layer. > > > > -=R > > > > > > Email secured by Check Point > > > > --001a11c35c6066174904e505f21d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Aug 28, 2013 at 10:41 AM, Michael Thornburgh <mthornbu@ad= obe.com> wrote:
replies inline.

> -----Original Message-----
> From: Mike Belshe [mailto:mike@bels= he.com]
> Sent: Tuesday, August 27, 2013 3:12 PM
>
>
> On Tue, Aug 27, 2013 at 2:46 PM, Michael Thornburgh <mthornbu@adobe.com> wrote:
>
>
> =A0 =A0 =A0 if you're bringing up something like QUIC, i'll po= int out that RTMFP addresses almost every
> point on The List, and is currently widely deployed in the Internet (i= n Flash Player) with 5+ years of
> deployment experience. =A0RTMFP is a general-purpose transport protoco= l that runs on top of UDP and
> provides prioritization, parallel message channels ("flows")= , partial reliability, shared congestion
> control, a generalized security framework, independent flow control fo= r every flow/channel, no flow-
> flow HOL blocking, IP address mobility, and more. =A0RTMFP sessions st= art in 2 RTT, and arbitrary
> numbers of unidirectional flows in that session can be started in 0 RT= T. =A0flows are named with
> arbitrary/opaque-to-RTMFP metadata instead of port or stream numbers. = =A0"return flow association"
> generalizes bidirectional communication to arbitrarily complex trees o= f flows, which can more
> naturally model structured data transport (such as request/multiple-re= sponse).
>
>
>
> =A0 =A0 =A0 RTMFP is described here:
>
>
>
> =A0 =A0 =A0 =A0 http://tools.ietf.org/html/draft-thornburgh= -adobe-rtmfp
>
>
>
> =A0 =A0 =A0 and is currently in the RFC Editor's queue for publica= tion as an Informational RFC.
>
>
> Sounds cool. =A0Why don't you benchmark it in a browser? =A0If it = does all this stuff, it should be faster
> today.

i'll add that to the list.

> =A0 =A0 =A0 note that while SCTP might not technically have HOL blocki= ng stream-stream, the structure of its
> acknowledgements and the Transmission Sequence Number semantics can ca= use a priority inversion during
> periods of congestion. =A0SCTP does not have independent flow control = for each stream.
>
>
>
> =A0 =A0 =A0 some thoughts on "fast channel startup with no state = at the server":
>
>
>
> =A0 =A0 =A0 =A0 1) you will typically want some kind of handshake with= the server to establish that the client
> is actually at the address it appears to be coming from, to avoid TCP&= #39;s "SYN flood" problem. =A0that
> means at least one RTT when you have no current state at the server fo= r a client.
>
>
> When at Google, we devised several systems to counteract this. =A0The = winning candidate (never
> implemented) was a hybrid solution: =A0you let the first one in for fr= ee (no RTT), and require RTTs for
> the secondary parallel requests until confidence is established. =A0Th= is gives you most of the perf
> benefit.

i don't understand how that approach addresses the "a bad pe= rson initiates 100M one-packet connection attempts from different [forged/p= wned] addresses and doesn't follow through" SYN flood problem, whe= re every packet coming in would be "the first one", thereby creat= ing connection state in the server.

> =A0 =A0 =A0 =A0 2) when designing RTMFP, we rejected a "connectio= n reset" message that could be sent by a
> server to a client that thought it had a connection when no connection= existed in the server (for
> example, if the server rebooted or timed out the connection but the cl= ient didn't know), as that would
> be an abusable denial-of-service vector.
>
>
> Not if it ran atop a secured, encrypted channel :-)

the issue here is there is no secured, encrypted channel over which t= o send a connection reset message, from a server with no connection state t= o a client with a connection state. =A0if you were going to go to the PK/CP= U trouble to compute new session keys at the server just to send a reset, y= ou might as well not reset and just continue with the session. =A0RTMFP doe= s have an in-session "abrupt close" mechanism, and flows in a ses= sion can be rejected at any time by the receiver.

> =A0 =A0 =A0 =A0 3) if you're willing to maintain some state at a s= erver, you can leave an RTMFP session open
> for a long time, and use the "address mobility" capability t= o handle the case when a client changes
> addresses (for example, on getting a new translation in a NAT after a = quiet period). =A0the method
> described in Section 3.5.4.2 of the RTMFP spec currently has a 1 RTT c= ost to verify the address
> change. =A0that method could be modified to allow a provisional change= of address immediately, with a
> switch back to the old address if the verification fails.
>
>
> Maybe, but generally, I think that doesn't scales enough or as wel= l as it could.... =A0I was thinking
> client state, but happy to be proven wrong.
>
>
> =A0 =A0 =A0 =A0 4) if you've been idle for long enough to time out= a session (minutes?), then establishing a
> new session (even at a cost of a couple RTTs) shouldn't perceptual= ly be a big deal.
>
>
> I disagree :-) RTTs are still 100+ms. =A0Thats money.

there's no reason a timeout couldn't be tuned (per site? and = communicated to the client to behave accordingly) to balance resource use a= t the servers for idle connections with expected users' idle periods be= tween accesses to the site.

At this point, I think we're going in = circles - this all sounds great. =A0I encourage you and others to continue = down this path. =A0

At this point we need to move = the discussion from theory to execution. =A0I hear statements like this one= all the time - "there is no reason a timeout couldn't be.....&quo= t;. =A0You're right, no reason except the devil of the details when you= put it all together and realize you forgot something :-) =A0It needs to be= put to practice in real product, benchmarked, documented, tested, and iter= ated.

The first person to actually implement, rather than the= orize, will be the one who defines the next protocol. =A0If that person bor= rows mostly from SCTP or RTMFP or QUIC or something else doesn't matter= . =A0Theory is nothing - execution is everything. :-)

Mike


=A0

>
> Mike

-michael thornburgh

>
> =A0 =A0 =A0 -michael thornburgh
>
>
> =A0 =A0 =A0 From: tsvwg-boun= ces@ietf.org [mailto:tsvwg-bo= unces@ietf.org] On Behalf Of Mike Belshe
> =A0 =A0 =A0 Sent: Tuesday, August 06, 2013 2:31 AM
> =A0 =A0 =A0 To: Yoav Nir
> =A0 =A0 =A0 Cc: HTTP Working Group; = tsvwg@ietf.org
> =A0 =A0 =A0 Subject: Re: [tsvwg] The List (of application-layer desire= d features)
>
>
>
> =A0 =A0 =A0 On Tue, Aug 6, 2013 at 10:49 AM, Yoav Nir <ynir@checkpoint.com> wrote:
>
> =A0 =A0 =A0 I think most of that is addressed in SCTP. =A0Except the d= eployment part. Standards people can't
> force vendors of operating systems or Linux distributions to include a= ny feature. So we have a lot of
> "version 2"s in the IETF that take a very long time to get d= eployed.
>
>
>
> =A0 =A0 =A0 It's also much more attractive to define a new thing (= like SCTP) than to make something old work
> a little better. SCTP was sexier than TCPM.
>
>
>
> =A0 =A0 =A0 So it took ages to get deployment of IPv6, IKEv2, TLS 1.2,= and all three are still used far less
> than IPv4, IKEv1 and TLS 1.0. SCTP is used almost never. HTTP/2 will l= ikely fare better because the
> vendors are more involved and committed, but it's hard to make pre= dictions, especially about the
> future.
>
>
>
> =A0 =A0 =A0 You're right, SCTP is non-deployable, which makes it a= non-starter. =A0SCTP also does not address
> handshake issues or TLS issues.
>
>
>
> =A0 =A0 =A0 I don't mean to sound inflammatory - but for all inten= ts and purposes, the next generation
> transport will need to be in user space and run on top of UDP. =A0Ther= e simply is no other deployable
> option on the table. =A0QUIC is already reasonably far at exploring th= ese issues:
> http:/= /en.wikipedia.org/wiki/QUIC
>
>
>
> =A0 =A0 =A0 Mike
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yoav
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 From: Roberto Peon [mailto:grmocg@gmail.com]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sent: Tuesday, August 06, 2013 11:16 AM >
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 To: HTTP Working Group; tsvwg@ietf.org
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Subject: Re: The List (of application-laye= r desired features)
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Actually sending to the right list for TSV= WG...
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 -=3DR
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 On Tue, Aug 6, 2013 at 1:14 AM, Roberto Pe= on <grmocg@gmail.com> wrote:<= br> >
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 For those of you who missed it, at the HTT= PBis/TSVG joint session, a question about what
> applications want from the transport (I really want to put quotes arou= nd that) came up.
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Here is a rendition of what was on the not= e that I jotted down in response to this
> question, and which I passed to people at the mic.
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 (Apps-folks want the following) Deployed i= n 1996:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 -----------------------------------------<= br> >
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Prioritization
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Partial Reliability
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 - "Shared" congestion between mu= ltiple streams
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Security
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 - No HOL blocking on stream X when loss on= stream Y
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Cheap/Fast =A0channel/connection setup >
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Wide, "safe" deployment
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Competes with TCP/HTTP/1.1 (performance-= wise)
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Multipath/roaming robustness, i.e. the &= quot;driveway" problem
>
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 I'll reiterate that by far the most im= portant feature is "is deployed".
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Nothing else matters until that is true, a= t least at the application-layer.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 -=3DR
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Email secured by Check Point
>


--001a11c35c6066174904e505f21d-- From dave.taht@gmail.com Wed Aug 28 12:32:31 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1B311E81B8 for ; Wed, 28 Aug 2013 12:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[AWL=-0.874, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BpkCElEr91G for ; Wed, 28 Aug 2013 12:32:29 -0700 (PDT) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9053611E81A8 for ; Wed, 28 Aug 2013 12:32:29 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 1so3718279qec.35 for ; Wed, 28 Aug 2013 12:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rPampnor14g0SDsx4c7g9lilPBxYmCADv4qJTXyr2wU=; b=HFMnSmHg6CYIi6k8W+ZKJ7ymi/MoJq+GnoPXdkr1gyGjUmpJ1m6swBlkNSRdQAZOCT IUC66OpeJQUUZFnAxDyk46GtZUnw49KaQSlERL0SAeRVphbUTD6m99X4eSLMIwpu1sB8 bSohA9mkOQVH34jRvlews1H2eGPaS8Xw4Dwf/0FkrUQd1aWFwXTq8iqHWb/XfvXnfggU l+0SgjgQ3st5Mb6oyVYQTYYSybbWg7SK2rh4c+J/Ix6bbLdLhTSDmJ2eny6rW+jVrp31 yyXh3xiXDQKKTKrA0OFmGZiOd0m0WbwqAmTbuDZigfhOTqfV2qkERdmys6ccE0j+581E r2Hg== MIME-Version: 1.0 X-Received: by 10.49.52.41 with SMTP id q9mr19683323qeo.32.1377718348310; Wed, 28 Aug 2013 12:32:28 -0700 (PDT) Received: by 10.224.60.137 with HTTP; Wed, 28 Aug 2013 12:32:28 -0700 (PDT) In-Reply-To: References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> Date: Wed, 28 Aug 2013 12:32:28 -0700 Message-ID: From: Dave Taht To: Mike Belshe Content-Type: multipart/alternative; boundary=047d7bea3f3cc07c4404e5070c62 Cc: "tsvwg@ietf.org" , Yoav Nir , HTTP Working Group Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 19:32:31 -0000 --047d7bea3f3cc07c4404e5070c62 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 28, 2013 at 11:13 AM, Mike Belshe wrote: > > > > On Wed, Aug 28, 2013 at 10:41 AM, Michael Thornburgh = wrote: > >> replies inline. >> >> > -----Original Message----- >> > From: Mike Belshe [mailto:mike@belshe.com] >> > Sent: Tuesday, August 27, 2013 3:12 PM >> > >> > >> > On Tue, Aug 27, 2013 at 2:46 PM, Michael Thornburgh >> wrote: >> > >> > >> > if you're bringing up something like QUIC, i'll point out that >> RTMFP addresses almost every >> > point on The List, and is currently widely deployed in the Internet (i= n >> Flash Player) with 5+ years of >> > deployment experience. RTMFP is a general-purpose transport protocol >> that runs on top of UDP and >> > provides prioritization, parallel message channels ("flows"), partial >> reliability, shared congestion >> > control, a generalized security framework, independent flow control fo= r >> every flow/channel, no flow- >> > flow HOL blocking, IP address mobility, and more. RTMFP sessions star= t >> in 2 RTT, and arbitrary >> > numbers of unidirectional flows in that session can be started in 0 >> RTT. flows are named with >> > arbitrary/opaque-to-RTMFP metadata instead of port or stream numbers. >> "return flow association" >> > generalizes bidirectional communication to arbitrarily complex trees o= f >> flows, which can more >> > naturally model structured data transport (such as >> request/multiple-response). >> > >> > >> > >> > RTMFP is described here: >> > >> > >> > >> > http://tools.ietf.org/html/draft-thornburgh-adobe-rtmfp >> > >> > >> > >> > and is currently in the RFC Editor's queue for publication as an >> Informational RFC. >> > >> > >> > Sounds cool. Why don't you benchmark it in a browser? If it does all >> this stuff, it should be faster >> > today. >> >> i'll add that to the list. >> >> > note that while SCTP might not technically have HOL blocking >> stream-stream, the structure of its >> > acknowledgements and the Transmission Sequence Number semantics can >> cause a priority inversion during >> > periods of congestion. SCTP does not have independent flow control fo= r >> each stream. >> > >> > >> > >> > some thoughts on "fast channel startup with no state at the >> server": >> > >> > >> > >> > 1) you will typically want some kind of handshake with the >> server to establish that the client >> > is actually at the address it appears to be coming from, to avoid TCP'= s >> "SYN flood" problem. that >> > means at least one RTT when you have no current state at the server fo= r >> a client. >> > >> > >> > When at Google, we devised several systems to counteract this. The >> winning candidate (never >> > implemented) was a hybrid solution: you let the first one in for free >> (no RTT), and require RTTs for >> > the secondary parallel requests until confidence is established. This >> gives you most of the perf >> > benefit. >> >> i don't understand how that approach addresses the "a bad person >> initiates 100M one-packet connection attempts from different [forged/pwn= ed] >> addresses and doesn't follow through" SYN flood problem, where every pac= ket >> coming in would be "the first one", thereby creating connection state in >> the server. >> >> > 2) when designing RTMFP, we rejected a "connection reset" >> message that could be sent by a >> > server to a client that thought it had a connection when no connection >> existed in the server (for >> > example, if the server rebooted or timed out the connection but the >> client didn't know), as that would >> > be an abusable denial-of-service vector. >> > >> > >> > Not if it ran atop a secured, encrypted channel :-) >> >> the issue here is there is no secured, encrypted channel over which to >> send a connection reset message, from a server with no connection state = to >> a client with a connection state. if you were going to go to the PK/CPU >> trouble to compute new session keys at the server just to send a reset, = you >> might as well not reset and just continue with the session. RTMFP does >> have an in-session "abrupt close" mechanism, and flows in a session can = be >> rejected at any time by the receiver. >> >> > 3) if you're willing to maintain some state at a server, you >> can leave an RTMFP session open >> > for a long time, and use the "address mobility" capability to handle >> the case when a client changes >> > addresses (for example, on getting a new translation in a NAT after a >> quiet period). the method >> > described in Section 3.5.4.2 of the RTMFP spec currently has a 1 RTT >> cost to verify the address >> > change. that method could be modified to allow a provisional change o= f >> address immediately, with a >> > switch back to the old address if the verification fails. >> > >> > >> > Maybe, but generally, I think that doesn't scales enough or as well as >> it could.... I was thinking >> > client state, but happy to be proven wrong. >> > >> > >> > 4) if you've been idle for long enough to time out a session >> (minutes?), then establishing a >> > new session (even at a cost of a couple RTTs) shouldn't perceptually b= e >> a big deal. >> > >> > >> > I disagree :-) RTTs are still 100+ms. Thats money. >> >> there's no reason a timeout couldn't be tuned (per site? and communicate= d >> to the client to behave accordingly) to balance resource use at the serv= ers >> for idle connections with expected users' idle periods between accesses = to >> the site. >> > > At this point, I think we're going in circles - this all sounds great. I > encourage you and others to continue down this path. > > At this point we need to move the discussion from theory to execution. I > hear statements like this one all the time - "there is no reason a timeou= t > couldn't be.....". You're right, no reason except the devil of the detai= ls > when you put it all together and realize you forgot something :-) It nee= ds > to be put to practice in real product, benchmarked, documented, tested, a= nd > iterated. > > The first person to actually implement, rather than theorize, will be the > one who defines the next protocol. If that person borrows mostly from SC= TP > or RTMFP or QUIC or something else doesn't matter. Theory is nothing - > execution is everything. :-) > > Mike > > +10. --=20 Dave T=E4ht Fixing bufferbloat with fq_codel: http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos#Dave-Taumlhts= -FQ_codel-World-Tour-March-June-2013 --047d7bea3f3cc07c4404e5070c62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Aug 28, 2013 at 11:13 AM, Mike Belshe <= ;mike@belshe.com&g= t; wrote:



On Wed, Aug 28, 2013 at 10:41 AM, Michael Thornburgh <mthornbu@ad= obe.com> wrote:
replies inline.

> -----Original Message-----
> From: Mike Belshe [mailto:mike@belshe.com]
> Sent: Tuesday, August 27, 2013 3:12 PM
>
>
> On Tue, Aug 27, 2013 at 2:46 PM, Michael Thornburgh <mthornbu@adobe.com> wrote:=
>
>
> =A0 =A0 =A0 if you're bringing up something like QUIC, i'll po= int out that RTMFP addresses almost every
> point on The List, and is currently widely deployed in the Internet (i= n Flash Player) with 5+ years of
> deployment experience. =A0RTMFP is a general-purpose transport protoco= l that runs on top of UDP and
> provides prioritization, parallel message channels ("flows")= , partial reliability, shared congestion
> control, a generalized security framework, independent flow control fo= r every flow/channel, no flow-
> flow HOL blocking, IP address mobility, and more. =A0RTMFP sessions st= art in 2 RTT, and arbitrary
> numbers of unidirectional flows in that session can be started in 0 RT= T. =A0flows are named with
> arbitrary/opaque-to-RTMFP metadata instead of port or stream numbers. = =A0"return flow association"
> generalizes bidirectional communication to arbitrarily complex trees o= f flows, which can more
> naturally model structured data transport (such as request/multiple-re= sponse).
>
>
>
> =A0 =A0 =A0 RTMFP is described here:
>
>
>
> =A0 =A0 =A0 =A0 http://tools.ietf.org/html/draft-thornburgh= -adobe-rtmfp
>
>
>
> =A0 =A0 =A0 and is currently in the RFC Editor's queue for publica= tion as an Informational RFC.
>
>
> Sounds cool. =A0Why don't you benchmark it in a browser? =A0If it = does all this stuff, it should be faster
> today.

i'll add that to the list.

> =A0 =A0 =A0 note that while SCTP might not technically have HOL blocki= ng stream-stream, the structure of its
> acknowledgements and the Transmission Sequence Number semantics can ca= use a priority inversion during
> periods of congestion. =A0SCTP does not have independent flow control = for each stream.
>
>
>
> =A0 =A0 =A0 some thoughts on "fast channel startup with no state = at the server":
>
>
>
> =A0 =A0 =A0 =A0 1) you will typically want some kind of handshake with= the server to establish that the client
> is actually at the address it appears to be coming from, to avoid TCP&= #39;s "SYN flood" problem. =A0that
> means at least one RTT when you have no current state at the server fo= r a client.
>
>
> When at Google, we devised several systems to counteract this. =A0The = winning candidate (never
> implemented) was a hybrid solution: =A0you let the first one in for fr= ee (no RTT), and require RTTs for
> the secondary parallel requests until confidence is established. =A0Th= is gives you most of the perf
> benefit.

i don't understand how that approach addresses the "a bad pe= rson initiates 100M one-packet connection attempts from different [forged/p= wned] addresses and doesn't follow through" SYN flood problem, whe= re every packet coming in would be "the first one", thereby creat= ing connection state in the server.

> =A0 =A0 =A0 =A0 2) when designing RTMFP, we rejected a "connectio= n reset" message that could be sent by a
> server to a client that thought it had a connection when no connection= existed in the server (for
> example, if the server rebooted or timed out the connection but the cl= ient didn't know), as that would
> be an abusable denial-of-service vector.
>
>
> Not if it ran atop a secured, encrypted channel :-)

the issue here is there is no secured, encrypted channel over which t= o send a connection reset message, from a server with no connection state t= o a client with a connection state. =A0if you were going to go to the PK/CP= U trouble to compute new session keys at the server just to send a reset, y= ou might as well not reset and just continue with the session. =A0RTMFP doe= s have an in-session "abrupt close" mechanism, and flows in a ses= sion can be rejected at any time by the receiver.

> =A0 =A0 =A0 =A0 3) if you're willing to maintain some state at a s= erver, you can leave an RTMFP session open
> for a long time, and use the "address mobility" capability t= o handle the case when a client changes
> addresses (for example, on getting a new translation in a NAT after a = quiet period). =A0the method
> described in Section 3.5.4.2 of the RTMFP spec currently has a 1 RTT c= ost to verify the address
> change. =A0that method could be modified to allow a provisional change= of address immediately, with a
> switch back to the old address if the verification fails.
>
>
> Maybe, but generally, I think that doesn't scales enough or as wel= l as it could.... =A0I was thinking
> client state, but happy to be proven wrong.
>
>
> =A0 =A0 =A0 =A0 4) if you've been idle for long enough to time out= a session (minutes?), then establishing a
> new session (even at a cost of a couple RTTs) shouldn't perceptual= ly be a big deal.
>
>
> I disagree :-) RTTs are still 100+ms. =A0Thats money.

there's no reason a timeout couldn't be tuned (per site? and = communicated to the client to behave accordingly) to balance resource use a= t the servers for idle connections with expected users' idle periods be= tween accesses to the site.

At this point, I think we'= re going in circles - this all sounds great. =A0I encourage you and others = to continue down this path. =A0

At this point we n= eed to move the discussion from theory to execution. =A0I hear statements l= ike this one all the time - "there is no reason a timeout couldn't= be.....". =A0You're right, no reason except the devil of the deta= ils when you put it all together and realize you forgot something :-) =A0It= needs to be put to practice in real product, benchmarked, documented, test= ed, and iterated.

The first person to actually implement, rather than the= orize, will be the one who defines the next protocol. =A0If that person bor= rows mostly from SCTP or RTMFP or QUIC or something else doesn't matter= . =A0Theory is nothing - execution is everything. :-)

Mike


+10.

--
Dave T=E4ht

Fixing bufferbloat with fq_codel: http://www.bufferbloat.net= /projects/cerowrt/wiki/Bloat-videos#Dave-Taumlhts-FQ_codel-World-Tour-March= -June-2013
=20
--047d7bea3f3cc07c4404e5070c62-- From michawe@ifi.uio.no Thu Aug 29 00:36:05 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EED11E8102 for ; Thu, 29 Aug 2013 00:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.249 X-Spam-Level: X-Spam-Status: No, score=-104.249 tagged_above=-999 required=5 tests=[AWL=-1.651, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnCCMwWl4jHN for ; Thu, 29 Aug 2013 00:35:59 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 16B4411E80FD for ; Thu, 29 Aug 2013 00:35:58 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VEwln-0007KA-0A; Thu, 29 Aug 2013 09:35:55 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1VEwlm-0004Ex-CQ; Thu, 29 Aug 2013 09:35:54 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_2CD64289-D759-4C5D-B43B-DC7538BCA932" From: Michael Welzl In-Reply-To: Date: Thu, 29 Aug 2013 09:35:50 +0200 Message-Id: References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> <081D0F76-F4AE-42D5-B354-795BE4910D23@lurchi.franken.de> <2ADDC87F-8E20-4D7D-B0A0-20CE3DD12B81@ifi.uio.no> <07FF0072-DA3F-4E4A-9418-F2C4CF918817@ifi.uio.no> To: Scott Brim X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 15 msgs/h 5 sum rcpts/h 16 sum msgs/h 5 total rcpts 6977 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-7.4, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.4, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C012000BA447D8D0DDBDC5C1FD31CAFEDB525416 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -73 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 2779 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: "tsvwg@ietf.org" , Yoav Nir , Mike Belshe , HTTP Working Group , willchan@google.com, Michael Tuexen Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 07:36:05 -0000 --Apple-Mail=_2CD64289-D759-4C5D-B43B-DC7538BCA932 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 28. aug. 2013, at 17:52, Scott Brim wrote: > On Wed, Aug 28, 2013 at 11:34 AM, Brian Trammell = wrote: > My only concern here -- and I say this as someone who's a big fan of = the general approach of endpoints being smart in how they work around = deficiency in the network -- is that SCTP and TCP provide different = services. ... >=20 > So even if the OS handles the fallback (which it should), the = application still has to determine whether the SCTP features it wants to = use are available >=20 > Brian, this has been the case since (at least) IBM access method = assembler macros. Somehow the apps that want to do adjust, if you give = them the hooks to do so. >=20 > We don't need to make it simple for everyone, just simple for those = who want to use it. Agree 100%. But I'll also say that in fact, streams should be hidden, and so should = multihoming (all an application wants is to efficiently communicate to = the other host). As for the actual application services provided by SCTP, such as = unordered delivery and partial reliability, it seems to me that they're = semantically consistent with TCP's ordered total reliable transfer, so = the fall-back should just make things less efficient, but still correct = for what the application expects. Either way, we are, at this point, very much leaving the field that Mike = would like to stay in when he says "Theory is nothing - execution is = everything." Being an academic, as much as I do value execution, I just = can't agree that theory is nothing :-) Cheers, Michael --Apple-Mail=_2CD64289-D759-4C5D-B43B-DC7538BCA932 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Wed, Aug 28, 2013 at 11:34 AM, Brian Trammell <trammell@tik.ee.ethz.ch> wrote:
My only concern here = -- and I say this as someone who's a big fan of the general approach of = endpoints being smart in how they work around deficiency in the network = -- is that SCTP and TCP provide different services. ...

So even if the OS handles the fallback (which it should), the = application still has to determine whether the SCTP features it wants to = use are available

Brian, this has = been the case since (at least) IBM access method assembler macros. =  Somehow the apps that want to do adjust, if you give them the = hooks to do so.

We don't need to make it simple for everyone, just = simple for those who want to use = it.

Agree = 100%.

But I'll also say that in fact, streams should = be hidden, and so should multihoming (all an application wants is = to efficiently communicate to the other = host).

As for the actual application services = provided by SCTP, such as unordered delivery and partial = reliability, it seems to me that they're semantically consistent with = TCP's ordered total reliable transfer, so the fall-back should just make = things less efficient, but still correct for what the application = expects.

Either way, we are, at this point, = very much leaving the field that Mike would like to stay in when he says = "Theory is nothing - execution is everything."  Being an academic, = as much as I do value execution, I just can't agree that theory is = nothing =  :-)

Cheers,
Michael
= --Apple-Mail=_2CD64289-D759-4C5D-B43B-DC7538BCA932-- From michawe@ifi.uio.no Thu Aug 29 00:56:28 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6811E21F9EF8 for ; Thu, 29 Aug 2013 00:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.667 X-Spam-Level: X-Spam-Status: No, score=-103.667 tagged_above=-999 required=5 tests=[AWL=-2.465, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahCoEHGe-yrR for ; Thu, 29 Aug 2013 00:56:24 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 75FE921F9F9F for ; Thu, 29 Aug 2013 00:56:14 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VEx5K-0004OQ-1G; Thu, 29 Aug 2013 09:56:06 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VEx5J-00030l-06; Thu, 29 Aug 2013 09:56:05 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_E4BD343E-7173-4B0C-8A2E-FB027203F05D" From: Michael Welzl In-Reply-To: Date: Thu, 29 Aug 2013 09:56:04 +0200 Message-Id: <13D8A8EF-8A59-44B1-A5F3-40CAD2C330C4@ifi.uio.no> References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> <081D0F76-F4AE-42D5-B354-795BE4910D23@lurchi.franken.de> <2ADDC87F-8E20-4D7D-B0A0-20CE3DD12B81@ifi.uio.no> <07FF0072-DA3F-4E4A-9418-F2C4CF918817@ifi.uio.no> To: willchan@google.com X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 21 msgs/h 6 sum rcpts/h 22 sum msgs/h 6 total rcpts 6983 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-7.4, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-2.4, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B1CA89C7340D15DD473CCA9909A7057CB0F708AA X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -73 maxlevel 80 minaction 2 bait 0 mail/h: 6 total 2780 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: Michael Tuexen , "tsvwg@ietf.org" , Yoav Nir , Mike Belshe , HTTP Working Group Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 07:56:28 -0000 --Apple-Mail=_E4BD343E-7173-4B0C-8A2E-FB027203F05D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 28. aug. 2013, at 15:34, William Chan (=E9=99=88=E6=99=BA=E6=98=8C) = wrote: > On Wed, Aug 28, 2013 at 7:53 PM, Michael Welzl = wrote: >=20 > On 28. aug. 2013, at 11:53, William Chan (=E9=99=88=E6=99=BA=E6=98=8C) = wrote: >=20 >> On Aug 28, 2013 4:01 PM, "Michael Welzl" wrote: >> > >> > Hi, >> > >> > I agree 100% with Michael Tuexen here... just one thing, in line: >> > >> > >> >>> You're right, SCTP is non-deployable, which makes it a = non-starter. SCTP also does not address handshake issues or TLS issues. >> >> >> >> I agree that SCTP over IP can't be deployed now due to missing NAT = support. >> > >> > >> > Indeed that's not an argument against SCTP/UDP/IP, but I also = wonder why, instead of saying "can't be deployed", people don't just go = ahead and use it whenever it's there and works, with a fall-back to TCP? = This could be done with (this version of) Happy Eyeballs: >> > http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02 >> > >> > Good reasons against doing this are... what? Anyone? >>=20 >> Implementation usefulness. Why bother adding code that barely gets = used (and that is unlikely to improve in the near future), adds = complexity, code bloat, etc...? >>=20 >=20 > Fair point. That's why I think the OS should in fact do Happy Eyeballs = for you! >=20 >=20 > I'm not sure if you're trolling me. In case you aren't, you may want = to look at the graph at: = http://gs.statcounter.com/#os-ww-monthly-201207-201307. Windows XP = (released in 2001) is still around 20% of browser usage. If you have the = ability to get Microsoft to backport SCTP/IP onto their XP stack, I'd = love to know. We're not going to ignore large segments of our user base = when we could use UDP and deploy for all relevant OSes. That may be = acceptable for some applications, but not for the browser I work on. I'm not trolling you. So, first, I think we all agree that SCTP over UDP could be a useful = approach anyway, and indeed maybe that could be the long-term path = towards wider OS-level deployment. Imagine we had SCTP-over-UDP used by = browsers all the time, this might be an argument for putting it in the = OS. The way things are now, OS folks won't do it cause applications = don't use it, and vice versa. Having a multitude of application-specific = solutions over UDP that all pretty much do the same things as SCTP = doesn't help that, I don't imagine that QUIC et al are going to end up = in the OS at some point. Why is it even so important that things would be in the OS and not in = user space? I don't know, maybe it isn't... I figure that some timing = things could be done better, but maybe it really doesn't matter much. So = yes, SCTP over UDP sounds like the way to go for me. But just to explain my argument: for Happy Eyeballs with OS-level SCTP, = my point was that one could use OS-level SCTP whenever it's there. When = it's not, do the UDP thing. Yes it's more complicated than simply going = for the over-UDP solution at all times, and may not be worth it (are = there numbers showing that OS-level SCTP is better than userspace SCTP?) = - I'm just trying to explain what I had in mind. Anyway, when I wrote "the OS should do it for you", I was thinking about = something quite different, and not a recommendation for what you put in = your browser at all. Never mind. >=20 > This is why Roberto said: > """ > Wide, "safe" deployment > """ >> SCTP/UDP has a much higher likelihood of usefulness. But as Roberto = has mentioned, it still has deficiencies, mostly around RTTs (connection = + DTLS setup). If they can be fixed, great. Let's do it. >>=20 > Why shouldn't it be possible to fix SCTP to do whatever you want? = Anyway it sounds to me like a simpler approach than building a whole new = protocol. Of course, SCTP++ isn't the nicest acronym... then again, = RTMFP isn't either, if you ask me, sounds almost like RTFM... QUIC is = great though! >=20 > I have no attachments to the protocol name or frame format or = whatever. Look at what we're doing in HTTP/2 which was inspired by SPDY = but now has undergone substantial changes. We're serious about this. As = long as the transport=20 Sorry if my statement about acronyms rubbed you the wrong way, I was = only trying to be a bit ironic here. What I mean is: SCTP seems to do a = lot of the things that RTMFP or QUIC are meant to do. Rather than = re-inventing the wheel over and over again, it might be better to have a = discussion in tsvwg about what you guys think is missing in SCTP and = seeing how it could be fixed. I understand that speed of deployment is a key issue here, and trying to = update SCTP in the IETF according to your wishes may take too long, but = then just extending the code as you want might have been an even faster = solution?! Well that doesn't matter and is of course your decision alone = - either way, it's probably worth to look at the requirements addressed = by RTMFP and QUIC, and not addressed by SCTP, and then discuss if or in = which way SCTP should be extended. > provides all the features we need, we'll use it. This conversation got = started because tsvwg asked httpbis what the application layer wants = from the transport. We're telling you. I think the constructive next = step is for tsvwg folks to ask for clarification on any requirement they = don't understand, discuss whether or not the requirements are = reasonable, and discuss what may need to be done to address them. Yes, absolutely. Cheers, Michael --Apple-Mail=_E4BD343E-7173-4B0C-8A2E-FB027203F05D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Wed, Aug 28, 2013 at 7:53 PM, Michael = Welzl <michawe@ifi.uio.no> = wrote:

On 28. aug. 2013, at 11:53, William Chan (=E9=99=88=E6=99=BA=E6=98=8C= ) wrote:

On Aug 28, = 2013 4:01 PM, "Michael Welzl" <michawe@ifi.uio.no> wrote:
>
> Hi,
>
> I agree 100% with Michael Tuexen here... just one thing, in = line:
>
>
>>> You're right, SCTP is non-deployable, which makes it a = non-starter.  SCTP also does not address handshake issues or TLS = issues.
>>
>> I agree that SCTP over IP can't be deployed now due to missing = NAT support.
>
>
> Indeed that's not an argument against SCTP/UDP/IP, but I also = wonder why, instead of saying "can't be deployed", people don't just go = ahead and use it whenever it's there and works, with a fall-back to TCP? = This could be done with (this version of) Happy Eyeballs:
> http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeball= s-sctp-02
>
> Good reasons against doing this are... what? Anyone?

Implementation usefulness. Why bother adding code that = barely gets used (and that is unlikely to improve in the near future), = adds complexity, code bloat, etc...?

Fair point. That's why I think the OS should in = fact do Happy Eyeballs for you!


I'm = not sure if you're trolling me. In case you aren't, you may want to look = at the graph at: http://gs.= statcounter.com/#os-ww-monthly-201207-201307. Windows XP (released = in 2001) is still around 20% of browser usage. If you have the ability = to get Microsoft to backport SCTP/IP onto their XP stack, I'd love to = know. We're not going to ignore large segments of our user base when we = could use UDP and deploy for all relevant OSes. That may be acceptable = for some applications, but not for the browser I work = on.

I'm not trolling = you.

So, first, I think we all agree that SCTP = over UDP could be a useful approach anyway, and indeed maybe that could = be the long-term path towards wider OS-level deployment. Imagine we had = SCTP-over-UDP used by browsers all the time, this might be an argument = for putting it in the OS. The way things are now, OS folks won't do it = cause applications don't use it, and vice versa. Having a multitude of = application-specific solutions over UDP that all pretty much do the same = things as SCTP doesn't help that, I don't imagine that QUIC et al are = going to end up in the OS at some point.

Why is = it even so important that things would be in the OS and not in user = space? I don't know, maybe it isn't... I figure that some timing things = could be done better, but maybe it really doesn't matter much. So yes, = SCTP over UDP sounds like the way to go for = me.

But just to explain my argument: for Happy = Eyeballs with OS-level SCTP, my point was that one could use OS-level = SCTP whenever it's there. When it's not, do the UDP thing. Yes it's more = complicated than simply going for the over-UDP solution at all times, = and may not be worth it (are there numbers showing that OS-level SCTP is = better than userspace SCTP?) - I'm just trying to explain what I had in = mind.

Anyway, when I wrote "the OS should do it = for you", I was thinking about something quite different, and not a = recommendation for what you put in your browser at all. Never = mind.



This is why Roberto = said:
"""
Wide, "safe" = deployment
"""

SCTP/UDP has a much higher likelihood of = usefulness. But as Roberto has mentioned, it still has deficiencies, = mostly around RTTs (connection + DTLS setup). If they can be fixed, = great. Let's do it.

Why shouldn't it be possible to fix SCTP to do = whatever you want? Anyway it sounds to me like a simpler approach than = building a whole new protocol. Of course, SCTP++ isn't the nicest = acronym...  then again, RTMFP isn't either, if you ask me, sounds = almost like RTFM...  QUIC is great though!

I have no attachments to the protocol = name or frame format or whatever. Look at what we're doing in HTTP/2 = which was inspired by SPDY but now has undergone substantial changes. = We're serious about this. As long as the = transport 

Sorry if my = statement about acronyms rubbed you the wrong way, I was only trying to = be a bit ironic here. What I mean is: SCTP seems to do a lot of the = things that RTMFP or QUIC are meant to do. Rather than re-inventing the = wheel over and over again, it might be better to have a discussion in = tsvwg about what you guys think is missing in SCTP and seeing how it = could be fixed.

I understand that speed of = deployment is a key issue here, and trying to update SCTP in the IETF = according to your wishes may take too long, but then just extending the = code as you want might have been an even faster solution?! Well that = doesn't matter and is of course your decision alone - either way, it's = probably worth to look at the requirements addressed by RTMFP and QUIC, = and not addressed by SCTP, and then discuss if or in which way SCTP = should be = extended.


provides all the features we need, we'll use = it. This conversation got started because tsvwg asked httpbis what the = application layer wants from the transport. We're telling you. I think = the constructive next step is for tsvwg folks to ask for clarification = on any requirement they don't understand, discuss whether or not the = requirements are reasonable, and discuss what may need to be done to = address them.

<= div>Yes, = absolutely.


Cheers,
Mich= ael

= --Apple-Mail=_E4BD343E-7173-4B0C-8A2E-FB027203F05D-- From Michael.Tuexen@lurchi.franken.de Thu Aug 29 08:40:25 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA87C21F970E for ; Thu, 29 Aug 2013 08:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLon5+Gafz8z for ; Thu, 29 Aug 2013 08:40:24 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 08FA921F969F for ; Thu, 29 Aug 2013 08:40:23 -0700 (PDT) Received: from [192.168.1.100] (p508F3585.dip0.t-ipconnect.de [80.143.53.133]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id D91921C0C0692; Thu, 29 Aug 2013 17:40:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Tuexen In-Reply-To: Date: Thu, 29 Aug 2013 17:40:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <99A2CD4D-D250-442C-A242-5693BD4F0F53@lurchi.franken.de> References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> <081D0F76-F4AE-42D5-B354-795BE4910D23@lurchi.franken.de> <2ADDC87F-8E20-4D7D-B0A0-20CE3DD12B81@ifi.uio.no> <07FF0072-DA3F-4E4A-9418-F2C4CF918817@ifi.uio.no> <13D8A8EF-8A59-44B1-A5F3-40CAD2C330C4@ifi.uio.no> To: Mike Belshe X-Mailer: Apple Mail (2.1508) Cc: "tsvwg@ietf.org" , Yoav Nir , HTTP Working Group , Michael Welzl , William Chan Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 15:40:25 -0000 On Aug 29, 2013, at 4:36 PM, Mike Belshe wrote: >=20 >=20 >=20 > On Thu, Aug 29, 2013 at 12:56 AM, Michael Welzl = wrote: >=20 > On 28. aug. 2013, at 15:34, William Chan (=E9=99=88=E6=99=BA=E6=98=8C) = wrote: >=20 >> On Wed, Aug 28, 2013 at 7:53 PM, Michael Welzl = wrote: >>=20 >> On 28. aug. 2013, at 11:53, William Chan (=E9=99=88=E6=99=BA=E6=98=8C) = wrote: >>=20 >>> On Aug 28, 2013 4:01 PM, "Michael Welzl" wrote: >>> > >>> > Hi, >>> > >>> > I agree 100% with Michael Tuexen here... just one thing, in line: >>> > >>> > >>> >>> You're right, SCTP is non-deployable, which makes it a = non-starter. SCTP also does not address handshake issues or TLS issues. >>> >> >>> >> I agree that SCTP over IP can't be deployed now due to missing = NAT support. >>> > >>> > >>> > Indeed that's not an argument against SCTP/UDP/IP, but I also = wonder why, instead of saying "can't be deployed", people don't just go = ahead and use it whenever it's there and works, with a fall-back to TCP? = This could be done with (this version of) Happy Eyeballs: >>> > http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02 >>> > >>> > Good reasons against doing this are... what? Anyone? >>>=20 >>> Implementation usefulness. Why bother adding code that barely gets = used (and that is unlikely to improve in the near future), adds = complexity, code bloat, etc...? >>>=20 >> Fair point. That's why I think the OS should in fact do Happy = Eyeballs for you! >>=20 >>=20 >> I'm not sure if you're trolling me. In case you aren't, you may want = to look at the graph at: = http://gs.statcounter.com/#os-ww-monthly-201207-201307. Windows XP = (released in 2001) is still around 20% of browser usage. If you have the = ability to get Microsoft to backport SCTP/IP onto their XP stack, I'd = love to know. We're not going to ignore large segments of our user base = when we could use UDP and deploy for all relevant OSes. That may be = acceptable for some applications, but not for the browser I work on. >=20 > I'm not trolling you. >=20 > So, first, I think we all agree that SCTP over UDP could be a useful = approach anyway, and indeed maybe that could be the long-term path = towards wider OS-level deployment. Imagine we had SCTP-over-UDP used by = browsers all the time, this might be an argument for putting it in the = OS. The way things are now, OS folks won't do it cause applications = don't use it, and vice versa. Having a multitude of application-specific = solutions over UDP that all pretty much do the same things as SCTP = doesn't help that, I don't imagine that QUIC et al are going to end up = in the OS at some point. >=20 > Why is it even so important that things would be in the OS and not in = user space? I don't know, maybe it isn't... I figure that some timing = things could be done better, but maybe it really doesn't matter much. So = yes, SCTP over UDP sounds like the way to go for me. >=20 > But just to explain my argument: for Happy Eyeballs with OS-level = SCTP, my point was that one could use OS-level SCTP whenever it's there. = When it's not, do the UDP thing. Yes it's more complicated than simply = going for the over-UDP solution at all times, and may not be worth it = (are there numbers showing that OS-level SCTP is better than userspace = SCTP?) - I'm just trying to explain what I had in mind. >=20 > Anyway, when I wrote "the OS should do it for you", I was thinking = about something quite different, and not a recommendation for what you = put in your browser at all. Never mind. >=20 >=20 >=20 > I find this thread frustrating because it inadvertently replaces our = real end-user goals with technogeek protocol goals that will likely = fail: > Step 1: make broad claims that existing protocol XYZ already = solves a problem like web page loading times (even though it has never = been proven to do so) > Step 2: claim that the goal should be to deploy protocol XYZ = since it already solves the problem ("rather than reinvent the wheel") >=20 > No no no! By doing this we swapped the real goals for fake ones. The = result will be a bunch of nerds wondering why nobody is using their = glorious new protocol. Next we'll be writing a "Happy Eyeballs" style = spec to help them see the light! Look, if the protocol was so = lackluster we had to write a spec to tell people how to deploy it, we = failed to solve interesting problems. It's time to start over, not time = to keep re-brandishing the same tired old protocol. >=20 > To be clear:=20 > - OS-level deployment of any protocols is not a goal > - deployment of SCTP is not a goal > - getting SCTP into the kernel is not a goal None of this is a goal. I like to understand which = services/features/properties are considered to be useful or required by the HTTP people. Then we can = see which protocol fits best (maybe TCP, maybe TCP Minion, maybe SCTP with = extensions, maybe QUIC, maybe something which doesn't exist yet). Evaluation at this step really requires prototyping. I agree completely here. >=20 > Useful goals would be: > - making web pages load 10x faster > - making servers that scale to 1B users > - making the web accessible to more 10x people > - eliminating privacy leaks, phishing scams, etc I agree to all of them. But we have to find a way from these goals to technical features of the protocols... Best regards Michael >=20 >=20 >=20 >=20 > =20 >=20 >=20 >>=20 >> This is why Roberto said: >> """ >> Wide, "safe" deployment >> """ >>> SCTP/UDP has a much higher likelihood of usefulness. But as Roberto = has mentioned, it still has deficiencies, mostly around RTTs (connection = + DTLS setup). If they can be fixed, great. Let's do it. >>>=20 >> Why shouldn't it be possible to fix SCTP to do whatever you want? = Anyway it sounds to me like a simpler approach than building a whole new = protocol. Of course, SCTP++ isn't the nicest acronym... then again, = RTMFP isn't either, if you ask me, sounds almost like RTFM... QUIC is = great though! >>=20 >> I have no attachments to the protocol name or frame format or = whatever. Look at what we're doing in HTTP/2 which was inspired by SPDY = but now has undergone substantial changes. We're serious about this. As = long as the transport=20 >=20 > Sorry if my statement about acronyms rubbed you the wrong way, I was = only trying to be a bit ironic here. What I mean is: SCTP seems to do a = lot of the things that RTMFP or QUIC are meant to do. Rather than = re-inventing the wheel over and over again, it might be better to have a = discussion in tsvwg about what you guys think is missing in SCTP and = seeing how it could be fixed. > =20 >=20 > Wishful thinking alert! -- If it wasn't designed for a particular = goal, it likely doesn't solve that particular goal. And no, SCTP was = not designed for low-latency web transactions. >=20 > Don't let me discourage you too much, I'd love to see what you say = here turn out to be true. But if these protocols worked as you say, = they'd be deployed already. You think nobody tried HTTP over SCTP? Of = course we did! It's a marginal improvement at best, after you get past = all the complexity and bugginess of protocols that were not designed for = this purpose.=20 >=20 > I hope this doesn't come across too harsh. >=20 > Best, > Mike >=20 >=20 >=20 >=20 > =20 >=20 > I understand that speed of deployment is a key issue here, and trying = to update SCTP in the IETF according to your wishes may take too long, = but then just extending the code as you want might have been an even = faster solution?! Well that doesn't matter and is of course your = decision alone - either way, it's probably worth to look at the = requirements addressed by RTMFP and QUIC, and not addressed by SCTP, and = then discuss if or in which way SCTP should be extended. >=20 >=20 >> provides all the features we need, we'll use it. This conversation = got started because tsvwg asked httpbis what the application layer wants = from the transport. We're telling you. I think the constructive next = step is for tsvwg folks to ask for clarification on any requirement they = don't understand, discuss whether or not the requirements are = reasonable, and discuss what may need to be done to address them. >=20 > Yes, absolutely. >=20 >=20 > Cheers, > Michael >=20 >=20 From michawe@ifi.uio.no Fri Aug 30 00:29:42 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B3A11E80EE for ; Fri, 30 Aug 2013 00:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.021 X-Spam-Level: X-Spam-Status: No, score=-104.021 tagged_above=-999 required=5 tests=[AWL=-1.423, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCkAMpbR4L3W for ; Fri, 30 Aug 2013 00:29:37 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id F162E11E80E0 for ; Fri, 30 Aug 2013 00:29:36 -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 1VFJ95-00054A-Se; Fri, 30 Aug 2013 09:29:27 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VFJ95-00030A-AG; Fri, 30 Aug 2013 09:29:27 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_5209736F-7CF1-4B0D-9F82-8497533BD272" From: Michael Welzl In-Reply-To: Date: Fri, 30 Aug 2013 09:29:25 +0200 Message-Id: <40EDDD52-1461-49DA-8BD6-9A3C1FD69B90@ifi.uio.no> References: <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> <081D0F76-F4AE-42D5-B354-795BE4910D23@lurchi.franken.de> <2ADDC87F-8E20-4D7D-B0A0-20CE3DD12B81@ifi.uio.no> <07FF0072-DA3F-4E4A-9418-F2C4CF918817@ifi.uio.no> <13D8A8EF-8A59-44B1-A5F3-40CAD2C330C4@ifi.uio.no> To: Mike Belshe X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 7 sum msgs/h 2 total rcpts 7020 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-7.4, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.4, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A8CE95B0C890F12082A2F15E108D293769A5FEF9 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -73 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 2795 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: Michael Tuexen , "tsvwg@ietf.org" , Yoav Nir , HTTP Working Group , William Chan Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 07:29:42 -0000 --Apple-Mail=_5209736F-7CF1-4B0D-9F82-8497533BD272 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > Wishful thinking alert! -- If it wasn't designed for a particular = goal, it likely doesn't solve that particular goal. And no, SCTP was = not designed for low-latency web transactions. Low-latency signaling messages (which it was designed for) don't strike = me as being extremely different from low-latency web transactions... = well, maybe the devil is in the detail. > Don't let me discourage you too much, I'd love to see what you say = here turn out to be true. But if these protocols worked as you say, = they'd be deployed already. You think nobody tried HTTP over SCTP? Of = course we did! It's a Just curious, which implementation did you test? This group had posted pretty good results achieved with HTTP over SCTP = long ago: http://www.eecis.udel.edu/~amer/PEL/index.html - although the only paper I can dig up from their page about this now is = this one: = http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SIGCOMM-NSDR2008-NatarajanMult= istreamed-transport-developing-regions.pdf and now their page mentions a "SPDY over SCTP project supported by = Google". So are you saying that the outcome of this project is = disappointing already? > marginal improvement at best, after you get past all the complexity = and bugginess of protocols that were not designed for this purpose.=20 >=20 > I hope this doesn't come across too harsh. No it doesn't - it's interesting and makes me want to dig deeper into = QUIC and RTFMP to better understand what makes it perform so much better = than SCTP. ( I figured that multi-streaming at the transport layer would be the big = win, and since SCTP already gives you that, well... though I did notice = the mention of e.g. lack of per-stream flow control in SCTP, which I = also found to be a problem long ago... I had thought that this might = have been fixed by now? Shouldn't be too hard to fix. ) Cheers, Michael --Apple-Mail=_5209736F-7CF1-4B0D-9F82-8497533BD272 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Wishful thinking alert!  --  If it = wasn't designed for a particular goal, it likely doesn't solve that = particular goal.  And no, SCTP was not designed for low-latency web = transactions.

Low-l= atency signaling messages (which it was designed for) don't strike me as = being extremely different from low-latency web transactions... well, = maybe the devil is in the = detail.


Don't let me discourage you too much, I'd love to see what = you say here turn out to be true.  But if these protocols worked as = you say, they'd be deployed already.  You think nobody tried HTTP = over SCTP?  Of course we did!  It's = a

Just curious, which = implementation did you test?
This group had posted pretty good = results achieved with HTTP over SCTP long ago:
- although the only paper I = can dig up from their page about this now is this one:

and now their page = mentions a "SPDY over SCTP project supported by Google". So are you = saying that the outcome of this project is disappointing = already?


= marginal improvement at best, after you get past all the complexity and = bugginess of protocols that were not designed for this = purpose. 

I hope this doesn't come across too = harsh.

No it doesn't = - it's interesting and makes me want to dig deeper into QUIC and RTFMP = to better understand what makes it perform so much better than = SCTP.

( I figured that multi-streaming at the = transport layer would be the big win, and since SCTP already gives you = that, well...  though I did notice the mention of e.g. lack of = per-stream flow control in SCTP, which I also found to be a problem long = ago... I had thought that this might have been fixed by now? Shouldn't = be too hard to fix. = )

Cheers,
Michael

<= /div>= --Apple-Mail=_5209736F-7CF1-4B0D-9F82-8497533BD272--