Subject: RE: [Speermint] Congestion and Load Balancing

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 16 Aug 2006 10:44:49 -0400

Brian,

Do we have the same topological picture here?  

Your words suggest peering is 1-1 with an SBC on each side of a
boundary, rather than an entry signaling node facing an IP network.

In essence the policy point is acting as a load balancer.  The 503
problem occurs precisely because you may be facing an unknown N number
of federation peers and it is already too late to react when you are
being overloaded with INVITEs.  An INVITE load balancer may be
overwhelmed.  The idea behind the SUB/Notify mechanism is that it would
be orders of magnitude below these spigots of INVITE sources.

Getting real starts with asking the right questions and solving the same
problems.  Thus, my first question above.  We may be envisioning
different approaches to peering.

Mike

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Wednesday, August 16, 2006 9:55 AM
> To: 'Khan, Sohel Q [CTO]'; [email-masked]
> Subject: RE: [Speermint] Congestion and Load Balancing
> 
> I can't imagine any delay through a peering system that could 
> add up to something an application can detect.  It should be 
> very small.  If it's not, get a new peering system, something 
> is wrong.  Most peering is a SIP exchange directly between 
> the peers (with an ENUM dip and possibly some other simple 
> database things on the origination side).  The transit time 
> TO the peering point should swamp the actual signaling exchange.
> 
> What kind of "hot spot" could you imagine we could create in 
> a peering system that was not due to poor engineering?  Best 
> I can do is to force an underpowered SBC to face the peering 
> network and bottleneck on that.  Don't do that.
> 
> People, I think we need to get real here.  Let's start 
> throwing around realistic numbers, and see if they work or 
> don't.  What I see here is telephone engineering numbers in 
> an IP environment.  
> 
> I believe in millions of BHCA between peers, and gigabits of 
> bandwidth.  Is someone believing we are building peering 
> systems with hundreds of millions of BHCA between a single 
> pair of peers?  Hundreds of gigabits of bandwidth don't seem 
> to be a problem for a peering system; we can do that with a 
> single element these days.
> 
> I can imagine we WILL get numbers in the hundreds of millions 
> of BHCA some day.  I don't think we need to worry about that now.
> 
> I can easily see how you can get beyond a single signaling 
> element facing or within the peering fabric, but I think load 
> balancing that is pretty straightforward, and doesn't require 
> much standardization.  I don't think you ever create hotspots 
> in the peering.  
> 
> I don't believe in blocking calls before the termination 
> resource.  That may get congested, but then "Busy" is the 
> appropriate response.  
> 
> Brian
> 
> 

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Aug 2006 11:12:06 -0400

I think peering is functionally a star: peers have some collection of
elements facing the peering fabric and peering goes from one edge to the
other.  The "fabric" may be nothing but an IP network.  It may even be the
Internet.  There may or may not be any active element at the hub of the
star.  If there is, it's a proxy server.  If there isn't, it's just an IP
switch or functional equivalent.

If the federation, by contract, limits the total number of calls towards the
fabric from any one peer, and either federation contract policy or bilateral
contract policy limits traffic between two specific peers, I think we can
create non-blocking peering (or at least non blocking to the point where the
incidence of blocking is low enough that we can ignore it and busy the
call).  I think that is sufficient.

The SIP overload work is dealing with the 503 issue.  I don't have anything
to offer beyond that work, do you?

I am extremely suspicious of simplistic congestion control mechanisms that
try to push congestion knowledge back earlier in a network.  We have LOTS of
experience that getting them right is not easy.  Look at the archives on
"Explicit Congestion Notification" in TCP for example.  Unless you can show
me a big network successfully using SUB/NOT to push congestion state
backwards, then I don't believe it will work.  I guarantee it won't work if
it's literally just a notification to stop: that is, there is no explicit
text on how you control the rate of messages, and how you control the on/off
nature of the mechanism so that it has dampening.  Getting such text right,
and behavior right at both ends, is hard.

Brian

> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Wednesday, August 16, 2006 10:45 AM
> To: Brian Rosen; [email-masked]