Subject: Re: [Sipping] Server Load Balancer Integration?

From: [email-masked]
Date: Thu, 8 Nov 2001 20:22:04 -0500

Henning - I agree that we should do nothing (option 1).  If SLB makers want
to support SIP correctly, they should make them look
like compliant SIP proxies.

A few additional comments:

point (a) - the time difference between updating DNS records and when
clients stop hitting the removed machine is
too long even for well controlled networks (I know - we have a large number
of these deployed).  I want the machine
to gracefully shut down (e.g. stop getting new hits) within a second of
making the change or the machine failing.

point (b) Most HTTP SLBs can be viewed as Hardware HTTP Proxies with no
cache and some nice TCP-layer capabilities,
and HTTP layer keep-alives.  This is clearly lacking in DNS - now I always
assumed that if two SIP servers wanted
to know that the other is alive they would register to each other -
one-way, both-ways, whatever would make sense - correct me if I am wrong.

point (c) yes it is possible to make SYN floods a thing of the past (but
are they?  did not notice all them ISP making changes
just quite yet - hope they will) - some like Exodus did because of well
publicized events - but is it fool-proof?  What I am talking
about are application level attacks - I want these messages to be stripped
by some DMZ hardware - and not have my ultimate
SIP application take care of them (yes it still has to be robust - but
that's a separate issue).

point (d) you say I am wrong but also at the same time you say "...and has
some machinery behind the DNS server
that computes the right answer..." - I don't differentiate between DNS Load
balancers and "proxy" load balancers - both
have their places in the network.  That "some machinery" is a there to find
the closest cache right?  that's the function of a global load
balancer - so I think we are actually agreeing...

anyway - as we both think option (1) is the correct one, I guess there is
nothing to do but watch SLBs makers implement SIP ;-)

cheers -

- gur

                    "Henning G.                                                                                                                
                    Schulzrinne"          To:     [email-masked]                                                                      
                    <[email-masked]        cc:     Jonathan Rosenberg <[email-masked]>, "'Henning G. Schulzrinne'"                     
                    ia.edu>               <[email-masked]>, Steve Gardell <[email-masked]>, "[email-masked]'" <"sipping,          
                    Sent by:              _sipping-admin"@ietf.org>                                                                            
                    [email-masked]        Subject:     Re: [Sipping] Server Load Balancer Integration?                                         
                    lumbia.edu                                                                                                                 

                    11/08/2001                                                                                                                 
                    02:32 PM                                                                                                                   

Quick note: Akamai uses DNS to inform the browser of the best replica
(and has some machinery behind the DNS server that computes the right
answer). We had an Akamai person talk about this here.

> (a) maintenance procedure - given a farm of SIP servers (or proxies,
> regardless),
> gracefully remove one out of the cluster for maintenance without that
> server ever
> getting "hit" erroneously.

See my previous email.

>
> (b) internal topology hiding - given a DMZ farm hide the internal
structure
> by
> exposing a pair of SLBs as "front-ends".  backbone does not allow direct
> access
> to internal topology (yes this can be done with proxies, so consider the
> SLB a
> hardware proxy).

Not sure what a "hardware proxy" is.

>
> (c) DoS protection - SLBs usually provide DoS protection on the TCP
level,
> as they
> do it in hardware that takes quite a load off applicative attacks (SIP is
> so easy
> we have to assume application-level attacks are too easy...).

If we do our job right, SYN-flood style attacks should not be possible.
Pure packet flooding clearly is, but there, packet filtering is probably
the only viable solution.

> (1) consider SLBs SIP Proxies with shared state and some out-of-scope
> (for SIP) capabilities like DoS protection and failover support.
>
> (2) write specs on how SLBs should handle SIP, failover scnearios,
> keep-alive
> detection, etc.

I certainly hope we avoid (2).

>
> BTY, the akamai example does hit a cloud of global SLBs to find the
closest
> cache -
> that's the whole akamai premise...

See above. Wrong.

> - gur

--
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 08 Nov 2001 19:44:14 -0500

> making the change or the machine failing.

As I said, this is easy. Stop machine, assign its IP address to buddy
machine, so that it has two. Bring up new machine with a new address,
recycle addresses. This can be automated.

> one-way, both-ways, whatever would make sense - correct me if I am wrong.

This would be one SIP way, but they could also send each other SIP
OPTIONS request periodically.

> that's a separate issue).

As long as you have authentication, including null authentication, SIP
doesn't have the SYN flood problem since no state is established until
there's a verifiable response. If your SIP server doesn't implement the
protocol correctly, that's a separate problem...

> balancer - so I think we are actually agreeing...

No, but the mechanism is very different. The DNS answer is computed
without ever touching the HTTP connection. Your HTTP (or SIP) proxy has
to handle the "real" transaction. DNS is much faster than HTTP load
balancing: You have to do a DNS lookup anyway, so the incremental cost
is zero. If you go to an HTTP server with a fixed IP address, you may
make the initial TCP connection to a remote corner of the world. All
subsequent bytes, not just the two DNS UDP packets, go there. Bad news.
Thus, for geographic proximity routing, HTTP proxy servers are useless.
The other mechanism is HTTP redirect, but even that's inferior, due to
the larger number of packets that need to go "far".

You could play the same Akamai-style game to find the nearest SIP proxy
server, but I'm not sure it would matter much.