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
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).

-=R


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

>
>
>
> 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 ****
>>
>> ** **
>>
>
>