Re: [tsvwg] The List (of application-layer desired features)
Mike Belshe <mike@belshe.com> Tue, 27 August 2013 22:12 UTC
Return-Path: <mike@belshe.com>
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 <tsvwg@ietfa.amsl.com>; 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 <tsvwg@ietfa.amsl.com>; 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 <tsvwg@ietf.org>; Tue, 27 Aug 2013 15:12:26 -0700 (PDT)
Received: by mail-bk0-f49.google.com with SMTP id r7so1817237bkg.36 for <tsvwg@ietf.org>; 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: <D9D602D39A98E34D9C43E965BEC7439826988809@nambx08.corp.adobe.com>
References: <CAP+FsNeMqB0+igBZjjsT-Xb+17YdUyptBJ2N0x9_jaaLYzKisQ@mail.gmail.com> <CAP+FsNcvR5q3N2iLv6wM6LQXS72sg1pdvTWdU9rsSFAP8OHpwA@mail.gmail.com> <4613980CFC78314ABFD7F85CC302772111B7D710@IL-EX10.ad.checkpoint.com> <CABaLYCuom7VH+9VJrbe7-D+S7YfGtbS59ne5fG03Zrm=U5tc0Q@mail.gmail.com> <D9D602D39A98E34D9C43E965BEC7439826988809@nambx08.corp.adobe.com>
Date: Tue, 27 Aug 2013 15:12:25 -0700
Message-ID: <CABaLYCtoVJ9swP12r5foz2d6Gr1PtjuiXdBkXEeEoan+dF+XeQ@mail.gmail.com>
From: Mike Belshe <mike@belshe.com>
To: Michael Thornburgh <mthornbu@adobe.com>
Content-Type: multipart/alternative; boundary="20cf30223901ee1ac704e4f52a14"
X-Mailman-Approved-At: Wed, 28 Aug 2013 11:49:17 -0700
Cc: Yoav Nir <ynir@checkpoint.com>, HTTP Working Group <ietf-http-wg@w3.org>, "tsvwg@ietf.org" <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 <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Aug 2013 22:12:30 -0000
On Tue, Aug 27, 2013 at 2:46 PM, Michael Thornburgh <mthornbu@adobe.com>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. > **** > > ** ** > > 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. > **** > > ** ** > > 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 :-) > **** > > ** ** > > 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. 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 <ynir@checkpoint.com> 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 **** > > ** ** >
- Re: [tsvwg] The List (of application-layer desire… Scharf, Michael (Michael)
- Re: [tsvwg] The List (of application-layer desire… Roberto Peon
- Re: [tsvwg] The List (of application-layer desire… Roberto Peon
- Re: [tsvwg] The List (of application-layer desire… Mike Belshe
- Re: [tsvwg] The List (of application-layer desire… William Chan (陈智昌)
- Re: [tsvwg] The List (of application-layer desire… Michael Tuexen
- Re: [tsvwg] The List (of application-layer desire… Michael Thornburgh
- Re: [tsvwg] The List (of application-layer desire… Roberto Peon
- Re: [tsvwg] The List (of application-layer desire… Michael Welzl
- Re: [tsvwg] The List (of application-layer desire… Michael Welzl
- Re: [tsvwg] The List (of application-layer desire… Michael Tuexen
- Re: [tsvwg] The List (of application-layer desire… Michael Tuexen
- Re: [tsvwg] The List (of application-layer desire… Brian Trammell
- Re: [tsvwg] The List (of application-layer desire… Scott Brim
- Re: [tsvwg] The List (of application-layer desire… Michael Thornburgh
- Re: [tsvwg] The List (of application-layer desire… Michael Thornburgh
- Re: [tsvwg] The List (of application-layer desire… Ted Hardie
- Re: [tsvwg] The List (of application-layer desire… William Chan (陈智昌)
- Re: [tsvwg] The List (of application-layer desire… William Chan (陈智昌)
- Re: [tsvwg] The List (of application-layer desire… William Chan (陈智昌)
- Re: [tsvwg] The List (of application-layer desire… Mike Belshe
- Re: [tsvwg] The List (of application-layer desire… Mike Belshe
- Re: [tsvwg] The List (of application-layer desire… Dave Taht
- Re: [tsvwg] The List (of application-layer desire… Michael Welzl
- Re: [tsvwg] The List (of application-layer desire… Michael Welzl
- Re: [tsvwg] The List (of application-layer desire… Michael Tuexen
- Re: [tsvwg] The List (of application-layer desire… Michael Welzl
- Re: [tsvwg] The List (of application-layer desire… Joe Touch
- Re: [tsvwg] The List (of application-layer desire… Roberto Peon
- Re: [tsvwg] The List (of application-layer desire… Stephen Farrell
- Re: [tsvwg] The List (of application-layer desire… Roberto Peon
- Re: [tsvwg] The List (of application-layer desire… Joe Touch
- Re: [tsvwg] The List (of application-layer desire… Roberto Peon
- Re: [tsvwg] The List (of application-layer desire… Yuchung Cheng
- Re: [tsvwg] The List (of application-layer desire… Joe Touch
- Re: [tsvwg] The List (of application-layer desire… Yuchung Cheng
- Re: [tsvwg] The List (of application-layer desire… Joe Touch
- Re: [tsvwg] The List (of application-layer desire… Michael Tuexen
- Re: [tsvwg] The List (of application-layer desire… Roberto Peon
- Re: [tsvwg] The List (of application-layer desire… Michael Tuexen
- Re: [tsvwg] The List (of application-layer desire… Michael Tuexen
- Re: [tsvwg] The List (of application-layer desire… Joe Touch
- Re: [tsvwg] The List (of application-layer desire… Roberto Peon
- Re: [tsvwg] The List (of application-layer desire… Joe Touch
- Re: [tsvwg] The List (of application-layer desire… Joe Touch
- Re: [tsvwg] The List (of application-layer desire… Michael Tuexen
- Re: [tsvwg] The List (of application-layer desire… Michael Welzl
- Re: [tsvwg] The List (of application-layer desire… Michael Welzl
- Re: [tsvwg] The List (of application-layer desire… Nico Williams
- Re: [tsvwg] The List (of application-layer desire… Nico Williams
- Re: [tsvwg] The List (of application-layer desire… Joe Touch
- Re: [tsvwg] The List (of application-layer desire… Joe Touch
- Re: [tsvwg] The List (of application-layer desire… Michael Welzl
- Re: [tsvwg] The List (of application-layer desire… Nico Williams
- Re: [tsvwg] The List (of application-layer desire… Joe Touch