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

I don't understand this statement. A TCP option can carry the same
"contraband", right?


>
> (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.)
>

I think this is the critical distinction. You are more concerned about
extensibility within a protocol that is typically implemented in user space
(HTTP/2), as opposed to a protocol that is typically implemented in kernel
space (TCP). Is that it? If so, I think that's a reasonable distinction to
highlight.


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