Re: [tsvwg] The List (of application-layer desired features)

On Wed, Aug 28, 2013 at 10:41 AM, Michael Thornburgh <mthornbu@adobe.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:
> >
> >
> >       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 <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
> >
>
>