Subject: RE: [Speermint] Congestion and Load Balancing

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 9 Aug 2006 17:08:59 -0400

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

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Wednesday, August 09, 2006 4:50 PM
> To: 'Patrick Melampy'; 'Klaus Darilion'
> Cc: [email-masked]
> Subject: RE: [Speermint] Congestion and Load Balancing
> 
> I don't think there is anything particularly dynamic about 
> what A knows about B, because it will be subject to contract. 
>  I do not think we know enough to design congestion control 
> mechanisms that work across the peering boundary.  I am not 
> aware of experimental work that would point towards what 
> kinds of mechanisms are appropriate, and in the absence of 
> some working examples, I fail to see why we should even 
> consider it.  We can limit calls per unit of time, and 
> bandwidth, on a list of proxies and I think that's it.
> 
> The design of congestion control protocols is fraught with 
> failures on things that ought to have worked.  The congestion 
> control mechanisms we see in the PSTN are wholly unsuitable 
> for the Internet.  What we will need for the Internet has yet 
> to be investigated.  I encourage such investigation.
> I'd be very interested in reports describing new mechanisms 
> and how well they work, both on simulated and real traffic.
> 
> But unless you can point to something that appears to work, 
> it's out of bounds for this group, in my opinion.
> 
> Brian
> 
> > -----Original Message-----
> > From: Patrick Melampy [mailto:[email-masked]]
> > Sent: Wednesday, August 09, 2006 1:30 PM
> > To: 'Klaus Darilion'
> > Cc: 'Brian Rosen'; [email-masked]
> > Subject: RE: [Speermint] Congestion and Load Balancing
> > 
> > Network A needs to know things about Network B (dynamic 
> things). This 
> > is what spearmint is about. A needs to know where B's 
> proxies are, and 
> > how to use them. A will have many possible ways of reaching 
> downstream 
> > domains. A needs to be able to efficiently route traffic. This 
> > requires information about B's capabilities (speeds, rates, 
> volumes).
> > 
> > Its all very simple. Either A has to provision everything 
> based on B's 
> > information, or we need to develop a protocol for exchanging this 
> > information.
> > 
> > The advantage of a protocol, is that the information can be 
> dynamic, 
> > and the same protocol can be used for congestion control
> > 
> > You pooh-pooh congestion control. Service Provider Peering 
> will never 
> > work if it doesn't have congestion control. You can take 
> that to the bank.
> > 
> > --- Patrick
> > -----Original Message-----
> > From: Klaus Darilion [mailto:[email-masked]]
> > Sent: Wednesday, August 09, 2006 11:48 AM
> > To: Patrick Melampy
> > Cc: 'Brian Rosen'; [email-masked]
> > Subject: Re: [Speermint] Congestion and Load Balancing
> > 
> > Patrick Melampy wrote:
> > > Klaus --- What the carrier needs is four basic requirements (the
> > receiving
> > > or B carrier):
> > >
> > > 1.) To be able to receive calls
> > > 2.) To be able to count the simultaneous calls
> > 
> > = dialog-statefull proxy
> > 
> > > 3.) To be able to count the kilobytes of bandwidth the media is
> > consuming
> > 
> > = calls x bandwidth per call.
> > 
> > > 4.) To be able to settle accounts in some way
> > >
> > > Optional requirements include:
> > > 5.) To be able to control the rate each customer sends calls
> > > 6.) To be able to manage congestion on certain domains
> > 
> > Manage congestions have 2 results: either tell A that there 
> is no way 
> > to route this call in network B, or reroute the call to an 
> idle node.
> > Rerouting can happen in network B or in network A (SIP redirect 3xx)
> > >
> > > A stateless load balancer can't provide these.
> > 
> > IMO a load balancer is a load balancer, and beeing statefull at SIP 
> > layser is different to knowing the state (load) on the SIP 
> proxies and 
> > media gateways inside your network. A LB can be SIP stateless, but 
> > still knows the status of the SIP nodes in the network and may 
> > distribute the calls accordingly to the SIP nodes (ok, here a 
> > transaction stateful LB would be good, but a session 
> statefull LB is 
> > not required)
> > 
> > > I believe that semi-stateless load-balancers are required. All of 
> > > the technology you and Brian speak to works. However, none of that
> > technology
> > > helps solve the above problems. The above problems will 
> ultimately 
> > > call
> > for
> > > distributed session state with distributed admission 
> control. I also
> > believe
> > > that the load balancers will be semi-stateful (slightly 
> slower than 
> > > a redirect, but more reliable from B's point of view) and 
> will not 
> > > scale
> > to
> > > the point where only one is required. I would suggest 
> that locating
> > these
> > > semi-stateful proxies and their attributes (distributed admission
> > control
> > > parameters) will be important topics for this group.
> > 
> > IMO this is inside of network B, thus out of scope for SPEERMINT.
> > 
> > regards
> > klaus
> > 
> > 
> > >
> > > -----Original Message-----
> > > From: Klaus Darilion [mailto:[email-masked]]
> > > Sent: Wednesday, August 09, 2006 7:59 AM
> > > To: Brian Rosen
> > > Cc: 'Patrick Melampy'; [email-masked]
> > > Subject: Re: [Speermint] Congestion and Load Balancing
> > >
> > > Some more practical LB issues.
> > >
> > > If the LB is used for load balancing only, there is no need to be 
> > > transaction stateful - it depends on the distribution 
> logic of the LB.
> > > If there is a random component within the LB-logic, you need a 
> > > transaction statefull LB to ensure proper handling of 
> retransmissions.
> > > But if the LB-logic is based on some part of the message (e.g. 
> > > callid, R-URI), then the LB will route retransmissions 
> always to the same proxy.
> > >
> > > In-dialog requests will be routed by SIP's loose routing 
> logic, thus 
> > > the LB is not needed for in-dialog requests.
> > >
> > > Of course if you imply that a LB also has to do topology 
> hiding and 
> > > counting the number of active calls than you need a 
> session-stateful 
> > > element.
> > >
> > > regards
> > > klaus
> > >
> > >
> > > Brian Rosen wrote:
> > >> I think the A proxy has a "load balancer", but it's a 
> byproduct of 
> > >> how
> > it
> > >> assigns registrants to outgoing proxy servers.
> > >>
> > >> There are a couple of ways to load balance SIP.  One of 
> the nicest 
> > >> is a redirect proxy.  Another is a transaction aware, but not 
> > >> transaction stateful LB (might have to be session aware, 
> depending 
> > >> on what the leaf proxy did).  SIP effectively does have 
> "cookies"; they are the tags.
> > >>
> > >> The LB doesn't have to keep state, because the transaction ID is
> > visible
> > > in
> > >> every message.  Of course if the leaf proxies are 
> stateless, so is 
> > >> the
> > LB.
> > >>
> > >> Now, I agree that you can't have ONE load balancer.  You have to
> > replicate
> > >> it, but I suspect that the mechanism that distributes 
> calls to the 
> > >> replicated LB is pretty simple.  You do have to model 
> the failure 
> > >> cases
> > > and
> > >> make sure the entire load is shouldered by, and 
> distributed to, the 
> > >> remaining replicas.
> > >>
> > >> Brian
> > >>
> > >>> -----Original Message-----
> > >>> From: Patrick Melampy [mailto:[email-masked]]
> > >>> Sent: Saturday, August 05, 2006 4:42 PM
> > >>> To: 'Brian Rosen'
> > >>> Cc: [email-masked]
> > >>> Subject: RE: [Speermint] Congestion and Load Balancing
> > >>>
> > >>> Assuming that Domain B was determined to be the next domain 
> > >>> (through a
> > > yet
> > >>> unknown means), I partially agree. I think in practice, 
> both the A
> > proxy
> > >>> and
> > >>> B proxy would require load balancers. The load leaving 
> A might be
> > easily
> > >>> sent to a single very high capacity load balancer that B owns. 
> > >>> This
> > load
> > >>> balancer would likely be stateless, and as such unable to really
> > manage
> > >>> the
> > >>> relationship parameters (# of calls, amount of 
> bandwidth, call rate).
> > > Most
> > >>> of the scalable load balancers today are at best TCP 
> stateful with
> > some
> > > L5
> > >>> cookie mashing to keep TCP socket requests going to the 
> same place.
> > This
> > >>> of
> > >>> course will not work for SIP unless we open a new 
> Socket for every
> > call.
> > >>> For
> > >>> discussion purposes, lets suppose that systems of this type can
> > process
> > a
> > >>> very large amount of traffic -- lets say in excess of 
> 10,000 calls 
> > >>> per second.
> > >>>
> > >>> If B's load balancer was transaction stateful, then B could 
> > >>> balance
> > the
> > >>> traffic by transactions. Also note that if B terminated and
> > reoriginated
> > >>> TCP
> > >>> sockets for security association reasons, then B would 
> be required 
> > >>> to
> > be
> > >>> transaction stateful at a minimum to remember where 
> messages need 
> > >>> to
> > be
> > >>> sent. Problem with B's loadbalancer being transaction 
> stateful, is
> > that
> > > it
> > >>> runs significantly slower. I would bet that it would be 
> at least 
> > >>> 1/20
> > of
> > >>> the
> > >>> performance of the totally stateless model -- lets say 
> 500 calls 
> > >>> per second (1000 Transactions per second, 3500 Sip Messages per 
> > >>> second...)
> > >>>
> > >>> One problem we have now with B's load balancer, is that B can't 
> > >>> really know or control how many real calls are coming 
> from A. For 
> > >>> example, A could
> > be
> > >>> sending lots of transactions that are failing. 
> Conversely, A could 
> > >>> be sending a very slow rate of transactions that keep 
> sessions up 
> > >>> for
> > hours
> > >>> at
> > >>> a time. Obviously, there is still a lack of controls 
> for enforcing 
> > >>> the relationship between B and A. --- Whats missing?
> > >>>
> > >>> B may require that the load balancer be session stateful. This 
> > >>> could
> > be
> > >>> any
> > >>> range of possible solutions, including a record route 
> proxy that 
> > >>> is transaction stateful all the way through a B2BUA 
> like the edge 
> > >>> of an
> > IMS
> > >>> network. Now B could keep track of total sessions established 
> > >>> coming
> > from
> > >>> A.
> > >>>
> > >>> Probably, A has the same issue that B has ... How many calls 
> > >>> coming
> > from
> > > a
> > >>> variety of proxies is actually traversing into B's load 
> balancer. 
> > >>> I
> > would
> > >>> suggest that A might need a "concentrator" (the 
> opposite of a load 
> > >>> balancer). The concentrator might manage the 
> relationship with B, 
> > >>> and provide statefull management of the traffic destined for B.
> > >>>
> > >>> Why is all this required? Well frankly, much of the 
> traffic will 
> > >>> have "media" based bandwidth limitations. One could consider a 
> > >>> central PDF function to manage the relationship. Either 
> way, the 
> > >>> load balancer has
> > > the
> > >>> same issues.
> > >>>
> > >>> What if B can't process the communication request? Where does A 
> > >>> send
> > it?
> > >>> Is
> > >>> there an alternative? How can A determine if there is another 
> > >>> network
> > > (say
> > >>> C) that can process the communication? How would A share 
> > >>> information
> > with
> > >>> all of its source proxies...that B is constrained, full, or
> > unavailable?
> > >>>
> > >>> I'm guessing we have a bit of modeling to do. If SIP were more 
> > >>> like
> > HTTP
> > >>> where the TCP session and the HTTP session were 
> directly connected 
> > >>> --
> > > with
> > >>> COOKIES binding the physical sessions into logical application
> > sessions,
> > >>> then we could more readily use your suggestions. Last I looked, 
> > >>> SIP transactions and dialogues are pretty nasty to 
> recognize, and 
> > >>> add retransmissions, cancels, and other nasty things that make 
> > >>> load
> > balancing
> > >>> difficult if not impossible with out being a full SIP 
> participant.
> > >>>
> > >>> If a load balancer is a full SIP participant, and the load 
> > >>> balancer is balancing traffic based on established 
> sessions -- you 
> > >>> pretty much
> > have
> > a
> > >>> device that wont scale big enough to have one-size fits 
> all....now 
> > >>> you have the problem that I suggested. How does A find 
> B's "load 
> > >>> balancers" -- which I stated as "how does A find B's 
> proxies, and 
> > >>> their attributes.
> > >>>
> > >>>
> > >>>
> > >>> -----Original Message-----
> > >>> From: Brian Rosen [mailto:[email-masked]]
> > >>> Sent: Friday, August 04, 2006 2:28 PM
> > >>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff 
> Devine'; 'Michael
> > Hammer
> > >>> (mhammer)'; 'Hadriel Kaplan'
> > >>> Cc: [email-masked]
> > >>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: 
> > >>> Secure
> > RTP
> > >>>
> > >>> In my opinion, the Load Balancer belongs to Proxy B, 
> and it can do 
> > >>> anything it likes.  PAx sends to LB, and is not aware, 
> and doesn't 
> > >>> care, which
> > PBy
> > >>> gets the call.  SIP handles this well.
> > >>>
> > >>> Of course LB is a single point of failure.
> > >>>
> > >>> Brian
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Reinaldo Penno [mailto:[email-masked]]
> > >>>> Sent: Friday, August 04, 2006 2:14 PM
> > >>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer
> > >>> (mhammer);
> > >>>> Hadriel Kaplan
> > >>>> Cc: [email-masked]
> > >>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: 
> > >>>> Secure
> > >>> RTP
> > >>>> Hello Brian,
> > >>>>
> > >>>> Are you assuming some kind of public peering or third party run
> > peering
> > >>>> point?
> > >>>>
> > >>>> Let me give you a simpler barebones example to hear 
> your thoughts...
> > >>>>
> > >>>>
> > >>>> PA1           PB1
> > >>>>      \      /
> > >>>> PA2  -- LB -- PB2
> > >>>>      /      \
> > >>>> PA3           PB3
> > >>>>
> > >>>>
> > >>>> PAx reads Proxy x of peer A. Similar for PBy.
> > >>>>
> > >>>> Now PeerB does not really care how the signaling calls get
> > distributed
> > >>>> _to_ peer's A proxy from peer's A end users. It only cares how 
> > >>>> the
> > calls
> > >>>> get distributed to _its_ proxies from peer's A proxies, right?
> > >>>>
> > >>>> That's why I put the load balancer between them from a logical 
> > >>>> perspective.
> > >>>>
> > >>>> Would this load balancer be able to probe peer's B 
> proxy dynamic
> > "state"
> > >>>> (alive, dead, too many calls, too much bandwidth, 
> etc)? Is that 
> > >>>> your proposal?
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>> Reinaldo
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Brian Rosen [mailto:[email-masked]]
> > >>>>> Sent: Friday, August 04, 2006 10:47 AM
> > >>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer 
> > >>>>> (mhammer)'; 'Hadriel Kaplan'
> > >>>>> Cc: [email-masked]
> > >>>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re:
> > Secure
> > >>>> RTP
> > >>>>> <I changed the Subject, we have severely hijacked the 
> thread on
> > Secure
> > >>>>> RTP>
> > >>>>>
> > >>>>> I fail to see why any of this is a standardization issue: I 
> > >>>>> don't
> > see
> > >>>> why
> > >>>>> one end cares what the other end uses to load balance.
> > >>>>>
> > >>>>> I don't see any kind of load balance mechanism that requires 
> > >>>>> that
> > the
> > >>>>> other
> > >>>>> end do something related to it other than normal SIP 
> operations.  
> > >>>>> I certainly don't think it would be advisable to 
> introduce such 
> > >>>>> an interface.
> > >>>>>
> > >>>>> I don't think this has much to do with location.  Most 
> > >>>>> commercial
> > load
> > >>>>> balancers more or less assume everything is 
> collocated, but they
> > don't
> > >>>>> have
> > >>>>> to be, and there are simple ways to distribute to multiple 
> > >>>>> instances
> > >>>> of
> > >>>>> load
> > >>>>> balancing, which might indeed be the source of the 
> call related, 
> > >>>>> but again, not something that needs standardization.
> > >>>>>
> > >>>>> Let's take an example:
> > >>>>>
> > >>>>> Suppose that a peering system has peering connections 
> at 3 IXPs 
> > >>>>> in
> > San
> > >>>>> Jose,
> > >>>>> NY and Miami.  PeerA happens to have facilities at, or "near" 
> > >>>>> (in an
> > >>>> L3
> > >>>>> sense) the NY and Miami IXPs and PeerB happens to have 
> > >>>>> facilities
> > at,
> > >>>> or
> > >>>>> "near" NY and San Jose.  So, the peering exchange 
> might indeed 
> > >>>>> want
> > to
> > >>>> try
> > >>>>> to send traffic between PeerA and PeerB that 
> originate in their 
> > >>>>> NY facilities to the other's proxy in New York.  
> However, if NY 
> > >>>>> went
> > >>>> down,
> > >>>>> peering at either Miami or San Jose would be fine, since the
> > >>>> underlying
> > >>>>> network would make that one, or at most 2 router hops 
> away.  If
> > there
> > >>>> were
> > >>>>> only two major peering facilities for PeerA, you would clearly
> > >>>> engineer
> > >>>>> each
> > >>>>> to be able to take the entire load.
> > >>>>>
> > >>>>> If you make it more complicated, where each facility 
> is not able 
> > >>>>> to
> > >>>> take
> > >>>>> the
> > >>>>> entire load on a failure, you may need some other 
> load balancing
> > >>>> operation
> > >>>>> on top of the server farm approach that lets one farm refuse
> > traffic,
> > >>>>> which
> > >>>>> would cause the originator to try another IP address. 
>  You can 
> > >>>>> do
> > that
> > >>>>> with
> > >>>>> DNS, you can do that with the peering database, and there are 
> > >>>>> other mechanisms, none of which need any new work in 
> SPEERMINT 
> > >>>>> or SIP.  I
> > >>>> don't
> > >>>>> even think we need to enumerate them; it's all 
> something one end
> > does
> > >>>>> itself.
> > >>>>>
> > >>>>> Brian
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Patrick Melampy [mailto:[email-masked]]
> > >>>>>> Sent: Friday, August 04, 2006 12:39 PM
> > >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer 
> (mhammer)';
> > >>>> 'Hadriel
> > >>>>>> Kaplan'
> > >>>>>> Cc: [email-masked]
> > >>>>>> Subject: RE: [Speermint] Secure RTP
> > >>>>>>
> > >>>>>> Continuing on your train of thought ---
> > >>>>>>
> > >>>>>> 1.) We need load balancers
> > >>>>>>
> > >>>>>> I agree. How should you propose we balance the load?
> > >>>>>> 	1.) By TLS SESSION ESTABLISHMENT?
> > >>>>>> 	2.) By Round Robin Call Request
> > >>>>>>       3.) By source/destination proxy pairs?
> > >>>>>>
> > >>>>>> If your proposing using a standard ARROWPOINT or F5 
> load balancer?
> > >>>> We
> > >>>>> have
> > >>>>>> seen these techniques used successfully, and the good ones 
> > >>>>>> (like
> > the
> > >>>> F5)
> > >>>>>> actually understand and maintain proxy state. Lets 
> explore some
> > more
> > >>>> on
> > >>>>>> what
> > >>>>>> we would want in an ideal load balancer....
> > >>>>>>
> > >>>>>> 1.) We would want to balance load based on proxy 
> responsiveness
> > >>>>>> 2.) We might want to balance load based on a fairness 
> > >>>>>> mechanisms
> > >>>> (why
> > >>>>> not)
> > >>>>>> based on incoming request addresses
> > >>>>>> 3.) We might further want to fine tune the balancer to 
> > >>>>>> accommodate
> > >>>> some
> > >>>>>> larger customers (not exactly fair).
> > >>>>>>
> > >>>>>> What configurations would the load balancer need? Would the
> > >>>> originators
> > >>>>> of
> > >>>>>> the requests need to understand the programmed limits of the 
> > >>>>>> load balancer?
> > >>>>>>
> > >>>>>> NOW--- and MOST IMPORANTLY--- unlike in a HTTP load balancing
> > >>>>> application,
> > >>>>>> where there is only one load balancing location (at 
> the server
> > farm)
> > >>>> --
> > >>>>>> think about balancing load at other locations in the 
> middle of 
> > >>>>>> the network.
> > >>>>>> Assume here there are HTTP requests that MUST be proxied or
> > >>>> processed by
> > >>>>>> your network infrastructure. How would one balance 
> the load here?
> > >>>> What
> > >>>>>> would
> > >>>>>> the data requirements be? In this case, the 
> from/to/source/TLS
> > >>>> socket
> > >>>>>> connections are being multi-plexed at the proxy. So 
> where do I 
> > >>>>>> put
> > >>>> the
> > >>>>>> load
> > >>>>>> balancer? How do I configure it? What are the data 
> models that
> > could
> > >>>>>> support
> > >>>>>> such a multi-loadbalancer architecture?
> > >>>>>>
> > >>>>>> I urge you to continue developing your load balancer 
> concept....
> > >>>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Brian Rosen [mailto:[email-masked]]
> > >>>>>> Sent: Friday, August 04, 2006 12:01 PM
> > >>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer 
> > >>>>>> (mhammer)'; 'Hadriel Kaplan'
> > >>>>>> Cc: [email-masked]
> > >>>>>> Subject: RE: [Speermint] Secure RTP
> > >>>>>>
> > >>>>>> This isn't a telephone network.
> > >>>>>>
> > >>>>>> We typically DON'T have overload conditions on well 
> engineered
> > >>>> networks.
> > >>>>>> We
> > >>>>>> presently have some mighty fine self limiting issues with 
> > >>>>>> media,
> > but
> > >>>> if
> > >>>>> we
> > >>>>>> had proper QoS on the media, that would be, I think, very
> > sufficient
> > >>>>>> congestion control.  I've never seen a well engineered SIP 
> > >>>>>> based
> > >>>> network
> > >>>>>> where the signaling issues were a big problem.  It's 
> almost all 
> > >>>>>> in
> > >>>> the
> > >>>>>> media.
> > >>>>>>
> > >>>>>> I know all about "Americal Idol" night.  The numbers just 
> > >>>>>> aren't
> > >>>> scary
> > >>>>> any
> > >>>>>> more.
> > >>>>>>
> > >>>>>> Do the math.  A million BHCA is 278 calls per 
> second.  How many
> > >>>> million
> > >>>>> do
> > >>>>>> you want?  Rack up the servers (best make them stateless, but
> > that's
> > >>>> not
> > >>>>> a
> > >>>>>> problem).
> > >>>>>>
> > >>>>>> Sure, you need a load balancer.  Sure, you need a failover 
> > >>>>>> strategy
> > >>>> with
> > >>>>> a
> > >>>>>> good database.
> > >>>>>>
> > >>>>>> Now, every system has limits.  We have an answer for 
> those: busy.
> > >>>>>>
> > >>>>>> More importantly, we actually can use some telephone 
> > >>>>>> engineering to predict the traffic at the peering point.  We 
> > >>>>>> can engineer systems pretty straightforwardly to handle that 
> > >>>>>> traffic.  We DO need some
> > >>>> congestion
> > >>>>>> control mechanisms, because the peering mechanisms 
> we have do 
> > >>>>>> have
> > >>>>> finite
> > >>>>>> capacity.  However, I don't see much need for 
> telephone style 
> > >>>>>> call
> > >>>>> gapping
> > >>>>>> and only trivial metering.
> > >>>>>>
> > >>>>>> Today, we can build peering systems where the actual peering
> > happens
> > >>>> at
> > >>>>>> multiple places around the globe, where there is no effective
> > limits
> > >>>> on
> > >>>>>> signaling bandwith (or for that matter, media 
> bandwith) to and 
> > >>>>>> from
> > >>>> the
> > >>>>>> peering points.  We can have SIP proxies that perform the 
> > >>>>>> actual
> > >>>> peering
> > >>>>>> function (take a call, do a dip to determine where 
> it's going, 
> > >>>>>> use available DNS and other mechanisms to spread 
> load) that are 
> > >>>>>> similarly spread
> > >>>> out
> > >>>>> and
> > >>>>>> redundant enough that we get the kind of reliability 
> we expect.
> > And
> > >>>> we
> > >>>>>> can
> > >>>>>> engineer them to take load up to a static limit reliably.
> > >>>>>>
> > >>>>>> What can't we do?
> > >>>>>>
> > >>>>>> Brian
> > >>>>>>
> > >>>>>>
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: Geoff Devine [mailto:[email-masked]]
> > >>>>>>> Sent: Friday, August 04, 2006 11:35 AM
> > >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer);
> > >>>> Hadriel
> > >>>>>> Kaplan
> > >>>>>>> Cc: [email-masked]
> > >>>>>>> Subject: RE: [Speermint] Secure RTP
> > >>>>>>>
> > >>>>>>> Telephone networks don't and can't work that way.  They have
> > >>>> overload
> > >>>>>>> conditions and you absolutely must have a mechanism for 
> > >>>>>>> dealing
> > >>>> with
> > >>>>>>> them.  In the legacy network, you can take SS#7 CICs out of
> > >>>> service.
> > >>>>>>> You can implement call gapping and call metering.  We need
> > >>>> equivalent
> > >>>>>>> mechanisms and can likely do far better than best common 
> > >>>>>>> practices
> > >>>> in
> > >>>>>>> the legacy network.
> > >>>>>>>
> > >>>>>>> Geoff
> > >>>>>>>
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: Brian Rosen [mailto:[email-masked]]
> > >>>>>>> Sent: Friday, August 04, 2006 11:27 AM
> > >>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer 
> > >>>>>>> (mhammer)'; 'Hadriel Kaplan'
> > >>>>>>> Cc: [email-masked]
> > >>>>>>> Subject: RE: [Speermint] Secure RTP
> > >>>>>>>
> > >>>>>>> There is no evidence that you can't do this with the 
> > >>>>>>> mechanisms we
> > >>>>> have,
> > >>>>>>> and
> > >>>>>>> some that we can.  I believe in a contractual, 
> static, limit 
> > >>>>>>> on
> > >>>>> traffic
> > >>>>>>> between peers.  I don't think we need anything else.
> > >>>>>>>
> > >>>>>>> Brian
> > >>>>>>>
> > >>>>>>>> -----Original Message-----
> > >>>>>>>> From: Geoff Devine [mailto:[email-masked]]
> > >>>>>>>> Sent: Friday, August 04, 2006 11:01 AM
> > >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer);
> > >>>> Hadriel
> > >>>>>>> Kaplan
> > >>>>>>>> Cc: [email-masked]
> > >>>>>>>> Subject: RE: [Speermint] Secure RTP
> > >>>>>>>>
> > >>>>>>>> I'm with Patrick on this one.  The requirements for a
> > >>>> carrier-class
> > >>>>>>>> telephone network are quite different from the 
> requirements 
> > >>>>>>>> for
> > >>>> a
> > >>>>> web
> > >>>>>>>> server.  A web server doesn't have the moral and ethical
> > >>>> obligation
> > >>>>> to
> > >>>>>>>> ensure that the network is stable to complete 911 
> calls.  If 
> > >>>>>>>> the
> > >>>>>>> network
> > >>>>>>>> floods a soft switch or media gateway controller 
> with peering
> > >>>>> traffic
> > >>>>>>>> with no notion of congestion control, flow 
> control, or fault
> > >>>>>>> management,
> > >>>>>>>> you could kill somebody.  In the real world, resources are
> > >>>> finite,
> > >>>>> not
> > >>>>>>>> infinite and the network architecture has to take that into
> > >>>> account.
> > >>>>>>>> Geoff
> > >>>>>>>>
> > >>>>>>>> -----Original Message-----
> > >>>>>>>> From: Brian Rosen [mailto:[email-masked]]
> > >>>>>>>> Sent: Friday, August 04, 2006 10:20 AM
> > >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel
> > >>>> Kaplan'
> > >>>>>>>> Cc: [email-masked]
> > >>>>>>>> Subject: RE: [Speermint] Secure RTP
> > >>>>>>>>
> > >>>>>>>> I don't think any of this is something we are 
> chartered to do.
> > >>>> I
> > >>>>>>> don't
> > >>>>>>>> think it's needed, at least for a long time, 
> possibly forever.
> > >>>>>>>>
> > >>>>>>>> We have lots of experience building "farms" of servers that
> > >>>> handle
> > >>>>>>> HTTP
> > >>>>>>>> load, and I don't see any reason we shouldn't use all of 
> > >>>>>>>> those techniques to deal with SIP load.  I certainly don't 
> > >>>>>>>> see reasons to make the originator aware of 
> congestion issues 
> > >>>>>>>> at the terminating domain, beyond the contractual 
> limits that 
> > >>>>>>>> may be in place.
> > >>>>>>>>
> > >>>>>>>> I don't see any reason why peers should be aware of element
> > >>>>> failures.
> > >>>>>>>> We
> > >>>>>>>> clearly understand how to have a set of boxes that 
> appear to 
> > >>>>>>>> be
> > >>>> one
> > >>>>>>>> domain
> > >>>>>>>> name that are always available.
> > >>>>>>>>
> > >>>>>>>> I don't agree we need anything like a BGP for SIP 
> any time I 
> > >>>>>>>> can foresee.
> > >>>>>>>> The underlying network handles all the issues I am 
> aware of.
> > >>>> Given
> > >>>>>>> the
> > >>>>>>>> name
> > >>>>>>>> of a domain (or subdomain), normal SIP routing is quite
> > >>>> sufficient I
> > >>>>>>>> think.
> > >>>>>>>> We attempted this for a really simple subset of the problem
> > >>>> (gateway
> > >>>>>>>> selection, see TRIP), and we found it was not needed (or at
> > >>>> least
> > >>>>> the
> > >>>>>>>> complexity it introduced was not worth the value 
> it provided).
> > >>>>>>>>
> > >>>>>>>> Brian
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>> -----Original Message-----
> > >>>>>>>>> From: Patrick Melampy [mailto:[email-masked]]
> > >>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM
> > >>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel
> > >>>> Kaplan'
> > >>>>>>>>> Cc: [email-masked]
> > >>>>>>>>> Subject: RE: [Speermint] Secure RTP
> > >>>>>>>>>
> > >>>>>>>>> Brian,
> > >>>>>>>>>
> > >>>>>>>>> I agree with you. However some aspects are 
> protocol worthy.
> > >>>> Path
> > >>>>>>>>> determination -- or said another way -- the next 
> hop network
> > >>>> to
> > >>>>> use
> > >>>>>>> to
> > >>>>>>>>> reach
> > >>>>>>>>> a destination domain, must be partially provisioned, and
> > >>>> partially
> > >>>>>>>>> discovered. The discovery aspects are the dynamic aspects.
> > >>>> This
> > >>>>>>> would
> > >>>>>>>>> include things like:
> > >>>>>>>>> 	1.) Proxy Availability
> > >>>>>>>>> 	2.) Reachable Domains
> > >>>>>>>>> 	3.) Congested Domains
> > >>>>>>>>>
> > >>>>>>>>> In #1 -- proxy availability -- its very similar 
> to how SS7 
> > >>>>>>>>> is
> > >>>> used
> > >>>>>>> to
> > >>>>>>>> set
> > >>>>>>>>> the service states on each and every DS0. SS7 is the 
> > >>>>>>>>> protocol
> > >>>>>>> family,
> > >>>>>>>> and
> > >>>>>>>>> ISUP messages are sent to bring circuits in and out of
> > >>>> service.
> > >>>>> The
> > >>>>>>>> actual
> > >>>>>>>>> phone numbers to send down the circuit are 
> provisioned in SS7.
> > >>>> In
> > >>>>>>> our
> > >>>>>>>> case
> > >>>>>>>>> to have a well managed service, we need an equivalent to
> > >>>> "circuit
> > >>>>>>>> service
> > >>>>>>>>> state", which might be embodied as a call arrival rate,
> > >>>> maximum
> > >>>>>>>> sessions
> > >>>>>>>>> permitted, and maximum bandwidth to use.
> > >>>>>>>>>
> > >>>>>>>>> In #2 -- reachable domains -- Unlike the PSTN 
> which uses the
> > >>>> NPA-
> > >>>>> NXX
> > >>>>>>>>> routing
> > >>>>>>>>> models which are hierarchical and well understood, IP 
> > >>>>>>>>> domains
> > >>>> are
> > >>>>>>>>> amorphous
> > >>>>>>>>> and have very unpredictable intersection points. 
> This is why
> > >>>> BGP
> > >>>>> was
> > >>>>>>>>> invented for routing IP packets. The same is true for SIP
> > >>>> based
> > >>>>>>>> sessions.
> > >>>>>>>>> If
> > >>>>>>>>> there is to be peering, there will need to be a domain
> > >>>>> advertisement
> > >>>>>>>>> protocol that goes network to network. Thus a protocol is
> > >>>> required
> > >>>>>>>> here.
> > >>>>>>>>> In #3 -- congestion -- is dynamic and not 
> provisionable. It 
> > >>>>>>>>> is
> > >>>>>>>> directly
> > >>>>>>>>> related to #2, and the congestion detection and prevention
> > >>>>>>> mechanisms
> > >>>>>>>> must
> > >>>>>>>>> follow in reverse the paths established in #2.
> > >>>>>>>>>
> > >>>>>>>>> So I think we do have some protocol work here. I 
> also think 
> > >>>>>>>>> we
> > >>>>> need
> > >>>>>>> to
> > >>>>>>>>> leave
> > >>>>>>>>> to the individual networks, any and all decisions 
> on how to
> > >>>> run
> > >>>>>>> their
> > >>>>>>>>> networks, choose next networks, etc.
> > >>>>>>>>>
> > >>>>>>>>> -----Original Message-----
> > >>>>>>>>> From: Brian Rosen [mailto:[email-masked]]
> > >>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM
> > >>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan'
> > >>>>>>>>> Cc: [email-masked]
> > >>>>>>>>> Subject: RE: [Speermint] Secure RTP
> > >>>>>>>>>
> > >>>>>>>>> I think you have to be careful with the "p" word.
> > >>>>>>>>>
> > >>>>>>>>> I don't see the purpose in standardizing mechanisms for 
> > >>>>>>>>> peers
> > >>>>> within
> > >>>>>>> a
> > >>>>>>>>> peering federation to discover policies that apply to each
> > >>>> other.
> > >>>>>>>> That is
> > >>>>>>>>> provisioning, and there is usually not a lot of value in
> > >>>>>>> standardizing
> > >>>>>>>>> provisioning.  It's not dynamic (in fact, it's usually
> > >>>> specified
> > >>>>> by
> > >>>>>>>>> contract).
> > >>>>>>>>>
> > >>>>>>>>> What there is value in is in defining what 
> mechanisms exist 
> > >>>>>>>>> to
> > >>>>>>>> provision.
> > >>>>>>>>> So, for example, if one of the things peering 
> means is that
> > >>>> the
> > >>>>> rate
> > >>>>>>>> of
> > >>>>>>>>> calls is limited in some way, then we probably have to
> > >>>> standardize
> > >>>>>>> the
> > >>>>>>>>> definition of limiting, but not the way to determine what 
> > >>>>>>>>> the
> > >>>>> limit
> > >>>>>>>> is.
> > >>>>>>>>> In
> > >>>>>>>>> that way, the vendor who builds the proxy for 
> Peer A will be
> > >>>> able
> > >>>>> to
> > >>>>>>>> build
> > >>>>>>>>> in it the ability to meet the policy for Peer B.  This is 
> > >>>>>>>>> not
> > >>>> a
> > >>>>>>>> protocol
> > >>>>>>>>> issue, but it is what you would expect to find in a BCP.
> > >>>>>>>>>
> > >>>>>>>>> Similarly, it's not clear to me that a federation will
> > >>>> necessarily
> > >>>>>>>> define
> > >>>>>>>>> all of the potential policy mechanisms, or what 
> their values
> > >>>> are
> > >>>>>>>> limited
> > >>>>>>>>> to.
> > >>>>>>>>> It clearly WILL do that for some variables, and again, we
> > >>>> don't
> > >>>>> need
> > >>>>>>>>> automatic provisioning mechanisms to discover these.  Even
> > >>>> within
> > >>>>> a
> > >>>>>>>>> federation, I think it will be common that bilateral
> > >>>> arrangements
> > >>>>>>>> making
> > >>>>>>>>> further policy limitations will exist.
> > >>>>>>>>>
> > >>>>>>>>> Brian
> > >>>>>>>>>
> > >>>>>>>>>> -----Original Message-----
> > >>>>>>>>>> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > >>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM
> > >>>>>>>>>> To: Hadriel Kaplan; Brian Rosen
> > >>>>>>>>>> Cc: [email-masked]
> > >>>>>>>>>> Subject: RE: [Speermint] Secure RTP
> > >>>>>>>>>>
> > >>>>>>>>>> The focus of Speermint should be centered around whether 
> > >>>>>>>>>> one
> > >>>> can
> > >>>>>>>>>> discover the policies of a potential peer and 
> whether those
> > >>>>>>> policies
> > >>>>>>>> can
> > >>>>>>>>>> systematically describe the requirements on 
> multiple levels
> > >>>> that
> > >>>>>>>> will
> > >>>>>>>>>> need to be supported to have a successful communication 
> > >>>>>>>>>> with
> > >>>>> that
> > >>>>>>>> peer.
> > >>>>>>>>>> It is not about specifying X, Y, Z, or <name 
> your favorite
> > >>>> MUST
> > >>>>>>>> here>
> > >>>>>>>>>> Is is about whether the policy can be stated so one knows
> > >>>> that
> > >>>>> X,
> > >>>>>>> Y,
> > >>>>>>>> ...
> > >>>>>>>>>> is required to peer.
> > >>>>>>>>>>
> > >>>>>>>>>> I suspect that each federation will select 
> different MUSTs
> > >>>> for
> > >>>>>>> each
> > >>>>>>>>>> category of choices we come up with.
> > >>>>>>>>>>
> > >>>>>>>>>> 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
> 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 9 Aug 2006 17:37:36 -0400

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

> Sent: Wednesday, August 09, 2006 5:09 PM
> To: Brian Rosen; Patrick Melampy; Klaus Darilion
> Cc: [email-masked]