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

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.

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

Received on Wednesday, 28 August 2013 17:42:18 UTC