Re: [hybi] New port and Tunneling?

["Shelby Moore" <[e-mail]>]

> On Sun, Aug 15, 2010 at 08:24:44PM -0400, Shelby Moore wrote:
>> My point is that at least port+tunnel will work on the more widespread
>> use
>> cases outside the enterprise, probably as often than HTTP Upgrade on
>> port
>> 80 will and with better hard fail and better performance (less quirks
>> after tunnel succeeds).
>
> Noone said otherwise.

Was he aware of the new technique (emulating traceroute) in the links I
provided in the first post that started this thread, and could that change
his analysis?

> But if you're only focusing on the easiest problems
> to solve only one part of the problem, then we don't need a new protocol.

I am focusing on finding the solution that will work in the most number of
cases, so we fall back less often.  I don't understand why you say we
don't need a new protocol.


>> Lets think outside the Enterprise please, where the big prize is.
>> Enterprise is going to always be a least common denominator, e.g.
>> Comet/BOSH perhaps.

Perhaps I should have noted that WS/HTTP might be acceptable to the
enterprise, if WS/HTTP can be reliable and efficient.  From my prior 2
posts, I am doubting whether it can be significantly more reliable and
efficent than Comet/BOSH, but still waiting for the conclusion of that
sharing of ideas.

>>  Enterprise will die any way (the future is already
>> moving away from that slavery over here).
>
> Please, stop using the list to relay your political opinions.

I have intended no animosity towards you whatsoever.  Also I forgot to
mention in the prior post that I appreciated you explaining the rational
for the Connection: close.  I have had several lapses in the way I have
worded my emails that may have incorrectly sounded like I was admonishing
you and I assure you I was not. I am searching for the facts only. Thank
you so much for sharing your expertise.

LIST FEEL FREE TO IGNORE SOME OF THE FOLLOWING ASBSTRACT PARAGRAPHS, more
focused technical issue debate resumes futher down this post.

I am stating what I understand to be mathematical fact of entropy. I
believe in mathematical truth, which is that entropy is always driving
towards more independent actors at the expense of centralized control
(albeit with exponential local order growth and decay S curves along the
way).

I have 0 political opinions (don't try to get my way by ganging up in a
group). I never vote (authorize my opinion to be used to gang up against
others), and you are correct above that I don't really have a preference
to what this group decides (if we get a new protocol or not), I am only
here to foster information dispersal (as it will help me learn which
architecture is best for my own plans). Ultimately the market will do what
it is going to do.  But that doesn't mean I don't care about all of you
and I don't want to help you get a great spec.  It just means I am not
invested in that outcome (because mathematically I understand that that
group decisions are just local order on the big trend towards disorder).

Philosophy based in math is a form of technical analysis, but it is very
abstract and broad stroke and most people don't agree with the relevance,
until it hits them in face and even then, they don't recognize it as
entropy in action.  Failure to understand the exponential function is why
humans are destined to repeat the same errors over and over again.

> Also, such
> unthought and childish comments totally discredits your technical
> analysis.
> I'll put that on the lack of sleep.

You are free to characterize broad mathematical understanding as
unthought, childish, and non-technical. Thank you for expressing your
opinion. It is a free market. I intend you no harm, only sharing what I
believe to be the facts.

>
>> >> You might as well just hack the browser, so then you need to close
>> port
>> >> 80 too.
>> >
>> > No, because when the browser can only get out via the proxy, it does
>> not
>> > have access to port 80 itself, otherwise it would be pointless to
>> install
>> > filtering devices !
>>
>> Okay I understand your point now which is that HTTP is filtered and
>> another port is not unless the proxy understands the spec.  But SSL is
>> not
>> filterable because the proxy can't see the unencrypted data, so block
>> all
>> secure ecommerce and personal privacy?
>
> No, just leave open a list of known good sites. But if your site uses SSL
> and
> is not in the list, it cannot be reached from those points. There's a
> reason
> Yahoo Mail still supports HTTP. At some places it's the only option.

I am free to characterize that mathematically as blocking port 80 for all
free people who won't sign (implicitly) a futures contract, unfreedom, and
slippery slope towards complete failure.  It is not a political analysis,
rather a mathematical one. I already presented the applicable famous
computer language theorems. I doubt it is worthwhile to go deeper into my
reasoning, as most people won't agree and thus it is more efficient to
just let the market prove it. I am not going to try to troll my wall into
getting others to accept my understanding. I am maybe interested to say no
more on that point if I am not challenged to do so (but that could mean
withdrawing from useful debate, so I can not promise).

>
>> I think it is pointless to install filtering devices if you depend on
>> them
>> for security.
>
> This statement makes no sense at all.

Makes sense to me because I understand mathematically that centralized
security is an illusion/oxymoron. It mathematically forces non-use. When
humans can not control something, they make a law and pretend they can,
which results in putting people in jails for that which can not be stopped
because it is mathematically natural. We are already down to the level of
blocking most freedom on port 80 and blocking all other ports and
innovation (at least in the enterprise slavery zone, which mathematically
must decay eventually and probably already has peaked).

