Re: Encouraging a healthy HTTP/2 ecosystem

On Wed, Jul 2, 2014 at 12:48 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>
wrote:

> In message <
> CAA4WUYimAsnSxGcHS4hedxrazxCJG25t4OhCiQT6ujOZ9eKVJQ@mail.gmail.com>,
> =?UTF-8?B?V2lsbGlhbSBDaGF
> uICjpmYjmmbrmmIwp?= writes:
>
> >> A bad analogy is like a wet screwdriver:  TCP options are not
> >> information carrying (unless you're truly evil that is...)
> >
> >I'm confused. I don't understand why you think this is a bad analogy. What
> >information can a HTTP/2 extension carry that a TCP option can't?
>
> Pretty much any kind of contraband a filtering proxy might be
> installed to stop ?
>
> (Further: Very few people are able to add a new TCP option to their
> outgoing packets.  Everybody can add a new HTTP/2 extension simply
> by downloading a program, but yes, I do know about the IP-over-TCP-OPTIONS
> hack, and it is very relevant to this discussion.)
>
> >We're doing multiplexing in the application layer
> >since we've been unable to deploy multiplexing at a lower layer.
>
> We have never really tried to deploy multiplexing in the transport
> layer, we know it isn't happening on its own, but we have never
> really tried to push it.
>

Actually this is not true.  While at Google, way back when we were doing
SPDY research, we worked with the Univ of Maryland team which was doing
exactly this.  (I was the sponsot from Google that helped them attain a
research grant to help with their work)  This was the same team that put
together the RFC for how to run HTTP/1.1 over SCTP.  You're welcome to
reach out to Paul Amer, the research professor we worked with who led the
team there and get more information yourself, although facts don't seem to
be what you're generally interested in.

We would have loved for SCTP to be an answer rather than moving up the
stack, it was not practical for several reasons:
   a) no machines have SCTP stacks on them today (not windows, linux, macos
or any major mobile OS)
   b) there are two leading SCTP stack implementations, but neither has
received a ton of attention and there are a lot of bugs (simple stuff in
the handshakes even).
   c) it didn't really work that well anyway.  If you look at how multiple
streams are negotiated in sctp, you'll see its all pre-setup in an odd way.
 it can be made to 'work', but its not very good.  So given the challenges
of a & b, its actually not a good starting point.

Anyway, I'm sure you'll have a thousand reasons why this was inadequate and
doesn't count as "really trying", and I'm sure the great PHK could have
done a better job with just 3 hours of his mega brain on the problem than
the team of grad students did over the course of several years...  but
hey,I didn't know you then.


> If we can (and that's TBD of course) publish a HTTP/n running over
> SCTP which gives tangible benefits, then people would have a reason
> to make SCTP work.
>

I 100% support your doing research on this and coming back to the group
when you're done!

Mike




>
> Without a killer-app, it stays on their TODO list.
>
> Right after IPv6.
>
> And giving up without ever even trying is a looser-attitude IMO.
>
> >It sounds to me like you think [...]
>
> I think that always taking the easy path through whatever unintended
> wormholes we may be able to find is going to totally muck up any
> semblance of architecture which the internet protocols ever had.
>
> It is also a cowardly abdication as members of society, for our
> and our technologys impact on the lay person and their civil rights.
>
> If there were good (as opposed to merely "meh...") reasons for
> making TCP options, IPv6 or SCTP work, they will start working all
> by themselves, but you have to dangle at tasty carrot for it to
> happen.
>
>
> When I say:
>
> >"There are never any easy technical fixes for hard political problems."
>
> I'm not talking about TCP options, I'm talking about freedom of
> speech.  Privacy.  Protection against unreasonable search, seisure
> or monitoring.
>
> Also known as "the hard political problems".
>
> >My assertion is that this situation is unacceptable. You're right, for
> >political / compliance reasons, proxies are going to be there and do these
> >things that ossify our protocols and force us to tunnel higher up the
> stack
> >and develop way more cruft in our protocol stack.
>
> And I'm telling you:  That is neither a way to build a civilized society
> nor
> a well-functioning or -performing network.
>
> The Global War on Privacy, as carried out by governments and gigacorps
> alike
> can only be won through politics, technology will never do it, and doing
> "elastic advances" further and further up the stack is just an eupherism
> for slow defeat.
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
>