Subject: RE: [Speermint] Congestion and Load Balancing

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Tue, 15 Aug 2006 11:38:59 -0500

There are connection setup delay sensitive applications that require
setup time below certain threshold.
While the propagation delay is the main attribute of the a setup delay,
the reduction of processing delay is also important. More importantly,
blocked calls need to be avoided. Thus, we need to perform appropriate
routing/load balancing to mitigate signaling congestion hotspots in the
peering proxies. 

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Tuesday, August 15, 2006 8:13 AM
To: [email-masked]
Subject: RE: [Speermint] Congestion and Load Balancing

I think there is enough middle ground between nothing and a full fledge
SIP BGP.

You can start with simple enough mechanisms such with plain text file
configuration, DNS, SIP Subscribe/Notify all the way to some SIP BGP.

What we need to agree first is: Is there a problem to be tackled? Is
there a need for some kind of policy discovery (whatever that is at this
point)?

Regards,

Reinaldo

> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Monday, August 14, 2006 12:14 PM
> To: Brian Rosen; Patrick Melampy; Klaus Darilion
> Cc: [email-masked]
> Subject: RE: [Speermint] Congestion and Load Balancing
> 
> Brian,
> 
> It might be useful to keep the IP network traffic congestion control
and
> the signaling overloading the SIP Proxy control concepts separate.
Some
> of the later emails in this thread seemed to be headed down a media 
> congestion path.
> 
> Also, when talking about things in the "stuff we pretty much know
works"
> category, are you excluding the experiences with call gapping from the

> PSTN?  I think there may be some pretty strong analogies that can be 
> made.  And I am pretty sure that the control software in switches is 
> running code.
> 
> Mike
> 
> 
> > -----Original Message-----
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Wednesday, August 09, 2006 5:38 PM
> > To: Michael Hammer (mhammer); 'Patrick Melampy'; 'Klaus Darilion'
> > Cc: [email-masked]
> > Subject: RE: [Speermint] Congestion and Load Balancing
> >
> > Please don't get me started on the IETF's abandonment of its belief 
> > in running code.
> >
> > While occasionally we actually just document something that exists, 
> > we usually end up extending somewhat from something we know works.  
> > We have pretty bad experience inventing major new functionality 
> > ESPECIALLY IN CONGESTION CONTROL, and seeing it work.  It almost 
> > never does.
> >
> > So, sure, we can invent some new stuff, as long as it is some 
> > likely-to-work extension of stuff we pretty much know works.
> >
> > Let me cite an example.  ICE is a pretty complex piece of machinery,

> > but it's built on a base of work we KNOW will work.  ICE may have a 
> > bunch of text to tweak as we gain some implementation experience, 
> > but we know it will work.
> >
> > I'm not aware of any work in this area we know works we can build 
> > from.  Can you cite some?
> >
> > I'm not particularly opposed to having discovery mechanisms for 
> > proxy domain names, call rates and bandwidth limits rather than 
> > provisioning.  I'm skeptical they would be used, but it's simple 
> > enough.  I am opposed to trying to say that info varies from call to

> > call, but something faster than a contract negotiation does seem 
> > practical.
> >
> > That's a far cry from anything we would consider to be dynamic 
> > congestion control.
> >
> > Brian
> >

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

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Aug 2006 09:54:55 -0400

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

> From: Khan, Sohel Q [CTO] [mailto:[email-masked]]
> Sent: Tuesday, August 15, 2006 12:39 PM
> To: [email-masked]