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

On Aug 29, 2013, at 4:36 PM, Mike Belshe <mike@belshe.com> wrote:

> 
> 
> 
> On Thu, Aug 29, 2013 at 12:56 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
> 
> On 28. aug. 2013, at 15:34, William Chan (陈智昌) wrote:
> 
>> On Wed, Aug 28, 2013 at 7:53 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
>> 
>> On 28. aug. 2013, at 11:53, William Chan (陈智昌) wrote:
>> 
>>> On Aug 28, 2013 4:01 PM, "Michael Welzl" <michawe@ifi.uio.no> wrote:
>>> >
>>> > Hi,
>>> >
>>> > I agree 100% with Michael Tuexen here... just one thing, in line:
>>> >
>>> >
>>> >>> You're right, SCTP is non-deployable, which makes it a non-starter.  SCTP also does not address handshake issues or TLS issues.
>>> >>
>>> >> I agree that SCTP over IP can't be deployed now due to missing NAT support.
>>> >
>>> >
>>> > Indeed that's not an argument against SCTP/UDP/IP, but I also wonder why, instead of saying "can't be deployed", people don't just go ahead and use it whenever it's there and works, with a fall-back to TCP? This could be done with (this version of) Happy Eyeballs:
>>> > http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02
>>> >
>>> > Good reasons against doing this are... what? Anyone?
>>> 
>>> Implementation usefulness. Why bother adding code that barely gets used (and that is unlikely to improve in the near future), adds complexity, code bloat, etc...?
>>> 
>> Fair point. That's why I think the OS should in fact do Happy Eyeballs for you!
>> 
>> 
>> I'm not sure if you're trolling me. In case you aren't, you may want to look at the graph at: http://gs.statcounter.com/#os-ww-monthly-201207-201307. Windows XP (released in 2001) is still around 20% of browser usage. If you have the ability to get Microsoft to backport SCTP/IP onto their XP stack, I'd love to know. We're not going to ignore large segments of our user base when we could use UDP and deploy for all relevant OSes. That may be acceptable for some applications, but not for the browser I work on.
> 
> I'm not trolling you.
> 
> So, first, I think we all agree that SCTP over UDP could be a useful approach anyway, and indeed maybe that could be the long-term path towards wider OS-level deployment. Imagine we had SCTP-over-UDP used by browsers all the time, this might be an argument for putting it in the OS. The way things are now, OS folks won't do it cause applications don't use it, and vice versa. Having a multitude of application-specific solutions over UDP that all pretty much do the same things as SCTP doesn't help that, I don't imagine that QUIC et al are going to end up in the OS at some point.
> 
> Why is it even so important that things would be in the OS and not in user space? I don't know, maybe it isn't... I figure that some timing things could be done better, but maybe it really doesn't matter much. So yes, SCTP over UDP sounds like the way to go for me.
> 
> But just to explain my argument: for Happy Eyeballs with OS-level SCTP, my point was that one could use OS-level SCTP whenever it's there. When it's not, do the UDP thing. Yes it's more complicated than simply going for the over-UDP solution at all times, and may not be worth it (are there numbers showing that OS-level SCTP is better than userspace SCTP?) - I'm just trying to explain what I had in mind.
> 
> Anyway, when I wrote "the OS should do it for you", I was thinking about something quite different, and not a recommendation for what you put in your browser at all. Never mind.
> 
> 
> 
> I find this thread frustrating because it inadvertently replaces our real end-user goals with technogeek protocol goals that will likely fail:
>     Step 1:  make broad claims that existing protocol XYZ already solves a problem like web page loading times  (even though it has never been proven to do so)
>     Step 2:  claim that the goal should be to deploy protocol XYZ since it already solves the problem ("rather than reinvent the wheel")
> 
> No no no!  By doing this we swapped the real goals for fake ones.  The result will be a bunch of nerds wondering why nobody is using their glorious new protocol.  Next we'll be writing a "Happy Eyeballs" style spec to help them see the light!   Look, if the protocol was so lackluster we had to write a spec to tell people how to deploy it, we failed to solve interesting problems.  It's time to start over, not time to keep re-brandishing the same tired old protocol.
> 
> To be clear: 
>     - OS-level deployment of any protocols is not a goal
>     - deployment of SCTP is not a goal
>     - getting SCTP into the kernel is not a goal
None of this is a goal. I like to understand which services/features/properties
are considered to be useful or required by the HTTP people. Then we can see
which protocol fits best (maybe TCP, maybe TCP Minion, maybe SCTP with extensions,
maybe QUIC, maybe something which doesn't exist yet). Evaluation at this
step really requires prototyping. I agree completely here.
> 
> Useful goals would be:
>       - making web pages load 10x faster
>       - making servers that scale to 1B users
>       - making the web accessible to more 10x people
>       - eliminating privacy leaks, phishing scams, etc
I agree to all of them. But we have to find a way from these goals to
technical features of the protocols...

Best regards
Michael
> 
> 
> 
> 
>  
> 
> 
>> 
>> This is why Roberto said:
>> """
>> Wide, "safe" deployment
>> """
>>> SCTP/UDP has a much higher likelihood of usefulness. But as Roberto has mentioned, it still has deficiencies, mostly around RTTs (connection + DTLS setup). If they can be fixed, great. Let's do it.
>>> 
>> Why shouldn't it be possible to fix SCTP to do whatever you want? Anyway it sounds to me like a simpler approach than building a whole new protocol. Of course, SCTP++ isn't the nicest acronym...  then again, RTMFP isn't either, if you ask me, sounds almost like RTFM...  QUIC is great though!
>> 
>> I have no attachments to the protocol name or frame format or whatever. Look at what we're doing in HTTP/2 which was inspired by SPDY but now has undergone substantial changes. We're serious about this. As long as the transport 
> 
> Sorry if my statement about acronyms rubbed you the wrong way, I was only trying to be a bit ironic here. What I mean is: SCTP seems to do a lot of the things that RTMFP or QUIC are meant to do. Rather than re-inventing the wheel over and over again, it might be better to have a discussion in tsvwg about what you guys think is missing in SCTP and seeing how it could be fixed.
>  
> 
> Wishful thinking alert!  --  If it wasn't designed for a particular goal, it likely doesn't solve that particular goal.  And no, SCTP was not designed for low-latency web transactions.
> 
> Don't let me discourage you too much, I'd love to see what you say here turn out to be true.  But if these protocols worked as you say, they'd be deployed already.  You think nobody tried HTTP over SCTP?  Of course we did!  It's a marginal improvement at best, after you get past all the complexity and bugginess of protocols that were not designed for this purpose. 
> 
> I hope this doesn't come across too harsh.
> 
> Best,
> Mike
> 
> 
> 
> 
>  
> 
> I understand that speed of deployment is a key issue here, and trying to update SCTP in the IETF according to your wishes may take too long, but then just extending the code as you want might have been an even faster solution?! Well that doesn't matter and is of course your decision alone - either way, it's probably worth to look at the requirements addressed by RTMFP and QUIC, and not addressed by SCTP, and then discuss if or in which way SCTP should be extended.
> 
> 
>> provides all the features we need, we'll use it. This conversation got started because tsvwg asked httpbis what the application layer wants from the transport. We're telling you. I think the constructive next step is for tsvwg folks to ask for clarification on any requirement they don't understand, discuss whether or not the requirements are reasonable, and discuss what may need to be done to address them.
> 
> Yes, absolutely.
> 
> 
> Cheers,
> Michael
> 
>

Received on Thursday, 29 August 2013 15:40:46 UTC