Subject: RE: [Speermint] Congestion and Load Balancing

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Thu, 10 Aug 2006 12:40:24 -0500

There used to be also a PNNI signaling and congestion control
specification (ATMF, April 2002); I do not know whether anyone
implemented it, if so, what is the experience?

--- Sohel   

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, August 10, 2006 12:31 PM
To: Khan, Sohel Q [CTO]; 'Daryl Malas'
Cc: [email-masked]
Subject: RE: [Speermint] Congestion and Load Balancing

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: "Brian Rosen" <[email-masked]>
Date: Thu, 10 Aug 2006 13:59:34 -0400

Oh, yes, PNNI was very successful.  It worked pretty darn well.  PNNI was
essentially the routing protocol between ATM switches.  There is extensive
documentation and experience on how PNNI works.  

Just for fun, we calculated once that we could build a network of existing
switches that could provide VBR/CBR bandwidth RESERVATIONS, down to the
individual call, and meet the call throughput (BHCA) of the largest PSTN
networks.  That means we could set up VBR/CBR switched virtual circuits for
EVERY CALL in the network worst case, and have guaranteed QoS for each of
them.  This is roughly equivalent to doing RSVP per call throughout the
network. 

But that was several years ago.  

Again, while there IS much to learn from PNNI, I don't see yet how to apply
it to the problem.  I think THAT is an interesting research topic, and if
the result of the research looks interesting, then maybe some specification
work would be warranted.

There are a number of successful congestion control protocols that have been
devised for a variety of environments.  How applicable they are to this
environment is not very clear, at least to me, right now.

Brian

> Sent: Thursday, August 10, 2006 1:40 PM

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 10 Aug 2006 18:50:27 +0000

An ABR-like congestion control scheme, if such existed, would in thepry provide for bandwidth sharing amongst "elastic" sessions.  That doesn't seem like the problem we're dealing with here, though.
 
tim

________________________________

From: Brian Rosen [mailto:[email-masked]]
Sent: Thu 08/10/2006 5:59 PM
To: 'Khan, Sohel Q [CTO]'; 'Daryl Malas'
Cc: [email-masked]
Subject: RE: [Speermint] Congestion and Load Balancing

Brian

> > > > https://www1.ietf.org/mailman/listinfo/speermint <https://ssl.mcilink.com/https/www1.ietf.org/mailman/listinfo/speermint> 
> >
> >
> > https://www1.ietf.org/mailman/listinfo/speermint <https://ssl.mcilink.com/https/www1.ietf.org/mailman/listinfo/speermint> 
>
>

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint <https://ssl.mcilink.com/https/www1.ietf.org/mailman/listinfo/speermint>