- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Wed, 02 Jul 2014 19:48:53 +0000
- To: William Chan (ιζΊζ) <willchan@chromium.org>
- cc: Jason Greene <jason.greene@redhat.com>, HTTP Working Group <ietf-http-wg@w3.org>
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. 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.
Received on Wednesday, 2 July 2014 19:49:17 UTC