Subject: RE: [Speermint] Congestion and Load Balancing

From: "Brian Rosen" <[email-masked]>
Date: Thu, 10 Aug 2006 13:31:04 -0400

Yeah, a bit; I used to work for FORE Systems, which implemented ABR pretty
carefully.  ABR was never used much.

It is the kind of thing I'm talking about; the mechanism had some
significant theoretic work behind it, and the mechanism was pretty well
understood before the spec was written.  Tim Dwight and others can probably
comment more than I on that subject.

I don't think the ABR mechanism is applicable to the problem at hand.

Brian

> -----Original Message-----
> From: Khan, Sohel Q [CTO] [mailto:[email-masked]]
> Sent: Thursday, August 10, 2006 1:20 PM
> To: Brian Rosen; Daryl Malas
> Cc: [email-masked]
> Subject: RE: [Speermint] Congestion and Load Balancing
> 
> 
> 
> 
> 
> I think in old ATM days, there were significant research and simulation
> studies conducted on Available Bit Rate (ABR) flow control and
> congestion control. I do not know whether anyone implemented it, any
> insight?
> 
> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Wednesday, August 09, 2006 7:28 PM
> To: 'Daryl Malas'
> Cc: [email-masked]
> Subject: Re: [Speermint] Congestion and Load Balancing
> 
> I am aware of the congestion control (overload) work going on.  So far,
> I'm suspicious of it, because I don't see any experimental or simulation
> studies that show the effects of trying to control congestion in SIP.
> We'll see how it develops.
> 
> I'm very suspicious of what looks like very simple dynamic feedback
> control on the peering point.  We've seen this kind of thing many times
> before.  The Internet is very fast, and feedback loops tend to oscillate
> wildly really easily.  You almost always need a dampener, and sometimes
> something more exotic.  I'm pretty sure a straight dynamic "I'm full"
> mechanism will not be stable.  I have no idea what kinds of filtering we
> need, and what kind of "frequency response" we need, but I'm pretty sure
> we need some.  I don't know if we want simple on/off ("bang-bang)
> control, or proportional control.
> I don't even know if we understand how you measure congestion in these
> kinds of systems.
> 
> Please dream up a mechanism and go try it.  Let us know how it does.
> There are some pretty useful simulation mechanisms for networks around,
> simulation results rarely match real world results, but they are
> informative.  Better if you could try it on real networks.
> 
> But please don't just propose a dynamic feedback type "loop control"
> without a good set of definitions, an understanding of what and how you
> are measuring, a viable control mechanism, a filter/dampener and some
> inkling of how well it works on real or simulated traffic.
> 
> Brian
> 
> > -----Original Message-----
> > From: Daryl Malas [mailto:[email-masked]]
> > Sent: Wednesday, August 09, 2006 6:12 PM
> > To: Brian Rosen
> > Cc: 'Michael Hammer (mhammer)'; 'Patrick Melampy'; 'Klaus Darilion';
> > [email-masked]
> > Subject: RE: [Speermint] Congestion and Load Balancing
> >
> > I apologize if I am restating or missing this, but I am going to jump
> > in...so a shut up and go away is acceptable. ;-)
> >
> > Just to throw in my two cents...I think there are two different issues
> 
> > to solve here.  First, dynamic congestion control in SIP.  Rosenberg,
> > Hilt, and myself are working on this problem...but definitely
> > appreciate input.  Second, policy based congestion control for
> > peering.  I think this second aspect is the beast we are trying to
> > tackle in this working group. This second aspect was going to be apart
> 
> > of the policy function in the peering architecture.  Now, how does it
> > dynamically update the sender...I had initially recommended a
> > subscribe mechanism where an expiry timer will essential force the
> > peer to re-subscribe to gain new policy information...this could
> > include updated congestion information for changing the destination
> > signaling function...or may say...go away...I can't handle any more
> > traffic.  Either way, this second method is in addition to the SIP
> > congestion/overload method...yet specific for the peering environment.
> >
> > What do you think?
> >
> > --Daryl
> >
> > On Wed, 2006-08-09 at 17:37 -0400, Brian Rosen wrote:
> > > 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
> > >
> > > > -----Original Message-----
> > > > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > > > Sent: Wednesday, August 09, 2006 5:09 PM
> > > > To: Brian Rosen; Patrick Melampy; Klaus Darilion
> > > > Cc: [email-masked]
> > > > Subject: RE: [Speermint] Congestion and Load Balancing
> > > >
> > > > So, we can't invent anything new unless it has already been
> invented?
> > > >
> > > > I don't think I agree that only manual methods of configuring
> > > > peers is the only way to go.  I presume that VSPs in a federation
> > > > may come and go, and that traffic between peers will come and go.
> 
> > > > It seems like on some time scale slower than call setup and faster
> 
> > > > than a contract negotiation, there ought to be a way to adjust
> > > > parameters of peers to reflect a balance between traffic offered
> and resources available.
> > > >
> > > > When contacted based on a DNS lookup, it doesn't seem that bad to
> > > > tell
> > a
> > > > peer which has shown it is part of a federation which proxy (farm)
> 
> > > > to use and what parameters to stay within.
> > > >
> > > > Mike
> > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/speermint
> 
> 
> _______________________________________________
> 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: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Thu, 10 Aug 2006 12:19:37 -0500

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, August 09, 2006 7:28 PM
To: 'Daryl Malas'
Cc: [email-masked]
Subject: Re: [Speermint] Congestion and Load Balancing

Brian

never does.

from.
invented?

and resources available.