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

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 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<mailto:mike@belshe.com>> wrote:


On Tue, Aug 27, 2013 at 2:46 PM, Michael Thornburgh <mthornbu@adobe.com<mailto: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> [mailto: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<mailto: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<mailto: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<mailto:grmocg@gmail.com>]
Sent: Tuesday, August 06, 2013 11:16 AM

To: HTTP Working Group; tsvwg@ietf.org<mailto: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<mailto: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