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

[Mike Belshe <[e-mail]>]

On Tue, Aug 27, 2013 at 2:46 PM, Michael Thornburgh <[e-mail]>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:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Mike Belshe
> *Sent:* Tuesday, August 06, 2013 2:31 AM
> *To:* Yoav Nir
> *Cc:* HTTP Working Group; [e-mail]
> *Subject:* Re: [tsvwg] The List (of application-layer desired features)***
> *
>
> ** **
>
> ** **
>
> ** **
>
> On Tue, Aug 6, 2013 at 10:49 AM, Yoav Nir <[e-mail]> 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:[e-mail]]
> *Sent:* Tuesday, August 06, 2013 11:16 AM****
>
>
> *To:* HTTP Working Group; [e-mail]
> *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 <[e-mail]> 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 ****
>
> ** **
>