Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

Mark Andrews <marka@isc.org> Wed, 27 July 2011 01:29 UTC

Return-Path: <marka@isc.org>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B47C5E800D; Tue, 26 Jul 2011 18:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.454
X-Spam-Level:
X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StHUf5z7cwlb; Tue, 26 Jul 2011 18:29:02 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD595E8003; Tue, 26 Jul 2011 18:29:02 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 8E3C25F9911; Wed, 27 Jul 2011 01:28:41 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 30050216C88; Wed, 27 Jul 2011 01:28:09 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id EBB811231907; Wed, 27 Jul 2011 11:28:06 +1000 (EST)
To: Iñaki Baz Castillo <ibc@aliax.net>
From: Mark Andrews <marka@isc.org>
References: <CALiegf=pYzybvc7WB2QfPg6FKrhLxgzHuP-DpuuMfZYJV6Z7FQ@mail.gmail.com> <CAP992=FJymFPKcPVWrF-LkcEtNUz=Kt9L_ex+kLtjiGjL1T46w@mail.gmail.com> <4E28A51F.4020704@callenish.com> <CALiegf=4K2oWfmZjGMD7J_jyaDtS3i+Mu7R0Wh75Rr+MrQCjtw@mail.gmail.com> <20110722054345.GE18126@1wt.eu> <CALiegfnYm6g63JDHLiSH__r-or3kzK0XCVa3cC7RMP14KWBOSg@mail.gmail.com> <20110724120751.GQ22405@1wt.eu> <CALiegfncavmoMp4YDCeeJ3rsOfHAYQ99itKX2Q2eHB351T3X5A@mail.gmail.com> <20110724184537.GZ22405@1wt.eu> <CALiegfne620wuDMAp235n3mVcXTAnbhhNm8vpiNCy5F7+VD92A@mail.gmail.com> <20110724192948.GD22405@1wt.eu> <CALiegf=e48kkF+Gky1mY7LippUB-0kZDgSGZrJxk1aZupAGkYw@mail.gmail.com>
In-reply-to: Your message of "Tue, 26 Jul 2011 11:47:48 +0200." <CALiegf=e48kkF+Gky1mY7LippUB-0kZDgSGZrJxk1aZupAGkYw@mail.gmail.com>
Date: Wed, 27 Jul 2011 11:28:06 +1000
Message-Id: <20110727012806.EBB811231907@drugs.dv.isc.org>
Cc: Server-Initiated HTTP <hybi@ietf.org>, IETF-Discussion <ietf@ietf.org>
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2011 01:29:03 -0000

In message <CALiegf=e48kkF+Gky1mY7LippUB-0kZDgSGZrJxk1aZupAGkYw@mail.gmail.com>
, =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= writes:
> 2011/7/24 Willy Tarreau <w@1wt.eu>:
> >> Ok, but what would be the failover solution then? any failover
> >> solution can take some time until redirects the client's request to a
> >> working server, it's not just a client problem.
> >
> > This is already addressed by existing web architectures. DNS provides
> > geolocation and proposes you the closest working datacenter. BGP ensures
> > that this datacenter is always reachable via multiple links and multiple
> > providers. Load balancers on the site ensure that only valid servers are
> > used. I know some people who configure their load balancers so that a
> > server is removed from the pool less than 50ms after a failure or 
> slowdown
> > has been noticed. You will never be able to offer that quality of 
> service
> > using DNS only, because those 50ms are less than the time it takes for
> > most visitors to ping the site.
> 
> Yes, but those are expensive server side solutions. I wouldn't like
> that a scalable architecture requires so complex solutions (which are
> not very suitable in case of usual web hostings). DNS SRV provides a
> cheaper way of doing something similar (both ways can live together
> thought).
> 
> 
> 
> >> Anyhow, don't forget that SRV is not just for failover, but also for
> >> load-balancing (you can state that a more powerful server-01 receives
> >> 80% of the traffic and server-02 the remaining 20%).
> >
> > This is already addressed by DNS round robin and used by a lot of sites.
> 
> I consider that a hack.
> 
> 
> > But keep in mind that DNS is used between *sites* and not *servers*. If
> > you use it for servers, you'll fail because you won't be able to 
> silently
> > put them in maintenance without disturbing visitors.
> 
> SRV provides load-balancing and failover. I never said that SRV is a
> solution for temporaly put in maintenance a server.

Happy eyeballs however does allow you to take a server out of production
and not really notice it.  Note webbrowsers have had the ability to do
this for as long as webbrowsers have existed.

Billions of dollars have been wasted globally for the sake of a few hours
work by webbrowser vendors.
 
> > Load balancers are
> > used for servers. And between sites, people are not seeking imbalanced
> > distribution. If they really do, then it's easy using multiple 
> addresses.
> >
> > Don't take this as an attack (it is not), but you accused Roy of not
> > knowing SRV, but I think that you're not much experienced with web
> > infrastructures and that may be why you think that SRV is the *only*
> > solution to many problems that have been dealt with for ages.
> 
> Right, but I'm used to scalable and big SIP infrastructures and DNS
> SRV is used for that (along with server side solutions as SIP load
> balancers). What I say is that web infraestructures cannot use SRV
> mechanism so it's not valid for me that just current HTTP solutions
> are valid for any other new protocol.
> 
> In contrast it seems that for many people the hacks existing in HTTP
> world (www.facebook.com resolves to a single IP) is the only way to go
> for a scalable infraestructure "so DNS SRV is not needed". Why so many
> efforts in disallowing an *optional* mechanism like SRV? If somebody
> does not like it, just don't use it.
> 
> 
> Regards.
> 
> 
> -- 
> Iñaki Baz Castillo
> <ibc@aliax.net>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org