> You could as well push the reasoning
> further "it's pointless to install this or that operating system and
> applications because they're the most targetted by malware and using them
> will require filtering devices". Then "it's pointless to try to be
> interoperable with our customers because that will required an OS which is
> targetted by malware".

That shows you ignored or did not understand what I meant by the "big
epipheny" I mentioned in HTTP Compliance thread.

There is a big difference between adding features and requiring the
natural law to not apply to them.

Rather I have said if stop assuming we can control that which can not be
controlled, and give ourselves a reset button, then that is the most
entropy directed.  Nature will constantly do creative destruction, stand
in its way at your peril.

>
>> Kills anonymity, privacy, thus free speech.  And especially critical in
>> this epoch ahead of us.
>
> Once you've said that, it does not change what we have to deal with.

It does if a significant and exponentially growing portion of the world
does not try to filter the internet.  I will give you an example. 
Westerners are very concerned about maintaining control over their online
accounts. Asians just walk away from an account and create another free
one.  They often have innumerable accounts.  They don't try to hold on or
enforce unnatural order.  That is the fundamental underlying reason why
facebook gets its butt kicked in China.  They don't understand that Asians
have different philosophy on what can and should be controlled and how to
deal with the march of entropy.  And even more so in the tropical islands
as compared to the Taoist cultures, where filipinos do almost everything
without planning and completely haphazardly without any attempt to control
and direct their lives.

>
>> Also I expect that HTTP over port 80 will become so well attacked (from
>> the application state machines) that will have to close port 80
>> eventually.
>
> I don't buy that a second.

You just stated the for SSL (privacy and freedom) that is already
effectively the case.  A whitelist is not freedom.  A blacklist is evil
enough.

> It's probably the most well mastered protocol
> and it has the advantage to support cleaning devices that work at insane
> speeds, and thus are very cheap.

Great point about efficiency, and I should never argue against efficiency.
But that local efficiency is only efficient for global free market
perspective, in those cases where it is supplementing freedom, not
destroying it. Impinging on the free market causes a mis-allocation of
human capital, which is domino effect of inefficiency (even though might
get a local measure of great efficiency...correlate that to local order S
curves in progression of entropy).

> In fact it's even the opposite. It's so
> much exposed and attacked that it quickly had to become robust.

I differentiate between robustness of the protocol for freedom and the
mis-use of proxies to curtail freedom.  No argument on the former.

> It's as
> if you said that Ethernet had so many collisions that it would never
> succeed... In fact it succeeded precisely because it was designed to work
> in harsh environments.

No argument there, as far as I know Ethernet does not restrict any freedom
of the market.

>
> (... rant ...)
>> Proxies should only be used to add capability, not restrict it.
>
> Adding the ability to surf on the web without your browser being hijacked
> by ads popups and various keyloggers is a capability.

But I the user am free to configure that. Do you know how many times I
need to turn that off to get useful work done in my dating site research?

I can not turn off the filtering that my ISP is doing.  When I registered
asiadear.com, they cached the old nameservers for like a week!  Argh!  I
couldn't do anything about it.  I tried hosts.txt but that didn't work.

> Those components are
> not there to prevent users from doing something but to prevent their
> browsers from doing something on their behalf.
>
>> The entire model is wrong and we are going to suffer horribly for it.
>
> Quite the opposite again. Look around you. People spend their week-ends
> reinstalling their PC at home, while they never have to do that in well
> controlled environment at work. This security is necessary and it's not
> by claiming it's useless that we won't have to deal with it.

I told you already 2x that if you install Baseline Shield, you will never
have to reinstall your PC again ($4 per copy if you negotiate hard for
huge site license).  I couldn't believe I had ever lived without it.  And
besides all the mathematical advantages for freedom I already mentioned,
it also travels with me, unlike the enterprise jail.  And I don't have to
block anything on port 80 or any other port!  I AM FREE AT LAST!!!

Try it.  Freedom is quite addictive.


>
>> > Two competing implementations to maintain for the site owner.
>>
>> They are going to have to do it any way, no matter what we do.
>
> There's a difference between having to do that just for some time and
> having to do that forever.

WS/P+T won't be a partial fail forever, as you admitted if it becomes
popular enough, even the enterprises can parse it and allow it.  Or if you
argue that it will still be an open security hole, I still retort with
that centralized model of control is dying.  The world will turn to
freedom of something like Baseline Shield instead where each user controls
their own level of protection and has an instant reset button.


> Look, 10 years ago, not everyone was using
> virtual hosting because some old browsers were not HTTP/1.1 compliant
> and did not always emit the Host header. Now that's universally used.

No argument with that.

