W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

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

From: Michael Thornburgh <mthornbu@adobe.com>
Date: Tue, 27 Aug 2013 14:46:01 -0700
To: Mike Belshe <mike@belshe.com>, Yoav Nir <ynir@checkpoint.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Message-ID: <D9D602D39A98E34D9C43E965BEC7439826988809@nambx08.corp.adobe.com>
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.

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.

  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.

  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.

  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.

-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<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
Received on Tuesday, 27 August 2013 21:46:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:15 UTC