>
>> > We must keep in mind that the goal of the spec is to propose
>> > something that people want to deploy, otherwise it's a failure.
>>
>> How does this not support my logic so far?
>
> If it only works for 80% of the users, while an existing alternative
> already exists for 100% of the users, the one with 80% has no added
> value and will not be used.

Unless the 80% one has better features or performance.

Which proposed solution works for 100% of users?  I think none of them. 
And all proposed solutions can converge to 100% over time.  But which
solution gives the most improvement out of the starting gates?  I think
WS/P+T.


> The problem is not getting 80% of the users
> happy, it's getting 20% of them angry.


Agreed.  That is why the 20% must get fall back to Comet/BOSH.


> If your site gets 1 million
> unique visitors each day and 200000 of them can't use some of your
> site's features, you'd better not have competition in your domain.


Agreed, but this is not an argument against any of my points.


>
>> >> Might be easy to solve with the tunneling algorithm I shared, because
>> >> you
>> >> could have each server emit a different packet signature to which the
>> >> client sent the same signature replies.
>> >
>> > yes, possibly, though it still requires developping support for a new
>> > protocol in existing components, while with HTTP at least there's
>> nothing
>> > to do (except sometimes fix a few ones).
>>
>> "nothing to do" is not the way I would characterize the mess ahead with
>> soft fail in HTTP.  Consider the actual cost in the market place.
>
> The cost is unrelated. Some devices will be upgraded in 1-3 years and once
> users have complained about lack of support of XXX, this will be part of
> the prerequisite features to select a new one.


This violates your 20% failure intolerance argument above, because if you
don't fall back, there will be no adoption, and if you do fall back, there
will no (fewer) complaints.

Also the cost is real in any case, we have to weigh it in comparison to
other options we have.


>> > As I said, none of TLS and your specific port addresses the stickiness
>> > requirements.
>>
>> I thought I did above?
>
> Nothing which works right now. It requires to completely implement your
> new protocol in server-side load balancers for it to get a chance to be
> used first. Building from scratch generally does not work well. Building
> from existing blocks works well.

Strong point.  The links I provided for WS/P+T were aimed more at two
client computers, not at server farms.  However, your point does not apply
to the applications running off a server that has a dedicated IP address,
which includes my server at pair.com.  And the "100% compatibility will be
reached over time" argument applies in this case too.  We need to weigh
all the tradeoffs and use cases.  No proposed transport is 100% now.  No
proposed transport can't become 100%.  Shouldn't we let the free market
decide unless we have clairvoyant certainty?

I am starting to lean towards a "one size fit all" is not optimum
solution.  We may need alternative transports for the application to
choose.

>
>> > WS/TLS + Comet/BOSH still requires support for two different
>> > protocols on the server side.
>>
>> We must have that fallback no matter what we do.  All options forward
>> have
>> failure cases.
>
> but not necessarily in the long run.


For all our proposed transport options.


>> > If I had the choice, I'd rather go for
>> > WS/TLS with a quick fail to WS/HTTP.
>>
>>
>> WS/HTTP can fail at random times after that quick fail, you still need
>> Comet/BOSH.
>>
>> What advantages and disadvantages does WS/TLS offer over port+tunnel?
>
> TLS offers at least confidentiality, integrity, framing and cross-protocol
> protection. It has a larger handshake overhead.


TLS appears to be the more "secure" option, at a handshake, enterprise
blocking, etc costs.  Someone needs to put all these tradeoffs for all
options into a huge table so we and the market can grok this.  Disagree?


>> Ditto WS/HTTP?
>
> HTTP relies on existing infrastructure to work immediately and support
> scalability.

We have Comet/BOSH for that already, and we have to compare the tradeoffs
of the advantages versus disadvantages that WS/HTTP introduces.

> It supports proxying,

That is a negative for real-time communications.

> does not require the visitors to open
> a new port.

Neither does the fallback to Comet/BOSH.  How much are we gaining and
losing with WS/HTTP?  I say much better gain to have a real TCP channel
instead of a proxied one.

> Supports authentication too.

TLS will give us that option (but not on enterprise)?  We can add it to
proposed WS/P+T?

Can't we authenticate orthogonally using HTTP and then pass signatures in
WS/P+T?  This is application layer, and should we be more focused first on
transport layer specific tradeoffs?


> And the connection may be reused
> by the browser from the HTTP one, reducing the round trips.

I am not so convinced of this will be so in practice and considering
numerous other factors, but I am not an expert in this area.  Will defer
to others on this one...there is  lot of past commentary on the list about
this and afaics questions that claim.


>
> It will fail at some places, but :
>   - server-side failures caused by lack of support for 101 will be fixed
>     as bugfixes in many implementations when admins will start to look at
>     competing products ;
>
>   - client-side failures caused by overzealous proxies can quickly be
> fixed
>     by configuration (either open all or just a small list of sites, as in
>     the TLS case).
>
> Regards,
> Willy
>
>
>