From speermint-bounces@ietf.org Tue Aug 01 02:28:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7njl-0003zn-FR; Tue, 01 Aug 2006 02:28:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7njk-0003ya-SI for speermint@ietf.org; Tue, 01 Aug 2006 02:28:16 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7njj-0003ZH-I5 for speermint@ietf.org; Tue, 01 Aug 2006 02:28:16 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 376401A381; Tue, 1 Aug 2006 08:28:14 +0200 (CEST) Date: Tue, 1 Aug 2006 08:28:14 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Voice codecs Message-ID: <20060801062813.GI19113@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <402F25FC1EB2BD44831F8A4A4F6DF9420548E4@MAIL02.cedarpointcom.com> <1154379918.19821.153.camel@montag.eng.level3.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1154379918.19821.153.camel@montag.eng.level3.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Yes, that makes a lot of sense. On 2006/07/31 23:07, Daryl Malas wrote: > I agree with Geoff's statement below. > > On Mon, 2006-07-31 at 14:52 -0400, Geoff Devine wrote: > > That sounds good to me. > > > > I'd point out that different federations are likely to have different > > ideas about what makes up the "minimal codec". In broadband-oriented > > federations, that would likely be G.711. In cellular-centric > > federations that are converging to IP transport, it's more likely to be > > their native client compression codec. If eBay created one based on > > Skype, it could very well be iLBC. > > > > I think we all agree that transcoding is something we want to avoid but > > we need to come up with an architecture that takes it into account. > > > > Geoff > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, July 31, 2006 2:39 PM > > To: Geoff Devine; 'Livingood, Jason'; speermint@ietf.org > > Cc: 'Greg Herlein'; 'Ed Okerson'; 'Lipford,Mark A [CTO]'; 'Klaus > > Darilion'; 'Henry Sinnreich' > > Subject: RE: [Speermint] Voice codecs > > > > Okay, makes sense. So, maybe it's more like, the federation agrees on > > minimal codec support, and participants must be prepared to transcode to > > that minimal set if their endpoints need it. > > > > I don't think you can mandate anything that guarantees only one > > transcode. > > However desirable it may be. > > -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 03:12:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7oQa-0007Nw-Qu; Tue, 01 Aug 2006 03:12:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7oQa-0007Nr-9E for speermint@ietf.org; Tue, 01 Aug 2006 03:12:32 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7oQY-0002u2-WD for speermint@ietf.org; Tue, 01 Aug 2006 03:12:32 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 01 Aug 2006 00:12:30 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k717CUtG006755; Tue, 1 Aug 2006 00:12:30 -0700 Received: from [192.168.1.2] (sjc-vpn4-560.cisco.com [10.21.82.48]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k717CUmQ014586; Tue, 1 Aug 2006 00:12:30 -0700 (PDT) In-Reply-To: <44C0910B.1010107@pernau.at> References: <953beacc0606190159h5e6c40b5u4b51251eaab3f7b@mail.gmail.com> <44C0910B.1010107@pernau.at> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Speermint] Just submitted draft-mahy-speermint-direct-peering-00 Date: Tue, 1 Aug 2006 00:12:32 -0700 To: Klaus Darilion X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1249; t=1154416350; x=1155280350; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Speermint]=20Just=20submitted=20draft-mahy-speermint-direct-pee ring-00; X=v=3Dcisco.com=3B=20h=3Dsp8osFRihvBMgsI4YWmofRnpJ30=3D; b=XzR/a2YHDGAuIwF2St5lFSel3PL0IHswJgFCqp+ca52AZhnpLygoYhDkACu9dAs5pY2+v6Rk VAUiNPLj8szDQ0p7kNDpCjzEgO9ZBKZSMUYR80X6O2KEMN8JhvHQZC/c; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Jul 21, 2006, at 1:32 AM, Klaus Darilion wrote: > Hi Rohan! > > Sorry for jumping in late - I had long holidays. I have a few > concerns about the TLS stuff: > > >> 4.1.6 Setup TLS connection >> Once a transport, port, and address are found, the initiating peer >> will open or find a reusable TLS connection to the peer. The >> initiating provider MUST verify the server certificate which >> SHOULD >> be rooted in a well-known certificate authority. The initiating > > How should the validation be done? You describe how the client > validation works, but not the server validation. > >> provider MUST be prepared to provide a TLS client certificate upon >> request during the TLS handshake. The client certificate MUST >> contain a DNS or URI choice type in the subjectAltName which >> corresponds to the domain asserted in the host production of >> the From >> header URI. The certificate SHOULD be valid and rooted in a well- Hmm - I missed this when I read Rohan's draft - nice catch. I think that if you use client certs, you would want to do it more like what is described in draft-mahy-sip-connect-reuse. My initial reaction would be don't use client certs in the first stab at this and add them later. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 04:19:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7pSr-00037h-Lf; Tue, 01 Aug 2006 04:18:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7pSq-00037Z-RH for speermint@ietf.org; Tue, 01 Aug 2006 04:18:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7oiQ-0007ix-M8 for speermint@ietf.org; Tue, 01 Aug 2006 03:30:58 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7oI4-0002Kg-Hs for speermint@ietf.org; Tue, 01 Aug 2006 03:03:48 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 01 Aug 2006 00:03:41 -0700 X-IronPort-AV: i="4.07,200,1151910000"; d="scan'208"; a="1843224505:sNHT31736984" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7173fjH002912; Tue, 1 Aug 2006 00:03:41 -0700 Received: from [192.168.1.2] (sjc-vpn4-560.cisco.com [10.21.82.48]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7173emQ011283; Tue, 1 Aug 2006 00:03:41 -0700 (PDT) In-Reply-To: <8587F175CDB3D741B58C79F67E8E09AD3BA453@PACDCEXCMB03.cable.comcast.com> References: <8587F175CDB3D741B58C79F67E8E09AD3BA453@PACDCEXCMB03.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <08336EE4-7FE3-4B65-BB2A-24BB8348764C@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: TLS for peering (was RE:Comments (RE:[speermint]requirementsdraftsubmitted)) Date: Tue, 1 Aug 2006 00:03:43 -0700 To: "Lee, Yiu" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=11863; t=1154415821; x=1155279821; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20TLS=20for=20peering=20(was=20RE=3AComments=09(RE=3A[speermint]re quirementsdraftsubmitted)); X=v=3Dcisco.com=3B=20h=3DUMvnFeSxLq6y4HrZHeHlctCo3n0=3D; b=fJDkzsevUt58gIJg8aTMD5M/IG7sCTlbB/aSM4xmwrWIGIR1/OOqsBx3jEATtjQbd/Uf+VBX giGAgMEcskTlRO9gFSBwLMK91Gka0vWNrD56hZjvMwOOp3ZHTBC9ioq5; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.4 (--) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org End to end certificates seem like they would be used with the S/MIME portion of SIP. I don't think anyone has been suggesting one should mandate that. I don't think we should confuse the TLS stuff with end to end security. With the TLS stuff you only compare the name in the certificate to the next hop that you are routing too. I think this is fairly well defined and lots of people have implemented that part of 3261. (I agree there are problems with implementing sips but again, I don't think anyone is talking about using sips here). I will note that many enterprises today peer IM with folks like MSN/ Yahoo/AOL using SIP and it is mostly done over TLS. Anyways, it sounds like we are coming to some agreement for the type of TLS thing we are interested - which is TLS transport and not end to end and not sips, RFC 3261 is adequately specified and implementable. Cullen On Jul 27, 2006, at 6:37 AM, Lee, Yiu wrote: > Hi Klaus, > > Sorry for mis-understanding your previous post. I agree that using the > domain for the end-to-end certification is broken in federation. > > Thanks for the clarification. > > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Thursday, July 27, 2006 2:55 AM > To: Lee, Yiu > Cc: Brian Rosen; speermint@ietf.org > Subject: Re: TLS for peering (was RE:Comments > (RE:[speermint]requirementsdraftsubmitted)) > > Lee, Yiu wrote: >> Hi, >> >> We agree that it is difficult to enforce hop-by-hop TLS session for >> SIPS in federation. I think we can't mandate SIPS, but we can require >> a TLS session between A and T and a TLS session between T and B. >> So we > >> can relax the requirement of SIPS but still provide some security to >> transport SIP messages. > > H! > > Looks like I'm still not clear enough - it was not talking about SIPS. > Only SIP which uses TLS between providers. IMO, TLS as transport is a > MUST, but the L5 certificate domain validation must not be a MUST. > > regards > klaus > >> >> Thanks, >> Yiu >> >> -----Original Message----- >> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >> Sent: Monday, July 24, 2006 11:28 AM >> To: Brian Rosen >> Cc: speermint@ietf.org >> Subject: Re: TLS for peering (was RE:Comments >> (RE:[speermint]requirementsdraftsubmitted)) >> >> Brian Rosen wrote: >>> I think you are misinterpreting 3261. Section 26.3.2.2 is >>> illustrating a simple SIP trapezoid call where the call goes from >>> atlanta.com to biloxi.com. If there is another intermediary, >>> biloxi.com would not be checking the From to see that it matched the >>> domain of the T proxy handling >> >> How will biloxi's proxy know if the request comes directly from >> atlanta or via an intermediary? You suggest that in this case the > From: >> validation is not used. Then we should remove the From: validation >> completely and validate only the Identity signature. >> >> The only thing I want to say is that Rohan's suggested From: >> validation >> >> .... The client certificate MUST >> contain a DNS or URI choice type in the subjectAltName which >> corresponds to the domain asserted in the host production of the >> From >> header URI.... >> >> can't be mandated. >> >>> the call. We all agree that TLS is underspecified in 3261. >>> There is > >>> some effort to address this shortcoming underway. >>> >>> If the path is A -> T -> B, then the mutual TLS cert validation is A >>> <-> T and T <-> B. In a peering system, the peers authenticate each >>> other within >> >> Yes. >> >>> the peering regime. If T accepts a call from A destined for B, then >>> it authenticates A as a peer which it accepts transit calls for B, >>> and >> >>> it authenticates B as a peer with whom it can send calls destined >>> for >> B. >> >> Yes - but the L5 domain validation can't be used. >> >> Maybe I express myself a little bit unclear. Thus, I describe it more >> detailed. >> >> When using SSL/TLS to secure a transport connection, there are >> several > >> validation steps. Some of the are done in the SSL stack, some of the >> are done in the application. I'm speaking of experience in using >> openssl and openser. >> >> During the TLS handshake, the peers verify the certificate presented >> by the other peer. The TLS stacks of the certificate is signed by a >> (to the >> stack) well known CA and it is valid (not expired). Let's call >> this L4 > >> certificate validation. >> >> Once the TLS connection is setup, the application can further >> validate > >> the certificate, e.g. if the domain presented in the certificate >> equals the domain in the request URI. Let's call this L5 certificate >> validation. >> >> To authenticate a peer, L5 is NOT necessary. For example, T and B are >> in the same federation. (B trusts T, T trusts B, and both of them >> trusts the federation's CA) >> >> If B receives a call from T, which is originally from an other >> service > >> provider (which T trusts), the domain in the From header is not >> important, as the authentication is based on the certificate. And B >> and T can bill each other because they were both authenticated >> (although there was no L5 validation). >> >> Conclusion: >> IMO TLS should be MUST, but the L5 domain validation (as suggested in >> RFC3261 and Rohan's draft) must be removed as it does not work in >> many > >> scenarios and further is not needed. Nevertheless, in scenarios where >> it is useful it should be used. But a MUST is wrong. >> >> regards >> Klaus >> >> >> >>> Brian >>> >>>> -----Original Message----- >>>> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >>>> Sent: Sunday, July 23, 2006 7:49 PM >>>> To: Brian Rosen >>>> Cc: speermint@ietf.org >>>> Subject: RE: TLS for peering (was RE: Comments >>>> (RE:[speermint]requirementsdraftsubmitted)) >>>> >>>> Hi Brian! >>>> >>>> On Fri, July 21, 2006 18:08, Brian Rosen said: >>>>> I believe it is the case that the link from one peer to another, >>>>> which >>>> is >>>>> generally between two proxies, can very reasonably be protected >>>>> with >>>> TLS, >>>>> with many current implementations, and with reasonable assumptions >>>>> about PKI. Specifically, if one of the parts of a federation was >>>>> an >> >>>>> agreement on a CA, then each peer can have a certificate that >>>>> other > >>>>> peers can verify. >>>>> I >>>>> believe all operations, including forwarding, if they work at all >>>>> across the peering system would work if it was TLS protected. >>>> Using TLS for encryption and TLS certificate validation works - but >>>> the L5 validation (validate the certificate domain names against >>>> the > >>>> domains in the SIP headers) does not work without mandating a >>>> B2BUA. >>>> >>>> TLS/SSL was invented for a very simple client-server system - HTTP. >>>> Let's compare HTTP with SIP: >>>> >>>> HTTP: >>>> 1 request - 1 (or more) responses. >>>> L5 validation: verify domain in browser's location bar against the >>>> domain in the server certificate - this is straight forward >>>> >>>> SIP: >>>> Multiple - bidirectional requests >>>> L5 validation: There are several headers which are used for routing >>>> and thus can be used for validation: requestURI, From, To, Via, >>>> Route, Contact. >>>> We can have in-dialog requests which are initiated in reverse >>>> direction of the original dialog setup. And each of this domain >>>> resolves to several domains (due to NAPTR, SRV, A resolution). This >>>> alone should have people think a little more before defining TLS >>>> for >> SIP. >>>> I am a fan of forwarding - and probably every transit service >>>> provider too. As transit will happen I will use the transit >>>> scenario > >>>> (simple forwarding without a B2BUA) to show that L5 validation is >>>> broken - and I would be very very happy if someone can show that >>>> I'm >> wrong. >>>> A want to call B. There is no direct peering agreement. Thus A >>>> sends > >>>> the call to it's transit provider T. (only the signaling between >>>> the > >>>> proxies is shown) >>>> >>>> A->T >>>> INVITE sip:B@B >>>> From: sip:A@A >>>> To: sip:B@B >>>> Contact: user@phone >>>> Record-Route: sip:A >>>> >>>> Cert validation according to RFC3261 section 26.3.2.2: >>>> T will show a TLS certificate for T (not for B) - thus, when A >>>> validates T's certificate, the validation will fail. IMO this >>>> can be > >>>> fixed by adding a Route: header with sip:T, but this is nowhere >> mentioned in RFC 3261. >>>> T->B >>>> INVITE sip:B@B >>>> From: sip:A@A >>>> To: sip:B@B >>>> Contact: user@phone >>>> Record-Route: sip:T >>>> Record-Route: sip:A >>>> >>>> Cert validation according to RFC3261 section 26.3.2.2: >>>> B should validate the domain in the From header (A) aginst the >>>> domain >> >>>> in the client's certificate (T) --> it will fail. >>>> >>>> Now let's assume the previous validation have succeeded and B sends >>>> a >> >>>> BYE request to A, and the TLS connection was dropped and must be >>>> re-established: >>>> >>>> B->T >>>> BYE name@1.2.3.4 >>>> From: sip:B@B >>>> To: sip:A@A >>>> Route: sip:T >>>> Route: sip:A >>>> >>>> How should T's certificate be validated? Probably against the >>>> domain > >>>> in the topmost Route header - but again: This is nowhere specified. >>>> >>>> T->A >>>> BYE name@1.2.3.4 >>>> From: sip:B@B >>>> To: sip:A@A >>>> Route: sip:A >>>> >>>> Again, probably T should use the domain in the Route header for >>>> certificate validation. But A can't validate the certificate's >>>> domain >> >>>> (T) against the From header (B) - it will fail. >>>> >>>> Similar problem arise in a forwarding scenario - A-->B which >>>> forwards >> >>>> it's call to C. The suggested L5 validation will fail (except B >>>> uses > >>>> a B2BUA, and IMO a B2BUA should not be mandatory). >>>> >>>>> This does not assume sips works (whatever that means), and does >>>>> not >>>> assume >>>>> endpoints implement TLS, or either the originating or terminating >>>> domains >>>>> deploy TLS anywhere else. >>>>> >>>>> It does provide a reasonable degree of protection across the >>>>> peering >> >>>>> point, which I think is a good thing. >>>> Yes, TLS provides protection, but we should not specify a broken L5 >>>> certificate validation. >>>> >>>>> Having lived with protocols that offered options like IPsec and >>>>> VPNs >> >>>>> and other mechanisms, I think that despite the fact that you can, >>>>> in >> >>>>> theory, create a satisfactory security arrangement, it is >>>>> exceedingly hard to >>>> make >>>>> it actually work except for cases where there is an entity that >>>> completely >>>>> controls all aspects of the peering. That just isn't the case for >>>>> what >>>> I >>>>> think we are trying to specify here (such cases don't need IETF >>>>> standardization). Thus, I personally think mandating TLS is a >>>>> good >>>> thing, >>>>> achievable, and reasonable. That's a MUST IMPLEMENT, not a must >>>>> deploy; >>>> Yes, I agree. I want TLS in the specs too - but we have to specify >>>> the validation more precisely and it has to work in other scenarios >>>> than a basic call too. Otherwise people wont use it. >>>> >>>> regards >>>> Klaus >> >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 04:27:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7pbZ-0000FE-56; Tue, 01 Aug 2006 04:27:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7pbY-0000F9-Hv for speermint@ietf.org; Tue, 01 Aug 2006 04:27:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7oiQ-0007ix-K0 for speermint@ietf.org; Tue, 01 Aug 2006 03:30:58 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7oI5-0002Kn-Qd for speermint@ietf.org; Tue, 01 Aug 2006 03:03:49 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-6.cisco.com with ESMTP; 01 Aug 2006 00:03:43 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7173gjq018036; Tue, 1 Aug 2006 00:03:42 -0700 Received: from [192.168.1.2] (sjc-vpn4-560.cisco.com [10.21.82.48]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7173emR011283; Tue, 1 Aug 2006 00:03:42 -0700 (PDT) In-Reply-To: <44C50A97.3080402@pernau.at> References: <44C50A97.3080402@pernau.at> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Speermint] TLs performance Date: Tue, 1 Aug 2006 00:03:49 -0700 To: Klaus Darilion X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1143; t=1154415822; x=1155279822; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Speermint]=20TLs=20performance; X=v=3Dcisco.com=3B=20h=3Do+yTF7da5zDLmPpiFZ6iZbdb+eQ=3D; b=cg3xHykBYyM+nGRsIkO2gLH0XaU+LfZCqdQb7D5WMOmAX8t4wcn7mYCSL29d+eTEYbUDWbSK WuMAaszCEsnrBe4+5OHomX3V8sggAniT0hih6qxSRFHx0D669YqVzp0Y; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.4 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Klaus, first of all thank you for producing some real results we can discuss. Just to validate some of your results - this is not the first time I have seen performance results where TLS (or more specifically TCP) has better performance that UDP. I have seen this on other products too and when I think about it, it is not that surprising. Cullen On Jul 24, 2006, at 10:59 AM, Klaus Darilion wrote: > Hi! > > I made some tests with sipp+openser: > > scenario: > > UAC <-TLS-> openser <-TLS-> UAS (all of them got its own 2xP3 > 1,26GHz machine, linked with 100MBit). Simple forwarding > configuration (like a loadbalancer), no DNS lookups or DB queries. > > UDP: ~620 cps > TLS: ~680 cps (single TLS connection) > > cps=calls per second = INVITE-180-200-OK-ACK-BYE-200 > > I think TLS performs better as because of UDP retransmissions, > which "kills" the proxy if it becomes slow. > > More data when I have it. > > regards > klaus > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 05:39:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7qil-0007M5-NU; Tue, 01 Aug 2006 05:39:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7qij-0007La-NB for speermint@ietf.org; Tue, 01 Aug 2006 05:39:25 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7qih-0003AZ-D8 for speermint@ietf.org; Tue, 01 Aug 2006 05:39:25 -0400 Received: from [192.168.0.7] (81-178-58-134.dsl.pipex.com [81.178.58.134]) by ranger.systems.pipex.net (Postfix) with ESMTP id B579FE000255; Tue, 1 Aug 2006 10:39:21 +0100 (BST) Message-ID: <44CF2122.1010208@bulukucing.org> Date: Tue, 01 Aug 2006 10:38:42 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Speermint] TLs performance References: <44C50A97.3080402@pernau.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi all, just to share my data, fwiw. In my benchmark, TCP (with single connection) performs almost consistently better than UDP in transactions and calls processing, but only when UAC and UAS are in local machine. When UAC and UAS are separated into different boxes, TCP performance is only about half of UDP performance. For me, my data makes perfect sense, because in local machine, TCP transactions has lower cost to setup (e.g. less timers), so it should be faster. While on the network, the TCP round-trip probably prevents transaction to complete as fast as the UDP version, so TCP should be slower. So I'm a bit surprised that in your benchmarks TCP outperformed UDP, but perhaps it's just some tuning in the socket settings (any info on these will be appreciated). Btw my benchmark report can be found here: http://www.pjsip.org/testing/0.5.6.5/bench.htm -benny Cullen Jennings wrote: > > Klaus, first of all thank you for producing some real results we can > discuss. Just to validate some of your results - this is not the first > time I have seen performance results where TLS (or more specifically > TCP) has better performance that UDP. I have seen this on other products > too and when I think about it, it is not that surprising. > > Cullen > > > On Jul 24, 2006, at 10:59 AM, Klaus Darilion wrote: > >> Hi! >> >> I made some tests with sipp+openser: >> >> scenario: >> >> UAC <-TLS-> openser <-TLS-> UAS (all of them got its own 2xP3 1,26GHz >> machine, linked with 100MBit). Simple forwarding configuration (like a >> loadbalancer), no DNS lookups or DB queries. >> >> UDP: ~620 cps >> TLS: ~680 cps (single TLS connection) >> >> cps=calls per second = INVITE-180-200-OK-ACK-BYE-200 >> >> I think TLS performs better as because of UDP retransmissions, which >> "kills" the proxy if it becomes slow. >> >> More data when I have it. >> >> regards >> klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 05:57:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7r01-0005hp-R9; Tue, 01 Aug 2006 05:57:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7r00-0005ae-8t for speermint@ietf.org; Tue, 01 Aug 2006 05:57:16 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7qzy-0006Z8-PO for speermint@ietf.org; Tue, 01 Aug 2006 05:57:16 -0400 Received: from frmail28.netfr.alcatel.fr (frmail28.netfr.alcatel.fr [155.132.251.28]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k719vCYB010912; Tue, 1 Aug 2006 11:57:12 +0200 Received: from [139.54.131.75] ([139.54.131.75]) by frmail28.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006080111571062:3889 ; Tue, 1 Aug 2006 11:57:10 +0200 Message-ID: <44CF2573.9010703@alcatel.fr> Date: Tue, 01 Aug 2006 11:57:07 +0200 From: Thomas.Froment@alcatel.fr User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Klaus Darilion Subject: Re: [Speermint] TLs performance References: <44C50A97.3080402@pernau.at> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on FRMAIL28/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 08/01/2006 11:57:10, Serialize by Router on FRMAIL28/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 08/01/2006 11:57:11, Serialize complete at 08/01/2006 11:57:11 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org "I think TLS performs better as because of UDP retransmissions, which "kills" the proxy if it becomes slow. " That's why I think it is not possible to make performance testing in UDP without activating some kind of flow regulation mechanism... overwise the results are very difficult to interpret: what does it mean to test a proxy overloaded by retransmissions?.... Should always test performances on a stable rate, overwise this is a resistance/torture test... Cullen Jennings wrote: > > Klaus, first of all thank you for producing some real results we can > discuss. Just to validate some of your results - this is not the > first time I have seen performance results where TLS (or more > specifically TCP) has better performance that UDP. I have seen this on > other products too and when I think about it, it is not that surprising. > > Cullen > > > On Jul 24, 2006, at 10:59 AM, Klaus Darilion wrote: > >> Hi! >> >> I made some tests with sipp+openser: >> >> scenario: >> >> UAC <-TLS-> openser <-TLS-> UAS (all of them got its own 2xP3 1,26GHz >> machine, linked with 100MBit). Simple forwarding configuration (like >> a loadbalancer), no DNS lookups or DB queries. >> >> UDP: ~620 cps >> TLS: ~680 cps (single TLS connection) >> >> cps=calls per second = INVITE-180-200-OK-ACK-BYE-200 >> >> _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 08:33:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7tR1-0005GE-Gi; Tue, 01 Aug 2006 08:33:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7tR0-0005G9-St for speermint@ietf.org; Tue, 01 Aug 2006 08:33:18 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7tR0-0000cg-Ex for speermint@ietf.org; Tue, 01 Aug 2006 08:33:18 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G7tQv-0008Bn-N3; Tue, 01 Aug 2006 07:33:14 -0500 From: "Brian Rosen" To: "'Drage, Keith \(Keith\)'" , Subject: RE: [Speermint] Voice codecs Date: Tue, 1 Aug 2006 08:33:13 -0400 Message-ID: <054901c6b566$aa47c640$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5D1A7985295922448D5550C94DE291801E433D@DEEXC1U01.de.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXgAJXsKmAACa16AAAAir3QACN3DBAAAcZk0A== X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I read this a couple of times before I grokked it. I think you are right in the big picture, but maybe not in the practical world we live in now. Ideally, you would like to "search" the available transcoder inventory among the originating, terminating, and possibly services-within-the-peering-fabric domains to see if you can find an available resource that bridge directly between the endpoint's actual capabilities. We don't have any protocol mechanisms which would do that. That involves a distributed discovery mechanism with two lists -- find me an available transcoder that can bridge between any codec on list A and any codec on list B, and while we're at it, optimize two such discoveries simultaneously. Ideally, you would like both sides of one call to go through the same resource, and not two different ones. Do we need to get to this new protocol before we have something functional in SPEERMINT? I think not. Many interdomain wireless call today would transcode twice (from one wireless codec to G.711, across the PSTN to another carrier and transcode from G.711 to its codec). We often do this even if they are the same codec on both carriers. I suspect we do the same thing for now, and work towards a better way. I think the better way is not a SPEERMINT charter item, but perhaps we could write a requirements doc for someone else. It's an interesting problem. Brian > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Tuesday, August 01, 2006 8:13 AM > To: Brian Rosen; speermint@ietf.org > Subject: RE: [Speermint] Voice codecs > > That is why I think that if we mandate transcoders, we should also make > sure we have studied the issues to allow us to have the minimum number > of transcodes, and if that means new protocol, then so be it. > > Regards > > Keith > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: 31 July 2006 19:39 > > To: 'Geoff Devine'; 'Livingood, Jason'; speermint@ietf.org > > Cc: 'Ed Okerson'; 'Lipford,Mark A [CTO]' > > Subject: RE: [Speermint] Voice codecs > > > > Okay, makes sense. So, maybe it's more like, the federation > > agrees on minimal codec support, and participants must be > > prepared to transcode to that minimal set if their endpoints need it. > > > > I don't think you can mandate anything that guarantees only > > one transcode. > > However desirable it may be. > > > > Brian > > > > > -----Original Message----- > > > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > > > Sent: Monday, July 31, 2006 2:28 PM > > > To: Livingood, Jason; Brian Rosen; speermint@ietf.org > > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Klaus Darilion; > > > Henry Sinnreich > > > Subject: RE: [Speermint] Voice codecs > > > > > > In your codec architecture example, you say that the originator may > > > have some strange and wonderful codec that is not supported by the > > > peer network. I'd point out that the other 50% of the time, that > > > endpoint is the terminator in the call, not the originator. > > I would > > > think that transcoding would be something that is > > negotiated as part > > > of the peering business arrangement. In terms of $ per port, > > > transcoding is a relatively costly operation and somebody > > is going to > > > have to purchase and operate the transcoding equipment. > > > > > > Transcoding, like echo cancellation, is something you want to avoid > > > doing extra times since it degrades voice quality. A path > > that goes, > > > say, from AMR to G.711 to iLBC is going to have a lower MOS > > score than > > > a path that goes AMR to iLBC. Ideally, you don't want to > > transcode at > > > all since that gives you the least impairment and the least delay. > > > > > > Geoff > > > > > > -----Original Message----- > > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Sent: Monday, July 31, 2006 9:47 AM > > > To: Brian Rosen; speermint@ietf.org > > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Geoff Devine; > > > Klaus Darilion; Henry Sinnreich > > > Subject: RE: [Speermint] Voice codecs > > > > > > Brian wrote: > > > > > > > I did say something in my message which may have escaped some > > > > notice. I said "origination side". One of the things > > you have to > > > > get right on any kind of part like transcoding is what > > assumptions > > > > are made. You can assume the origination side does it, the > > > > destination side does it or the peering fabric itself does it. I > > > > think it's essential to choose one, or we won't have > > > > interoperability. More than one is always possible, but at least > > > > one is required. I think origination side is best: it means that > > > > across the peering fabric, there is at least one common codec. > > > > > > So, it is looking convincingly now that WG consensus is against a > > > lowest common denominator codec. ;-) > > > > > > But Brian raises an interesting question here. Somewhere in our > > > drafts (several of them) we *may* need to consider optional > > inclusion > > > of a transcoding function and describe how it might be > > implemented. > > > When we take up that discussion, I think Brian poses an > > interesting question. > > > > > > If I consider it from the perspective of some operator that > > is using > > > all the major codecs in my endpoints, and someone connects > > with some > > > obscure codec then I can see an arguement for having the originator > > > perform any transcoding. (And if that is indeed the case, > > it may even > > > be like lots of other stuff an originating network may or > > may not do > > > that we don't care about and call out of scope.) > > > > > > Jason > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 10:24:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7vAc-00068t-AL; Tue, 01 Aug 2006 10:24:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7vAa-0005yS-O4 for speermint@ietf.org; Tue, 01 Aug 2006 10:24:28 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7vAZ-0006Xu-Cc for speermint@ietf.org; Tue, 01 Aug 2006 10:24:28 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k71EOYuc028161 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 1 Aug 2006 07:24:35 -0700 From: "Richard Shockey" To: "'Cullen Jennings'" , "'Lee, Yiu'" Subject: RE: TLS for peering (wasRE:Comments (RE:[speermint]requirementsdraftsubmitted)) Date: Tue, 1 Aug 2006 10:24:08 -0400 Message-ID: <00ec01c6b576$27b612d0$23f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca1QzJr3gh6lYaBR8q8N4KMqmkfiAAMpMHg In-Reply-To: <08336EE4-7FE3-4B65-BB2A-24BB8348764C@cisco.com> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, August 01, 2006 3:04 AM > To: Lee, Yiu > Cc: speermint@ietf.org > Subject: Re: TLS for peering (wasRE:Comments > (RE:[speermint]requirementsdraftsubmitted)) > > > End to end certificates seem like they would be used with the S/MIME > portion of SIP. I don't think anyone has been suggesting one should > mandate that. I don't think we should confuse the TLS stuff with end > to end security. > > With the TLS stuff you only compare the name in the certificate to > the next hop that you are routing too. I think this is fairly well > defined and lots of people have implemented that part of 3261. (I > agree there are problems with implementing sips but again, I don't > think anyone is talking about using sips here). > > I will note that many enterprises today peer IM with folks like MSN/ > Yahoo/AOL using SIP and it is mostly done over TLS. Yes but that is edge to edge, not end to end. I'm convinced that we are going to make very little progress unless we state that the first iteration here of speerming is really edge to edge oriented. I agree that anything that looks like end to end is rat hole #32 > > Anyways, it sounds like we are coming to some agreement for the type > of TLS thing we are interested - which is TLS transport and not end > to end and not sips, RFC 3261 is adequately specified and implementable. Yes .. > > Cullen > > > On Jul 27, 2006, at 6:37 AM, Lee, Yiu wrote: > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 10:42:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7vSE-0002aM-Mg; Tue, 01 Aug 2006 10:42:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7vSD-0002VY-MP for speermint@ietf.org; Tue, 01 Aug 2006 10:42:41 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7vSD-0007ih-2A for speermint@ietf.org; Tue, 01 Aug 2006 10:42:41 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k71Ege1V030911 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 1 Aug 2006 07:42:45 -0700 From: "Richard Shockey" To: "'Brian Rosen'" , "'Drage, Keith \(Keith\)'" , Subject: RE: [Speermint] Voice codecs Date: Tue, 1 Aug 2006 10:42:15 -0400 Message-ID: <00ed01c6b578$b3b05aa0$23f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXgAJXsKmAACa16AAAAir3QACN3DBAAAcZk0AAEW4ow In-Reply-To: <054901c6b566$aa47c640$640fa8c0@cis.neustar.com> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Interesting problem but easily solvable. The issue as I see it is we have to separate anything that looks like policy and capabilities discovery from the basic issue if connectivity. Now one issue we have is how do you discover the acceptable codecs for a particular federation. OK that is a simple database issue. Presumably based on the domain part of the SIP URI how do you issue a query? I'm starting to think IRIS begins to look good here as the mechanism for discovery of policy related information re a TN or a domain. When we did some work in the US ENUM forum we decided to specify that the US ENUM implementation in e164.arpa would use a IRIS database for what would essentially be Line Level and or Whois like data associated with a E.164 number. We knew this would eventually be essential. Say you cannot connect to a particular URI' what is the contact data associated with that URI you need to report a problem etc. It would seem perfectly reasonable to construct various XML schemas various capabilities of federations and then query those. You have to have a response mechanism that is structured and right now IRIS is the best candidate we have for structured database queries. http://www.ietf.org/html.charters/crisp-charter.html > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, August 01, 2006 8:33 AM > To: 'Drage, Keith (Keith)'; speermint@ietf.org > Subject: RE: [Speermint] Voice codecs > > I read this a couple of times before I grokked it. I think you are right > in > the big picture, but maybe not in the practical world we live in now. > > Ideally, you would like to "search" the available transcoder inventory > among > the originating, terminating, and possibly > services-within-the-peering-fabric domains to see if you can find an > available resource that bridge directly between the endpoint's actual > capabilities. We don't have any protocol mechanisms which would do that. > That involves a distributed discovery mechanism with two lists -- find me > an > available transcoder that can bridge between any codec on list A and any > codec on list B, and while we're at it, optimize two such discoveries > simultaneously. Ideally, you would like both sides of one call to go > through the same resource, and not two different ones. > > Do we need to get to this new protocol before we have something functional > in SPEERMINT? I think not. Many interdomain wireless call today would > transcode twice (from one wireless codec to G.711, across the PSTN to > another carrier and transcode from G.711 to its codec). We often do this > even if they are the same codec on both carriers. I suspect we do the > same > thing for now, and work towards a better way. I think the better way is > not > a SPEERMINT charter item, but perhaps we could write a requirements doc > for > someone else. > > It's an interesting problem. > > Brian > > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Tuesday, August 01, 2006 8:13 AM > > To: Brian Rosen; speermint@ietf.org > > Subject: RE: [Speermint] Voice codecs > > > > That is why I think that if we mandate transcoders, we should also make > > sure we have studied the issues to allow us to have the minimum number > > of transcodes, and if that means new protocol, then so be it. > > > > Regards > > > > Keith > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: 31 July 2006 19:39 > > > To: 'Geoff Devine'; 'Livingood, Jason'; speermint@ietf.org > > > Cc: 'Ed Okerson'; 'Lipford,Mark A [CTO]' > > > Subject: RE: [Speermint] Voice codecs > > > > > > Okay, makes sense. So, maybe it's more like, the federation > > > agrees on minimal codec support, and participants must be > > > prepared to transcode to that minimal set if their endpoints need it. > > > > > > I don't think you can mandate anything that guarantees only > > > one transcode. > > > However desirable it may be. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > > > > Sent: Monday, July 31, 2006 2:28 PM > > > > To: Livingood, Jason; Brian Rosen; speermint@ietf.org > > > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Klaus Darilion; > > > > Henry Sinnreich > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > In your codec architecture example, you say that the originator may > > > > have some strange and wonderful codec that is not supported by the > > > > peer network. I'd point out that the other 50% of the time, that > > > > endpoint is the terminator in the call, not the originator. > > > I would > > > > think that transcoding would be something that is > > > negotiated as part > > > > of the peering business arrangement. In terms of $ per port, > > > > transcoding is a relatively costly operation and somebody > > > is going to > > > > have to purchase and operate the transcoding equipment. > > > > > > > > Transcoding, like echo cancellation, is something you want to avoid > > > > doing extra times since it degrades voice quality. A path > > > that goes, > > > > say, from AMR to G.711 to iLBC is going to have a lower MOS > > > score than > > > > a path that goes AMR to iLBC. Ideally, you don't want to > > > transcode at > > > > all since that gives you the least impairment and the least delay. > > > > > > > > Geoff > > > > > > > > -----Original Message----- > > > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > > Sent: Monday, July 31, 2006 9:47 AM > > > > To: Brian Rosen; speermint@ietf.org > > > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Geoff Devine; > > > > Klaus Darilion; Henry Sinnreich > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > Brian wrote: > > > > > > > > > I did say something in my message which may have escaped some > > > > > notice. I said "origination side". One of the things > > > you have to > > > > > get right on any kind of part like transcoding is what > > > assumptions > > > > > are made. You can assume the origination side does it, the > > > > > destination side does it or the peering fabric itself does it. I > > > > > think it's essential to choose one, or we won't have > > > > > interoperability. More than one is always possible, but at least > > > > > one is required. I think origination side is best: it means that > > > > > across the peering fabric, there is at least one common codec. > > > > > > > > So, it is looking convincingly now that WG consensus is against a > > > > lowest common denominator codec. ;-) > > > > > > > > But Brian raises an interesting question here. Somewhere in our > > > > drafts (several of them) we *may* need to consider optional > > > inclusion > > > > of a transcoding function and describe how it might be > > > implemented. > > > > When we take up that discussion, I think Brian poses an > > > interesting question. > > > > > > > > If I consider it from the perspective of some operator that > > > is using > > > > all the major codecs in my endpoints, and someone connects > > > with some > > > > obscure codec then I can see an arguement for having the originator > > > > perform any transcoding. (And if that is indeed the case, > > > it may even > > > > be like lots of other stuff an originating network may or > > > may not do > > > > that we don't care about and call out of scope.) > > > > > > > > Jason > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 11:17:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7w0J-000692-Oz; Tue, 01 Aug 2006 11:17:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7w0I-00068m-Da for speermint@ietf.org; Tue, 01 Aug 2006 11:17:54 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7w0H-0001Dr-Rd for speermint@ietf.org; Tue, 01 Aug 2006 11:17:54 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G7w09-0003GV-SO; Tue, 01 Aug 2006 10:17:46 -0500 From: "Brian Rosen" To: , "'Drage, Keith \(Keith\)'" , Subject: RE: [Speermint] Voice codecs Date: Tue, 1 Aug 2006 11:17:42 -0400 Message-ID: <057901c6b57d$a74f2840$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <00ed01c6b578$b3b05aa0$23f0a544@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXgAJXsKmAACa16AAAAir3QACN3DBAAAcZk0AAEW4owAAFlG0A= X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Nope, it's more interesting than that. Sure, each domain has a policy of what codecs it allows on its network, but if you want to avoid double transcoding, you want to know, really, what is happening on both sides of the peering, to see if you can optimize it. Suppose A allows g.711 and AMR, and B allows g.711 and EvRC. You know what is really going to happen. The AMR handsets get transcoded to g.711 on A, the EvRC handsets get transcoded to g.711 on B and they "work". But what you really want to know is whether there is a transcoder available on either side (or in the middle) for EvRC to AMR and vice versa. If that example doesn't convince you, suppose A's list was g.711 and AMR-WB and B's list was g.711 and VMR-WB. So, you don't want to force A or B to transcode to the federation's list if you can figure out what the "right" thing to do is. You want to take the list of codecs the originating endpoint really can do, and the similar list from the terminating endpoint, and see if you can discover a resource that can bridge across the lists. This isn't a policy issue really. Brian > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Tuesday, August 01, 2006 10:42 AM > To: 'Brian Rosen'; 'Drage, Keith (Keith)'; speermint@ietf.org > Subject: RE: [Speermint] Voice codecs > > > > Interesting problem but easily solvable. > > The issue as I see it is we have to separate anything that looks like > policy > and capabilities discovery from the basic issue if connectivity. > > Now one issue we have is how do you discover the acceptable codecs for a > particular federation. > > OK that is a simple database issue. Presumably based on the domain part of > the SIP URI how do you issue a query? > > I'm starting to think IRIS begins to look good here as the mechanism for > discovery of policy related information re a TN or a domain. > > When we did some work in the US ENUM forum we decided to specify that the > US > ENUM implementation in e164.arpa would use a IRIS database for what would > essentially be Line Level and or Whois like data associated with a E.164 > number. > > We knew this would eventually be essential. Say you cannot connect to a > particular URI' what is the contact data associated with that URI you need > to report a problem etc. > > It would seem perfectly reasonable to construct various XML schemas > various > capabilities of federations and then query those. You have to have a > response mechanism that is structured and right now IRIS is the best > candidate we have for structured database queries. > > > http://www.ietf.org/html.charters/crisp-charter.html > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, August 01, 2006 8:33 AM > > To: 'Drage, Keith (Keith)'; speermint@ietf.org > > Subject: RE: [Speermint] Voice codecs > > > > I read this a couple of times before I grokked it. I think you are > right > > in > > the big picture, but maybe not in the practical world we live in now. > > > > Ideally, you would like to "search" the available transcoder inventory > > among > > the originating, terminating, and possibly > > services-within-the-peering-fabric domains to see if you can find an > > available resource that bridge directly between the endpoint's actual > > capabilities. We don't have any protocol mechanisms which would do > that. > > That involves a distributed discovery mechanism with two lists -- find > me > > an > > available transcoder that can bridge between any codec on list A and any > > codec on list B, and while we're at it, optimize two such discoveries > > simultaneously. Ideally, you would like both sides of one call to go > > through the same resource, and not two different ones. > > > > Do we need to get to this new protocol before we have something > functional > > in SPEERMINT? I think not. Many interdomain wireless call today would > > transcode twice (from one wireless codec to G.711, across the PSTN to > > another carrier and transcode from G.711 to its codec). We often do > this > > even if they are the same codec on both carriers. I suspect we do the > > same > > thing for now, and work towards a better way. I think the better way is > > not > > a SPEERMINT charter item, but perhaps we could write a requirements doc > > for > > someone else. > > > > It's an interesting problem. > > > > Brian > > > > > -----Original Message----- > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > Sent: Tuesday, August 01, 2006 8:13 AM > > > To: Brian Rosen; speermint@ietf.org > > > Subject: RE: [Speermint] Voice codecs > > > > > > That is why I think that if we mandate transcoders, we should also > make > > > sure we have studied the issues to allow us to have the minimum number > > > of transcodes, and if that means new protocol, then so be it. > > > > > > Regards > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: 31 July 2006 19:39 > > > > To: 'Geoff Devine'; 'Livingood, Jason'; speermint@ietf.org > > > > Cc: 'Ed Okerson'; 'Lipford,Mark A [CTO]' > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > Okay, makes sense. So, maybe it's more like, the federation > > > > agrees on minimal codec support, and participants must be > > > > prepared to transcode to that minimal set if their endpoints need > it. > > > > > > > > I don't think you can mandate anything that guarantees only > > > > one transcode. > > > > However desirable it may be. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > > > > > Sent: Monday, July 31, 2006 2:28 PM > > > > > To: Livingood, Jason; Brian Rosen; speermint@ietf.org > > > > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Klaus > Darilion; > > > > > Henry Sinnreich > > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > > > In your codec architecture example, you say that the originator > may > > > > > have some strange and wonderful codec that is not supported by the > > > > > peer network. I'd point out that the other 50% of the time, that > > > > > endpoint is the terminator in the call, not the originator. > > > > I would > > > > > think that transcoding would be something that is > > > > negotiated as part > > > > > of the peering business arrangement. In terms of $ per port, > > > > > transcoding is a relatively costly operation and somebody > > > > is going to > > > > > have to purchase and operate the transcoding equipment. > > > > > > > > > > Transcoding, like echo cancellation, is something you want to > avoid > > > > > doing extra times since it degrades voice quality. A path > > > > that goes, > > > > > say, from AMR to G.711 to iLBC is going to have a lower MOS > > > > score than > > > > > a path that goes AMR to iLBC. Ideally, you don't want to > > > > transcode at > > > > > all since that gives you the least impairment and the least delay. > > > > > > > > > > Geoff > > > > > > > > > > -----Original Message----- > > > > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > > > Sent: Monday, July 31, 2006 9:47 AM > > > > > To: Brian Rosen; speermint@ietf.org > > > > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Geoff Devine; > > > > > Klaus Darilion; Henry Sinnreich > > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > > > Brian wrote: > > > > > > > > > > > I did say something in my message which may have escaped some > > > > > > notice. I said "origination side". One of the things > > > > you have to > > > > > > get right on any kind of part like transcoding is what > > > > assumptions > > > > > > are made. You can assume the origination side does it, the > > > > > > destination side does it or the peering fabric itself does it. > I > > > > > > think it's essential to choose one, or we won't have > > > > > > interoperability. More than one is always possible, but at > least > > > > > > one is required. I think origination side is best: it means > that > > > > > > across the peering fabric, there is at least one common codec. > > > > > > > > > > So, it is looking convincingly now that WG consensus is against a > > > > > lowest common denominator codec. ;-) > > > > > > > > > > But Brian raises an interesting question here. Somewhere in our > > > > > drafts (several of them) we *may* need to consider optional > > > > inclusion > > > > > of a transcoding function and describe how it might be > > > > implemented. > > > > > When we take up that discussion, I think Brian poses an > > > > interesting question. > > > > > > > > > > If I consider it from the perspective of some operator that > > > > is using > > > > > all the major codecs in my endpoints, and someone connects > > > > with some > > > > > obscure codec then I can see an arguement for having the > originator > > > > > perform any transcoding. (And if that is indeed the case, > > > > it may even > > > > > be like lots of other stuff an originating network may or > > > > may not do > > > > > that we don't care about and call out of scope.) > > > > > > > > > > Jason > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 11:28:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wAu-00053M-ED; Tue, 01 Aug 2006 11:28:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wAs-00053E-Uf for speermint@ietf.org; Tue, 01 Aug 2006 11:28:50 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7wAs-0001tt-74 for speermint@ietf.org; Tue, 01 Aug 2006 11:28:50 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005) with ESMTP id k71FSfNE027030; Tue, 1 Aug 2006 17:28:41 +0200 In-Reply-To: <057901c6b57d$a74f2840$640fa8c0@cis.neustar.com> Subject: RE: [Speermint] Voice codecs To: "Brian Rosen" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel.de Date: Tue, 1 Aug 2006 17:28:39 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/01/2006 17:28:41 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.2 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Just a technical comment concerning transcoding between codec types X and Z. In many cases isn't a direct transcoding X-to-Z possible. In general you need a "common denominator format" Y, used "transcoder internally" only. Transcoding relates then to X-to-Y-to-Z. Note: Y could be e.g. "linear PCM encoding" (= linearized G.711) in case of narrowband audio codec types. Format Y could be a criteria for codec selection or transcoder selection respectively. - Albrecht "Brian Rosen" , "'Drage, Keith \(Keith\)'" , et> cc: 01.08.2006 17:17 Subject: RE: [Speermint] Voice codecs Nope, it's more interesting than that. Sure, each domain has a policy of what codecs it allows on its network, but if you want to avoid double transcoding, you want to know, really, what is happening on both sides of the peering, to see if you can optimize it. Suppose A allows g.711 and AMR, and B allows g.711 and EvRC. You know what is really going to happen. The AMR handsets get transcoded to g.711 on A, the EvRC handsets get transcoded to g.711 on B and they "work". But what you really want to know is whether there is a transcoder available on either side (or in the middle) for EvRC to AMR and vice versa. If that example doesn't convince you, suppose A's list was g.711 and AMR-WB and B's list was g.711 and VMR-WB. So, you don't want to force A or B to transcode to the federation's list if you can figure out what the "right" thing to do is. You want to take the list of codecs the originating endpoint really can do, and the similar list from the terminating endpoint, and see if you can discover a resource that can bridge across the lists. This isn't a policy issue really. Brian > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Tuesday, August 01, 2006 10:42 AM > To: 'Brian Rosen'; 'Drage, Keith (Keith)'; speermint@ietf.org > Subject: RE: [Speermint] Voice codecs > > > > Interesting problem but easily solvable. > > The issue as I see it is we have to separate anything that looks like > policy > and capabilities discovery from the basic issue if connectivity. > > Now one issue we have is how do you discover the acceptable codecs for a > particular federation. > > OK that is a simple database issue. Presumably based on the domain part of > the SIP URI how do you issue a query? > > I'm starting to think IRIS begins to look good here as the mechanism for > discovery of policy related information re a TN or a domain. > > When we did some work in the US ENUM forum we decided to specify that the > US > ENUM implementation in e164.arpa would use a IRIS database for what would > essentially be Line Level and or Whois like data associated with a E.164 > number. > > We knew this would eventually be essential. Say you cannot connect to a > particular URI' what is the contact data associated with that URI you need > to report a problem etc. > > It would seem perfectly reasonable to construct various XML schemas > various > capabilities of federations and then query those. You have to have a > response mechanism that is structured and right now IRIS is the best > candidate we have for structured database queries. > > > http://www.ietf.org/html.charters/crisp-charter.html > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, August 01, 2006 8:33 AM > > To: 'Drage, Keith (Keith)'; speermint@ietf.org > > Subject: RE: [Speermint] Voice codecs > > > > I read this a couple of times before I grokked it. I think you are > right > > in > > the big picture, but maybe not in the practical world we live in now. > > > > Ideally, you would like to "search" the available transcoder inventory > > among > > the originating, terminating, and possibly > > services-within-the-peering-fabric domains to see if you can find an > > available resource that bridge directly between the endpoint's actual > > capabilities. We don't have any protocol mechanisms which would do > that. > > That involves a distributed discovery mechanism with two lists -- find > me > > an > > available transcoder that can bridge between any codec on list A and any > > codec on list B, and while we're at it, optimize two such discoveries > > simultaneously. Ideally, you would like both sides of one call to go > > through the same resource, and not two different ones. > > > > Do we need to get to this new protocol before we have something > functional > > in SPEERMINT? I think not. Many interdomain wireless call today would > > transcode twice (from one wireless codec to G.711, across the PSTN to > > another carrier and transcode from G.711 to its codec). We often do > this > > even if they are the same codec on both carriers. I suspect we do the > > same > > thing for now, and work towards a better way. I think the better way is > > not > > a SPEERMINT charter item, but perhaps we could write a requirements doc > > for > > someone else. > > > > It's an interesting problem. > > > > Brian > > > > > -----Original Message----- > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > Sent: Tuesday, August 01, 2006 8:13 AM > > > To: Brian Rosen; speermint@ietf.org > > > Subject: RE: [Speermint] Voice codecs > > > > > > That is why I think that if we mandate transcoders, we should also > make > > > sure we have studied the issues to allow us to have the minimum number > > > of transcodes, and if that means new protocol, then so be it. > > > > > > Regards > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: 31 July 2006 19:39 > > > > To: 'Geoff Devine'; 'Livingood, Jason'; speermint@ietf.org > > > > Cc: 'Ed Okerson'; 'Lipford,Mark A [CTO]' > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > Okay, makes sense. So, maybe it's more like, the federation > > > > agrees on minimal codec support, and participants must be > > > > prepared to transcode to that minimal set if their endpoints need > it. > > > > > > > > I don't think you can mandate anything that guarantees only > > > > one transcode. > > > > However desirable it may be. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > > > > > Sent: Monday, July 31, 2006 2:28 PM > > > > > To: Livingood, Jason; Brian Rosen; speermint@ietf.org > > > > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Klaus > Darilion; > > > > > Henry Sinnreich > > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > > > In your codec architecture example, you say that the originator > may > > > > > have some strange and wonderful codec that is not supported by the > > > > > peer network. I'd point out that the other 50% of the time, that > > > > > endpoint is the terminator in the call, not the originator. > > > > I would > > > > > think that transcoding would be something that is > > > > negotiated as part > > > > > of the peering business arrangement. In terms of $ per port, > > > > > transcoding is a relatively costly operation and somebody > > > > is going to > > > > > have to purchase and operate the transcoding equipment. > > > > > > > > > > Transcoding, like echo cancellation, is something you want to > avoid > > > > > doing extra times since it degrades voice quality. A path > > > > that goes, > > > > > say, from AMR to G.711 to iLBC is going to have a lower MOS > > > > score than > > > > > a path that goes AMR to iLBC. Ideally, you don't want to > > > > transcode at > > > > > all since that gives you the least impairment and the least delay. > > > > > > > > > > Geoff > > > > > > > > > > -----Original Message----- > > > > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > > > Sent: Monday, July 31, 2006 9:47 AM > > > > > To: Brian Rosen; speermint@ietf.org > > > > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Geoff Devine; > > > > > Klaus Darilion; Henry Sinnreich > > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > > > Brian wrote: > > > > > > > > > > > I did say something in my message which may have escaped some > > > > > > notice. I said "origination side". One of the things > > > > you have to > > > > > > get right on any kind of part like transcoding is what > > > > assumptions > > > > > > are made. You can assume the origination side does it, the > > > > > > destination side does it or the peering fabric itself does it. > I > > > > > > think it's essential to choose one, or we won't have > > > > > > interoperability. More than one is always possible, but at > least > > > > > > one is required. I think origination side is best: it means > that > > > > > > across the peering fabric, there is at least one common codec. > > > > > > > > > > So, it is looking convincingly now that WG consensus is against a > > > > > lowest common denominator codec. ;-) > > > > > > > > > > But Brian raises an interesting question here. Somewhere in our > > > > > drafts (several of them) we *may* need to consider optional > > > > inclusion > > > > > of a transcoding function and describe how it might be > > > > implemented. > > > > > When we take up that discussion, I think Brian poses an > > > > interesting question. > > > > > > > > > > If I consider it from the perspective of some operator that > > > > is using > > > > > all the major codecs in my endpoints, and someone connects > > > > with some > > > > > obscure codec then I can see an arguement for having the > originator > > > > > perform any transcoding. (And if that is indeed the case, > > > > it may even > > > > > be like lots of other stuff an originating network may or > > > > may not do > > > > > that we don't care about and call out of scope.) > > > > > > > > > > Jason > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 11:40:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wMD-0000pK-7Y; Tue, 01 Aug 2006 11:40:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wMC-0000pA-7O for speermint@ietf.org; Tue, 01 Aug 2006 11:40:32 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=MAILSRV01.cedarpointcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7wMA-0003P9-Tj for speermint@ietf.org; Tue, 01 Aug 2006 11:40:32 -0400 Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 11:39:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Voice codecs Date: Tue, 1 Aug 2006 11:39:35 -0400 Message-ID: <402F25FC1EB2BD44831F8A4A4F6DF942054AE5@MAIL02.cedarpointcom.com> In-Reply-To: <057901c6b57d$a74f2840$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXgAJXsKmAACa16AAAAir3QACN3DBAAAcZk0AAEW4owAAFlG0AAANV2MA== From: "Geoff Devine" To: "Brian Rosen" , , "Drage, Keith \(Keith\)" , X-OriginalArrivalTime: 01 Aug 2006 15:39:30.0195 (UTC) FILETIME=[ADBD6630:01C6B580] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org In your wideband codec transcoding example (a good one, by the way), there are only so many possible business arrangements: The originator transcodes The terminator transcodes A transcodes, always B transcodes, always C, a third party, transcodes I think any solution we come up with needs to support all of these possibilities.=20 Geoff -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, August 01, 2006 11:18 AM To: richard@shockey.us; 'Drage, Keith (Keith)'; speermint@ietf.org Subject: RE: [Speermint] Voice codecs Nope, it's more interesting than that. Sure, each domain has a policy of what codecs it allows on its network, but if you want to avoid double transcoding, you want to know, really, what is happening on both sides of the peering, to see if you can optimize it. Suppose A allows g.711 and AMR, and B allows g.711 and EvRC. You know what is really going to happen. The AMR handsets get transcoded to g.711 on A, the EvRC handsets get transcoded to g.711 on B and they "work". But what you really want to know is whether there is a transcoder available on either side (or in the middle) for EvRC to AMR and vice versa. If that example doesn't convince you, suppose A's list was g.711 and AMR-WB and B's list was g.711 and VMR-WB. So, you don't want to force A or B to transcode to the federation's list if you can figure out what the "right" thing to do is. You want to take the list of codecs the originating endpoint really can do, and the similar list from the terminating endpoint, and see if you can discover a resource that can bridge across the lists. This isn't a policy issue really. Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 11:45:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wRJ-0001aq-Ux; Tue, 01 Aug 2006 11:45:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wRI-0001aW-N0 for speermint@ietf.org; Tue, 01 Aug 2006 11:45:48 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7wRI-0004Fg-2K for speermint@ietf.org; Tue, 01 Aug 2006 11:45:48 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G7wR5-000638-U0; Tue, 01 Aug 2006 10:45:36 -0500 From: "Brian Rosen" To: Subject: RE: [Speermint] Voice codecs Date: Tue, 1 Aug 2006 11:45:37 -0400 Message-ID: <05d801c6b581$8ad3c1e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca1fyyTno50zLQXTn2VpHR5RTIjJAAAbrIA X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Sure, but I point out that even when transcoding between AMR and EvRC, using a strictly linear PCM, rather than the g.711 encoding, is quite helpful. When it's wideband, it's more helpful. You can also optimize a number of sampling rate issues if you are not forced to an 8Khz sample rate in the middle. Depending on the exact pair, there may be other filtering mechanisms that can improve quality. Brian > -----Original Message----- > From: Albrecht.Schwarz@alcatel.de [mailto:Albrecht.Schwarz@alcatel.de] > Sent: Tuesday, August 01, 2006 11:29 AM > To: Brian Rosen > Cc: 'Drage, Keith (Keith)'; richard@shockey.us; speermint@ietf.org > Subject: RE: [Speermint] Voice codecs > > > Just a technical comment concerning transcoding between codec types X and > Z. > In many cases isn't a direct transcoding X-to-Z possible. > In general you need a "common denominator format" Y, used "transcoder > internally" only. Transcoding relates then to X-to-Y-to-Z. > > Note: Y could be e.g. "linear PCM encoding" (= linearized G.711) in case > of > narrowband audio codec types. Format Y could be a criteria for codec > selection or transcoder selection respectively. > > - Albrecht > > > > > > "Brian Rosen" > , "'Drage, Keith \(Keith\)'" , > et> > cc: > 01.08.2006 17:17 Subject: RE: [Speermint] > Voice codecs > > > > > > Nope, it's more interesting than that. Sure, each domain has a policy of > what codecs it allows on its network, but if you want to avoid double > transcoding, you want to know, really, what is happening on both sides of > the peering, to see if you can optimize it. > > Suppose A allows g.711 and AMR, and B allows g.711 and EvRC. You know > what > is really going to happen. The AMR handsets get transcoded to g.711 on A, > the EvRC handsets get transcoded to g.711 on B and they "work". > > But what you really want to know is whether there is a transcoder > available > on either side (or in the middle) for EvRC to AMR and vice versa. > > If that example doesn't convince you, suppose A's list was g.711 and AMR- > WB > and B's list was g.711 and VMR-WB. > > So, you don't want to force A or B to transcode to the federation's list > if > you can figure out what the "right" thing to do is. > > You want to take the list of codecs the originating endpoint really can > do, > and the similar list from the terminating endpoint, and see if you can > discover a resource that can bridge across the lists. > > This isn't a policy issue really. > > Brian > > > > > -----Original Message----- > > From: Richard Shockey [mailto:richard@shockey.us] > > Sent: Tuesday, August 01, 2006 10:42 AM > > To: 'Brian Rosen'; 'Drage, Keith (Keith)'; speermint@ietf.org > > Subject: RE: [Speermint] Voice codecs > > > > > > > > Interesting problem but easily solvable. > > > > The issue as I see it is we have to separate anything that looks like > > policy > > and capabilities discovery from the basic issue if connectivity. > > > > Now one issue we have is how do you discover the acceptable codecs for a > > particular federation. > > > > OK that is a simple database issue. Presumably based on the domain part > of > > the SIP URI how do you issue a query? > > > > I'm starting to think IRIS begins to look good here as the mechanism for > > discovery of policy related information re a TN or a domain. > > > > When we did some work in the US ENUM forum we decided to specify that > the > > US > > ENUM implementation in e164.arpa would use a IRIS database for what > would > > essentially be Line Level and or Whois like data associated with a E.164 > > number. > > > > We knew this would eventually be essential. Say you cannot connect to a > > particular URI' what is the contact data associated with that URI you > need > > to report a problem etc. > > > > It would seem perfectly reasonable to construct various XML schemas > > various > > capabilities of federations and then query those. You have to have a > > response mechanism that is structured and right now IRIS is the best > > candidate we have for structured database queries. > > > > > > http://www.ietf.org/html.charters/crisp-charter.html > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, August 01, 2006 8:33 AM > > > To: 'Drage, Keith (Keith)'; speermint@ietf.org > > > Subject: RE: [Speermint] Voice codecs > > > > > > I read this a couple of times before I grokked it. I think you are > > right > > > in > > > the big picture, but maybe not in the practical world we live in now. > > > > > > Ideally, you would like to "search" the available transcoder inventory > > > among > > > the originating, terminating, and possibly > > > services-within-the-peering-fabric domains to see if you can find an > > > available resource that bridge directly between the endpoint's actual > > > capabilities. We don't have any protocol mechanisms which would do > > that. > > > That involves a distributed discovery mechanism with two lists -- find > > me > > > an > > > available transcoder that can bridge between any codec on list A and > any > > > codec on list B, and while we're at it, optimize two such discoveries > > > simultaneously. Ideally, you would like both sides of one call to go > > > through the same resource, and not two different ones. > > > > > > Do we need to get to this new protocol before we have something > > functional > > > in SPEERMINT? I think not. Many interdomain wireless call today > would > > > transcode twice (from one wireless codec to G.711, across the PSTN to > > > another carrier and transcode from G.711 to its codec). We often do > > this > > > even if they are the same codec on both carriers. I suspect we do the > > > same > > > thing for now, and work towards a better way. I think the better way > is > > > not > > > a SPEERMINT charter item, but perhaps we could write a requirements > doc > > > for > > > someone else. > > > > > > It's an interesting problem. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > > Sent: Tuesday, August 01, 2006 8:13 AM > > > > To: Brian Rosen; speermint@ietf.org > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > That is why I think that if we mandate transcoders, we should also > > make > > > > sure we have studied the issues to allow us to have the minimum > number > > > > of transcodes, and if that means new protocol, then so be it. > > > > > > > > Regards > > > > > > > > Keith > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: 31 July 2006 19:39 > > > > > To: 'Geoff Devine'; 'Livingood, Jason'; speermint@ietf.org > > > > > Cc: 'Ed Okerson'; 'Lipford,Mark A [CTO]' > > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > > > Okay, makes sense. So, maybe it's more like, the federation > > > > > agrees on minimal codec support, and participants must be > > > > > prepared to transcode to that minimal set if their endpoints need > > it. > > > > > > > > > > I don't think you can mandate anything that guarantees only > > > > > one transcode. > > > > > However desirable it may be. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > > > > > > Sent: Monday, July 31, 2006 2:28 PM > > > > > > To: Livingood, Jason; Brian Rosen; speermint@ietf.org > > > > > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Klaus > > Darilion; > > > > > > Henry Sinnreich > > > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > > > > > In your codec architecture example, you say that the originator > > may > > > > > > have some strange and wonderful codec that is not supported by > the > > > > > > peer network. I'd point out that the other 50% of the time, > that > > > > > > endpoint is the terminator in the call, not the originator. > > > > > I would > > > > > > think that transcoding would be something that is > > > > > negotiated as part > > > > > > of the peering business arrangement. In terms of $ per port, > > > > > > transcoding is a relatively costly operation and somebody > > > > > is going to > > > > > > have to purchase and operate the transcoding equipment. > > > > > > > > > > > > Transcoding, like echo cancellation, is something you want to > > avoid > > > > > > doing extra times since it degrades voice quality. A path > > > > > that goes, > > > > > > say, from AMR to G.711 to iLBC is going to have a lower MOS > > > > > score than > > > > > > a path that goes AMR to iLBC. Ideally, you don't want to > > > > > transcode at > > > > > > all since that gives you the least impairment and the least > delay. > > > > > > > > > > > > Geoff > > > > > > > > > > > > -----Original Message----- > > > > > > From: Livingood, Jason > [mailto:Jason_Livingood@cable.comcast.com] > > > > > > Sent: Monday, July 31, 2006 9:47 AM > > > > > > To: Brian Rosen; speermint@ietf.org > > > > > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Geoff > Devine; > > > > > > Klaus Darilion; Henry Sinnreich > > > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > > > > > Brian wrote: > > > > > > > > > > > > > I did say something in my message which may have escaped some > > > > > > > notice. I said "origination side". One of the things > > > > > you have to > > > > > > > get right on any kind of part like transcoding is what > > > > > assumptions > > > > > > > are made. You can assume the origination side does it, the > > > > > > > destination side does it or the peering fabric itself does it. > > I > > > > > > > think it's essential to choose one, or we won't have > > > > > > > interoperability. More than one is always possible, but at > > least > > > > > > > one is required. I think origination side is best: it means > > that > > > > > > > across the peering fabric, there is at least one common codec. > > > > > > > > > > > > So, it is looking convincingly now that WG consensus is against > a > > > > > > lowest common denominator codec. ;-) > > > > > > > > > > > > But Brian raises an interesting question here. Somewhere in our > > > > > > drafts (several of them) we *may* need to consider optional > > > > > inclusion > > > > > > of a transcoding function and describe how it might be > > > > > implemented. > > > > > > When we take up that discussion, I think Brian poses an > > > > > interesting question. > > > > > > > > > > > > If I consider it from the perspective of some operator that > > > > > is using > > > > > > all the major codecs in my endpoints, and someone connects > > > > > with some > > > > > > obscure codec then I can see an arguement for having the > > originator > > > > > > perform any transcoding. (And if that is indeed the case, > > > > > it may even > > > > > > be like lots of other stuff an originating network may or > > > > > may not do > > > > > > that we don't care about and call out of scope.) > > > > > > > > > > > > Jason > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 11:57:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wcK-0004OE-69; Tue, 01 Aug 2006 11:57:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wcI-0004O6-Ct for speermint@ietf.org; Tue, 01 Aug 2006 11:57:10 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7wcH-0005IK-2p for speermint@ietf.org; Tue, 01 Aug 2006 11:57:10 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G7wc8-0007Ko-TD; Tue, 01 Aug 2006 10:57:01 -0500 From: "Brian Rosen" To: "'Geoff Devine'" , , "'Drage, Keith \(Keith\)'" , Subject: RE: [Speermint] Voice codecs Date: Tue, 1 Aug 2006 11:57:02 -0400 Message-ID: <05d901c6b583$2323cd90$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <402F25FC1EB2BD44831F8A4A4F6DF942054AE5@MAIL02.cedarpointcom.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXgAJXsKmAACa16AAAAir3QACN3DBAAAcZk0AAEW4owAAFlG0AAANV2MAAAmR8g X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Recognize that we are in fact out of charter scope in SPEERMINT, even if this is an interesting problem to think about. "Cost" is a metric we often use in "routing" protocols. We usually don't directly attribute the metric to the literal money exchange between parties, but there is a relationship. I think including a "cost" metric is not unreasonable in the algorithm. To me, the interesting part here is the "two list" aspect of the routing mechanism. Usually, the goal is simpler and the path choices more complex. Other than that, it seems pretty straightforward to have a distributed resource discovery protocol with all the right characteristics. It really does look like a routing protocol: transcoders advertise availability of their resource within a cloud, with the announcements are propagated within and between domains. Costs are domain-relative. Since the availability of the resource can change quickly (due to use), it needs to work pretty fast, but the scale is not really that bad. You'll need to first look for direct (X to Z) and then indirect (X to Y, Y to Z) transcoding. Might be useful to somehow take into account the various metrics that would allow you to optimize the choice of Y's if there were more than one. As I said, it's pretty interesting. Brian > -----Original Message----- > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > Sent: Tuesday, August 01, 2006 11:40 AM > To: Brian Rosen; richard@shockey.us; Drage, Keith (Keith); > speermint@ietf.org > Subject: RE: [Speermint] Voice codecs > > In your wideband codec transcoding example (a good one, by the way), > there are only so many possible business arrangements: > > The originator transcodes > The terminator transcodes > A transcodes, always > B transcodes, always > C, a third party, transcodes > > I think any solution we come up with needs to support all of these > possibilities. > > Geoff > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, August 01, 2006 11:18 AM > To: richard@shockey.us; 'Drage, Keith (Keith)'; speermint@ietf.org > Subject: RE: [Speermint] Voice codecs > > Nope, it's more interesting than that. Sure, each domain has a policy > of > what codecs it allows on its network, but if you want to avoid double > transcoding, you want to know, really, what is happening on both sides > of > the peering, to see if you can optimize it. > > Suppose A allows g.711 and AMR, and B allows g.711 and EvRC. You know > what > is really going to happen. The AMR handsets get transcoded to g.711 on > A, > the EvRC handsets get transcoded to g.711 on B and they "work". > > But what you really want to know is whether there is a transcoder > available > on either side (or in the middle) for EvRC to AMR and vice versa. > > If that example doesn't convince you, suppose A's list was g.711 and > AMR-WB > and B's list was g.711 and VMR-WB. > > So, you don't want to force A or B to transcode to the federation's list > if > you can figure out what the "right" thing to do is. > > You want to take the list of codecs the originating endpoint really can > do, > and the similar list from the terminating endpoint, and see if you can > discover a resource that can bridge across the lists. > > This isn't a policy issue really. > > Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 11:58:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wdJ-0004nb-JP; Tue, 01 Aug 2006 11:58:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wdJ-0004nV-6H for speermint@ietf.org; Tue, 01 Aug 2006 11:58:13 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7wdG-0005OO-SJ for speermint@ietf.org; Tue, 01 Aug 2006 11:58:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Voice codecs Date: Tue, 1 Aug 2006 17:54:31 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B44@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: Aca1fxnBB+he/3nlQ/mpwNJXU3TpZwAA61r+ References: From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >In many cases isn't a direct transcoding X-to-Z possible. >In general you need a "common denominator format" Y, used "transcoder >internally" only. Transcoding relates then to X-to-Y-to-Z. I have a deja vu =20 This remindes me of loop back trunks ;-) =20 -sta _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 12:11:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wpm-0005cd-KS; Tue, 01 Aug 2006 12:11:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wpl-0005bW-I6 for speermint@ietf.org; Tue, 01 Aug 2006 12:11:05 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7wpk-0006eV-8V for speermint@ietf.org; Tue, 01 Aug 2006 12:11:05 -0400 Received: from PMelampy2 [10.0.200.104] by acmepacket.com with ESMTP (SMTPD-9.03) id AD1F0654; Tue, 01 Aug 2006 12:11:11 -0400 From: "Patrick Melampy" To: "'Geoff Devine'" , "'Brian Rosen'" , , "'Drage, Keith \(Keith\)'" , Subject: RE: [Speermint] Voice codecs Date: Tue, 1 Aug 2006 12:11:02 -0400 Message-ID: <004201c6b585$15d81b80$68c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXgAJXsKmAACa16AAAAir3QACN3DBAAAcZk0AAEW4owAAFlG0AAANV2MAAAjkXQ In-Reply-To: <402F25FC1EB2BD44831F8A4A4F6DF942054AE5@MAIL02.cedarpointcom.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On problem with "codec policies", is that they are not necessarily transitive. Transit networks may not support CODEC's that are indeed supported by the originator/terminator. Even the terminating network may not support the terminators CODEC capabilities. For example, we current use a VOIP service, that only uses G.711 for calls going to the PSTN or other IP Networks. However, when we call another phone, connected to these "restrictive networks", we can negotiate to G.729. It seems to me that CODEC's are indeed capabilities of networks -- but only insofar as to their connection to the PSTN. Establishing policies or exchanging these kind of capabilities to determine a best next-hop network would be senseless. -----Original Message----- From: Geoff Devine [mailto:gdevine@cedarpointcom.com] Sent: Tuesday, August 01, 2006 11:40 AM To: Brian Rosen; richard@shockey.us; Drage, Keith (Keith); speermint@ietf.org Subject: RE: [Speermint] Voice codecs In your wideband codec transcoding example (a good one, by the way), there are only so many possible business arrangements: The originator transcodes The terminator transcodes A transcodes, always B transcodes, always C, a third party, transcodes I think any solution we come up with needs to support all of these possibilities. Geoff -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, August 01, 2006 11:18 AM To: richard@shockey.us; 'Drage, Keith (Keith)'; speermint@ietf.org Subject: RE: [Speermint] Voice codecs Nope, it's more interesting than that. Sure, each domain has a policy of what codecs it allows on its network, but if you want to avoid double transcoding, you want to know, really, what is happening on both sides of the peering, to see if you can optimize it. Suppose A allows g.711 and AMR, and B allows g.711 and EvRC. You know what is really going to happen. The AMR handsets get transcoded to g.711 on A, the EvRC handsets get transcoded to g.711 on B and they "work". But what you really want to know is whether there is a transcoder available on either side (or in the middle) for EvRC to AMR and vice versa. If that example doesn't convince you, suppose A's list was g.711 and AMR-WB and B's list was g.711 and VMR-WB. So, you don't want to force A or B to transcode to the federation's list if you can figure out what the "right" thing to do is. You want to take the list of codecs the originating endpoint really can do, and the similar list from the terminating endpoint, and see if you can discover a resource that can bridge across the lists. This isn't a policy issue really. Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 12:13:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wrx-0006Sd-UU; Tue, 01 Aug 2006 12:13:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wrw-0006S4-GV for speermint@ietf.org; Tue, 01 Aug 2006 12:13:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7tbQ-0001IK-ME for speermint@ietf.org; Tue, 01 Aug 2006 08:44:04 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7t7O-0002fC-FT for speermint@ietf.org; Tue, 01 Aug 2006 08:13:05 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k71CCopu004147; Tue, 1 Aug 2006 07:12:51 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 1 Aug 2006 07:12:50 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 1 Aug 2006 14:12:49 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Speermint] Voice codecs Date: Tue, 1 Aug 2006 14:12:48 +0200 Message-ID: <5D1A7985295922448D5550C94DE291801E433D@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXgAJXsKmAACa16AAAAir3QACN3DBA= From: "Drage, Keith \(Keith\)" To: "Brian Rosen" , X-OriginalArrivalTime: 01 Aug 2006 12:12:49.0015 (UTC) FILETIME=[CE0F8070:01C6B563] X-Spam-Score: -1.5 (-) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org That is why I think that if we mandate transcoders, we should also make sure we have studied the issues to allow us to have the minimum number of transcodes, and if that means new protocol, then so be it. Regards Keith=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: 31 July 2006 19:39 > To: 'Geoff Devine'; 'Livingood, Jason'; speermint@ietf.org > Cc: 'Ed Okerson'; 'Lipford,Mark A [CTO]' > Subject: RE: [Speermint] Voice codecs >=20 > Okay, makes sense. So, maybe it's more like, the federation=20 > agrees on minimal codec support, and participants must be=20 > prepared to transcode to that minimal set if their endpoints need it. >=20 > I don't think you can mandate anything that guarantees only=20 > one transcode. > However desirable it may be. >=20 > Brian >=20 > > -----Original Message----- > > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > > Sent: Monday, July 31, 2006 2:28 PM > > To: Livingood, Jason; Brian Rosen; speermint@ietf.org > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Klaus Darilion;=20 > > Henry Sinnreich > > Subject: RE: [Speermint] Voice codecs > >=20 > > In your codec architecture example, you say that the originator may=20 > > have some strange and wonderful codec that is not supported by the=20 > > peer network. I'd point out that the other 50% of the time, that=20 > > endpoint is the terminator in the call, not the originator.=20 > I would=20 > > think that transcoding would be something that is=20 > negotiated as part=20 > > of the peering business arrangement. In terms of $ per port,=20 > > transcoding is a relatively costly operation and somebody=20 > is going to=20 > > have to purchase and operate the transcoding equipment. > >=20 > > Transcoding, like echo cancellation, is something you want to avoid=20 > > doing extra times since it degrades voice quality. A path=20 > that goes,=20 > > say, from AMR to G.711 to iLBC is going to have a lower MOS=20 > score than=20 > > a path that goes AMR to iLBC. Ideally, you don't want to=20 > transcode at=20 > > all since that gives you the least impairment and the least delay. > >=20 > > Geoff > >=20 > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Monday, July 31, 2006 9:47 AM > > To: Brian Rosen; speermint@ietf.org > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Geoff Devine;=20 > > Klaus Darilion; Henry Sinnreich > > Subject: RE: [Speermint] Voice codecs > >=20 > > Brian wrote: > >=20 > > > I did say something in my message which may have escaped some=20 > > > notice. I said "origination side". One of the things=20 > you have to=20 > > > get right on any kind of part like transcoding is what=20 > assumptions=20 > > > are made. You can assume the origination side does it, the=20 > > > destination side does it or the peering fabric itself does it. I=20 > > > think it's essential to choose one, or we won't have=20 > > > interoperability. More than one is always possible, but at least=20 > > > one is required. I think origination side is best: it means that=20 > > > across the peering fabric, there is at least one common codec. > >=20 > > So, it is looking convincingly now that WG consensus is against a=20 > > lowest common denominator codec. ;-) > >=20 > > But Brian raises an interesting question here. Somewhere in our=20 > > drafts (several of them) we *may* need to consider optional=20 > inclusion=20 > > of a transcoding function and describe how it might be=20 > implemented. =20 > > When we take up that discussion, I think Brian poses an=20 > interesting question. > >=20 > > If I consider it from the perspective of some operator that=20 > is using=20 > > all the major codecs in my endpoints, and someone connects=20 > with some=20 > > obscure codec then I can see an arguement for having the originator=20 > > perform any transcoding. (And if that is indeed the case,=20 > it may even=20 > > be like lots of other stuff an originating network may or=20 > may not do=20 > > that we don't care about and call out of scope.) > >=20 > > Jason >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 13:07:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xid-0000nV-FK; Tue, 01 Aug 2006 13:07:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xic-0000jP-IO for speermint@ietf.org; Tue, 01 Aug 2006 13:07:46 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7xib-0003h3-1D for speermint@ietf.org; Tue, 01 Aug 2006 13:07:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Voice codecs Date: Tue, 1 Aug 2006 19:03:18 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B45@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXgAJXsKmAACa16AAAAir3QACN3DBAAAcZk0AAEW4owAAFlG0AAANV2MAAAjkXQAAK+yZ8= References: <004201c6b585$15d81b80$68c8000a@acmepacket.com> From: "Stastny Richard" To: "Patrick Melampy" , "Geoff Devine" , "Brian Rosen" , , "Drage, Keith \(Keith\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >It seems to me that CODEC's are indeed capabilities of networks -- but = only >insofar as to their connection to the PSTN. Establishing policies or >exchanging these kind of capabilities to determine a best next-hop = network >would be senseless. Perfectly correct. Codecs are end-device capabilities and an IP-PSTN = gateway is also an end-device, as far as IP is concerned. =20 So codecs are not an IP network issue =20 -sta ________________________________ Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] Gesendet: Di 01.08.2006 18:11 An: 'Geoff Devine'; 'Brian Rosen'; richard@shockey.us; 'Drage, Keith = (Keith)'; speermint@ietf.org Betreff: RE: [Speermint] Voice codecs On problem with "codec policies", is that they are not necessarily transitive. Transit networks may not support CODEC's that are indeed supported by the originator/terminator. Even the terminating network may = not support the terminators CODEC capabilities. For example, we current use = a VOIP service, that only uses G.711 for calls going to the PSTN or other = IP Networks. However, when we call another phone, connected to these "restrictive networks", we can negotiate to G.729. It seems to me that CODEC's are indeed capabilities of networks -- but = only insofar as to their connection to the PSTN. Establishing policies or exchanging these kind of capabilities to determine a best next-hop = network would be senseless. -----Original Message----- From: Geoff Devine [mailto:gdevine@cedarpointcom.com] Sent: Tuesday, August 01, 2006 11:40 AM To: Brian Rosen; richard@shockey.us; Drage, Keith (Keith); speermint@ietf.org Subject: RE: [Speermint] Voice codecs In your wideband codec transcoding example (a good one, by the way), there are only so many possible business arrangements: The originator transcodes The terminator transcodes A transcodes, always B transcodes, always C, a third party, transcodes I think any solution we come up with needs to support all of these possibilities. Geoff -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, August 01, 2006 11:18 AM To: richard@shockey.us; 'Drage, Keith (Keith)'; speermint@ietf.org Subject: RE: [Speermint] Voice codecs Nope, it's more interesting than that. Sure, each domain has a policy of what codecs it allows on its network, but if you want to avoid double transcoding, you want to know, really, what is happening on both sides of the peering, to see if you can optimize it. Suppose A allows g.711 and AMR, and B allows g.711 and EvRC. You know what is really going to happen. The AMR handsets get transcoded to g.711 on A, the EvRC handsets get transcoded to g.711 on B and they "work". But what you really want to know is whether there is a transcoder available on either side (or in the middle) for EvRC to AMR and vice versa. If that example doesn't convince you, suppose A's list was g.711 and AMR-WB and B's list was g.711 and VMR-WB. So, you don't want to force A or B to transcode to the federation's list if you can figure out what the "right" thing to do is. You want to take the list of codecs the originating endpoint really can do, and the similar list from the terminating endpoint, and see if you can discover a resource that can bridge across the lists. This isn't a policy issue really. Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 13:28:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7y2I-0005yM-8I; Tue, 01 Aug 2006 13:28:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7y2G-0005yH-UX for speermint@ietf.org; Tue, 01 Aug 2006 13:28:04 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7y2D-00058Q-Be for speermint@ietf.org; Tue, 01 Aug 2006 13:28:04 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Tue, 01 Aug 2006 10:27:43 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k71HPnBl020184; Tue, 1 Aug 2006 10:25:50 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k71HRNR0024361; Tue, 1 Aug 2006 10:27:31 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 10:27:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Voice codecs Date: Tue, 1 Aug 2006 10:22:30 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D220C3368@namail5.corp.adobe.com> In-Reply-To: <5D1A7985295922448D5550C94DE291801E433D@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXgAJXsKmAACa16AAAAir3QACN3DBAADATlwA== From: "Henry Sinnreich" To: "Drage, Keith \(Keith\)" , "Brian Rosen" , X-OriginalArrivalTime: 01 Aug 2006 17:27:23.0285 (UTC) FILETIME=[C0008C50:01C6B58F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: Ed Okerson , Jean-Marc Valin X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org It is heartening to see the interest in codecs after all in this group! > That is why I think that if we mandate transcoders A much better approach is to mandate SPEEX and only _allow_ (tolerate) transcoders for backward compatibility with legacy equipment. See why at: http://speex.org/docs.html and we can discuss the pros and cons of what is truly the basics of any VoIP peering: Voice quality for the user. Users could not care less about all the signaling issues that are debated here, but they will instantly perceive the quality of the peering. Thanks, Henry -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 Sent: Tuesday, August 01, 2006 5:13 AM To: Brian Rosen; speermint@ietf.org Subject: RE: [Speermint] Voice codecs That is why I think that if we mandate transcoders, we should also make sure we have studied the issues to allow us to have the minimum number of transcodes, and if that means new protocol, then so be it. Regards Keith=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: 31 July 2006 19:39 > To: 'Geoff Devine'; 'Livingood, Jason'; speermint@ietf.org > Cc: 'Ed Okerson'; 'Lipford,Mark A [CTO]' > Subject: RE: [Speermint] Voice codecs >=20 > Okay, makes sense. So, maybe it's more like, the federation=20 > agrees on minimal codec support, and participants must be=20 > prepared to transcode to that minimal set if their endpoints need it. >=20 > I don't think you can mandate anything that guarantees only=20 > one transcode. > However desirable it may be. >=20 > Brian >=20 > > -----Original Message----- > > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > > Sent: Monday, July 31, 2006 2:28 PM > > To: Livingood, Jason; Brian Rosen; speermint@ietf.org > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Klaus Darilion;=20 > > Henry Sinnreich > > Subject: RE: [Speermint] Voice codecs > >=20 > > In your codec architecture example, you say that the originator may=20 > > have some strange and wonderful codec that is not supported by the=20 > > peer network. I'd point out that the other 50% of the time, that=20 > > endpoint is the terminator in the call, not the originator.=20 > I would=20 > > think that transcoding would be something that is=20 > negotiated as part=20 > > of the peering business arrangement. In terms of $ per port,=20 > > transcoding is a relatively costly operation and somebody=20 > is going to=20 > > have to purchase and operate the transcoding equipment. > >=20 > > Transcoding, like echo cancellation, is something you want to avoid=20 > > doing extra times since it degrades voice quality. A path=20 > that goes,=20 > > say, from AMR to G.711 to iLBC is going to have a lower MOS=20 > score than=20 > > a path that goes AMR to iLBC. Ideally, you don't want to=20 > transcode at=20 > > all since that gives you the least impairment and the least delay. > >=20 > > Geoff > >=20 > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Monday, July 31, 2006 9:47 AM > > To: Brian Rosen; speermint@ietf.org > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Geoff Devine;=20 > > Klaus Darilion; Henry Sinnreich > > Subject: RE: [Speermint] Voice codecs > >=20 > > Brian wrote: > >=20 > > > I did say something in my message which may have escaped some=20 > > > notice. I said "origination side". One of the things=20 > you have to=20 > > > get right on any kind of part like transcoding is what=20 > assumptions=20 > > > are made. You can assume the origination side does it, the=20 > > > destination side does it or the peering fabric itself does it. I=20 > > > think it's essential to choose one, or we won't have=20 > > > interoperability. More than one is always possible, but at least=20 > > > one is required. I think origination side is best: it means that=20 > > > across the peering fabric, there is at least one common codec. > >=20 > > So, it is looking convincingly now that WG consensus is against a=20 > > lowest common denominator codec. ;-) > >=20 > > But Brian raises an interesting question here. Somewhere in our=20 > > drafts (several of them) we *may* need to consider optional=20 > inclusion=20 > > of a transcoding function and describe how it might be=20 > implemented. =20 > > When we take up that discussion, I think Brian poses an=20 > interesting question. > >=20 > > If I consider it from the perspective of some operator that=20 > is using=20 > > all the major codecs in my endpoints, and someone connects=20 > with some=20 > > obscure codec then I can see an arguement for having the originator=20 > > perform any transcoding. (And if that is indeed the case,=20 > it may even=20 > > be like lots of other stuff an originating network may or=20 > may not do=20 > > that we don't care about and call out of scope.) > >=20 > > Jason >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 13:46:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7yKD-00081T-3s; Tue, 01 Aug 2006 13:46:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7yKB-00081L-8x for speermint@ietf.org; Tue, 01 Aug 2006 13:46:35 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7yK9-0008IP-QH for speermint@ietf.org; Tue, 01 Aug 2006 13:46:35 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G7yJd-00080T-Ly; Tue, 01 Aug 2006 12:46:02 -0500 From: "Brian Rosen" To: "'Henry Sinnreich'" , "'Drage, Keith \(Keith\)'" , Subject: RE: [Speermint] Voice codecs Date: Tue, 1 Aug 2006 13:46:04 -0400 Message-ID: <060401c6b592$5e7052b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D220C3368@namail5.corp.adobe.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXgAJXsKmAACa16AAAAir3QACN3DBAADATlwAAA2WbA X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: 'Ed Okerson' , 'Jean-Marc Valin' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Henry If you have EvRC on one side and AMR on the other side, SPEEX will only hurt your quality if you force it in the middle. I really, truly believe that vendors and carriers who don't offer common wideband codecs as standard with their products have shot themselves in the foot. VoIP should have been positioned as better than "toll" quality. I'm a big believer in wideband all around. I think there are no excuses, the vendors and carriers just plain blew it, and are stuck on a race to the bottom with PSTN, when they could have been talking about better service. But given the realities, and I'm also big on reality, forcing SPEEX in the middle is truly a bad idea. Brian > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Tuesday, August 01, 2006 1:23 PM > To: Drage, Keith (Keith); Brian Rosen; speermint@ietf.org > Cc: Greg Herlein; Ed Okerson; Jean-Marc Valin > Subject: RE: [Speermint] Voice codecs > > It is heartening to see the interest in codecs after all in this group! > > > That is why I think that if we mandate transcoders > > A much better approach is to mandate SPEEX and only _allow_ (tolerate) > transcoders for backward compatibility with legacy equipment. > > See why at: http://speex.org/docs.html and we can discuss the pros and > cons of what is truly the basics of any VoIP peering: Voice quality for > the user. > > Users could not care less about all the signaling issues that are > debated here, but they will instantly perceive the quality of the > peering. > > Thanks, Henry > > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Tuesday, August 01, 2006 5:13 AM > To: Brian Rosen; speermint@ietf.org > Subject: RE: [Speermint] Voice codecs > > That is why I think that if we mandate transcoders, we should also make > sure we have studied the issues to allow us to have the minimum number > of transcodes, and if that means new protocol, then so be it. > > Regards > > Keith > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: 31 July 2006 19:39 > > To: 'Geoff Devine'; 'Livingood, Jason'; speermint@ietf.org > > Cc: 'Ed Okerson'; 'Lipford,Mark A [CTO]' > > Subject: RE: [Speermint] Voice codecs > > > > Okay, makes sense. So, maybe it's more like, the federation > > agrees on minimal codec support, and participants must be > > prepared to transcode to that minimal set if their endpoints need it. > > > > I don't think you can mandate anything that guarantees only > > one transcode. > > However desirable it may be. > > > > Brian > > > > > -----Original Message----- > > > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > > > Sent: Monday, July 31, 2006 2:28 PM > > > To: Livingood, Jason; Brian Rosen; speermint@ietf.org > > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Klaus Darilion; > > > Henry Sinnreich > > > Subject: RE: [Speermint] Voice codecs > > > > > > In your codec architecture example, you say that the originator may > > > have some strange and wonderful codec that is not supported by the > > > peer network. I'd point out that the other 50% of the time, that > > > endpoint is the terminator in the call, not the originator. > > I would > > > think that transcoding would be something that is > > negotiated as part > > > of the peering business arrangement. In terms of $ per port, > > > transcoding is a relatively costly operation and somebody > > is going to > > > have to purchase and operate the transcoding equipment. > > > > > > Transcoding, like echo cancellation, is something you want to avoid > > > doing extra times since it degrades voice quality. A path > > that goes, > > > say, from AMR to G.711 to iLBC is going to have a lower MOS > > score than > > > a path that goes AMR to iLBC. Ideally, you don't want to > > transcode at > > > all since that gives you the least impairment and the least delay. > > > > > > Geoff > > > > > > -----Original Message----- > > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Sent: Monday, July 31, 2006 9:47 AM > > > To: Brian Rosen; speermint@ietf.org > > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Geoff Devine; > > > Klaus Darilion; Henry Sinnreich > > > Subject: RE: [Speermint] Voice codecs > > > > > > Brian wrote: > > > > > > > I did say something in my message which may have escaped some > > > > notice. I said "origination side". One of the things > > you have to > > > > get right on any kind of part like transcoding is what > > assumptions > > > > are made. You can assume the origination side does it, the > > > > destination side does it or the peering fabric itself does it. I > > > > think it's essential to choose one, or we won't have > > > > interoperability. More than one is always possible, but at least > > > > one is required. I think origination side is best: it means that > > > > across the peering fabric, there is at least one common codec. > > > > > > So, it is looking convincingly now that WG consensus is against a > > > lowest common denominator codec. ;-) > > > > > > But Brian raises an interesting question here. Somewhere in our > > > drafts (several of them) we *may* need to consider optional > > inclusion > > > of a transcoding function and describe how it might be > > implemented. > > > When we take up that discussion, I think Brian poses an > > interesting question. > > > > > > If I consider it from the perspective of some operator that > > is using > > > all the major codecs in my endpoints, and someone connects > > with some > > > obscure codec then I can see an arguement for having the originator > > > perform any transcoding. (And if that is indeed the case, > > it may even > > > be like lots of other stuff an originating network may or > > may not do > > > that we don't care about and call out of scope.) > > > > > > Jason > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 14:03:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7yat-0003iL-Bm; Tue, 01 Aug 2006 14:03:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7yas-0003iF-IT for speermint@ietf.org; Tue, 01 Aug 2006 14:03:50 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7yaq-0001kc-VL for speermint@ietf.org; Tue, 01 Aug 2006 14:03:50 -0400 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Tue, 01 Aug 2006 11:03:26 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k71I3Xuv008882; Tue, 1 Aug 2006 11:03:34 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k71I31R8028824; Tue, 1 Aug 2006 11:03:14 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 11:03:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Voice codecs Date: Tue, 1 Aug 2006 11:01:09 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D220C337D@namail5.corp.adobe.com> In-Reply-To: <060401c6b592$5e7052b0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXgAJXsKmAACa16AAAAir3QACN3DBAADATlwAAA2WbAAABX46A= From: "Henry Sinnreich" To: "Brian Rosen" , "Drage, Keith \(Keith\)" , X-OriginalArrivalTime: 01 Aug 2006 18:03:08.0691 (UTC) FILETIME=[BEC38630:01C6B594] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: Ed Okerson , Jean-Marc Valin X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian, > I'm a big believer in wideband all around. Then why capitulate for "race to the bottom with PSTN" as you so well say it? Folks: Is this sentiment (race to the bottom with PSTN), of giving up, shared by you and your employers? If "racing to the bottom" is not in the business plan, take one more look at http://www.speex.org/comparison.html=20 Thanks, Henry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, August 01, 2006 10:46 AM To: Henry Sinnreich; 'Drage, Keith (Keith)'; speermint@ietf.org Cc: 'Greg Herlein'; 'Ed Okerson'; 'Jean-Marc Valin' Subject: RE: [Speermint] Voice codecs Henry If you have EvRC on one side and AMR on the other side, SPEEX will only hurt your quality if you force it in the middle. I really, truly believe that vendors and carriers who don't offer common wideband codecs as standard with their products have shot themselves in the foot. VoIP should have been positioned as better than "toll" quality. I'm a big believer in wideband all around. I think there are no excuses, the vendors and carriers just plain blew it, and are stuck on a race to the bottom with PSTN, when they could have been talking about better service. =20 But given the realities, and I'm also big on reality, forcing SPEEX in the middle is truly a bad idea. Brian > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Tuesday, August 01, 2006 1:23 PM > To: Drage, Keith (Keith); Brian Rosen; speermint@ietf.org > Cc: Greg Herlein; Ed Okerson; Jean-Marc Valin > Subject: RE: [Speermint] Voice codecs >=20 > It is heartening to see the interest in codecs after all in this group! >=20 > > That is why I think that if we mandate transcoders >=20 > A much better approach is to mandate SPEEX and only _allow_ (tolerate) > transcoders for backward compatibility with legacy equipment. >=20 > See why at: http://speex.org/docs.html and we can discuss the pros and > cons of what is truly the basics of any VoIP peering: Voice quality for > the user. >=20 > Users could not care less about all the signaling issues that are > debated here, but they will instantly perceive the quality of the > peering. >=20 > Thanks, Henry >=20 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Tuesday, August 01, 2006 5:13 AM > To: Brian Rosen; speermint@ietf.org > Subject: RE: [Speermint] Voice codecs >=20 > That is why I think that if we mandate transcoders, we should also make > sure we have studied the issues to allow us to have the minimum number > of transcodes, and if that means new protocol, then so be it. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: 31 July 2006 19:39 > > To: 'Geoff Devine'; 'Livingood, Jason'; speermint@ietf.org > > Cc: 'Ed Okerson'; 'Lipford,Mark A [CTO]' > > Subject: RE: [Speermint] Voice codecs > > > > Okay, makes sense. So, maybe it's more like, the federation > > agrees on minimal codec support, and participants must be > > prepared to transcode to that minimal set if their endpoints need it. > > > > I don't think you can mandate anything that guarantees only > > one transcode. > > However desirable it may be. > > > > Brian > > > > > -----Original Message----- > > > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > > > Sent: Monday, July 31, 2006 2:28 PM > > > To: Livingood, Jason; Brian Rosen; speermint@ietf.org > > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Klaus Darilion; > > > Henry Sinnreich > > > Subject: RE: [Speermint] Voice codecs > > > > > > In your codec architecture example, you say that the originator may > > > have some strange and wonderful codec that is not supported by the > > > peer network. I'd point out that the other 50% of the time, that > > > endpoint is the terminator in the call, not the originator. > > I would > > > think that transcoding would be something that is > > negotiated as part > > > of the peering business arrangement. In terms of $ per port, > > > transcoding is a relatively costly operation and somebody > > is going to > > > have to purchase and operate the transcoding equipment. > > > > > > Transcoding, like echo cancellation, is something you want to avoid > > > doing extra times since it degrades voice quality. A path > > that goes, > > > say, from AMR to G.711 to iLBC is going to have a lower MOS > > score than > > > a path that goes AMR to iLBC. Ideally, you don't want to > > transcode at > > > all since that gives you the least impairment and the least delay. > > > > > > Geoff > > > > > > -----Original Message----- > > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Sent: Monday, July 31, 2006 9:47 AM > > > To: Brian Rosen; speermint@ietf.org > > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Geoff Devine; > > > Klaus Darilion; Henry Sinnreich > > > Subject: RE: [Speermint] Voice codecs > > > > > > Brian wrote: > > > > > > > I did say something in my message which may have escaped some > > > > notice. I said "origination side". One of the things > > you have to > > > > get right on any kind of part like transcoding is what > > assumptions > > > > are made. You can assume the origination side does it, the > > > > destination side does it or the peering fabric itself does it. I > > > > think it's essential to choose one, or we won't have > > > > interoperability. More than one is always possible, but at least > > > > one is required. I think origination side is best: it means that > > > > across the peering fabric, there is at least one common codec. > > > > > > So, it is looking convincingly now that WG consensus is against a > > > lowest common denominator codec. ;-) > > > > > > But Brian raises an interesting question here. Somewhere in our > > > drafts (several of them) we *may* need to consider optional > > inclusion > > > of a transcoding function and describe how it might be > > implemented. > > > When we take up that discussion, I think Brian poses an > > interesting question. > > > > > > If I consider it from the perspective of some operator that > > is using > > > all the major codecs in my endpoints, and someone connects > > with some > > > obscure codec then I can see an arguement for having the originator > > > perform any transcoding. (And if that is indeed the case, > > it may even > > > be like lots of other stuff an originating network may or > > may not do > > > that we don't care about and call out of scope.) > > > > > > Jason > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 14:03:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7yaz-0003lD-I0; Tue, 01 Aug 2006 14:03:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7yay-0003l8-Gf for speermint@ietf.org; Tue, 01 Aug 2006 14:03:56 -0400 Received: from outbound-red.frontbridge.com ([216.148.222.49] helo=outbound2-red-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7yax-0001st-7P for speermint@ietf.org; Tue, 01 Aug 2006 14:03:56 -0400 Received: from outbound2-red.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-red-R.bigfish.com (Postfix) with ESMTP id 065FE100EC64 for ; Tue, 1 Aug 2006 18:03:55 +0000 (UTC) Received: from mail84-red-R.bigfish.com (unknown [172.18.12.3]) by outbound2-red.bigfish.com (Postfix) with ESMTP id F24E6100EC3F for ; Tue, 1 Aug 2006 18:03:54 +0000 (UTC) Received: from mail84-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail84-red-R.bigfish.com (Postfix) with ESMTP id C42C456BB5D for ; Tue, 1 Aug 2006 18:03:54 +0000 (UTC) X-BigFish: V Received: by mail84-red (MessageSwitch) id 1154455382795506_24793; Tue, 1 Aug 2006 18:03:02 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail84-red.bigfish.com (Postfix) with ESMTP id A5C91574B8E for ; Tue, 1 Aug 2006 18:03:02 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k71I3192017896 for ; Tue, 1 Aug 2006 13:03:02 -0500 (CDT) Received: from pdawg06a.ad.sprint.com (PDAWG06A.corp.sprint.com [10.122.2.33]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k71I30x06077 for ; Tue, 1 Aug 2006 13:03:00 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by pdawg06a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 13:03:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Aug 2006 13:02:55 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A130237C643@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secure RTP Thread-Index: Aca1f2ER5z280PXVSSampLyHtIQnRAAFIzDQ From: "Khan, Sohel Q [CTO]" To: X-OriginalArrivalTime: 01 Aug 2006 18:03:00.0914 (UTC) FILETIME=[BA20D920:01C6B594] X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Speermint] Secure RTP X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 Should SPEERMINT require Secure RTP for VoIP peering? (see section 3.4 ... Editor's Note, SPEERMINT Requirements draft) Thanks, Sohel Khan _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 14:11:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7yi7-0008W6-DG; Tue, 01 Aug 2006 14:11:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7yi5-0008TZ-Uu for speermint@ietf.org; Tue, 01 Aug 2006 14:11:17 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7yi4-0003EX-P1 for speermint@ietf.org; Tue, 01 Aug 2006 14:11:17 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 01 Aug 2006 14:11:23 -0400 id 01588143.44CF994C.00003C16 Message-ID: <44CF993B.40902@hxr.us> Date: Tue, 01 Aug 2006 14:11:07 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: richard@shockey.us Subject: Re: TLS for peering (wasRE:Comments (RE:[speermint]requirementsdraftsubmitted)) References: <00ec01c6b576$27b612d0$23f0a544@cis.neustar.com> In-Reply-To: <00ec01c6b576$27b612d0$23f0a544@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: speermint@ietf.org, "'Lee, Yiu'" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Richard Shockey wrote: > Yes but that is edge to edge, not end to end. > > I'm convinced that we are going to make very little progress unless we state > that the first iteration here of speerming is really edge to edge oriented. I'm lost. What problem is being solved by this solution? -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 14:26:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ywZ-00020N-Nx; Tue, 01 Aug 2006 14:26:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ywY-00020H-46 for speermint@ietf.org; Tue, 01 Aug 2006 14:26:14 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7ywV-0004r2-Qr for speermint@ietf.org; Tue, 01 Aug 2006 14:26:14 -0400 Received: from PMelampy2 [10.0.200.104] by acmepacket.com with ESMTP (SMTPD-9.03) id ACCC014C; Tue, 01 Aug 2006 14:26:20 -0400 From: "Patrick Melampy" To: "'Khan, Sohel Q [CTO]'" , Subject: RE: [Speermint] Secure RTP Date: Tue, 1 Aug 2006 14:26:11 -0400 Message-ID: <005e01c6b597$f6e798a0$68c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca1f2ER5z280PXVSSampLyHtIQnRAAFIzDQAAD1gZA= In-Reply-To: <858217C310A3D94182FA8AAE42860A130237C643@PLSWB08C.ad.sprint.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Not in my opinion. Both Codecs and SRTP can be negotiated at the signaling plane. Why bother requiring things that are already supported during the offer answer process. -----Original Message----- From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] Sent: Tuesday, August 01, 2006 2:03 PM To: speermint@ietf.org Subject: [Speermint] Secure RTP Should SPEERMINT require Secure RTP for VoIP peering? (see section 3.4 ... Editor's Note, SPEERMINT Requirements draft) Thanks, Sohel Khan _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 14:36:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7z6w-0002qG-G5; Tue, 01 Aug 2006 14:36:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7z6u-0002j9-9Y for speermint@ietf.org; Tue, 01 Aug 2006 14:36:56 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7z3v-0005aN-Rl for speermint@ietf.org; Tue, 01 Aug 2006 14:33:52 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 01 Aug 2006 14:33:59 -0400 id 015880F9.44CF9E97.000040BA Message-ID: <44CF9E87.8060200@hxr.us> Date: Tue, 01 Aug 2006 14:33:43 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Khan, Sohel Q [CTO]" Subject: Re: [Speermint] Secure RTP References: <858217C310A3D94182FA8AAE42860A130237C643@PLSWB08C.ad.sprint.com> In-Reply-To: <858217C310A3D94182FA8AAE42860A130237C643@PLSWB08C.ad.sprint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Khan, Sohel Q [CTO] wrote: > > Should SPEERMINT require Secure RTP for VoIP peering? > > (see section 3.4 ... Editor's Note, SPEERMINT Requirements draft) Considering all the talk about TLS, sure. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 14:54:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zNi-0003Rt-Ne; Tue, 01 Aug 2006 14:54:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zNh-0003Rc-Kn for speermint@ietf.org; Tue, 01 Aug 2006 14:54:17 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7zNf-00032c-Ag for speermint@ietf.org; Tue, 01 Aug 2006 14:54:17 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G7zNV-0006Tt-2m; Tue, 01 Aug 2006 13:54:06 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Khan, Sohel Q [CTO]'" Subject: RE: [Speermint] Secure RTP Date: Tue, 1 Aug 2006 14:54:04 -0400 Message-ID: <068101c6b59b$e1287080$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44CF9E87.8060200@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca1mXci2ZS6C6fiSZS5xivT1Q0UcgAAU83g X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I think we want to ask the question: Is the peering system transparent to media? This does not imply anything about media anchor points either end might have, but asks do we assume that the peering system is transparent to media or do we assume it is NOT transparent. Let me give you two extremes: One is a peering system that does not provide ANY media services. It's just a signaling interworking and peering system. It doesn't care what is in the SDP, doesn't have any affect on the SDP; it's completely transparent to the media, which would flow from the origination to termination (ignoring transit) outside of the peering system. The other is a media switch. All media goes to the switch which switches it to the other side. It acts as a B2BUA for all calls. I think that we are looking at case 1, and not at case 2. I don't think we care about the media. So, from strictly a peering point of view, this is a don't care, but like the codec choice, if you want interoperability, you have to state the assumptions or you won't get it. In this case I think it's strictly optional (that is, all participants must be prepared to accept RTP that is not protected with SRTP). Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, August 01, 2006 2:34 PM > To: Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Subject: Re: [Speermint] Secure RTP > > Khan, Sohel Q [CTO] wrote: > > > > Should SPEERMINT require Secure RTP for VoIP peering? > > > > (see section 3.4 ... Editor's Note, SPEERMINT Requirements draft) > > Considering all the talk about TLS, sure. > > -andy > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 15:07:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zaC-0006OX-Hs; Tue, 01 Aug 2006 15:07:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zaB-0006Bo-62 for speermint@ietf.org; Tue, 01 Aug 2006 15:07:11 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7zaA-0004Z6-0O for speermint@ietf.org; Tue, 01 Aug 2006 15:07:11 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 01 Aug 2006 15:07:17 -0400 id 015880F9.44CFA665.00004758 Message-ID: <44CFA655.3030605@hxr.us> Date: Tue, 01 Aug 2006 15:07:01 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Speermint] Secure RTP References: <068101c6b59b$e1287080$640fa8c0@cis.neustar.com> In-Reply-To: <068101c6b59b$e1287080$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian Rosen wrote: > I think that we are looking at case 1, and not at case 2. I don't think we > care about the media. Interesting. I don't know about you, but I get paid for getting the media right. Perfect signaling is useless without media. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 15:11:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zeZ-0000YJ-F3; Tue, 01 Aug 2006 15:11:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zeY-0000YA-Br for speermint@ietf.org; Tue, 01 Aug 2006 15:11:42 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7zeW-0006DG-4h for speermint@ietf.org; Tue, 01 Aug 2006 15:11:42 -0400 Received: from ([10.52.116.10]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.22814652; Tue, 01 Aug 2006 15:11:20 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 15:11:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Secure RTP Date: Tue, 1 Aug 2006 15:11:18 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD4CEF9B@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Secure RTP Thread-Index: Aca1f2ER5z280PXVSSampLyHtIQnRAAFIzDQAAKKj0A= From: "Lee, Yiu" To: "Khan, Sohel Q [CTO]" , X-OriginalArrivalTime: 01 Aug 2006 19:11:19.0726 (UTC) FILETIME=[4535ECE0:01C6B59E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org What is the implication to CALEA if SPEERMINT requires SRTP?=20 -----Original Message----- From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com]=20 Sent: Tuesday, August 01, 2006 2:03 PM To: speermint@ietf.org Subject: [Speermint] Secure RTP =20 Should SPEERMINT require Secure RTP for VoIP peering? (see section 3.4 ... Editor's Note, SPEERMINT Requirements draft) Thanks, Sohel Khan _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 15:11:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zec-0000bq-Lq; Tue, 01 Aug 2006 15:11:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zeb-0000ZI-IP for speermint@ietf.org; Tue, 01 Aug 2006 15:11:45 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7zea-0006DQ-45 for speermint@ietf.org; Tue, 01 Aug 2006 15:11:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Secure RTP Date: Tue, 1 Aug 2006 21:10:51 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B46@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Secure RTP Thread-Index: Aca1mXci2ZS6C6fiSZS5xivT1Q0UcgAAU83gAAB3qKk= References: <068101c6b59b$e1287080$640fa8c0@cis.neustar.com> From: "Stastny Richard" To: "Brian Rosen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >I think that we are looking at case 1, and not at case 2. I don't = think we >care about the media. Yes =20 First things first =20 a solution to case 1 is required for case 2 anyway -sta ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Di 01.08.2006 20:54 An: 'Andrew Newton'; 'Khan, Sohel Q [CTO]' Cc: speermint@ietf.org Betreff: RE: [Speermint] Secure RTP I think we want to ask the question: Is the peering system transparent = to media? This does not imply anything about media anchor points either = end might have, but asks do we assume that the peering system is transparent = to media or do we assume it is NOT transparent. Let me give you two extremes: One is a peering system that does not provide ANY media services. It's = just a signaling interworking and peering system. It doesn't care what is in = the SDP, doesn't have any affect on the SDP; it's completely transparent to = the media, which would flow from the origination to termination (ignoring transit) outside of the peering system. The other is a media switch. All media goes to the switch which = switches it to the other side. It acts as a B2BUA for all calls. I think that we are looking at case 1, and not at case 2. I don't think = we care about the media. So, from strictly a peering point of view, this is a don't care, but = like the codec choice, if you want interoperability, you have to state the assumptions or you won't get it. In this case I think it's strictly optional (that is, all participants must be prepared to accept RTP that = is not protected with SRTP). Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, August 01, 2006 2:34 PM > To: Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Subject: Re: [Speermint] Secure RTP > > Khan, Sohel Q [CTO] wrote: > > > > Should SPEERMINT require Secure RTP for VoIP peering? > > > > (see section 3.4 ... Editor's Note, SPEERMINT Requirements draft) > > Considering all the talk about TLS, sure. > > -andy > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 15:24:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zrC-0005g5-2B; Tue, 01 Aug 2006 15:24:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zrB-0005g0-LK for speermint@ietf.org; Tue, 01 Aug 2006 15:24:45 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7zrA-0006pK-DJ for speermint@ietf.org; Tue, 01 Aug 2006 15:24:45 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G7zr2-0000Cm-GN; Tue, 01 Aug 2006 14:24:36 -0500 From: "Brian Rosen" To: "'Lee, Yiu'" , "'Khan, Sohel Q [CTO]'" , Subject: RE: [Speermint] Secure RTP Date: Tue, 1 Aug 2006 15:24:40 -0400 Message-ID: <068b01c6b5a0$2517a820$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8587F175CDB3D741B58C79F67E8E09AD4CEF9B@PACDCEXCMB03.cable.comcast.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca1f2ER5z280PXVSSampLyHtIQnRAAFIzDQAAKKj0AAAGxbAA== X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org As with any interexchange carrier situation, CALEA doesn't apply to the peering, it applies to (possibly both) endpoints. IANAL, but I think if the carrier has the keys, it must give them up, and if it doesn't, it doesn't have to do anything except deliver the (encrypted) media packets. Brian > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Sent: Tuesday, August 01, 2006 3:11 PM > To: Khan, Sohel Q [CTO]; speermint@ietf.org > Subject: RE: [Speermint] Secure RTP > > What is the implication to CALEA if SPEERMINT requires SRTP? > > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Tuesday, August 01, 2006 2:03 PM > To: speermint@ietf.org > Subject: [Speermint] Secure RTP > > > Should SPEERMINT require Secure RTP for VoIP peering? > > (see section 3.4 ... Editor's Note, SPEERMINT Requirements draft) > > Thanks, > > Sohel Khan > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 15:32:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zz4-0007Oa-2G; Tue, 01 Aug 2006 15:32:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zz2-0007OT-Q3 for speermint@ietf.org; Tue, 01 Aug 2006 15:32:52 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7zz1-0007GX-GN for speermint@ietf.org; Tue, 01 Aug 2006 15:32:52 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G7zyr-0000ly-Lh; Tue, 01 Aug 2006 14:32:42 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Speermint] Secure RTP Date: Tue, 1 Aug 2006 15:32:46 -0400 Message-ID: <068c01c6b5a1$46cf4a30$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44CFA655.3030605@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqw X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Sure, but does the peering touch the media? I claim it doesn't, at least normally. "Getting it right" means that when the signaling happens, the resulting SDP will work. That part (the SDP part) matters to us, because we have to make sure that when that SDP gets to the other side, it will result in something that works. The peering system doesn't have to even look at the SDP, it just has to have rules that make interoperability work. The peering system has to, for example, make sure that an address given in the SDP on one side is actually reachable on the other side. Doing that doesn't involve any work, it's just rules the federation agrees to that makes that be true. So, we might need to specify no NAT or conversely, MUST support ICE. That all speaks to what the peers have to have between their endpoints and their peers. It doesn't imply the media packets traverse the peering fabric. Of course, in theory, the peering system doesn't even have to touch the signaling, but we don't have to go there. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, August 01, 2006 3:07 PM > To: Brian Rosen > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > Subject: Re: [Speermint] Secure RTP > > Brian Rosen wrote: > > I think that we are looking at case 1, and not at case 2. I don't think > we > > care about the media. > > Interesting. I don't know about you, but I get paid for getting the media > right. Perfect signaling is useless without media. > > -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 15:38:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G804M-0002S4-KW; Tue, 01 Aug 2006 15:38:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G804L-0002Rz-SF for speermint@ietf.org; Tue, 01 Aug 2006 15:38:21 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G804K-0007U6-5U for speermint@ietf.org; Tue, 01 Aug 2006 15:38:21 -0400 Received: from PMelampy2 [10.0.200.104] by acmepacket.com with ESMTP (SMTPD-9.03) id ADB20140; Tue, 01 Aug 2006 15:38:26 -0400 From: "Patrick Melampy" To: Date: Tue, 1 Aug 2006 15:38:17 -0400 Message-ID: <001401c6b5a2$0954ce40$68c8000a@acmepacket.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca1ogk/ZR+s8QXkSQCz716R5bT9Nw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0634ec58aad05a6aa9ac7d4670be9c6c Subject: [Speermint] Re: draft-ietf-speermint-requirements-00.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1195290058==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1195290058== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C6B580.82432E40" This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C6B580.82432E40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I would re-label the section 2.3 from "No Blocked Calls" to "Path Discovery and Availability". The ability to know that you can send a call at any time, and where to send it, is the essence of what the author intended here. I would in addition expand on this to include two sections: 2.3.1 Adjacency Attributes (Next hop network attributes) a. What proxies can a party use. For each proxy: i. How fast can I send calls (CPS) ii. How many calls can I send (total established calls) iii. How much bandwidth can I use (KBS) b. If there are many adjacent proxies to use, which should I use: i. Does the location of the proxy matter? ii. Is the proxy location a semaphore for where the media will cross? 2.3.2 Path Discovery and Attributes (Domains that are NOT adjacent) c. What are the paths to the destination domain that can: i. Guarantee quality ii. Participate in Guarantee's for Trust iii. Are these paths available It may not go in this section 2.3, but it is related to adjacency, and path availability 2.3.3 Adjacency and Path Congestion detection/avoidance d. How can a carrier restrict inflow of traffic (not call-by-call) i. For maintenance actions ii. For congestion management e. How can a carrier prevent upstream networks from submitting calls for certain destinations in overload i. Equivalent to SS7 ACC (Automatic Congestion Control) ------=_NextPart_000_0015_01C6B580.82432E40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I would re-label the section 2.3 from “No = Blocked Calls” to “Path Discovery and Availability”. The = ability to know that you can send a call at any time, and where to send it, is the = essence of what the author intended here. I would in addition expand on this to = include two sections:

 

2.3.1 Adjacency Attributes (Next hop network = attributes)

a.       = What proxies can a party use. For each proxy:

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   i.      How fast can I send calls = (CPS)

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp; ii.      How many calls can I send = (total established calls)

           = ;            =             &= nbsp;           &n= bsp;            iii.      How much bandwidth can I = use (KBS)

b.       = If there are many adjacent proxies to use, which should I = use:

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   i.      Does the location of the = proxy matter?

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp; ii.      Is the proxy location a = semaphore for where the media will cross?

2.3.2 Path Discovery and Attributes (Domains that are = NOT adjacent)

c.       = What are the paths to the destination domain that can:

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   i.      Guarantee = quality

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp; ii.      Participate in = Guarantee’s for Trust

           = ;            =             &= nbsp;           &n= bsp;            iii.      Are these paths = available

 

It may not go in this section 2.3, but it is related = to adjacency, and path availability

 

2.3.3          Adjacency and Path = Congestion detection/avoidance

d.       = How can a carrier restrict inflow of traffic (not = call-by-call)

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   i.      For maintenance = actions

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp; ii.      For congestion = management

e.       = How can a carrier prevent upstream networks from submitting calls for certain destinations in overload

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   i.      Equivalent to SS7 ACC = (Automatic Congestion Control)

------=_NextPart_000_0015_01C6B580.82432E40-- --===============1195290058== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1195290058==-- From speermint-bounces@ietf.org Tue Aug 01 16:09:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G80Y5-0002wm-8L; Tue, 01 Aug 2006 16:09:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G80Y3-0002vW-W6 for speermint@ietf.org; Tue, 01 Aug 2006 16:09:04 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G80Y1-0001zB-O5 for speermint@ietf.org; Tue, 01 Aug 2006 16:09:03 -0400 Received: from ([10.20.9.174]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.22920074; Tue, 01 Aug 2006 16:08:34 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 16:08:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Secure RTP Date: Tue, 1 Aug 2006 16:07:41 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD4CF033@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Secure RTP Thread-Index: Aca1f2ER5z280PXVSSampLyHtIQnRAAFIzDQAAKKj0AAAGxbAAABYdWw From: "Lee, Yiu" To: "Brian Rosen" , "Khan, Sohel Q [CTO]" , X-OriginalArrivalTime: 01 Aug 2006 20:08:34.0106 (UTC) FILETIME=[4442B9A0:01C6B5A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi Brain, I was thinking what happened if the caller and callee negotiated the keys directly to encrypt the stream. In this case, the network operators wouldn't have the keys to decrypt the stream. However, if it happened, this wouldn't be the operator responsibility to decrypt the stream. I agree if the network is providing SRTP, the network operator should have the key for CELEA. Thanks, Yiu =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, August 01, 2006 3:25 PM To: Lee, Yiu; 'Khan, Sohel Q [CTO]'; speermint@ietf.org Subject: RE: [Speermint] Secure RTP As with any interexchange carrier situation, CALEA doesn't apply to the peering, it applies to (possibly both) endpoints. IANAL, but I think if the carrier has the keys, it must give them up, and if it doesn't, it doesn't have to do anything except deliver the (encrypted) media packets. Brian > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Sent: Tuesday, August 01, 2006 3:11 PM > To: Khan, Sohel Q [CTO]; speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > What is the implication to CALEA if SPEERMINT requires SRTP? >=20 > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Tuesday, August 01, 2006 2:03 PM > To: speermint@ietf.org > Subject: [Speermint] Secure RTP >=20 >=20 > Should SPEERMINT require Secure RTP for VoIP peering? >=20 > (see section 3.4 ... Editor's Note, SPEERMINT Requirements draft) >=20 > Thanks, >=20 > Sohel Khan >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 16:09:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G80Y7-0002xs-E0; Tue, 01 Aug 2006 16:09:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G80Y5-0002wy-Ll for speermint@ietf.org; Tue, 01 Aug 2006 16:09:05 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G80Y4-0001zD-6K for speermint@ietf.org; Tue, 01 Aug 2006 16:09:05 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A4E505E8; Tue, 01 Aug 2006 16:09:09 -0400 From: "Hadriel Kaplan" To: "'Brian Rosen'" Subject: RE: [Speermint] Secure RTP Date: Tue, 1 Aug 2006 16:09:00 -0400 Message-ID: <015401c6b5a6$544bf320$6601a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySA= In-Reply-To: <068c01c6b5a1$46cf4a30$640fa8c0@cis.neustar.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org But there are currently 11(?) proposed SRTP key exchange mechanisms, some using SDP, some not - none of which interoperate. So "interoperability" is impacted there, and part of it is a signaling issue. In that sense it may well be reasonable for a speermint BCP to pick one preferred mechanism, but I'm sure that will be yet another rat-hole. And I recommend we stay out of those when we can. :) (besides, the RTPSEC-BOF group is assigned that Herculean task) -hadriel > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, August 01, 2006 3:33 PM > To: 'Andrew Newton' > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > Subject: RE: [Speermint] Secure RTP > > Sure, but does the peering touch the media? I claim it doesn't, at least > normally. "Getting it right" means that when the signaling happens, the > resulting SDP will work. That part (the SDP part) matters to us, because > we > have to make sure that when that SDP gets to the other side, it will > result > in something that works. The peering system doesn't have to even look at > the SDP, it just has to have rules that make interoperability work. > > The peering system has to, for example, make sure that an address given in > the SDP on one side is actually reachable on the other side. Doing that > doesn't involve any work, it's just rules the federation agrees to that > makes that be true. So, we might need to specify no NAT or conversely, > MUST > support ICE. That all speaks to what the peers have to have between their > endpoints and their peers. It doesn't imply the media packets traverse > the > peering fabric. > > Of course, in theory, the peering system doesn't even have to touch the > signaling, but we don't have to go there. > > Brian > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Tuesday, August 01, 2006 3:07 PM > > To: Brian Rosen > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > Subject: Re: [Speermint] Secure RTP > > > > Brian Rosen wrote: > > > I think that we are looking at case 1, and not at case 2. I don't > think > > we > > > care about the media. > > > > Interesting. I don't know about you, but I get paid for getting the > media > > right. Perfect signaling is useless without media. > > > > -andy > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 16:59:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G81Kk-0000Ap-Q4; Tue, 01 Aug 2006 16:59:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G81Kj-0000Ac-6P for speermint@ietf.org; Tue, 01 Aug 2006 16:59:21 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G81Kg-0006im-Ns for speermint@ietf.org; Tue, 01 Aug 2006 16:59:21 -0400 Received: from source ([192.150.20.142]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Tue, 01 Aug 2006 13:59:15 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k71KxIuv006320; Tue, 1 Aug 2006 13:59:19 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k71Kvs4b024623; Tue, 1 Aug 2006 13:58:43 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 13:57:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Secure RTP Date: Tue, 1 Aug 2006 13:57:29 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D220C33C0@namail5.corp.adobe.com> In-Reply-To: <44CFA655.3030605@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Secure RTP Thread-Index: Aca1nbdwAN1/chR9TsmrYhbunesqtAAC6Jfw From: "Henry Sinnreich" To: "Andrew Newton" , "Brian Rosen" X-OriginalArrivalTime: 01 Aug 2006 20:57:30.0427 (UTC) FILETIME=[1A71C0B0:01C6B5AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > Perfect signaling is useless without media. Amen and please y'all remember it. Thanks, Henry -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Tuesday, August 01, 2006 12:07 PM To: Brian Rosen Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org Subject: Re: [Speermint] Secure RTP Brian Rosen wrote: > I think that we are looking at case 1, and not at case 2. I don't think we > care about the media.=20 Interesting. I don't know about you, but I get paid for getting the media=20 right. Perfect signaling is useless without media. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 17:15:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G81aa-0007ds-Bl; Tue, 01 Aug 2006 17:15:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G81aZ-0007dG-CM for speermint@ietf.org; Tue, 01 Aug 2006 17:15:43 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G81aX-0000W5-4s for speermint@ietf.org; Tue, 01 Aug 2006 17:15:43 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 01 Aug 2006 17:15:48 -0400 id 01588143.44CFC484.00005F32 Message-ID: <44CFC474.1090800@hxr.us> Date: Tue, 01 Aug 2006 17:15:32 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [Speermint] Voice codecs References: <24CCCC428EFEA2469BF046DB3C7A8D220C3368@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D220C3368@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: speermint@ietf.org, Jean-Marc Valin , Ed Okerson X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Henry Sinnreich wrote: > It is heartening to see the interest in codecs after all in this group! I agree. > A much better approach is to mandate SPEEX and only _allow_ (tolerate) > transcoders for backward compatibility with legacy equipment. I think we should definitely explore this option. > See why at: http://speex.org/docs.html and we can discuss the pros and > cons of what is truly the basics of any VoIP peering: Voice quality for > the user. Buried in the FAQ at that site, I found this: > Can Speex pass DTMF? > > I guess it all depends on the bit-rate used. Though no formal testing has yet been performed, I'd say don't go below the 15 kbps mode if you want DTMF to be transmitted correctly. DTMF at 8 kbps may work but your mileage may vary. Also, make sure you don't use the lowest complexity (see SPEEX_SET_COMPLEXITY or -comp option), as it causes significant noise. I'm surprised nobody has mentioned making RFC 2833 mandatory. > Users could not care less about all the signaling issues that are > debated here, but they will instantly perceive the quality of the > peering. I agree. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 17:30:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G81of-0002NK-0V; Tue, 01 Aug 2006 17:30:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G81od-0002Ms-EG for speermint@ietf.org; Tue, 01 Aug 2006 17:30:15 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G81oa-0002HN-To for speermint@ietf.org; Tue, 01 Aug 2006 17:30:15 -0400 Received: from PMelampy2 [10.0.200.104] by acmepacket.com with ESMTP (SMTPD-9.03) id A7ED04EC; Tue, 01 Aug 2006 17:30:21 -0400 From: "Patrick Melampy" To: Subject: Re: [Speermint] draft-mahy-speermint-direct-peering-00.txt Date: Tue, 1 Aug 2006 17:30:11 -0400 Message-ID: <004801c6b5b1$ab526360$68c8000a@acmepacket.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca1sar1tZOzngQ9SmWUOThbgBZNTQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1620860479==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1620860479== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01C6B590.2440C360" This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C6B590.2440C360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Rohan - excellent work - thank you! I wanted to understand and comment on your draft. Section 4.1.3 entitled Carrier ENUM Lookup is really interesting, and I believe this concept can really work. I wanted to understand the mechanism a little more. If the "carrier-of-record" is returned, there may not be a guarantee that there exists a useful adjacency. I also assume that there may be more than one carrier-of-record for each domain (I'm thinking that a large multi-national company like NEC might have NTT be a carrier of record in Japan, but AT&T as a carrier of record in the USA). I believe that in the case of more than one carrier-of-record, the source of the communication can just pick whichever they think is best. I think that carrier-enum could really work if each participating domain built its own table/database. So carriers would advertise through some means reachable domains. These would be placed into a local adjacent-carrier-enum database, with the resultant always being the network that delivered the advertisement. Thus every carrier-enum resolution would always resolve to a NAPTR record that pointed to a single adjacent carrier. It would be possible to get two adjacent carriers that can complete a communication. Breaking the tie is out of scope currently, and is likely to be based on parameters of the business relationship. This has the possibility to scale to any size imaginable, and always be capable of resolving which next hop network can complete a communication request. So now we have the DOMAIN of the next hop network (as opposed to the final carrier-of-record). However when we get to section 4.1.5 entitled SIP DNS resolution, I worry that this is insufficient. First of all, I believe that network adjacencies will be more managed than people think. I think that there will likely be service guarantees, performance measurements, and contractual commitments. I also believe that these types of requirements will be defined by specific adjacencies. So if carrier A peers with Carrier B, A and B will likely have complex agreements. These will likely include volume commitments, and capacity guarantees. So I think that A and B will have some structure around how each accesses the other. I think (based on what I see today) this will include (for A sending to B) 1.) Which proxies can A use on B's network 2.) What rates of calling can A initiate at each of B's proxies (each may be different) 3.) What total call count is B willing to support 4.) What total bandwidth is B willing to support for media The reciprocal is true if calls go from B to A. I believe that there should be a new step inserted in the process. Once we have the domain of the adjacent network to use, we should go through a step of obtaining through some mechanism the list of proxies that are available at the adjacent network for use. Once we locate the list of proxies, we should pick the best one (distance/cost/load/etc), then use the DNS SRV mechanism in 4.1.5 for getting transport methods and addresses. I don't believe DNS/SRV responses can provide enough fine grained controls over proxy selection to keep general chaos from breaking out. I just don't think the carriers will use a system that can't be made very deterministic and predictable. ------=_NextPart_000_0049_01C6B590.2440C360 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Rohan – excellent work – thank = you!

 

I wanted to understand and comment on your draft. = Section 4.1.3 entitled Carrier ENUM Lookup is really interesting, and I believe = this concept can really work. I wanted to understand the mechanism a little = more. If the “carrier-of-record” is returned, there may not be a = guarantee that there exists a useful adjacency. I also assume that there may be = more than one carrier-of-record for each domain (I’m thinking that a large multi-national company like NEC might have NTT be a carrier of record in = Japan, but AT&T as a carrier of = record in the USA). I believe that in the case of more than one carrier-of-record, the = source of the communication can just pick whichever they think is = best.

 

I think that carrier-enum could really work if each participating domain built its own table/database. So carriers would = advertise through some means reachable domains. These would be placed into a local = adjacent-carrier-enum database, with the resultant always being the network that delivered the advertisement. Thus every carrier-enum resolution would always resolve = to a NAPTR record that pointed to a single adjacent carrier. It would be = possible to get two adjacent carriers that can complete a communication. Breaking = the tie is out of scope currently, and is likely to be based on parameters of = the business relationship. This has the possibility to scale to any size imaginable, and always be capable of resolving which next hop network = can complete a communication request. So now we have the DOMAIN of the next = hop network (as opposed to the final = carrier-of-record).

 

However when we get to section 4.1.5 entitled SIP DNS resolution, I worry that this is insufficient. First of all, I believe = that network adjacencies will be more managed than people think. I think that = there will likely be service guarantees, performance measurements, and = contractual commitments. I also believe that these types of requirements will be = defined by specific adjacencies. So if carrier A peers with Carrier B, A and B will = likely have complex agreements. These will likely include volume commitments, = and capacity guarantees. So I think that A and B will have some structure = around how each accesses the other. I think (based on what I see today) this = will include (for A sending to B)

1.)     = Which proxies can A use on B’s network

2.)     = What rates of calling can A initiate at each of B’s proxies (each may be = different)

3.)     = What total call count is B willing to support

4.)     = What total bandwidth is B willing to support for media

The reciprocal is true if calls go from B to A. =

 

I believe that there should be a new step inserted in = the process. Once we have the domain of the adjacent network to use, we = should go through a step of obtaining through some mechanism the list of proxies = that are available at the adjacent network for use. Once we locate the list of = proxies, we should pick the best one (distance/cost/load/etc), then use the DNS = SRV mechanism in 4.1.5 for getting transport methods and = addresses.

 

I don’t believe DNS/SRV responses can provide = enough fine grained controls over proxy selection to keep general chaos from = breaking out. I just don’t think the carriers will use a system that = can’t be made very deterministic and predictable. =

------=_NextPart_000_0049_01C6B590.2440C360-- --===============1620860479== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1620860479==-- From speermint-bounces@ietf.org Tue Aug 01 18:05:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G82Mw-0002jT-QZ; Tue, 01 Aug 2006 18:05:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G82Mw-0002hf-9S for speermint@ietf.org; Tue, 01 Aug 2006 18:05:42 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G82Mt-0002mn-OO for speermint@ietf.org; Tue, 01 Aug 2006 18:05:42 -0400 Received: from source ([192.150.20.142]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Tue, 01 Aug 2006 15:05:22 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k71M5Tuv016989; Tue, 1 Aug 2006 15:05:29 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k71M5DQw024323; Tue, 1 Aug 2006 15:05:14 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 15:05:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Voice codecs Date: Tue, 1 Aug 2006 15:05:12 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D220C33E0@namail5.corp.adobe.com> In-Reply-To: <44CFC474.1090800@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: Aca1r6cwqPDwzs5AS1KQJP2Hdb1WVAAAU1ng From: "Henry Sinnreich" To: "Andrew Newton" X-OriginalArrivalTime: 01 Aug 2006 22:05:13.0557 (UTC) FILETIME=[90423050:01C6B5B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: speermint@ietf.org, Jean-Marc Valin , Ed Okerson X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >> Can Speex pass DTMF?=20 It is appropriate IMHO to use SPEEX wideband audio in the broadband age with 16 kHz sampling (44 kb/s bit rate, still less than the 64 kb/s for G.711), so as to have both better audio and DTMF support. Thanks, Henry -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Tuesday, August 01, 2006 2:16 PM To: Henry Sinnreich Cc: Drage, Keith (Keith); Brian Rosen; speermint@ietf.org; Ed Okerson; Jean-Marc Valin Subject: Re: [Speermint] Voice codecs Henry Sinnreich wrote: > It is heartening to see the interest in codecs after all in this group! I agree. > A much better approach is to mandate SPEEX and only _allow_ (tolerate) > transcoders for backward compatibility with legacy equipment. I think we should definitely explore this option. > See why at: http://speex.org/docs.html and we can discuss the pros and > cons of what is truly the basics of any VoIP peering: Voice quality for > the user. Buried in the FAQ at that site, I found this: > Can Speex pass DTMF? >=20 > I guess it all depends on the bit-rate used. Though no formal testing has yet been performed, I'd say don't go below the 15 kbps mode if you want DTMF to be transmitted correctly. DTMF at 8 kbps may work but your mileage may vary. Also, make sure you don't use the lowest complexity (see SPEEX_SET_COMPLEXITY or -comp option), as it causes significant noise.=20 I'm surprised nobody has mentioned making RFC 2833 mandatory. > Users could not care less about all the signaling issues that are > debated here, but they will instantly perceive the quality of the > peering. I agree. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 18:29:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G82jd-0005pf-Vz; Tue, 01 Aug 2006 18:29:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G82jd-0005oV-5S for speermint@ietf.org; Tue, 01 Aug 2006 18:29:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G81kn-0001p9-4P for speermint@ietf.org; Tue, 01 Aug 2006 17:26:17 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G81YO-0007d9-NE for speermint@ietf.org; Tue, 01 Aug 2006 17:13:32 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G81Y9-0007Co-Ax; Tue, 01 Aug 2006 16:13:13 -0500 From: "Brian Rosen" To: "'Lee, Yiu'" , "'Khan, Sohel Q [CTO]'" , Subject: RE: [Speermint] Secure RTP Date: Tue, 1 Aug 2006 17:13:19 -0400 Message-ID: <072201c6b5af$52bd4dc0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8587F175CDB3D741B58C79F67E8E09AD4CF033@PACDCEXCMB03.cable.comcast.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca1f2ER5z280PXVSSampLyHtIQnRAAFIzDQAAKKj0AAAGxbAAABYdWwAAFYG+A= X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.4 (--) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org If the carrier doesn't have the keys, then he can't give them up in response to a warrant. I've never heard of any LEA telling a carrier that they have to demand their customers stop using their own encryption. I think this is out of scope for SPEERMINT. In general, support for legal intercept is out of scope in the IETF. Brian > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Sent: Tuesday, August 01, 2006 4:08 PM > To: Brian Rosen; Khan, Sohel Q [CTO]; speermint@ietf.org > Subject: RE: [Speermint] Secure RTP > > Hi Brain, > > I was thinking what happened if the caller and callee negotiated the > keys directly to encrypt the stream. In this case, the network operators > wouldn't have the keys to decrypt the stream. However, if it happened, > this wouldn't be the operator responsibility to decrypt the stream. I > agree if the network is providing SRTP, the network operator should have > the key for CELEA. > > Thanks, > Yiu > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, August 01, 2006 3:25 PM > To: Lee, Yiu; 'Khan, Sohel Q [CTO]'; speermint@ietf.org > Subject: RE: [Speermint] Secure RTP > > > As with any interexchange carrier situation, CALEA doesn't apply to the > peering, it applies to (possibly both) endpoints. > > IANAL, but I think if the carrier has the keys, it must give them up, > and if it doesn't, it doesn't have to do anything except deliver the > (encrypted) media packets. > > Brian > > > > -----Original Message----- > > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > Sent: Tuesday, August 01, 2006 3:11 PM > > To: Khan, Sohel Q [CTO]; speermint@ietf.org > > Subject: RE: [Speermint] Secure RTP > > > > What is the implication to CALEA if SPEERMINT requires SRTP? > > > > -----Original Message----- > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > Sent: Tuesday, August 01, 2006 2:03 PM > > To: speermint@ietf.org > > Subject: [Speermint] Secure RTP > > > > > > Should SPEERMINT require Secure RTP for VoIP peering? > > > > (see section 3.4 ... Editor's Note, SPEERMINT Requirements draft) > > > > Thanks, > > > > Sohel Khan > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 18:30:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G82kf-0007lI-PP; Tue, 01 Aug 2006 18:30:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G82jw-00070j-7C for speermint@ietf.org; Tue, 01 Aug 2006 18:29:28 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G82jt-0001Jk-Hr for speermint@ietf.org; Tue, 01 Aug 2006 18:29:27 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A5C104D0; Tue, 01 Aug 2006 18:29:21 -0400 From: "Hadriel Kaplan" To: "'Brian Rosen'" , , "'Drage, Keith \(Keith\)'" , Subject: RE: [Speermint] Voice codecs Date: Tue, 1 Aug 2006 18:29:13 -0400 Message-ID: <01a801c6b5b9$ea593590$6601a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXgAJXsKmAACa16AAAAir3QACN3DBAAAcZk0AAEW4owAAFlG0AACNaYQA== In-Reply-To: <057901c6b57d$a74f2840$640fa8c0@cis.neustar.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org To me the codec issue is just too complex to deal with in Speermint. It has cost, demand, performance, and other issues which are different for everyone, hard to quantify, and harder to cover generically in a BCP. For instance, your example assumes xcoding from AMR to EVRC would be the best/optimal outcome. It may be from a voice quality perspective, but may not be from a cost perspective. (and it may even be the same quality) It's not a one-size-fits-all. Also, I disagree that both will xcode to 711 in your example... it depends. IMHO, the "protocol" for discovering the codec capabilities of each side already exists: it's SDP. The advantage of using it beyond the obvious KISS principle is it allows a provider to have a mixture of devices and codecs instead of normalizing to one codec policy for all devices all the time. It's even used today for including xcoders dynamically per call, but there's no question it's not perfect for everyone/every-case. Obviously there are advantages to knowing the set ahead of time, but I would think that's an issue for much later after much beer. -hadriel > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, August 01, 2006 11:18 AM > To: richard@shockey.us; 'Drage, Keith (Keith)'; speermint@ietf.org > Subject: RE: [Speermint] Voice codecs > > Nope, it's more interesting than that. Sure, each domain has a policy of > what codecs it allows on its network, but if you want to avoid double > transcoding, you want to know, really, what is happening on both sides of > the peering, to see if you can optimize it. > > Suppose A allows g.711 and AMR, and B allows g.711 and EvRC. You know > what > is really going to happen. The AMR handsets get transcoded to g.711 on A, > the EvRC handsets get transcoded to g.711 on B and they "work". > > But what you really want to know is whether there is a transcoder > available > on either side (or in the middle) for EvRC to AMR and vice versa. > > If that example doesn't convince you, suppose A's list was g.711 and AMR- > WB > and B's list was g.711 and VMR-WB. > > So, you don't want to force A or B to transcode to the federation's list > if > you can figure out what the "right" thing to do is. > > You want to take the list of codecs the originating endpoint really can > do, > and the similar list from the terminating endpoint, and see if you can > discover a resource that can bridge across the lists. > > This isn't a policy issue really. > > Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 01 18:44:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G82yZ-0004Aw-Hj; Tue, 01 Aug 2006 18:44:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G82yY-0004Ap-1i for speermint@ietf.org; Tue, 01 Aug 2006 18:44:34 -0400 Received: from outbound-res.frontbridge.com ([63.161.60.49] helo=outbound1-res-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G82yW-0002zv-QP for speermint@ietf.org; Tue, 01 Aug 2006 18:44:34 -0400 Received: from outbound1-res.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-res-R.bigfish.com (Postfix) with ESMTP id B2D458FC415; Tue, 1 Aug 2006 22:44:32 +0000 (UTC) Received: from mail2-res-R.bigfish.com (unknown [172.18.16.1]) by outbound1-res.bigfish.com (Postfix) with ESMTP id A98718FC417; Tue, 1 Aug 2006 22:44:32 +0000 (UTC) Received: from mail2-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail2-res-R.bigfish.com (Postfix) with ESMTP id 9D2D1683FF8; Tue, 1 Aug 2006 22:44:32 +0000 (UTC) X-BigFish: V Received: by mail2-res (MessageSwitch) id 1154472272596257_5430; Tue, 1 Aug 2006 22:44:32 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail2-res.bigfish.com (Postfix) with ESMTP id 7BB60683A6A; Tue, 1 Aug 2006 22:44:32 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k71MiWMD028752; Tue, 1 Aug 2006 17:44:32 -0500 (CDT) Received: from pdawg06a.ad.sprint.com (PDAWG06A.corp.sprint.com [10.122.2.33]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k71MiVB15317; Tue, 1 Aug 2006 17:44:31 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by pdawg06a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 17:44:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Voice codecs Date: Tue, 1 Aug 2006 17:44:07 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A130241CBFE@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXgAJXsKmAACa16AAAAir3QACN3DBAAAcZk0AAEW4owAAFlG0AACNaYQAAG31Ng From: "Khan, Sohel Q [CTO]" To: "Hadriel Kaplan" , "Brian Rosen" , , "Drage, Keith \(Keith\)" , X-OriginalArrivalTime: 01 Aug 2006 22:44:31.0850 (UTC) FILETIME=[0DE924A0:01C6B5BC] X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org How about the following statements: "IETF SPEERMINT shall not mandate a codec or a minimum set of codecs. IETF VoIP peering documents will specify/reference Codec negotiation/discovery techniques among providers. Members of a federation will mutually determine a minimum acceptable set of codec and support of transcoding functions." "IETF SPEERMINT shall not mandate a codec or a minimum set of codecs. IETF VoIP peering documents will specify/reference Codec negotiation/discovery techniques among providers. Members of a federation will mutually determine a minimum acceptable set of codec and support of transcoding functions. Trascoding required for a call originating from outside the federation ...(?). IETF SPEERMINT may recommend (as opposed to mandate) the following codecs ... as default" =20 Thanks. Sohel Khan _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 02 00:16:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G88A2-0003eK-1u; Wed, 02 Aug 2006 00:16:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G88A1-0003dU-2H for speermint@ietf.org; Wed, 02 Aug 2006 00:16:45 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G889z-0001KM-Pz for speermint@ietf.org; Wed, 02 Aug 2006 00:16:45 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 01 Aug 2006 21:16:46 -0700 X-IronPort-AV: i="4.07,204,1151910000"; d="scan'208"; a="567862314:sNHT42528704" x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: draft-ietf-speermint-requirements-00.txt Date: Wed, 2 Aug 2006 00:16:52 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804F9549E@proton.jnpr.net> In-Reply-To: <001401c6b5a2$0954ce40$68c8000a@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: draft-ietf-speermint-requirements-00.txt Thread-Index: Aca1ogk/ZR+s8QXkSQCz716R5bT9NwASESoQ From: "Reinaldo Penno" To: "Patrick Melampy" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hello Patrick, You are the third or forth person to suggest something similar. I suggest something like it before the IETF meeting the first time I reviewed the draft. Thanks, Reinaldo ________________________________________ From: Patrick Melampy [mailto:PMelampy@acmepacket.com]=20 Sent: Tuesday, August 01, 2006 12:38 PM To: speermint@ietf.org Subject: [Speermint] Re: draft-ietf-speermint-requirements-00.txt I would re-label the section 2.3 from "No Blocked Calls" to "Path Discovery and Availability". The ability to know that you can send a call at any time, and where to send it, is the essence of what the author intended here. I would in addition expand on this to include two sections: 2.3.1 Adjacency Attributes (Next hop network attributes) a. What proxies can a party use. For each proxy: i. How fast can I send calls (CPS) ii. How many calls can I send (total established calls) iii. How much bandwidth can I use (KBS) b. If there are many adjacent proxies to use, which should I use: i. Does the location of the proxy matter? ii. Is the proxy location a semaphore for where the media will cross? 2.3.2 Path Discovery and Attributes (Domains that are NOT adjacent) c. What are the paths to the destination domain that can: i. Guarantee quality ii. Participate in Guarantee's for Trust=20 iii. Are these paths available It may not go in this section 2.3, but it is related to adjacency, and path availability 2.3.3 Adjacency and Path Congestion detection/avoidance d. How can a carrier restrict inflow of traffic (not call-by-call) i. For maintenance actions ii. For congestion management e. How can a carrier prevent upstream networks from submitting calls for certain destinations in overload i. Equivalent to SS7 ACC (Automatic Congestion Control) _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 02 02:20:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8A6A-0004vP-Ti; Wed, 02 Aug 2006 02:20:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8A68-0004tc-Uu for speermint@ietf.org; Wed, 02 Aug 2006 02:20:52 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8A68-0002Bm-CR for speermint@ietf.org; Wed, 02 Aug 2006 02:20:52 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005) with ESMTP id k726Kfmf027653; Wed, 2 Aug 2006 08:20:41 +0200 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B45@oefeg-s04.oefeg.loc> Subject: Re: [Speermint] Voice codecs To: "Stastny Richard" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel.de Date: Wed, 2 Aug 2006 08:20:37 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/02/2006 08:20:42 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >Perfectly correct. Codecs are end-device capabilities and an IP-PSTN gateway is also >an end-device, as far as IP is concerned. >So codecs are not an IP network issue Disagree to the last statement. There are also IP-to-IP gateways, and s= ome are just media-agnostic, but there are also media-aware IP-to-IP gatewa= y entities defined. One example is the MSF "S-SBG to D-SBG Interface Implementation Agreeme= nt; H.248 Profile for Distributed Session Border Gateways": =A7 5.16.1 is a= bout transcoding for IP-to-IP. - Albrecht = =20 "Stastny = =20 Richard" To: "Patrick Melamp= y" , "Geoff Devine" =20 , "Brian Rosen" , =20 @oefeg.at> , "D= rage, Keith \(Keith\)" , =20 = =20 01.08.2006 19:03 cc: = =20 Subject: Re: [Speermint]= Voice codecs =20 = =20 >It seems to me that CODEC's are indeed capabilities of networks -- but= only >insofar as to their connection to the PSTN. Establishing policies or >exchanging these kind of capabilities to determine a best next-hop net= work >would be senseless. Perfectly correct. Codecs are end-device capabilities and an IP-PSTN gateway is also an end-device, as far as IP is concerned. So codecs are not an IP network issue -sta ________________________________ Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] Gesendet: Di 01.08.2006 18:11 An: 'Geoff Devine'; 'Brian Rosen'; richard@shockey.us; 'Drage, Keith (Keith)'; speermint@ietf.org Betreff: RE: [Speermint] Voice codecs On problem with "codec policies", is that they are not necessarily transitive. Transit networks may not support CODEC's that are indeed supported by the originator/terminator. Even the terminating network ma= y not support the terminators CODEC capabilities. For example, we current use= a VOIP service, that only uses G.711 for calls going to the PSTN or other= IP Networks. However, when we call another phone, connected to these "restrictive networks", we can negotiate to G.729. It seems to me that CODEC's are indeed capabilities of networks -- but = only insofar as to their connection to the PSTN. Establishing policies or exchanging these kind of capabilities to determine a best next-hop netw= ork would be senseless. -----Original Message----- From: Geoff Devine [mailto:gdevine@cedarpointcom.com] Sent: Tuesday, August 01, 2006 11:40 AM To: Brian Rosen; richard@shockey.us; Drage, Keith (Keith); speermint@ietf.org Subject: RE: [Speermint] Voice codecs In your wideband codec transcoding example (a good one, by the way), there are only so many possible business arrangements: The originator transcodes The terminator transcodes A transcodes, always B transcodes, always C, a third party, transcodes I think any solution we come up with needs to support all of these possibilities. Geoff -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, August 01, 2006 11:18 AM To: richard@shockey.us; 'Drage, Keith (Keith)'; speermint@ietf.org Subject: RE: [Speermint] Voice codecs Nope, it's more interesting than that. Sure, each domain has a policy of what codecs it allows on its network, but if you want to avoid double transcoding, you want to know, really, what is happening on both sides of the peering, to see if you can optimize it. Suppose A allows g.711 and AMR, and B allows g.711 and EvRC. You know what is really going to happen. The AMR handsets get transcoded to g.711 on= A, the EvRC handsets get transcoded to g.711 on B and they "work". But what you really want to know is whether there is a transcoder available on either side (or in the middle) for EvRC to AMR and vice versa. If that example doesn't convince you, suppose A's list was g.711 and AMR-WB and B's list was g.711 and VMR-WB. So, you don't want to force A or B to transcode to the federation's lis= t if you can figure out what the "right" thing to do is. You want to take the list of codecs the originating endpoint really can= do, and the similar list from the terminating endpoint, and see if you can discover a resource that can bridge across the lists. This isn't a policy issue really. Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint = _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 02 04:36:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8CDD-0006L9-QA; Wed, 02 Aug 2006 04:36:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8CDC-0006Ks-Py for speermint@ietf.org; Wed, 02 Aug 2006 04:36:18 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8CDB-0003zs-GO for speermint@ietf.org; Wed, 02 Aug 2006 04:36:18 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 5C468210026; Wed, 2 Aug 2006 10:36:16 +0200 (CEST) Message-ID: <44D06407.1010103@pernau.at> Date: Wed, 02 Aug 2006 10:36:23 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Speermint] Just submitted draft-mahy-speermint-direct-peering-00 References: <953beacc0606190159h5e6c40b5u4b51251eaab3f7b@mail.gmail.com> <44C0910B.1010107@pernau.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Cullen Jennings wrote: > > On Jul 21, 2006, at 1:32 AM, Klaus Darilion wrote: > >> Hi Rohan! >> >> Sorry for jumping in late - I had long holidays. I have a few concerns >> about the TLS stuff: >> >> >>> 4.1.6 Setup TLS connection >>> Once a transport, port, and address are found, the initiating peer >>> will open or find a reusable TLS connection to the peer. The >>> initiating provider MUST verify the server certificate which SHOULD >>> be rooted in a well-known certificate authority. The initiating >> >> How should the validation be done? You describe how the client >> validation works, but not the server validation. >> >>> provider MUST be prepared to provide a TLS client certificate upon >>> request during the TLS handshake. The client certificate MUST >>> contain a DNS or URI choice type in the subjectAltName which >>> corresponds to the domain asserted in the host production of the From >>> header URI. The certificate SHOULD be valid and rooted in a well- > > Hmm - I missed this when I read Rohan's draft - nice catch. I think that > if you use client certs, you would want to do it more like what is > described in draft-mahy-sip-connect-reuse. My initial reaction would be > don't use client certs in the first stab at this and add them later. IMO client certs are a MUST. If my proxy receives an incoming TLS request, I want to know to whom I talk. I suggest having TLS and client certificates as must, but remove the SIP-level domain validation. regards klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 02 04:44:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8CLH-0008Le-GD; Wed, 02 Aug 2006 04:44:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8CLF-0008LZ-RB for speermint@ietf.org; Wed, 02 Aug 2006 04:44:37 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8CLE-00050L-38 for speermint@ietf.org; Wed, 02 Aug 2006 04:44:37 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 37203210026; Wed, 2 Aug 2006 10:44:32 +0200 (CEST) Message-ID: <44D065F6.2090709@pernau.at> Date: Wed, 02 Aug 2006 10:44:38 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Benny Prijono Subject: Re: [Speermint] TLs performance References: <44C50A97.3080402@pernau.at> <44CF2122.1010208@bulukucing.org> In-Reply-To: <44CF2122.1010208@bulukucing.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Benny Prijono wrote: > Hi all, > > just to share my data, fwiw. In my benchmark, TCP (with single > connection) performs almost consistently better than UDP in transactions > and calls processing, but only when UAC and UAS are in local machine. > When UAC and UAS are separated into different boxes, TCP performance is > only about half of UDP performance. > > For me, my data makes perfect sense, because in local machine, TCP > transactions has lower cost to setup (e.g. less timers), so it should be > faster. While on the network, the TCP round-trip probably prevents > transaction to complete as fast as the UDP version, so TCP should be > slower. So I'm a bit surprised that in your benchmarks TCP outperformed > UDP, but perhaps it's just some tuning in the socket settings (any info > on these will be appreciated). Hi Benny! Are you using a new TCP connection for each call or do you use connection reuse? In my case, all calls where sent over the same TLS connection, thus only one TCP/TLS handshake per test case, not per call. regards klaus > > Btw my benchmark report can be found here: > http://www.pjsip.org/testing/0.5.6.5/bench.htm > > -benny > > > Cullen Jennings wrote: >> >> Klaus, first of all thank you for producing some real results we can >> discuss. Just to validate some of your results - this is not the >> first time I have seen performance results where TLS (or more >> specifically TCP) has better performance that UDP. I have seen this on >> other products too and when I think about it, it is not that surprising. >> >> Cullen >> >> >> On Jul 24, 2006, at 10:59 AM, Klaus Darilion wrote: >> >>> Hi! >>> >>> I made some tests with sipp+openser: >>> >>> scenario: >>> >>> UAC <-TLS-> openser <-TLS-> UAS (all of them got its own 2xP3 1,26GHz >>> machine, linked with 100MBit). Simple forwarding configuration (like >>> a loadbalancer), no DNS lookups or DB queries. >>> >>> UDP: ~620 cps >>> TLS: ~680 cps (single TLS connection) >>> >>> cps=calls per second = INVITE-180-200-OK-ACK-BYE-200 >>> >>> I think TLS performs better as because of UDP retransmissions, which >>> "kills" the proxy if it becomes slow. >>> >>> More data when I have it. >>> >>> regards >>> klaus > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 02 04:47:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8CNo-0001oT-Bu; Wed, 02 Aug 2006 04:47:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8CNm-0001lh-Vb for speermint@ietf.org; Wed, 02 Aug 2006 04:47:14 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8CNl-0005LT-M6 for speermint@ietf.org; Wed, 02 Aug 2006 04:47:14 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 0D1E0210026; Wed, 2 Aug 2006 10:47:13 +0200 (CEST) Message-ID: <44D06697.9000007@pernau.at> Date: Wed, 02 Aug 2006 10:47:19 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Thomas.Froment@alcatel.fr Subject: Re: [Speermint] TLs performance References: <44C50A97.3080402@pernau.at> <44CF2573.9010703@alcatel.fr> In-Reply-To: <44CF2573.9010703@alcatel.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Thomas.Froment@alcatel.fr wrote: > "I think TLS performs better as because of UDP retransmissions, which > "kills" the proxy if it becomes slow. " > > That's why I think it is not possible to make performance testing in > UDP without activating some kind of flow regulation mechanism... > overwise the results are very difficult to interpret: what does it mean > to test a proxy overloaded by retransmissions?.... Should always test > performances on a stable rate, overwise this is a resistance/torture > test... Yes. Thus in my tests, I increased the call/second slowly (watching retransmissions) until I reach the limit (and the call rate is getting down due to proxy overload.). And this limit is the maximum number of calls. btw: does someone know another tool beside sipp (whose TCP implementation is buggy)? regards klaus > > > Cullen Jennings wrote: >> >> Klaus, first of all thank you for producing some real results we can >> discuss. Just to validate some of your results - this is not the >> first time I have seen performance results where TLS (or more >> specifically TCP) has better performance that UDP. I have seen this on >> other products too and when I think about it, it is not that surprising. >> >> Cullen >> >> >> On Jul 24, 2006, at 10:59 AM, Klaus Darilion wrote: >> >>> Hi! >>> >>> I made some tests with sipp+openser: >>> >>> scenario: >>> >>> UAC <-TLS-> openser <-TLS-> UAS (all of them got its own 2xP3 1,26GHz >>> machine, linked with 100MBit). Simple forwarding configuration (like >>> a loadbalancer), no DNS lookups or DB queries. >>> >>> UDP: ~620 cps >>> TLS: ~680 cps (single TLS connection) >>> >>> cps=calls per second = INVITE-180-200-OK-ACK-BYE-200 >>> >>> > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 02 04:50:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8CQf-0002iv-EY; Wed, 02 Aug 2006 04:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8CQe-0002iq-68 for speermint@ietf.org; Wed, 02 Aug 2006 04:50:12 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8CQa-0005hn-1k for speermint@ietf.org; Wed, 02 Aug 2006 04:50:12 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 80434210026; Wed, 2 Aug 2006 10:50:07 +0200 (CEST) Message-ID: <44D06746.1080102@pernau.at> Date: Wed, 02 Aug 2006 10:50:14 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: TLS for peering (was RE:Comments (RE:[speermint]requirementsdraftsubmitted)) References: <8587F175CDB3D741B58C79F67E8E09AD3BA453@PACDCEXCMB03.cable.comcast.com> <08336EE4-7FE3-4B65-BB2A-24BB8348764C@cisco.com> In-Reply-To: <08336EE4-7FE3-4B65-BB2A-24BB8348764C@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Cc: speermint@ietf.org, "Lee, Yiu" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Cullen Jennings wrote: > ... > I will note that many enterprises today peer IM with folks like > MSN/Yahoo/AOL using SIP and it is mostly done over TLS. > > Anyways, it sounds like we are coming to some agreement for the type of > TLS thing we are interested - which is TLS transport and not end to end > and not sips, RFC 3261 is adequately specified and implementable. Yes. But I still vote against some SIP layer domain validation (comparing the domains in the certificate with the domains in the URIs) as suggested in RFC3261. regards klaus > > Cullen > > > On Jul 27, 2006, at 6:37 AM, Lee, Yiu wrote: > >> Hi Klaus, >> >> Sorry for mis-understanding your previous post. I agree that using the >> domain for the end-to-end certification is broken in federation. >> >> Thanks for the clarification. >> >> -----Original Message----- >> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >> Sent: Thursday, July 27, 2006 2:55 AM >> To: Lee, Yiu >> Cc: Brian Rosen; speermint@ietf.org >> Subject: Re: TLS for peering (was RE:Comments >> (RE:[speermint]requirementsdraftsubmitted)) >> >> Lee, Yiu wrote: >>> Hi, >>> >>> We agree that it is difficult to enforce hop-by-hop TLS session for >>> SIPS in federation. I think we can't mandate SIPS, but we can require >>> a TLS session between A and T and a TLS session between T and B. So we >> >>> can relax the requirement of SIPS but still provide some security to >>> transport SIP messages. >> >> H! >> >> Looks like I'm still not clear enough - it was not talking about SIPS. >> Only SIP which uses TLS between providers. IMO, TLS as transport is a >> MUST, but the L5 certificate domain validation must not be a MUST. >> >> regards >> klaus >> >>> >>> Thanks, >>> Yiu >>> >>> -----Original Message----- >>> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >>> Sent: Monday, July 24, 2006 11:28 AM >>> To: Brian Rosen >>> Cc: speermint@ietf.org >>> Subject: Re: TLS for peering (was RE:Comments >>> (RE:[speermint]requirementsdraftsubmitted)) >>> >>> Brian Rosen wrote: >>>> I think you are misinterpreting 3261. Section 26.3.2.2 is >>>> illustrating a simple SIP trapezoid call where the call goes from >>>> atlanta.com to biloxi.com. If there is another intermediary, >>>> biloxi.com would not be checking the From to see that it matched the >>>> domain of the T proxy handling >>> >>> How will biloxi's proxy know if the request comes directly from >>> atlanta or via an intermediary? You suggest that in this case the >> From: >>> validation is not used. Then we should remove the From: validation >>> completely and validate only the Identity signature. >>> >>> The only thing I want to say is that Rohan's suggested From: >>> validation >>> >>> .... The client certificate MUST >>> contain a DNS or URI choice type in the subjectAltName which >>> corresponds to the domain asserted in the host production of the >>> From >>> header URI.... >>> >>> can't be mandated. >>> >>>> the call. We all agree that TLS is underspecified in 3261. There is >> >>>> some effort to address this shortcoming underway. >>>> >>>> If the path is A -> T -> B, then the mutual TLS cert validation is A >>>> <-> T and T <-> B. In a peering system, the peers authenticate each >>>> other within >>> >>> Yes. >>> >>>> the peering regime. If T accepts a call from A destined for B, then >>>> it authenticates A as a peer which it accepts transit calls for B, >>>> and >>> >>>> it authenticates B as a peer with whom it can send calls destined for >>> B. >>> >>> Yes - but the L5 domain validation can't be used. >>> >>> Maybe I express myself a little bit unclear. Thus, I describe it more >>> detailed. >>> >>> When using SSL/TLS to secure a transport connection, there are several >> >>> validation steps. Some of the are done in the SSL stack, some of the >>> are done in the application. I'm speaking of experience in using >>> openssl and openser. >>> >>> During the TLS handshake, the peers verify the certificate presented >>> by the other peer. The TLS stacks of the certificate is signed by a >>> (to the >>> stack) well known CA and it is valid (not expired). Let's call this L4 >> >>> certificate validation. >>> >>> Once the TLS connection is setup, the application can further validate >> >>> the certificate, e.g. if the domain presented in the certificate >>> equals the domain in the request URI. Let's call this L5 certificate >>> validation. >>> >>> To authenticate a peer, L5 is NOT necessary. For example, T and B are >>> in the same federation. (B trusts T, T trusts B, and both of them >>> trusts the federation's CA) >>> >>> If B receives a call from T, which is originally from an other service >> >>> provider (which T trusts), the domain in the From header is not >>> important, as the authentication is based on the certificate. And B >>> and T can bill each other because they were both authenticated >>> (although there was no L5 validation). >>> >>> Conclusion: >>> IMO TLS should be MUST, but the L5 domain validation (as suggested in >>> RFC3261 and Rohan's draft) must be removed as it does not work in many >> >>> scenarios and further is not needed. Nevertheless, in scenarios where >>> it is useful it should be used. But a MUST is wrong. >>> >>> regards >>> Klaus >>> >>> >>> >>>> Brian >>>> >>>>> -----Original Message----- >>>>> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >>>>> Sent: Sunday, July 23, 2006 7:49 PM >>>>> To: Brian Rosen >>>>> Cc: speermint@ietf.org >>>>> Subject: RE: TLS for peering (was RE: Comments >>>>> (RE:[speermint]requirementsdraftsubmitted)) >>>>> >>>>> Hi Brian! >>>>> >>>>> On Fri, July 21, 2006 18:08, Brian Rosen said: >>>>>> I believe it is the case that the link from one peer to another, >>>>>> which >>>>> is >>>>>> generally between two proxies, can very reasonably be protected >>>>>> with >>>>> TLS, >>>>>> with many current implementations, and with reasonable assumptions >>>>>> about PKI. Specifically, if one of the parts of a federation was >>>>>> an >>> >>>>>> agreement on a CA, then each peer can have a certificate that other >> >>>>>> peers can verify. >>>>>> I >>>>>> believe all operations, including forwarding, if they work at all >>>>>> across the peering system would work if it was TLS protected. >>>>> Using TLS for encryption and TLS certificate validation works - but >>>>> the L5 validation (validate the certificate domain names against the >> >>>>> domains in the SIP headers) does not work without mandating a B2BUA. >>>>> >>>>> TLS/SSL was invented for a very simple client-server system - HTTP. >>>>> Let's compare HTTP with SIP: >>>>> >>>>> HTTP: >>>>> 1 request - 1 (or more) responses. >>>>> L5 validation: verify domain in browser's location bar against the >>>>> domain in the server certificate - this is straight forward >>>>> >>>>> SIP: >>>>> Multiple - bidirectional requests >>>>> L5 validation: There are several headers which are used for routing >>>>> and thus can be used for validation: requestURI, From, To, Via, >>>>> Route, Contact. >>>>> We can have in-dialog requests which are initiated in reverse >>>>> direction of the original dialog setup. And each of this domain >>>>> resolves to several domains (due to NAPTR, SRV, A resolution). This >>>>> alone should have people think a little more before defining TLS for >>> SIP. >>>>> I am a fan of forwarding - and probably every transit service >>>>> provider too. As transit will happen I will use the transit scenario >> >>>>> (simple forwarding without a B2BUA) to show that L5 validation is >>>>> broken - and I would be very very happy if someone can show that I'm >>> wrong. >>>>> A want to call B. There is no direct peering agreement. Thus A sends >> >>>>> the call to it's transit provider T. (only the signaling between the >> >>>>> proxies is shown) >>>>> >>>>> A->T >>>>> INVITE sip:B@B >>>>> From: sip:A@A >>>>> To: sip:B@B >>>>> Contact: user@phone >>>>> Record-Route: sip:A >>>>> >>>>> Cert validation according to RFC3261 section 26.3.2.2: >>>>> T will show a TLS certificate for T (not for B) - thus, when A >>>>> validates T's certificate, the validation will fail. IMO this can be >> >>>>> fixed by adding a Route: header with sip:T, but this is nowhere >>> mentioned in RFC 3261. >>>>> T->B >>>>> INVITE sip:B@B >>>>> From: sip:A@A >>>>> To: sip:B@B >>>>> Contact: user@phone >>>>> Record-Route: sip:T >>>>> Record-Route: sip:A >>>>> >>>>> Cert validation according to RFC3261 section 26.3.2.2: >>>>> B should validate the domain in the From header (A) aginst the >>>>> domain >>> >>>>> in the client's certificate (T) --> it will fail. >>>>> >>>>> Now let's assume the previous validation have succeeded and B sends >>>>> a >>> >>>>> BYE request to A, and the TLS connection was dropped and must be >>>>> re-established: >>>>> >>>>> B->T >>>>> BYE name@1.2.3.4 >>>>> From: sip:B@B >>>>> To: sip:A@A >>>>> Route: sip:T >>>>> Route: sip:A >>>>> >>>>> How should T's certificate be validated? Probably against the domain >> >>>>> in the topmost Route header - but again: This is nowhere specified. >>>>> >>>>> T->A >>>>> BYE name@1.2.3.4 >>>>> From: sip:B@B >>>>> To: sip:A@A >>>>> Route: sip:A >>>>> >>>>> Again, probably T should use the domain in the Route header for >>>>> certificate validation. But A can't validate the certificate's >>>>> domain >>> >>>>> (T) against the From header (B) - it will fail. >>>>> >>>>> Similar problem arise in a forwarding scenario - A-->B which >>>>> forwards >>> >>>>> it's call to C. The suggested L5 validation will fail (except B uses >> >>>>> a B2BUA, and IMO a B2BUA should not be mandatory). >>>>> >>>>>> This does not assume sips works (whatever that means), and does not >>>>> assume >>>>>> endpoints implement TLS, or either the originating or terminating >>>>> domains >>>>>> deploy TLS anywhere else. >>>>>> >>>>>> It does provide a reasonable degree of protection across the >>>>>> peering >>> >>>>>> point, which I think is a good thing. >>>>> Yes, TLS provides protection, but we should not specify a broken L5 >>>>> certificate validation. >>>>> >>>>>> Having lived with protocols that offered options like IPsec and >>>>>> VPNs >>> >>>>>> and other mechanisms, I think that despite the fact that you can, >>>>>> in >>> >>>>>> theory, create a satisfactory security arrangement, it is >>>>>> exceedingly hard to >>>>> make >>>>>> it actually work except for cases where there is an entity that >>>>> completely >>>>>> controls all aspects of the peering. That just isn't the case for >>>>>> what >>>>> I >>>>>> think we are trying to specify here (such cases don't need IETF >>>>>> standardization). Thus, I personally think mandating TLS is a good >>>>> thing, >>>>>> achievable, and reasonable. That's a MUST IMPLEMENT, not a must >>>>>> deploy; >>>>> Yes, I agree. I want TLS in the specs too - but we have to specify >>>>> the validation more precisely and it has to work in other scenarios >>>>> than a basic call too. Otherwise people wont use it. >>>>> >>>>> regards >>>>> Klaus >>> >>> >>> _______________________________________________ >>> Speermint mailing list >>> Speermint@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speermint >> >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 02 05:19:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8CsX-0002GW-Pc; Wed, 02 Aug 2006 05:19:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8CsX-0002GJ-8K for speermint@ietf.org; Wed, 02 Aug 2006 05:19:01 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8CsV-00015l-WF for speermint@ietf.org; Wed, 02 Aug 2006 05:19:01 -0400 Received: from [192.168.0.7] (81-178-58-134.dsl.pipex.com [81.178.58.134]) by ranger.systems.pipex.net (Postfix) with ESMTP id F1932E0001E3; Wed, 2 Aug 2006 10:18:53 +0100 (BST) Message-ID: <44D06DF5.30102@bulukucing.org> Date: Wed, 02 Aug 2006 10:18:45 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Klaus Darilion Subject: Re: [Speermint] TLs performance References: <44C50A97.3080402@pernau.at> <44CF2122.1010208@bulukucing.org> <44D065F6.2090709@pernau.at> In-Reply-To: <44D065F6.2090709@pernau.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi Klaus! Klaus Darilion wrote: > Are you using a new TCP connection for each call or do you use > connection reuse? In my case, all calls where sent over the same TLS > connection, thus only one TCP/TLS handshake per test case, not per call. Same, I also use one TCP socket for all calls. > btw: does someone know another tool beside sipp (whose TCP > implementation is buggy)? I have a tool to send bulk requests/transactions/calls to a server (with UDP or TCP) and measure the completion time of the responses/transactions/calls. It's called pjsip-perf, and it's included in the source tarball from http://www.pjsip.org/download.htm -benny _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 03 15:13:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8ict-0002M3-2k; Thu, 03 Aug 2006 15:12:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8icr-0002Kx-Vo for speermint@ietf.org; Thu, 03 Aug 2006 15:12:57 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8icq-0000tj-Gj for speermint@ietf.org; Thu, 03 Aug 2006 15:12:57 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 03 Aug 2006 12:12:56 -0700 X-IronPort-AV: i="4.07,209,1151910000"; d="scan'208"; a="438578163:sNHT28011730" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k73JCtq1008862; Thu, 3 Aug 2006 12:12:55 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k73JCsBc017597; Thu, 3 Aug 2006 12:12:55 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 15:12:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Secure RTP Date: Thu, 3 Aug 2006 15:12:53 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301C6DC06@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Secure RTP Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8A== From: "Michael Hammer \(mhammer\)" To: "Hadriel Kaplan" , "Brian Rosen" X-OriginalArrivalTime: 03 Aug 2006 19:12:54.0871 (UTC) FILETIME=[D2BF6670:01C6B730] DKIM-Signature: a=rsa-sha1; q=dns; l=3737; t=1154632375; x=1155496375; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Secure=20RTP; X=v=3Dcisco.com=3B=20h=3DTav7+aVDpl+QOgZ4O1J+VN4eGlM=3D; b=YDSAIADJ14eeCPt7oLcmjnIOJr/T3ajdJC0c5ARW35YD4shDyFiO4FBI0A2DmPKO1wSVMd9p G5F8XCluzPmVVTY3rxIQRsaRLLroDaIBIS8otO5ZgaXf/lhjCfcU3v0W; Authentication-Results: sj-dkim-4.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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 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 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Tuesday, August 01, 2006 4:09 PM > To: 'Brian Rosen' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > But there are currently 11(?) proposed SRTP key exchange=20 > mechanisms, some using SDP, some not - none of which=20 > interoperate. So "interoperability" is impacted there, and=20 > part of it is a signaling issue. In that sense it may well=20 > be reasonable for a speermint BCP to pick one preferred=20 > mechanism, but I'm sure that will be yet another rat-hole. =20 > And I recommend we stay out of those when we can. :)=20 > (besides, the RTPSEC-BOF group is assigned that Herculean task) >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, August 01, 2006 3:33 PM > > To: 'Andrew Newton' > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > Subject: RE: [Speermint] Secure RTP > >=20 > > Sure, but does the peering touch the media? I claim it doesn't, at=20 > > least normally. "Getting it right" means that when the signaling=20 > > happens, the resulting SDP will work. That part (the SDP part)=20 > > matters to us, because we have to make sure that when that=20 > SDP gets to=20 > > the other side, it will result in something that works. =20 > The peering=20 > > system doesn't have to even look at the SDP, it just has to=20 > have rules=20 > > that make interoperability work. > >=20 > > The peering system has to, for example, make sure that an address=20 > > given in the SDP on one side is actually reachable on the=20 > other side. =20 > > Doing that doesn't involve any work, it's just rules the federation=20 > > agrees to that makes that be true. So, we might need to=20 > specify no NAT=20 > > or conversely, MUST support ICE. That all speaks to what the peers=20 > > have to have between their endpoints and their peers. It doesn't=20 > > imply the media packets traverse the peering fabric. > >=20 > > Of course, in theory, the peering system doesn't even have to touch=20 > > the signaling, but we don't have to go there. > >=20 > > Brian > >=20 > > > -----Original Message----- > > > From: Andrew Newton [mailto:andy@hxr.us] > > > Sent: Tuesday, August 01, 2006 3:07 PM > > > To: Brian Rosen > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > Subject: Re: [Speermint] Secure RTP > > > > > > Brian Rosen wrote: > > > > I think that we are looking at case 1, and not at case=20 > 2. I don't > > think > > > we > > > > care about the media. > > > > > > Interesting. I don't know about you, but I get paid for=20 > getting the > > media > > > right. Perfect signaling is useless without media. > > > > > > -andy > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 03 20:40:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8nkA-0001JP-Uh; Thu, 03 Aug 2006 20:40:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8nkA-0001Iw-3x for speermint@ietf.org; Thu, 03 Aug 2006 20:40:50 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8nk9-00063E-P9 for speermint@ietf.org; Thu, 03 Aug 2006 20:40:50 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A79703DC; Thu, 03 Aug 2006 20:40:55 -0400 From: "Hadriel Kaplan" To: "'Michael Hammer \(mhammer\)'" , "'Brian Rosen'" Subject: RE: [Speermint] Secure RTP Date: Thu, 3 Aug 2006 20:40:45 -0400 Message-ID: <04c501c6b75e$9f1cc730$6601a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AALE1WA In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301C6DC06@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org So you're saying they MUST implement such a policy exchange mechanism?? ;) To me the srtp and codec "policy" exchange is already there: SDP. We will probably need MUSTs for some things, because we need 2 speermint-supporting peers to interop. If two speermint federations can pick their own MUSTs for basic issues, then they may not interop. They can discover each other's policies all day long, but if there's no match we've screwed up. I don't put codecs into that basic issues list, because that's different and dependent per UA. It could be "normalized", but that's not easy to get consensus on. -hadriel > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Thursday, August 03, 2006 3:13 PM > To: Hadriel Kaplan; Brian Rosen > Cc: speermint@ietf.org > 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 > > 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 > > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Tuesday, August 01, 2006 4:09 PM > > To: 'Brian Rosen' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Secure RTP > > > > But there are currently 11(?) proposed SRTP key exchange > > mechanisms, some using SDP, some not - none of which > > interoperate. So "interoperability" is impacted there, and > > part of it is a signaling issue. In that sense it may well > > be reasonable for a speermint BCP to pick one preferred > > mechanism, but I'm sure that will be yet another rat-hole. > > And I recommend we stay out of those when we can. :) > > (besides, the RTPSEC-BOF group is assigned that Herculean task) > > > > -hadriel > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, August 01, 2006 3:33 PM > > > To: 'Andrew Newton' > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > Subject: RE: [Speermint] Secure RTP > > > > > > Sure, but does the peering touch the media? I claim it doesn't, at > > > least normally. "Getting it right" means that when the signaling > > > happens, the resulting SDP will work. That part (the SDP part) > > > matters to us, because we have to make sure that when that > > SDP gets to > > > the other side, it will result in something that works. > > The peering > > > system doesn't have to even look at the SDP, it just has to > > have rules > > > that make interoperability work. > > > > > > The peering system has to, for example, make sure that an address > > > given in the SDP on one side is actually reachable on the > > other side. > > > Doing that doesn't involve any work, it's just rules the federation > > > agrees to that makes that be true. So, we might need to > > specify no NAT > > > or conversely, MUST support ICE. That all speaks to what the peers > > > have to have between their endpoints and their peers. It doesn't > > > imply the media packets traverse the peering fabric. > > > > > > Of course, in theory, the peering system doesn't even have to touch > > > the signaling, but we don't have to go there. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > Sent: Tuesday, August 01, 2006 3:07 PM > > > > To: Brian Rosen > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > Subject: Re: [Speermint] Secure RTP > > > > > > > > Brian Rosen wrote: > > > > > I think that we are looking at case 1, and not at case > > 2. I don't > > > think > > > > we > > > > > care about the media. > > > > > > > > Interesting. I don't know about you, but I get paid for > > getting the > > > media > > > > right. Perfect signaling is useless without media. > > > > > > > > -andy > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 06:30:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8wwc-0008Vd-DA; Fri, 04 Aug 2006 06:30:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8wwa-0008VV-Sd for speermint@ietf.org; Fri, 04 Aug 2006 06:30:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8vAL-0008Er-RY for speermint@ietf.org; Fri, 04 Aug 2006 04:36:21 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1G8uvP-00014M-1J for speermint@ietf.org; Fri, 04 Aug 2006 04:20:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Secure RTP Date: Fri, 4 Aug 2006 10:19:54 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C509B@oefeg-s04.oefeg.loc> In-Reply-To: <04c501c6b75e$9f1cc730$6601a8c0@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Secure RTP Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AALE1WAAA+l3bA= From: "Stastny Richard" To: "Hadriel Kaplan" , "Michael Hammer \(mhammer\)" X-Spam-Score: -2.6 (--) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org IMO the main goal of SPEERMINT is to achieve potential interoperability between SPEERMINT compliant peers (all of them) - first on L5 This implies two steps: 1. policy which means at least that the originating SP is able to find out if the terminating SP is willing to ACCEPT the communication either direct or via a "transit" SP We should never forget that the terminating SP has a monopoly regarding terminating calls. A calling user may choose which originating SP to use, but for a given AoR ONE and only ONE terminating network is available. The "default" option to reach a terminating network via the PSTN is only available for a subset of communications (voice) and only for a limited period of time (as long as the PSTN exists) 2. minimum requirements A peer offering a public communication service may be forced by regulators to accept all incoming calls provided the originator and/or an intervening transit SP complies to a minimum set of requirements. It is the main task of SPEERMINT to define these requirements. Again: if the originator does not comply to these requirements, and end-user may choose another one. This is not the case for the terminating SP. Note1: this does not imply that the end-user must accept the call, he may=20 still reject it. Note2: this does also not imply that the end-user equipment is compatible But Note1 and 2 can be handled with normal protocol negotiations. Richard Stastny > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Friday, August 04, 2006 2:41 AM > To: 'Michael Hammer (mhammer)'; 'Brian Rosen' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > So you're saying they MUST implement such a policy exchange mechanism?? > ;) >=20 > To me the srtp and codec "policy" exchange is already there: SDP. >=20 > We will probably need MUSTs for some things, because we need 2 > speermint-supporting peers to interop. If two speermint federations can > pick their own MUSTs for basic issues, then they may not interop. They > can > discover each other's policies all day long, but if there's no match we've > screwed up. I don't put codecs into that basic issues list, because > that's > different and dependent per UA. It could be "normalized", but that's not > easy to get consensus on. >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Thursday, August 03, 2006 3:13 PM > > To: Hadriel Kaplan; Brian Rosen > > Cc: speermint@ietf.org > > 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 > > > > 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 > > > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Tuesday, August 01, 2006 4:09 PM > > > To: 'Brian Rosen' > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Secure RTP > > > > > > But there are currently 11(?) proposed SRTP key exchange > > > mechanisms, some using SDP, some not - none of which > > > interoperate. So "interoperability" is impacted there, and > > > part of it is a signaling issue. In that sense it may well > > > be reasonable for a speermint BCP to pick one preferred > > > mechanism, but I'm sure that will be yet another rat-hole. > > > And I recommend we stay out of those when we can. :) > > > (besides, the RTPSEC-BOF group is assigned that Herculean task) > > > > > > -hadriel > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Tuesday, August 01, 2006 3:33 PM > > > > To: 'Andrew Newton' > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > Sure, but does the peering touch the media? I claim it doesn't, at > > > > least normally. "Getting it right" means that when the signaling > > > > happens, the resulting SDP will work. That part (the SDP part) > > > > matters to us, because we have to make sure that when that > > > SDP gets to > > > > the other side, it will result in something that works. > > > The peering > > > > system doesn't have to even look at the SDP, it just has to > > > have rules > > > > that make interoperability work. > > > > > > > > The peering system has to, for example, make sure that an address > > > > given in the SDP on one side is actually reachable on the > > > other side. > > > > Doing that doesn't involve any work, it's just rules the federation > > > > agrees to that makes that be true. So, we might need to > > > specify no NAT > > > > or conversely, MUST support ICE. That all speaks to what the peers > > > > have to have between their endpoints and their peers. It doesn't > > > > imply the media packets traverse the peering fabric. > > > > > > > > Of course, in theory, the peering system doesn't even have to touch > > > > the signaling, but we don't have to go there. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > > Sent: Tuesday, August 01, 2006 3:07 PM > > > > > To: Brian Rosen > > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > > Subject: Re: [Speermint] Secure RTP > > > > > > > > > > Brian Rosen wrote: > > > > > > I think that we are looking at case 1, and not at case > > > 2. I don't > > > > think > > > > > we > > > > > > care about the media. > > > > > > > > > > Interesting. I don't know about you, but I get paid for > > > getting the > > > > media > > > > > right. Perfect signaling is useless without media. > > > > > > > > > > -andy > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 07:30:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8xtB-0002Rm-Dr; Fri, 04 Aug 2006 07:30:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8xtA-0002Qx-Bd for speermint@ietf.org; Fri, 04 Aug 2006 07:30:48 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8xt8-0000Yi-Ss for speermint@ietf.org; Fri, 04 Aug 2006 07:30:48 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id D2688210025; Fri, 4 Aug 2006 13:30:45 +0200 (CEST) Message-ID: <44D32FEE.7060601@pernau.at> Date: Fri, 04 Aug 2006 13:30:54 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Henry Sinnreich Subject: DNS performance (was Re: [Speermint] TLs performance) References: <24CCCC428EFEA2469BF046DB3C7A8D2206C463@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D2206C463@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Henry Sinnreich wrote: > Hi Klaus, > > This is a good beginning, but you may want to include the 2-3 DNS > lookups from the originating UAC and the additional 3-4 DNS lookups for > ENUM, NAPTR, etc. > > Can you add such a test? Hi Henry! Due to lack of time (and test applications) I did not made DNS tests yet, but some theory: DNS lookups do not need many resources. Of course, it will increase call setup time as the DNS lookup takes time, but that does not mean that the call throughput of the SIP proxy will decrease. If the SIP proxy uses asynchronous DNS or has enough threads, than the overall call throughput should be nearly constant, regardless of how long the DNS lookup takes. Regarding the call setup delay: If a domain is looked up the first time, it will take some time (usually <100 ms). But further lookups for this domain will be cached in the DNS resolver server. Usually, there will be a DNS resolver somewhere "near" the SIP proxy and DNS lookups for cached domains will be <2ms. There is also lots of discussion that RFC3263 is bad as NAPTR+SRV lookups will increase the call setup time as we need 3 DNS lookups instead of 1. But again, this additional 2 DNS lookups will usually only happen between the SIP proxy and the DNS resolver. If the NAPTRs, SRV and A/AAAA records are delegated to the same authoritative DNS server, this server will include all domains in the additional section of the DNS response. E.g. the SIP proxy has to resolve pernau.at (NAPTR+SRV+A). It first will query for NAPTR records: >dig pernau.at NAPTR ;; QUESTION SECTION: ;pernau.at. IN NAPTR ;; ANSWER SECTION: pernau.at. 65 IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.pernau.at. pernau.at. 65 IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.pernau.at. pernau.at. 65 IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.pernau.at. ;; ADDITIONAL SECTION: pernau.at. 1312 IN A 213.239.207.29 pb94.dyndns.org. 12114 IN A 213.239.207.29 _sips._tcp.pernau.at. 65 IN SRV 0 0 6061 pernau.at. _sip._tcp.pernau.at. 65 IN SRV 0 0 6060 pernau.at. _sip._udp.pernau.at. 65 IN SRV 0 0 6060 pernau.at. ;; Query time: 31 msec This lookup did take 31 msec as all the caches were empty. If now the SIP proxy queries for the SRV and A records, this will be really fast as the resolver already has cached the values from the additional section. > dig _sips._tcp.pernau.at SRV ;; QUESTION SECTION: ;_sips._tcp.pernau.at. IN SRV ;; ANSWER SECTION: _sips._tcp.pernau.at. 107 IN SRV 0 0 6061 pernau.at. ;; Query time: 2 msec The same is for the A lookup. Conclusion: Even if the DNS caches are empty, the call setup delays due to NAPTR and SRV lookups are not that big as lots of people think - DNS is quite intelligent. regards Klaus > > Thanks, Henry > > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Monday, July 24, 2006 1:00 PM > To: speermint@ietf.org > Subject: [Speermint] TLs performance > > Hi! > > I made some tests with sipp+openser: > > scenario: > > UAC <-TLS-> openser <-TLS-> UAS (all of them got its own 2xP3 1,26GHz > machine, linked with 100MBit). Simple forwarding configuration (like a > loadbalancer), no DNS lookups or DB queries. > > UDP: ~620 cps > TLS: ~680 cps (single TLS connection) > > cps=calls per second = INVITE-180-200-OK-ACK-BYE-200 > > I think TLS performs better as because of UDP retransmissions, which > "kills" the proxy if it becomes slow. > > More data when I have it. > > regards > klaus > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 08:47:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8z5O-0000ZS-I3; Fri, 04 Aug 2006 08:47:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8z5M-0000ZN-TL for speermint@ietf.org; Fri, 04 Aug 2006 08:47:28 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8z5K-00014F-FX for speermint@ietf.org; Fri, 04 Aug 2006 08:47:28 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G8z5D-00075x-95; Fri, 04 Aug 2006 07:47:19 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Hadriel Kaplan'" Subject: RE: [Speermint] Secure RTP Date: Fri, 4 Aug 2006 08:47:19 -0400 Message-ID: <02a901c6b7c4$21f168e0$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301C6DC06@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:mhammer@cisco.com] > Sent: Thursday, August 03, 2006 3:13 PM > To: Hadriel Kaplan; Brian Rosen > Cc: speermint@ietf.org > 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 > > 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 > > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Tuesday, August 01, 2006 4:09 PM > > To: 'Brian Rosen' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Secure RTP > > > > But there are currently 11(?) proposed SRTP key exchange > > mechanisms, some using SDP, some not - none of which > > interoperate. So "interoperability" is impacted there, and > > part of it is a signaling issue. In that sense it may well > > be reasonable for a speermint BCP to pick one preferred > > mechanism, but I'm sure that will be yet another rat-hole. > > And I recommend we stay out of those when we can. :) > > (besides, the RTPSEC-BOF group is assigned that Herculean task) > > > > -hadriel > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, August 01, 2006 3:33 PM > > > To: 'Andrew Newton' > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > Subject: RE: [Speermint] Secure RTP > > > > > > Sure, but does the peering touch the media? I claim it doesn't, at > > > least normally. "Getting it right" means that when the signaling > > > happens, the resulting SDP will work. That part (the SDP part) > > > matters to us, because we have to make sure that when that > > SDP gets to > > > the other side, it will result in something that works. > > The peering > > > system doesn't have to even look at the SDP, it just has to > > have rules > > > that make interoperability work. > > > > > > The peering system has to, for example, make sure that an address > > > given in the SDP on one side is actually reachable on the > > other side. > > > Doing that doesn't involve any work, it's just rules the federation > > > agrees to that makes that be true. So, we might need to > > specify no NAT > > > or conversely, MUST support ICE. That all speaks to what the peers > > > have to have between their endpoints and their peers. It doesn't > > > imply the media packets traverse the peering fabric. > > > > > > Of course, in theory, the peering system doesn't even have to touch > > > the signaling, but we don't have to go there. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > Sent: Tuesday, August 01, 2006 3:07 PM > > > > To: Brian Rosen > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > Subject: Re: [Speermint] Secure RTP > > > > > > > > Brian Rosen wrote: > > > > > I think that we are looking at case 1, and not at case > > 2. I don't > > > think > > > > we > > > > > care about the media. > > > > > > > > Interesting. I don't know about you, but I get paid for > > getting the > > > media > > > > right. Perfect signaling is useless without media. > > > > > > > > -andy > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 09:59:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G90DB-00072f-0r; Fri, 04 Aug 2006 09:59:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G90D9-00072a-JX for speermint@ietf.org; Fri, 04 Aug 2006 09:59:35 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G90D8-0003cf-5X for speermint@ietf.org; Fri, 04 Aug 2006 09:59:35 -0400 Received: from PMelampy2 [10.0.200.104] by acmepacket.com with ESMTP (SMTPD-9.03) id A2BB0630; Fri, 04 Aug 2006 09:59:23 -0400 From: "Patrick Melampy" To: "'Brian Rosen'" , "'Michael Hammer \(mhammer\)'" , "'Hadriel Kaplan'" Subject: RE: [Speermint] Secure RTP Date: Fri, 4 Aug 2006 09:59:13 -0400 Message-ID: <00f101c6b7ce$2aad8a40$6401a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqA= In-Reply-To: <02a901c6b7c4$21f168e0$9de6a8c0@cis.neustar.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:br@brianrosen.net] Sent: Friday, August 04, 2006 8:47 AM To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' Cc: speermint@ietf.org 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:mhammer@cisco.com] > Sent: Thursday, August 03, 2006 3:13 PM > To: Hadriel Kaplan; Brian Rosen > Cc: speermint@ietf.org > 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 > > 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 > > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Tuesday, August 01, 2006 4:09 PM > > To: 'Brian Rosen' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Secure RTP > > > > But there are currently 11(?) proposed SRTP key exchange > > mechanisms, some using SDP, some not - none of which > > interoperate. So "interoperability" is impacted there, and > > part of it is a signaling issue. In that sense it may well > > be reasonable for a speermint BCP to pick one preferred > > mechanism, but I'm sure that will be yet another rat-hole. > > And I recommend we stay out of those when we can. :) > > (besides, the RTPSEC-BOF group is assigned that Herculean task) > > > > -hadriel > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, August 01, 2006 3:33 PM > > > To: 'Andrew Newton' > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > Subject: RE: [Speermint] Secure RTP > > > > > > Sure, but does the peering touch the media? I claim it doesn't, at > > > least normally. "Getting it right" means that when the signaling > > > happens, the resulting SDP will work. That part (the SDP part) > > > matters to us, because we have to make sure that when that > > SDP gets to > > > the other side, it will result in something that works. > > The peering > > > system doesn't have to even look at the SDP, it just has to > > have rules > > > that make interoperability work. > > > > > > The peering system has to, for example, make sure that an address > > > given in the SDP on one side is actually reachable on the > > other side. > > > Doing that doesn't involve any work, it's just rules the federation > > > agrees to that makes that be true. So, we might need to > > specify no NAT > > > or conversely, MUST support ICE. That all speaks to what the peers > > > have to have between their endpoints and their peers. It doesn't > > > imply the media packets traverse the peering fabric. > > > > > > Of course, in theory, the peering system doesn't even have to touch > > > the signaling, but we don't have to go there. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > Sent: Tuesday, August 01, 2006 3:07 PM > > > > To: Brian Rosen > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > Subject: Re: [Speermint] Secure RTP > > > > > > > > Brian Rosen wrote: > > > > > I think that we are looking at case 1, and not at case > > 2. I don't > > > think > > > > we > > > > > care about the media. > > > > > > > > Interesting. I don't know about you, but I get paid for > > getting the > > > media > > > > right. Perfect signaling is useless without media. > > > > > > > > -andy > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 10:32:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G90jE-0002rC-6i; Fri, 04 Aug 2006 10:32:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G90jD-0002qX-IB for speermint@ietf.org; Fri, 04 Aug 2006 10:32:43 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G90XB-0000FK-D7 for speermint@ietf.org; Fri, 04 Aug 2006 10:20:19 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G90X3-0003M8-Ev; Fri, 04 Aug 2006 09:20:10 -0500 From: "Brian Rosen" To: "'Patrick Melampy'" , "'Michael Hammer \(mhammer\)'" , "'Hadriel Kaplan'" Subject: RE: [Speermint] Secure RTP Date: Fri, 4 Aug 2006 10:20:11 -0400 Message-ID: <02c901c6b7d1$1a7a2c20$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <00f101c6b7ce$2aad8a40$6401a8c0@acmepacket.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:PMelampy@acmepacket.com] > Sent: Friday, August 04, 2006 9:59 AM > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > Cc: speermint@ietf.org > 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:br@brianrosen.net] > Sent: Friday, August 04, 2006 8:47 AM > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > Cc: speermint@ietf.org > 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:mhammer@cisco.com] > > Sent: Thursday, August 03, 2006 3:13 PM > > To: Hadriel Kaplan; Brian Rosen > > Cc: speermint@ietf.org > > 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 > > > > 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 > > > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Tuesday, August 01, 2006 4:09 PM > > > To: 'Brian Rosen' > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Secure RTP > > > > > > But there are currently 11(?) proposed SRTP key exchange > > > mechanisms, some using SDP, some not - none of which > > > interoperate. So "interoperability" is impacted there, and > > > part of it is a signaling issue. In that sense it may well > > > be reasonable for a speermint BCP to pick one preferred > > > mechanism, but I'm sure that will be yet another rat-hole. > > > And I recommend we stay out of those when we can. :) > > > (besides, the RTPSEC-BOF group is assigned that Herculean task) > > > > > > -hadriel > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Tuesday, August 01, 2006 3:33 PM > > > > To: 'Andrew Newton' > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > Sure, but does the peering touch the media? I claim it doesn't, at > > > > least normally. "Getting it right" means that when the signaling > > > > happens, the resulting SDP will work. That part (the SDP part) > > > > matters to us, because we have to make sure that when that > > > SDP gets to > > > > the other side, it will result in something that works. > > > The peering > > > > system doesn't have to even look at the SDP, it just has to > > > have rules > > > > that make interoperability work. > > > > > > > > The peering system has to, for example, make sure that an address > > > > given in the SDP on one side is actually reachable on the > > > other side. > > > > Doing that doesn't involve any work, it's just rules the federation > > > > agrees to that makes that be true. So, we might need to > > > specify no NAT > > > > or conversely, MUST support ICE. That all speaks to what the peers > > > > have to have between their endpoints and their peers. It doesn't > > > > imply the media packets traverse the peering fabric. > > > > > > > > Of course, in theory, the peering system doesn't even have to touch > > > > the signaling, but we don't have to go there. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > > Sent: Tuesday, August 01, 2006 3:07 PM > > > > > To: Brian Rosen > > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > > Subject: Re: [Speermint] Secure RTP > > > > > > > > > > Brian Rosen wrote: > > > > > > I think that we are looking at case 1, and not at case > > > 2. I don't > > > > think > > > > > we > > > > > > care about the media. > > > > > > > > > > Interesting. I don't know about you, but I get paid for > > > getting the > > > > media > > > > > right. Perfect signaling is useless without media. > > > > > > > > > > -andy > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 11:00:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91AF-0003xZ-KC; Fri, 04 Aug 2006 11:00:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91AD-0003xI-SC for speermint@ietf.org; Fri, 04 Aug 2006 11:00:37 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=MAILSRV01.cedarpointcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G91AD-00041B-Cg for speermint@ietf.org; Fri, 04 Aug 2006 11:00:37 -0400 Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 11:00:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Secure RTP Date: Fri, 4 Aug 2006 11:00:35 -0400 Message-ID: <402F25FC1EB2BD44831F8A4A4F6DF94209C475@MAIL02.cedarpointcom.com> In-Reply-To: <02c901c6b7d1$1a7a2c20$9de6a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Secure RTP Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQ From: "Geoff Devine" To: "Brian Rosen" , "Patrick Melampy" , "Michael Hammer \(mhammer\)" , "Hadriel Kaplan" X-OriginalArrivalTime: 04 Aug 2006 15:00:36.0814 (UTC) FILETIME=[BE2CF6E0:01C6B7D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:br@brianrosen.net]=20 Sent: Friday, August 04, 2006 10:20 AM To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' Cc: speermint@ietf.org 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. =20 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:PMelampy@acmepacket.com] > Sent: Friday, August 04, 2006 9:59 AM > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > Brian, >=20 > 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 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, August 04, 2006 8:47 AM > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > I think you have to be careful with the "p" word. >=20 > 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). >=20 > 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. >=20 > 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. >=20 > Brian >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Thursday, August 03, 2006 3:13 PM > > To: Hadriel Kaplan; Brian Rosen > > Cc: speermint@ietf.org > > 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 > > > > 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 > > > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Tuesday, August 01, 2006 4:09 PM > > > To: 'Brian Rosen' > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Secure RTP > > > > > > But there are currently 11(?) proposed SRTP key exchange > > > mechanisms, some using SDP, some not - none of which > > > interoperate. So "interoperability" is impacted there, and > > > part of it is a signaling issue. In that sense it may well > > > be reasonable for a speermint BCP to pick one preferred > > > mechanism, but I'm sure that will be yet another rat-hole. > > > And I recommend we stay out of those when we can. :) > > > (besides, the RTPSEC-BOF group is assigned that Herculean task) > > > > > > -hadriel > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Tuesday, August 01, 2006 3:33 PM > > > > To: 'Andrew Newton' > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > Sure, but does the peering touch the media? I claim it doesn't, at > > > > least normally. "Getting it right" means that when the signaling > > > > happens, the resulting SDP will work. That part (the SDP part) > > > > matters to us, because we have to make sure that when that > > > SDP gets to > > > > the other side, it will result in something that works. > > > The peering > > > > system doesn't have to even look at the SDP, it just has to > > > have rules > > > > that make interoperability work. > > > > > > > > The peering system has to, for example, make sure that an address > > > > given in the SDP on one side is actually reachable on the > > > other side. > > > > Doing that doesn't involve any work, it's just rules the federation > > > > agrees to that makes that be true. So, we might need to > > > specify no NAT > > > > or conversely, MUST support ICE. That all speaks to what the peers > > > > have to have between their endpoints and their peers. It doesn't > > > > imply the media packets traverse the peering fabric. > > > > > > > > Of course, in theory, the peering system doesn't even have to touch > > > > the signaling, but we don't have to go there. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > > Sent: Tuesday, August 01, 2006 3:07 PM > > > > > To: Brian Rosen > > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > > Subject: Re: [Speermint] Secure RTP > > > > > > > > > > Brian Rosen wrote: > > > > > > I think that we are looking at case 1, and not at case > > > 2. I don't > > > > think > > > > > we > > > > > > care about the media. > > > > > > > > > > Interesting. I don't know about you, but I get paid for > > > getting the > > > > media > > > > > right. Perfect signaling is useless without media. > > > > > > > > > > -andy > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 11:03:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91Cs-0007GP-AF; Fri, 04 Aug 2006 11:03:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91Cr-0007GC-To for speermint@ietf.org; Fri, 04 Aug 2006 11:03:21 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G91Cp-0004DW-CN for speermint@ietf.org; Fri, 04 Aug 2006 11:03:21 -0400 Received: from PMelampy2 [10.0.200.104] by acmepacket.com with ESMTP (SMTPD-9.03) id A1C005B4; Fri, 04 Aug 2006 11:03:28 -0400 From: "Patrick Melampy" To: "'Brian Rosen'" , "'Michael Hammer \(mhammer\)'" , "'Hadriel Kaplan'" Subject: RE: [Speermint] Secure RTP Date: Fri, 4 Aug 2006 11:03:18 -0400 Message-ID: <011501c6b7d7$1eb57d20$6401a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABLq+A In-Reply-To: <02c901c6b7d1$1a7a2c20$9de6a8c0@cis.neustar.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >From the charter... >Note that the term "peering" is used here to refer to >the interconnection between application layer entities such as >SIP servers, as opposed to interconnection at the IP network >layer. So "peering" is about interconnection between SIP servers. It seems to me the types of issues we are discussing... 1.) Proxy Availability 2.) Path Discovery (which adjacent proxy can reach downstream domains) 3.) Congestion Control (which addresses are congested) Really are in scope. I am not suggesting TRIP at all. We do however, need to establish adjacency (peer) at the SIP Proxy Layer (as our charter says). This will include a trusted connection to a next-hop network. That next-hop network (and its TLS connections) will have real or business based limitations on the signaling rates they can support. Its far more likely that the limitations will be business defined -- possibly on a dynamic basis. They will also support reaching only some domains, not all. Thus rather than hunt and peck, we need to determine a way to learn what domains are reachable. Finally, the most pressing issue facing SIP in my opinion is the ability to manage congestion. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, August 04, 2006 10:20 AM To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' Cc: speermint@ietf.org 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:PMelampy@acmepacket.com] > Sent: Friday, August 04, 2006 9:59 AM > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > Cc: speermint@ietf.org > 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:br@brianrosen.net] > Sent: Friday, August 04, 2006 8:47 AM > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > Cc: speermint@ietf.org > 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:mhammer@cisco.com] > > Sent: Thursday, August 03, 2006 3:13 PM > > To: Hadriel Kaplan; Brian Rosen > > Cc: speermint@ietf.org > > 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 > > > > 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 > > > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Tuesday, August 01, 2006 4:09 PM > > > To: 'Brian Rosen' > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Secure RTP > > > > > > But there are currently 11(?) proposed SRTP key exchange > > > mechanisms, some using SDP, some not - none of which > > > interoperate. So "interoperability" is impacted there, and > > > part of it is a signaling issue. In that sense it may well > > > be reasonable for a speermint BCP to pick one preferred > > > mechanism, but I'm sure that will be yet another rat-hole. > > > And I recommend we stay out of those when we can. :) > > > (besides, the RTPSEC-BOF group is assigned that Herculean task) > > > > > > -hadriel > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Tuesday, August 01, 2006 3:33 PM > > > > To: 'Andrew Newton' > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > Sure, but does the peering touch the media? I claim it doesn't, at > > > > least normally. "Getting it right" means that when the signaling > > > > happens, the resulting SDP will work. That part (the SDP part) > > > > matters to us, because we have to make sure that when that > > > SDP gets to > > > > the other side, it will result in something that works. > > > The peering > > > > system doesn't have to even look at the SDP, it just has to > > > have rules > > > > that make interoperability work. > > > > > > > > The peering system has to, for example, make sure that an address > > > > given in the SDP on one side is actually reachable on the > > > other side. > > > > Doing that doesn't involve any work, it's just rules the federation > > > > agrees to that makes that be true. So, we might need to > > > specify no NAT > > > > or conversely, MUST support ICE. That all speaks to what the peers > > > > have to have between their endpoints and their peers. It doesn't > > > > imply the media packets traverse the peering fabric. > > > > > > > > Of course, in theory, the peering system doesn't even have to touch > > > > the signaling, but we don't have to go there. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > > Sent: Tuesday, August 01, 2006 3:07 PM > > > > > To: Brian Rosen > > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > > Subject: Re: [Speermint] Secure RTP > > > > > > > > > > Brian Rosen wrote: > > > > > > I think that we are looking at case 1, and not at case > > > 2. I don't > > > > think > > > > > we > > > > > > care about the media. > > > > > > > > > > Interesting. I don't know about you, but I get paid for > > > getting the > > > > media > > > > > right. Perfect signaling is useless without media. > > > > > > > > > > -andy > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 11:27:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91a0-0005lo-Oe; Fri, 04 Aug 2006 11:27:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91Zz-0005ia-Qz for speermint@ietf.org; Fri, 04 Aug 2006 11:27:15 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G91Zz-0005mQ-8S for speermint@ietf.org; Fri, 04 Aug 2006 11:27:15 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G91Zq-0007IT-Ky; Fri, 04 Aug 2006 10:27:07 -0500 From: "Brian Rosen" To: "'Geoff Devine'" , "'Patrick Melampy'" , "'Michael Hammer \(mhammer\)'" , "'Hadriel Kaplan'" Subject: RE: [Speermint] Secure RTP Date: Fri, 4 Aug 2006 11:27:07 -0400 Message-ID: <02db01c6b7da$7530e510$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <402F25FC1EB2BD44831F8A4A4F6DF94209C475@MAIL02.cedarpointcom.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:gdevine@cedarpointcom.com] > Sent: Friday, August 04, 2006 11:01 AM > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); Hadriel Kaplan > Cc: speermint@ietf.org > 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:br@brianrosen.net] > Sent: Friday, August 04, 2006 10:20 AM > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > Cc: speermint@ietf.org > 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:PMelampy@acmepacket.com] > > Sent: Friday, August 04, 2006 9:59 AM > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > Cc: speermint@ietf.org > > 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:br@brianrosen.net] > > Sent: Friday, August 04, 2006 8:47 AM > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > Cc: speermint@ietf.org > > 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:mhammer@cisco.com] > > > Sent: Thursday, August 03, 2006 3:13 PM > > > To: Hadriel Kaplan; Brian Rosen > > > Cc: speermint@ietf.org > > > 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 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 > > > > > > > > > > -----Original Message----- > > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > Sent: Tuesday, August 01, 2006 4:09 PM > > > > To: 'Brian Rosen' > > > > Cc: speermint@ietf.org > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > But there are currently 11(?) proposed SRTP key exchange > > > > mechanisms, some using SDP, some not - none of which > > > > interoperate. So "interoperability" is impacted there, and > > > > part of it is a signaling issue. In that sense it may well > > > > be reasonable for a speermint BCP to pick one preferred > > > > mechanism, but I'm sure that will be yet another rat-hole. > > > > And I recommend we stay out of those when we can. :) > > > > (besides, the RTPSEC-BOF group is assigned that Herculean task) > > > > > > > > -hadriel > > > > > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Tuesday, August 01, 2006 3:33 PM > > > > > To: 'Andrew Newton' > > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > > > Sure, but does the peering touch the media? I claim it doesn't, > at > > > > > least normally. "Getting it right" means that when the > signaling > > > > > happens, the resulting SDP will work. That part (the SDP part) > > > > > matters to us, because we have to make sure that when that > > > > SDP gets to > > > > > the other side, it will result in something that works. > > > > The peering > > > > > system doesn't have to even look at the SDP, it just has to > > > > have rules > > > > > that make interoperability work. > > > > > > > > > > The peering system has to, for example, make sure that an > address > > > > > given in the SDP on one side is actually reachable on the > > > > other side. > > > > > Doing that doesn't involve any work, it's just rules the > federation > > > > > agrees to that makes that be true. So, we might need to > > > > specify no NAT > > > > > or conversely, MUST support ICE. That all speaks to what the > peers > > > > > have to have between their endpoints and their peers. It > doesn't > > > > > imply the media packets traverse the peering fabric. > > > > > > > > > > Of course, in theory, the peering system doesn't even have to > touch > > > > > the signaling, but we don't have to go there. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > > > Sent: Tuesday, August 01, 2006 3:07 PM > > > > > > To: Brian Rosen > > > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > > > Subject: Re: [Speermint] Secure RTP > > > > > > > > > > > > Brian Rosen wrote: > > > > > > > I think that we are looking at case 1, and not at case > > > > 2. I don't > > > > > think > > > > > > we > > > > > > > care about the media. > > > > > > > > > > > > Interesting. I don't know about you, but I get paid for > > > > getting the > > > > > media > > > > > > right. Perfect signaling is useless without media. > > > > > > > > > > > > -andy > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 11:35:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91hn-0006jn-Au; Fri, 04 Aug 2006 11:35:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91hm-0006ji-9X for speermint@ietf.org; Fri, 04 Aug 2006 11:35:18 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=MAILSRV01.cedarpointcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G91hl-0006OM-Om for speermint@ietf.org; Fri, 04 Aug 2006 11:35:18 -0400 Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 11:35:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Secure RTP Date: Fri, 4 Aug 2006 11:35:15 -0400 Message-ID: <402F25FC1EB2BD44831F8A4A4F6DF94209C4C2@MAIL02.cedarpointcom.com> In-Reply-To: <02db01c6b7da$7530e510$9de6a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Secure RTP Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/AAABsDkA== From: "Geoff Devine" To: "Brian Rosen" , "Patrick Melampy" , "Michael Hammer \(mhammer\)" , "Hadriel Kaplan" X-OriginalArrivalTime: 04 Aug 2006 15:35:17.0035 (UTC) FILETIME=[96157FB0:01C6B7DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:br@brianrosen.net]=20 Sent: Friday, August 04, 2006 11:27 AM To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' Cc: speermint@ietf.org 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:gdevine@cedarpointcom.com] > Sent: Friday, August 04, 2006 11:01 AM > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); Hadriel Kaplan > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > 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. >=20 > Geoff >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, August 04, 2006 10:20 AM > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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). >=20 > Brian >=20 >=20 >=20 > > -----Original Message----- > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Sent: Friday, August 04, 2006 9:59 AM > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > Cc: speermint@ietf.org > > 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:br@brianrosen.net] > > Sent: Friday, August 04, 2006 8:47 AM > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > Cc: speermint@ietf.org > > 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:mhammer@cisco.com] > > > Sent: Thursday, August 03, 2006 3:13 PM > > > To: Hadriel Kaplan; Brian Rosen > > > Cc: speermint@ietf.org > > > 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 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 > > > > > > > > > > -----Original Message----- > > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > Sent: Tuesday, August 01, 2006 4:09 PM > > > > To: 'Brian Rosen' > > > > Cc: speermint@ietf.org > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > But there are currently 11(?) proposed SRTP key exchange > > > > mechanisms, some using SDP, some not - none of which > > > > interoperate. So "interoperability" is impacted there, and > > > > part of it is a signaling issue. In that sense it may well > > > > be reasonable for a speermint BCP to pick one preferred > > > > mechanism, but I'm sure that will be yet another rat-hole. > > > > And I recommend we stay out of those when we can. :) > > > > (besides, the RTPSEC-BOF group is assigned that Herculean task) > > > > > > > > -hadriel > > > > > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Tuesday, August 01, 2006 3:33 PM > > > > > To: 'Andrew Newton' > > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > > > Sure, but does the peering touch the media? I claim it doesn't, > at > > > > > least normally. "Getting it right" means that when the > signaling > > > > > happens, the resulting SDP will work. That part (the SDP part) > > > > > matters to us, because we have to make sure that when that > > > > SDP gets to > > > > > the other side, it will result in something that works. > > > > The peering > > > > > system doesn't have to even look at the SDP, it just has to > > > > have rules > > > > > that make interoperability work. > > > > > > > > > > The peering system has to, for example, make sure that an > address > > > > > given in the SDP on one side is actually reachable on the > > > > other side. > > > > > Doing that doesn't involve any work, it's just rules the > federation > > > > > agrees to that makes that be true. So, we might need to > > > > specify no NAT > > > > > or conversely, MUST support ICE. That all speaks to what the > peers > > > > > have to have between their endpoints and their peers. It > doesn't > > > > > imply the media packets traverse the peering fabric. > > > > > > > > > > Of course, in theory, the peering system doesn't even have to > touch > > > > > the signaling, but we don't have to go there. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > > > Sent: Tuesday, August 01, 2006 3:07 PM > > > > > > To: Brian Rosen > > > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > > > Subject: Re: [Speermint] Secure RTP > > > > > > > > > > > > Brian Rosen wrote: > > > > > > > I think that we are looking at case 1, and not at case > > > > 2. I don't > > > > > think > > > > > > we > > > > > > > care about the media. > > > > > > > > > > > > Interesting. I don't know about you, but I get paid for > > > > getting the > > > > > media > > > > > > right. Perfect signaling is useless without media. > > > > > > > > > > > > -andy > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 11:42:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91oW-00031r-Pq; Fri, 04 Aug 2006 11:42:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91oV-00031m-Iv for speermint@ietf.org; Fri, 04 Aug 2006 11:42:15 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G91oR-0006be-TR for speermint@ietf.org; Fri, 04 Aug 2006 11:42:15 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 Aug 2006 08:42:09 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,212,1151910000"; d="scan'208"; a="34609969:sNHT27101848" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k74FgA4h024184; Fri, 4 Aug 2006 11:42:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k74FgAdp022297; Fri, 4 Aug 2006 11:42:10 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 11:42:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Secure RTP Date: Fri, 4 Aug 2006 11:42:08 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301C6DE24@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Secure RTP Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AALE1WAAB/vNqA= From: "Michael Hammer \(mhammer\)" To: "Hadriel Kaplan" , "Brian Rosen" X-OriginalArrivalTime: 04 Aug 2006 15:42:09.0698 (UTC) FILETIME=[8C0CE020:01C6B7DC] DKIM-Signature: a=rsa-sha1; q=dns; l=5783; t=1154706130; x=1155570130; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Secure=20RTP |To:=22Hadriel=20Kaplan=22=20, =0A=20=20=20=20=20=20= 20=20=22Brian=20Rosen=22=20; X=v=3Dcisco.com=3B=20h=3DTav7+aVDpl+QOgZ4O1J+VN4eGlM=3D; b=T8YEXfr71449HJZzYkQSbpO4XllK1C2vDEKnXHSvFKNylT7W7j/uVLwWwOOYjrE0vlvjefM/ l0VcrlJaJLFLIvZ65YV7kt+aiQIscfKSaB4cakL/ignlz/Ya//XPuuA0; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Agree, that certain media related items will get negotiated by the signaling layer. As for trying to get everyone globally to agree, that is an idealistic goal. Expecting this to work at some lowever level (federations) is more realistic. Business interests will drive those federations to choose the right core pieces, therefore, I don't think we need to go down that rat-hole here. Mike > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Thursday, August 03, 2006 8:41 PM > To: Michael Hammer (mhammer); 'Brian Rosen' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > So you're saying they MUST implement such a policy exchange=20 > mechanism?? ;) >=20 > To me the srtp and codec "policy" exchange is already there: SDP. >=20 > We will probably need MUSTs for some things, because we need=20 > 2 speermint-supporting peers to interop. If two speermint=20 > federations can pick their own MUSTs for basic issues, then=20 > they may not interop. They can discover each other's=20 > policies all day long, but if there's no match we've screwed=20 > up. I don't put codecs into that basic issues list, because=20 > that's different and dependent per UA. It could be=20 > "normalized", but that's not easy to get consensus on. >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Thursday, August 03, 2006 3:13 PM > > To: Hadriel Kaplan; Brian Rosen > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Secure RTP > >=20 > > The focus of Speermint should be centered around whether one can=20 > > discover the policies of a potential peer and whether those=20 > policies=20 > > can systematically describe the requirements on multiple=20 > levels that=20 > > will need to be supported to have a successful=20 > communication with that peer. > >=20 > > It is not about specifying X, Y, Z, or MUST here> > >=20 > > Is is about whether the policy can be stated so one knows=20 > that X, Y, ... > > is required to peer. > >=20 > > I suspect that each federation will select different MUSTs for each=20 > > category of choices we come up with. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Tuesday, August 01, 2006 4:09 PM > > > To: 'Brian Rosen' > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Secure RTP > > > > > > But there are currently 11(?) proposed SRTP key exchange=20 > mechanisms,=20 > > > some using SDP, some not - none of which interoperate. So=20 > > > "interoperability" is impacted there, and part of it is a=20 > signaling=20 > > > issue. In that sense it may well be reasonable for a=20 > speermint BCP=20 > > > to pick one preferred mechanism, but I'm sure that will be yet=20 > > > another rat-hole. > > > And I recommend we stay out of those when we can. :)=20 > (besides, the=20 > > > RTPSEC-BOF group is assigned that Herculean task) > > > > > > -hadriel > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Tuesday, August 01, 2006 3:33 PM > > > > To: 'Andrew Newton' > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > Sure, but does the peering touch the media? I claim it=20 > doesn't,=20 > > > > at least normally. "Getting it right" means that when the=20 > > > > signaling happens, the resulting SDP will work. That part (the=20 > > > > SDP part) matters to us, because we have to make sure that when=20 > > > > that > > > SDP gets to > > > > the other side, it will result in something that works. > > > The peering > > > > system doesn't have to even look at the SDP, it just has to > > > have rules > > > > that make interoperability work. > > > > > > > > The peering system has to, for example, make sure that=20 > an address=20 > > > > given in the SDP on one side is actually reachable on the > > > other side. > > > > Doing that doesn't involve any work, it's just rules the=20 > > > > federation agrees to that makes that be true. So, we=20 > might need to > > > specify no NAT > > > > or conversely, MUST support ICE. That all speaks to what the=20 > > > > peers have to have between their endpoints and their peers. It=20 > > > > doesn't imply the media packets traverse the peering fabric. > > > > > > > > Of course, in theory, the peering system doesn't even have to=20 > > > > touch the signaling, but we don't have to go there. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > > Sent: Tuesday, August 01, 2006 3:07 PM > > > > > To: Brian Rosen > > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > > Subject: Re: [Speermint] Secure RTP > > > > > > > > > > Brian Rosen wrote: > > > > > > I think that we are looking at case 1, and not at case > > > 2. I don't > > > > think > > > > > we > > > > > > care about the media. > > > > > > > > > > Interesting. I don't know about you, but I get paid for > > > getting the > > > > media > > > > > right. Perfect signaling is useless without media. > > > > > > > > > > -andy > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 12:01:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G926p-0005yu-Ln; Fri, 04 Aug 2006 12:01:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G926p-0005yp-7T for speermint@ietf.org; Fri, 04 Aug 2006 12:01:11 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G926o-0007qV-ME for speermint@ietf.org; Fri, 04 Aug 2006 12:01:11 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G926d-0001FH-6a; Fri, 04 Aug 2006 11:00:59 -0500 From: "Brian Rosen" To: "'Geoff Devine'" , "'Patrick Melampy'" , "'Michael Hammer \(mhammer\)'" , "'Hadriel Kaplan'" Subject: RE: [Speermint] Secure RTP Date: Fri, 4 Aug 2006 12:01:01 -0400 Message-ID: <02eb01c6b7df$30d4a4b0$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/AAABsDkAAAfWzg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <402F25FC1EB2BD44831F8A4A4F6DF94209C4C2@MAIL02.cedarpointcom.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:gdevine@cedarpointcom.com] > Sent: Friday, August 04, 2006 11:35 AM > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); Hadriel Kaplan > Cc: speermint@ietf.org > 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:br@brianrosen.net] > Sent: Friday, August 04, 2006 11:27 AM > To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > 'Hadriel Kaplan' > Cc: speermint@ietf.org > 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:gdevine@cedarpointcom.com] > > Sent: Friday, August 04, 2006 11:01 AM > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); Hadriel > Kaplan > > Cc: speermint@ietf.org > > 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:br@brianrosen.net] > > Sent: Friday, August 04, 2006 10:20 AM > > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > Cc: speermint@ietf.org > > 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:PMelampy@acmepacket.com] > > > Sent: Friday, August 04, 2006 9:59 AM > > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > Cc: speermint@ietf.org > > > 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:br@brianrosen.net] > > > Sent: Friday, August 04, 2006 8:47 AM > > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > Cc: speermint@ietf.org > > > 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:mhammer@cisco.com] > > > > Sent: Thursday, August 03, 2006 3:13 PM > > > > To: Hadriel Kaplan; Brian Rosen > > > > Cc: speermint@ietf.org > > > > 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 > 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 Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 12:49:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92rj-00058X-6Q; Fri, 04 Aug 2006 12:49:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92rh-00056N-Bx for speermint@ietf.org; Fri, 04 Aug 2006 12:49:37 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G92hd-0002a3-Cu for speermint@ietf.org; Fri, 04 Aug 2006 12:39:16 -0400 Received: from PMelampy2 [10.0.200.104] by acmepacket.com with ESMTP (SMTPD-9.03) id A8370568; Fri, 04 Aug 2006 12:39:19 -0400 From: "Patrick Melampy" To: "'Brian Rosen'" , "'Geoff Devine'" , "'Michael Hammer \(mhammer\)'" , "'Hadriel Kaplan'" Subject: RE: [Speermint] Secure RTP Date: Fri, 4 Aug 2006 12:39:09 -0400 Message-ID: <012801c6b7e4$82a33b80$6401a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/AAABsDkAAAfWzgAAFrv3A= In-Reply-To: <02eb01c6b7df$30d4a4b0$9de6a8c0@cis.neustar.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:br@brianrosen.net] Sent: Friday, August 04, 2006 12:01 PM To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' Cc: speermint@ietf.org 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:gdevine@cedarpointcom.com] > Sent: Friday, August 04, 2006 11:35 AM > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); Hadriel Kaplan > Cc: speermint@ietf.org > 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:br@brianrosen.net] > Sent: Friday, August 04, 2006 11:27 AM > To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > 'Hadriel Kaplan' > Cc: speermint@ietf.org > 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:gdevine@cedarpointcom.com] > > Sent: Friday, August 04, 2006 11:01 AM > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); Hadriel > Kaplan > > Cc: speermint@ietf.org > > 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:br@brianrosen.net] > > Sent: Friday, August 04, 2006 10:20 AM > > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > Cc: speermint@ietf.org > > 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:PMelampy@acmepacket.com] > > > Sent: Friday, August 04, 2006 9:59 AM > > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > Cc: speermint@ietf.org > > > 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:br@brianrosen.net] > > > Sent: Friday, August 04, 2006 8:47 AM > > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > Cc: speermint@ietf.org > > > 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:mhammer@cisco.com] > > > > Sent: Thursday, August 03, 2006 3:13 PM > > > > To: Hadriel Kaplan; Brian Rosen > > > > Cc: speermint@ietf.org > > > > 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 > 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 Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 13:46:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G93l0-0001q2-Lm; Fri, 04 Aug 2006 13:46:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G93kz-0001pO-Ab for speermint@ietf.org; Fri, 04 Aug 2006 13:46:45 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G93ky-000747-Ls for speermint@ietf.org; Fri, 04 Aug 2006 13:46:45 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G93ko-0006ea-7l; Fri, 04 Aug 2006 12:46:34 -0500 From: "Brian Rosen" To: "'Patrick Melampy'" , "'Geoff Devine'" , "'Michael Hammer \(mhammer\)'" , "'Hadriel Kaplan'" Subject: RE: [Speermint] Congestion and Load Balancing was Re: Secure RTP Date: Fri, 4 Aug 2006 13:46:36 -0400 Message-ID: <031001c6b7ed$f11a1b70$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/AAABsDkAAAfWzgAAFrv3AAAfWesA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <012801c6b7e4$82a33b80$6401a8c0@acmepacket.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:PMelampy@acmepacket.com] > Sent: Friday, August 04, 2006 12:39 PM > To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; 'Hadriel > Kaplan' > Cc: speermint@ietf.org > 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:br@brianrosen.net] > Sent: Friday, August 04, 2006 12:01 PM > To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > 'Hadriel > Kaplan' > Cc: speermint@ietf.org > 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:gdevine@cedarpointcom.com] > > Sent: Friday, August 04, 2006 11:35 AM > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); Hadriel > Kaplan > > Cc: speermint@ietf.org > > 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:br@brianrosen.net] > > Sent: Friday, August 04, 2006 11:27 AM > > To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > 'Hadriel Kaplan' > > Cc: speermint@ietf.org > > 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:gdevine@cedarpointcom.com] > > > Sent: Friday, August 04, 2006 11:01 AM > > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); Hadriel > > Kaplan > > > Cc: speermint@ietf.org > > > 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:br@brianrosen.net] > > > Sent: Friday, August 04, 2006 10:20 AM > > > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > Cc: speermint@ietf.org > > > 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:PMelampy@acmepacket.com] > > > > Sent: Friday, August 04, 2006 9:59 AM > > > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > Cc: speermint@ietf.org > > > > 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:br@brianrosen.net] > > > > Sent: Friday, August 04, 2006 8:47 AM > > > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > Cc: speermint@ietf.org > > > > 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:mhammer@cisco.com] > > > > > Sent: Thursday, August 03, 2006 3:13 PM > > > > > To: Hadriel Kaplan; Brian Rosen > > > > > Cc: speermint@ietf.org > > > > > 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 > > 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 Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 14:10:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G948P-0007yp-Dd; Fri, 04 Aug 2006 14:10:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G948N-0007pO-Iu for speermint@ietf.org; Fri, 04 Aug 2006 14:10:55 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G948M-0000KZ-2r for speermint@ietf.org; Fri, 04 Aug 2006 14:10:55 -0400 Received: from source ([192.150.11.134]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Fri, 04 Aug 2006 11:10:52 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k74I8vBl021633; Fri, 4 Aug 2006 11:09:02 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k74IASR0004005; Fri, 4 Aug 2006 11:10:46 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 11:10:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DNS performance (was Re: [Speermint] TLs performance) Date: Fri, 4 Aug 2006 11:10:34 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D220C373B@namail5.corp.adobe.com> In-Reply-To: <44D32FEE.7060601@pernau.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS performance (was Re: [Speermint] TLs performance) Thread-Index: Aca3uXDhTkfqAKbPRzGCPdXOu29ihwANfmig From: "Henry Sinnreich" To: "Klaus Darilion" X-OriginalArrivalTime: 04 Aug 2006 18:10:35.0364 (UTC) FILETIME=[483DAA40:01C6B7F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Thanks Klaus for the thorough analysis! I would only add to the observation: >further lookups for this domain will be cached in the DNS resolver server. In this case there is the risk that the cached DNS data is stale, and we may have an error condition. Some mobile phone registrations may change with the same speed or even faster than the DNS refresh from domain to domain.=20 I could not get a handle on this. Any thoughts on this, or even more important, have any measurements been made to capture the effect of DNS caching on mobility between domains? Or is the mobile provider prevalent thinking that users will never change domains? :-) Thanks, Henry -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 Sent: Friday, August 04, 2006 4:31 AM To: Henry Sinnreich Cc: speermint@ietf.org Subject: DNS performance (was Re: [Speermint] TLs performance) Henry Sinnreich wrote: > Hi Klaus, >=20 > This is a good beginning, but you may want to include the 2-3 DNS > lookups from the originating UAC and the additional 3-4 DNS lookups for > ENUM, NAPTR, etc. >=20 > Can you add such a test? Hi Henry! Due to lack of time (and test applications) I did not made DNS tests=20 yet, but some theory: DNS lookups do not need many resources. Of course, it will increase call setup time as the DNS lookup takes time, but that=20 does not mean that the call throughput of the SIP proxy will decrease.=20 If the SIP proxy uses asynchronous DNS or has enough threads, than the=20 overall call throughput should be nearly constant, regardless of how=20 long the DNS lookup takes. Regarding the call setup delay: If a domain is looked up the first time, it will take some time (usually <100 ms). But further lookups for this=20 domain will be cached in the DNS resolver server. Usually, there will be a DNS resolver somewhere "near" the SIP proxy and DNS lookups for cached domains will be <2ms. There is also lots of discussion that RFC3263 is bad as NAPTR+SRV=20 lookups will increase the call setup time as we need 3 DNS lookups=20 instead of 1. But again, this additional 2 DNS lookups will usually only happen between the SIP proxy and the DNS resolver. If the NAPTRs, SRV=20 and A/AAAA records are delegated to the same authoritative DNS server,=20 this server will include all domains in the additional section of the=20 DNS response. E.g. the SIP proxy has to resolve pernau.at (NAPTR+SRV+A). It first will query for NAPTR records: >dig pernau.at NAPTR ;; QUESTION SECTION: ;pernau.at. IN NAPTR ;; ANSWER SECTION: pernau.at. 65 IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.pernau.at. pernau.at. 65 IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.pernau.at. pernau.at. 65 IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.pernau.at. ;; ADDITIONAL SECTION: pernau.at. 1312 IN A 213.239.207.29 pb94.dyndns.org. 12114 IN A 213.239.207.29 _sips._tcp.pernau.at. 65 IN SRV 0 0 6061 pernau.at. _sip._tcp.pernau.at. 65 IN SRV 0 0 6060 pernau.at. _sip._udp.pernau.at. 65 IN SRV 0 0 6060 pernau.at. ;; Query time: 31 msec This lookup did take 31 msec as all the caches were empty. If now the=20 SIP proxy queries for the SRV and A records, this will be really fast as the resolver already has cached the values from the additional section. > dig _sips._tcp.pernau.at SRV ;; QUESTION SECTION: ;_sips._tcp.pernau.at. IN SRV ;; ANSWER SECTION: _sips._tcp.pernau.at. 107 IN SRV 0 0 6061 pernau.at. ;; Query time: 2 msec The same is for the A lookup. Conclusion: Even if the DNS caches are empty, the call setup delays due=20 to NAPTR and SRV lookups are not that big as lots of people think - DNS=20 is quite intelligent. regards Klaus >=20 > Thanks, Henry >=20 > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 > Sent: Monday, July 24, 2006 1:00 PM > To: speermint@ietf.org > Subject: [Speermint] TLs performance >=20 > Hi! >=20 > I made some tests with sipp+openser: >=20 > scenario: >=20 > UAC <-TLS-> openser <-TLS-> UAS (all of them got its own 2xP3 1,26GHz=20 > machine, linked with 100MBit). Simple forwarding configuration (like a > loadbalancer), no DNS lookups or DB queries. >=20 > UDP: ~620 cps > TLS: ~680 cps (single TLS connection) >=20 > cps=3Dcalls per second =3D INVITE-180-200-OK-ACK-BYE-200 >=20 > I think TLS performs better as because of UDP retransmissions, which=20 > "kills" the proxy if it becomes slow. >=20 > More data when I have it. >=20 > regards > klaus >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 14:13:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G94BB-0001dZ-IP; Fri, 04 Aug 2006 14:13:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G94BA-0001ZT-S7 for speermint@ietf.org; Fri, 04 Aug 2006 14:13:48 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G94B9-0000Yv-Tp for speermint@ietf.org; Fri, 04 Aug 2006 14:13:48 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 04 Aug 2006 11:13:50 -0700 X-IronPort-AV: i="4.07,212,1151910000"; d="scan'208"; a="574340350:sNHT61081012" x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Congestion and Load Balancing was Re: Secure RTP Date: Fri, 4 Aug 2006 14:13:58 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2805182ACC@proton.jnpr.net> In-Reply-To: <031001c6b7ed$f11a1b70$9de6a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Congestion and Load Balancing was Re: Secure RTP Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/AAABsDkAAAfWzgAAFrv3AAAfWesAABmq5A From: "Reinaldo Penno" To: "Brian Rosen" , "Patrick Melampy" , "Geoff Devine" , "Michael Hammer \(mhammer\)" , "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 398dc098b38497efe55f044562a219e7 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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.=20 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:br@brianrosen.net] > Sent: Friday, August 04, 2006 10:47 AM > To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; > 'Hadriel Kaplan' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing was Re: Secure RTP >=20 > RTP> >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Let's take an example: >=20 > 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. >=20 > 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. >=20 > Brian >=20 >=20 >=20 > > -----Original Message----- > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Sent: Friday, August 04, 2006 12:39 PM > > To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; 'Hadriel > > Kaplan' > > Cc: speermint@ietf.org > > 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:br@brianrosen.net] > > Sent: Friday, August 04, 2006 12:01 PM > > To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > 'Hadriel > > Kaplan' > > Cc: speermint@ietf.org > > 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:gdevine@cedarpointcom.com] > > > Sent: Friday, August 04, 2006 11:35 AM > > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); Hadriel > > Kaplan > > > Cc: speermint@ietf.org > > > 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:br@brianrosen.net] > > > Sent: Friday, August 04, 2006 11:27 AM > > > To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > 'Hadriel Kaplan' > > > Cc: speermint@ietf.org > > > 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:gdevine@cedarpointcom.com] > > > > Sent: Friday, August 04, 2006 11:01 AM > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); Hadriel > > > Kaplan > > > > Cc: speermint@ietf.org > > > > 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:br@brianrosen.net] > > > > Sent: Friday, August 04, 2006 10:20 AM > > > > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > Cc: speermint@ietf.org > > > > 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:PMelampy@acmepacket.com] > > > > > Sent: Friday, August 04, 2006 9:59 AM > > > > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > > Cc: speermint@ietf.org > > > > > 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:br@brianrosen.net] > > > > > Sent: Friday, August 04, 2006 8:47 AM > > > > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > > Cc: speermint@ietf.org > > > > > 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:mhammer@cisco.com] > > > > > > Sent: Thursday, August 03, 2006 3:13 PM > > > > > > To: Hadriel Kaplan; Brian Rosen > > > > > > Cc: speermint@ietf.org > > > > > > 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 > > > 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 > > > > > > > > > > > > >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 14:28:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G94P5-0008RW-VL; Fri, 04 Aug 2006 14:28:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G94P4-0008RR-MY for speermint@ietf.org; Fri, 04 Aug 2006 14:28:10 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G94P2-0001PO-Sp for speermint@ietf.org; Fri, 04 Aug 2006 14:28:10 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G94Oq-0000DQ-MK; Fri, 04 Aug 2006 13:27:57 -0500 From: "Brian Rosen" To: "'Reinaldo Penno'" , "'Patrick Melampy'" , "'Geoff Devine'" , "'Michael Hammer \(mhammer\)'" , "'Hadriel Kaplan'" Subject: RE: [Speermint] Congestion and Load Balancing was Re: Secure RTP Date: Fri, 4 Aug 2006 14:27:59 -0400 Message-ID: <031c01c6b7f3$b919ce90$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/AAABsDkAAAfWzgAAFrv3AAAfWesAABmq5AAACioaA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2805182ACC@proton.jnpr.net> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ed37b243475b9c4ffb6a3f90050819d Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:rpenno@juniper.net] > Sent: Friday, August 04, 2006 2:14 PM > To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer (mhammer); > Hadriel Kaplan > Cc: speermint@ietf.org > 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:br@brianrosen.net] > > Sent: Friday, August 04, 2006 10:47 AM > > To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; > > 'Hadriel Kaplan' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Congestion and Load Balancing was Re: Secure > RTP > > > > > 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:PMelampy@acmepacket.com] > > > Sent: Friday, August 04, 2006 12:39 PM > > > To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; > 'Hadriel > > > Kaplan' > > > Cc: speermint@ietf.org > > > 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:br@brianrosen.net] > > > Sent: Friday, August 04, 2006 12:01 PM > > > To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > 'Hadriel > > > Kaplan' > > > Cc: speermint@ietf.org > > > 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:gdevine@cedarpointcom.com] > > > > Sent: Friday, August 04, 2006 11:35 AM > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > Hadriel > > > Kaplan > > > > Cc: speermint@ietf.org > > > > 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:br@brianrosen.net] > > > > Sent: Friday, August 04, 2006 11:27 AM > > > > To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > > 'Hadriel Kaplan' > > > > Cc: speermint@ietf.org > > > > 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:gdevine@cedarpointcom.com] > > > > > Sent: Friday, August 04, 2006 11:01 AM > > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > Hadriel > > > > Kaplan > > > > > Cc: speermint@ietf.org > > > > > 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:br@brianrosen.net] > > > > > Sent: Friday, August 04, 2006 10:20 AM > > > > > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel > Kaplan' > > > > > Cc: speermint@ietf.org > > > > > 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:PMelampy@acmepacket.com] > > > > > > Sent: Friday, August 04, 2006 9:59 AM > > > > > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel > Kaplan' > > > > > > Cc: speermint@ietf.org > > > > > > 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:br@brianrosen.net] > > > > > > Sent: Friday, August 04, 2006 8:47 AM > > > > > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > > > Cc: speermint@ietf.org > > > > > > 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:mhammer@cisco.com] > > > > > > > Sent: Thursday, August 03, 2006 3:13 PM > > > > > > > To: Hadriel Kaplan; Brian Rosen > > > > > > > Cc: speermint@ietf.org > > > > > > > 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 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 > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 17:11:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G96wd-0000Xe-Rm; Fri, 04 Aug 2006 17:10:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G96wc-0000WI-Ty for speermint@ietf.org; Fri, 04 Aug 2006 17:10:58 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G96wb-00050u-Ho for speermint@ietf.org; Fri, 04 Aug 2006 17:10:58 -0400 Received: from cccsb696aba308 (dhcp-65-64.ee.columbia.edu [128.59.65.64]) (user=qs2005 mech=LOGIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k74LAnJo013145 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Aug 2006 17:10:49 -0400 (EDT) From: "Charles Shen" To: "'Klaus Darilion'" , "'Henry Sinnreich'" Subject: RE: DNS performance (was Re: [Speermint] TLs performance) Date: Fri, 4 Aug 2006 17:10:49 -0400 Organization: Columbia U Message-ID: <021701c6b80a$7a2ea9a0$40413b80@cccsb696aba308> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca3uYVObBlXWlUiQRqOeb4IH+SyCgAT4/sA In-Reply-To: <44D32FEE.7060601@pernau.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi, We have the following technical report on ENUM performance, using PDNS, BIND, and ANS. Charles Shen and Henning Schulzrinne, "Measurement and Evaluation of ENUM Server Performance," Department of Computer Science, Columbia University, Tech. Rep. CUCS-029-06, July 2006. The report is available at: http://www.cs.columbia.edu/research/publications Hope it will be helpful. Thanks. Charles -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Sent: Friday, August 04, 2006 7:31 AM To: Henry Sinnreich Cc: speermint@ietf.org Subject: DNS performance (was Re: [Speermint] TLs performance) Henry Sinnreich wrote: > Hi Klaus, > > This is a good beginning, but you may want to include the 2-3 DNS > lookups from the originating UAC and the additional 3-4 DNS lookups > for ENUM, NAPTR, etc. > > Can you add such a test? Hi Henry! Due to lack of time (and test applications) I did not made DNS tests yet, but some theory: DNS lookups do not need many resources. Of course, it will increase call setup time as the DNS lookup takes time, but that does not mean that the call throughput of the SIP proxy will decrease. If the SIP proxy uses asynchronous DNS or has enough threads, than the overall call throughput should be nearly constant, regardless of how long the DNS lookup takes. Regarding the call setup delay: If a domain is looked up the first time, it will take some time (usually <100 ms). But further lookups for this domain will be cached in the DNS resolver server. Usually, there will be a DNS resolver somewhere "near" the SIP proxy and DNS lookups for cached domains will be <2ms. There is also lots of discussion that RFC3263 is bad as NAPTR+SRV lookups will increase the call setup time as we need 3 DNS lookups instead of 1. But again, this additional 2 DNS lookups will usually only happen between the SIP proxy and the DNS resolver. If the NAPTRs, SRV and A/AAAA records are delegated to the same authoritative DNS server, this server will include all domains in the additional section of the DNS response. E.g. the SIP proxy has to resolve pernau.at (NAPTR+SRV+A). It first will query for NAPTR records: >dig pernau.at NAPTR ;; QUESTION SECTION: ;pernau.at. IN NAPTR ;; ANSWER SECTION: pernau.at. 65 IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.pernau.at. pernau.at. 65 IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.pernau.at. pernau.at. 65 IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.pernau.at. ;; ADDITIONAL SECTION: pernau.at. 1312 IN A 213.239.207.29 pb94.dyndns.org. 12114 IN A 213.239.207.29 _sips._tcp.pernau.at. 65 IN SRV 0 0 6061 pernau.at. _sip._tcp.pernau.at. 65 IN SRV 0 0 6060 pernau.at. _sip._udp.pernau.at. 65 IN SRV 0 0 6060 pernau.at. ;; Query time: 31 msec This lookup did take 31 msec as all the caches were empty. If now the SIP proxy queries for the SRV and A records, this will be really fast as the resolver already has cached the values from the additional section. > dig _sips._tcp.pernau.at SRV ;; QUESTION SECTION: ;_sips._tcp.pernau.at. IN SRV ;; ANSWER SECTION: _sips._tcp.pernau.at. 107 IN SRV 0 0 6061 pernau.at. ;; Query time: 2 msec The same is for the A lookup. Conclusion: Even if the DNS caches are empty, the call setup delays due to NAPTR and SRV lookups are not that big as lots of people think - DNS is quite intelligent. regards Klaus > > Thanks, Henry > > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Monday, July 24, 2006 1:00 PM > To: speermint@ietf.org > Subject: [Speermint] TLs performance > > Hi! > > I made some tests with sipp+openser: > > scenario: > > UAC <-TLS-> openser <-TLS-> UAS (all of them got its own 2xP3 1,26GHz > machine, linked with 100MBit). Simple forwarding configuration (like a > loadbalancer), no DNS lookups or DB queries. > > UDP: ~620 cps > TLS: ~680 cps (single TLS connection) > > cps=calls per second = INVITE-180-200-OK-ACK-BYE-200 > > I think TLS performs better as because of UDP retransmissions, which > "kills" the proxy if it becomes slow. > > More data when I have it. > > regards > klaus > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 18:15:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97xO-0006rt-Df; Fri, 04 Aug 2006 18:15:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97xN-0006rg-1d for speermint@ietf.org; Fri, 04 Aug 2006 18:15:49 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G97xJ-0007ls-N6 for speermint@ietf.org; Fri, 04 Aug 2006 18:15:49 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 04 Aug 2006 15:15:35 -0700 X-IronPort-AV: i="4.07,213,1151910000"; d="scan'208"; a="1844375712:sNHT2587364068" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k74MFYaM008786; Fri, 4 Aug 2006 15:15:34 -0700 Received: from [192.168.1.101] (sjc-vpn2-100.cisco.com [10.21.112.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k74MFXIZ026092; Fri, 4 Aug 2006 15:15:34 -0700 (PDT) In-Reply-To: <44CF2122.1010208@bulukucing.org> References: <44C50A97.3080402@pernau.at> <44CF2122.1010208@bulukucing.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75289D69-51FE-42F7-973F-6E111064F48A@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Speermint] TLs performance Date: Fri, 4 Aug 2006 15:15:36 -0700 To: Benny Prijono X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=2401; t=1154729734; x=1155593734; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Speermint]=20TLs=20performance; X=v=3Dcisco.com=3B=20h=3Do+yTF7da5zDLmPpiFZ6iZbdb+eQ=3D; b=XJ2u+WFehyX+guoWlVq3bnu9JiTa/88fm5eQAzg/WJfa4BNkjbOVPUMYLgziQtwsZYu79TFt +kcQuSWX+iKw2Uu1AYR8nrumdNxtZkh/dYdZhC0MUzoZ68SvDCIc+K6m; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Well if you are benchmarking how fast a single transaction can be process, what you are saying makes sense. However, I think we were benchmarking the maximum number of transactions per second (or call per second) a proxy could support in a loaded network which often comes up with different results. On Aug 1, 2006, at 2:38 AM, Benny Prijono wrote: > Hi all, > > just to share my data, fwiw. In my benchmark, TCP (with single > connection) performs almost consistently better than UDP in > transactions and calls processing, but only when UAC and UAS are in > local machine. When UAC and UAS are separated into different boxes, > TCP performance is only about half of UDP performance. > > For me, my data makes perfect sense, because in local machine, TCP > transactions has lower cost to setup (e.g. less timers), so it > should be faster. While on the network, the TCP round-trip probably > prevents transaction to complete as fast as the UDP version, so TCP > should be slower. So I'm a bit surprised that in your benchmarks > TCP outperformed UDP, but perhaps it's just some tuning in the > socket settings (any info on these will be appreciated). > > Btw my benchmark report can be found here: > http://www.pjsip.org/testing/0.5.6.5/bench.htm > > -benny > > > Cullen Jennings wrote: >> Klaus, first of all thank you for producing some real results we >> can discuss. Just to validate some of your results - this is not >> the first time I have seen performance results where TLS (or more >> specifically TCP) has better performance that UDP. I have seen >> this on other products too and when I think about it, it is not >> that surprising. >> Cullen >> On Jul 24, 2006, at 10:59 AM, Klaus Darilion wrote: >>> Hi! >>> >>> I made some tests with sipp+openser: >>> >>> scenario: >>> >>> UAC <-TLS-> openser <-TLS-> UAS (all of them got its own 2xP3 >>> 1,26GHz machine, linked with 100MBit). Simple forwarding >>> configuration (like a loadbalancer), no DNS lookups or DB queries. >>> >>> UDP: ~620 cps >>> TLS: ~680 cps (single TLS connection) >>> >>> cps=calls per second = INVITE-180-200-OK-ACK-BYE-200 >>> >>> I think TLS performs better as because of UDP retransmissions, >>> which "kills" the proxy if it becomes slow. >>> >>> More data when I have it. >>> >>> regards >>> klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 18:31:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G98CW-00042f-Jm; Fri, 04 Aug 2006 18:31:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G98CV-0003ws-F6 for speermint@ietf.org; Fri, 04 Aug 2006 18:31:27 -0400 Received: from [86.59.12.252] (helo=sil1.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G98CR-0000hh-W0 for speermint@ietf.org; Fri, 04 Aug 2006 18:31:27 -0400 Received: from ap1.stiwoll.mah.priv.at ([62.99.233.53] helo=[10.0.1.2]) by sil1.mah.priv.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1G98CM-0005kb-Uf; Sat, 05 Aug 2006 00:31:19 +0200 Message-ID: <44D3CAB0.4020303@inode.at> Date: Sat, 05 Aug 2006 00:31:12 +0200 From: Michael Haberler User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Henry Sinnreich References: <24CCCC428EFEA2469BF046DB3C7A8D220C373B@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D220C373B@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 62.99.233.53 X-SA-Exim-Mail-From: mah@inode.at X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sil1.mah.priv.at X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Subject: Re: DNS performance (was Re: [Speermint] TLs performance) X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sil1.mah.priv.at) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Henry Sinnreich schrieb: > Thanks Klaus for the thorough analysis! > > I would only add to the observation: > > >> further lookups for this domain will be cached in the DNS resolver >> > server. > > In this case there is the risk that the cached DNS data is stale, and we > how often do you change telcos? > may have an error condition. an expired cache entry is not an error condition, it is a performance impact of a tradeoff decision between consistency and lookup time > Some mobile phone registrations may change > with the same speed or even faster than the DNS refresh from domain to > domain. > the change driver on ENUM DNS entries is your porting frequency, not your change-of-celltower/wlan access - that's a sip proxy issue > I could not get a handle on this. Any thoughts on this, or even more > important, have any measurements been made to capture the effect of DNS > caching on mobility between domains? Or is the mobile provider prevalent > thinking that users will never change domains? :-) > mobility between domains (if you're talking users changing providers for a domain) is standard ISP fare - user wants to change - reduce expiration timers - cutover - increase expiration timers - done I'm a bit lost which problem you're actually referring to -m > Thanks, Henry > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 04 19:11:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G98pP-0007Xi-Kv; Fri, 04 Aug 2006 19:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G98pN-0007Xd-Rh for speermint@ietf.org; Fri, 04 Aug 2006 19:11:37 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G98pM-0004j4-Ig for speermint@ietf.org; Fri, 04 Aug 2006 19:11:37 -0400 Received: from [192.168.0.66] (81-178-58-134.dsl.pipex.com [81.178.58.134]) by blaster.systems.pipex.net (Postfix) with ESMTP id E25ECE00013B; Sat, 5 Aug 2006 00:11:34 +0100 (BST) Message-ID: <44D3D425.8020304@bulukucing.org> Date: Sat, 05 Aug 2006 00:11:33 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Speermint] TLs performance References: <44C50A97.3080402@pernau.at> <44CF2122.1010208@bulukucing.org> <75289D69-51FE-42F7-973F-6E111064F48A@cisco.com> In-Reply-To: <75289D69-51FE-42F7-973F-6E111064F48A@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Not sure if I understand you correctly (why would anyone benchmark how fast a single transaction can be processed), but my observation was based on the time to complete 10,000 transactions or calls, then calculate the tps/cps. If you think this doesn't make sense, then I think we have something interesting to discuss. -benny Cullen Jennings wrote: > > Well if you are benchmarking how fast a single transaction can be > process, what you are saying makes sense. However, I think we were > benchmarking the maximum number of transactions per second (or call per > second) a proxy could support in a loaded network which often comes up > with different results. > > > On Aug 1, 2006, at 2:38 AM, Benny Prijono wrote: > >> Hi all, >> >> just to share my data, fwiw. In my benchmark, TCP (with single >> connection) performs almost consistently better than UDP in >> transactions and calls processing, but only when UAC and UAS are in >> local machine. When UAC and UAS are separated into different boxes, >> TCP performance is only about half of UDP performance. >> >> For me, my data makes perfect sense, because in local machine, TCP >> transactions has lower cost to setup (e.g. less timers), so it should >> be faster. While on the network, the TCP round-trip probably prevents >> transaction to complete as fast as the UDP version, so TCP should be >> slower. So I'm a bit surprised that in your benchmarks TCP >> outperformed UDP, but perhaps it's just some tuning in the socket >> settings (any info on these will be appreciated). >> >> Btw my benchmark report can be found here: >> http://www.pjsip.org/testing/0.5.6.5/bench.htm >> >> -benny _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat Aug 05 16:42:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9SyG-0007XG-Oj; Sat, 05 Aug 2006 16:42:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9SyF-0007XB-R8 for speermint@ietf.org; Sat, 05 Aug 2006 16:42:07 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9SyE-0006IX-TE for speermint@ietf.org; Sat, 05 Aug 2006 16:42:07 -0400 Received: from PMelampy2 [68.189.242.21] by acmepacket.com with ESMTP (SMTPD-9.03) id A2A5030C; Sat, 05 Aug 2006 16:42:13 -0400 From: "Patrick Melampy" To: "'Brian Rosen'" Subject: RE: [Speermint] Congestion and Load Balancing Date: Sat, 5 Aug 2006 16:42:03 -0400 Message-ID: <000401c6b8cf$9bccf740$6401a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/AAABsDkAAAfWzgAAFrv3AAAfWesAABmq5AAACioaAANhVVQA== In-Reply-To: <031c01c6b7f3$b919ce90$9de6a8c0@cis.neustar.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: fbb024a763f81fc20bcc0df70457576f Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:br@brianrosen.net] Sent: Friday, August 04, 2006 2:28 PM To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' Cc: speermint@ietf.org 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:rpenno@juniper.net] > Sent: Friday, August 04, 2006 2:14 PM > To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer (mhammer); > Hadriel Kaplan > Cc: speermint@ietf.org > 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:br@brianrosen.net] > > Sent: Friday, August 04, 2006 10:47 AM > > To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; > > 'Hadriel Kaplan' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Congestion and Load Balancing was Re: Secure > RTP > > > > > 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:PMelampy@acmepacket.com] > > > Sent: Friday, August 04, 2006 12:39 PM > > > To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; > 'Hadriel > > > Kaplan' > > > Cc: speermint@ietf.org > > > 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:br@brianrosen.net] > > > Sent: Friday, August 04, 2006 12:01 PM > > > To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > 'Hadriel > > > Kaplan' > > > Cc: speermint@ietf.org > > > 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:gdevine@cedarpointcom.com] > > > > Sent: Friday, August 04, 2006 11:35 AM > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > Hadriel > > > Kaplan > > > > Cc: speermint@ietf.org > > > > 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:br@brianrosen.net] > > > > Sent: Friday, August 04, 2006 11:27 AM > > > > To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > > 'Hadriel Kaplan' > > > > Cc: speermint@ietf.org > > > > 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:gdevine@cedarpointcom.com] > > > > > Sent: Friday, August 04, 2006 11:01 AM > > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > Hadriel > > > > Kaplan > > > > > Cc: speermint@ietf.org > > > > > 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:br@brianrosen.net] > > > > > Sent: Friday, August 04, 2006 10:20 AM > > > > > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel > Kaplan' > > > > > Cc: speermint@ietf.org > > > > > 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:PMelampy@acmepacket.com] > > > > > > Sent: Friday, August 04, 2006 9:59 AM > > > > > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel > Kaplan' > > > > > > Cc: speermint@ietf.org > > > > > > 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:br@brianrosen.net] > > > > > > Sent: Friday, August 04, 2006 8:47 AM > > > > > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > > > Cc: speermint@ietf.org > > > > > > 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:mhammer@cisco.com] > > > > > > > Sent: Thursday, August 03, 2006 3:13 PM > > > > > > > To: Hadriel Kaplan; Brian Rosen > > > > > > > Cc: speermint@ietf.org > > > > > > > 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 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 > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Aug 06 11:24:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9kUc-0002kH-Qv; Sun, 06 Aug 2006 11:24:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9kUb-0002kA-1p for speermint@ietf.org; Sun, 06 Aug 2006 11:24:41 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G9kUZ-0000uN-JO for speermint@ietf.org; Sun, 06 Aug 2006 11:24:41 -0400 Received: from source ([192.150.20.142]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Sun, 06 Aug 2006 08:24:33 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k76FOjuv015992; Sun, 6 Aug 2006 08:24:46 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k76FOT4Z020966; Sun, 6 Aug 2006 08:24:29 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Aug 2006 08:24:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DNS performance (was Re: [Speermint] TLs performance) Date: Sun, 6 Aug 2006 08:24:21 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D220C37C6@namail5.corp.adobe.com> In-Reply-To: <44D3CAB0.4020303@inode.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS performance (was Re: [Speermint] TLs performance) Thread-Index: Aca4Fb+NGKbtlFu7S9CH91mWfFcQ5QBUhssg From: "Henry Sinnreich" To: "Michael Haberler" X-OriginalArrivalTime: 06 Aug 2006 15:24:29.0553 (UTC) FILETIME=[68FB1610:01C6B96C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael, >I'm a bit lost which problem you're actually referring to Thanks for getting this in focus! I am trying to include the impact of numerous DNS lookups performed in an assumed peering scenario, when evaluating performance: Looking up the outbound proxy, ENUM, NAPTR, etc. in (1) the originating UA, (2) the (possibly two) SBCs and (3) the various SIP proxy's in the path. 1. How many lookups are there in various peering scenarios? 2. What is the delay due to the lookups? 3. What is the impact of caching and what if there is no caching? I don't expect a complete answer from you right now :-) but only wanted to point out this is not as trivial as was implied in previous messages. I guess some diagrams for various scenarios would provide better insight, and sure, some experimental results between real domains, with and without caching would be even more convincing. Henry=20 -----Original Message----- From: Michael Haberler [mailto:mah@inode.at]=20 Sent: Friday, August 04, 2006 3:31 PM To: Henry Sinnreich Cc: Klaus Darilion; speermint@ietf.org Subject: Re: DNS performance (was Re: [Speermint] TLs performance) Henry Sinnreich schrieb: > Thanks Klaus for the thorough analysis! > > I would only add to the observation: > > =20 >> further lookups for this domain will be cached in the DNS resolver >> =20 > server. > > In this case there is the risk that the cached DNS data is stale, and we > =20 how often do you change telcos? > may have an error condition.=20 an expired cache entry is not an error condition, it is a performance impact of a tradeoff decision between consistency and lookup time > Some mobile phone registrations may change > with the same speed or even faster than the DNS refresh from domain to > domain. > =20 the change driver on ENUM DNS entries is your porting frequency, not your change-of-celltower/wlan access - that's a sip proxy issue > I could not get a handle on this. Any thoughts on this, or even more > important, have any measurements been made to capture the effect of DNS > caching on mobility between domains? Or is the mobile provider prevalent > thinking that users will never change domains? :-) > =20 mobility between domains (if you're talking users changing providers for a domain) is standard ISP fare - user wants to change - reduce expiration timers - cutover - increase expiration timers - done I'm a bit lost which problem you're actually referring to -m > Thanks, Henry > =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Aug 06 12:38:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9le4-0002tc-BG; Sun, 06 Aug 2006 12:38:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9le2-0002tX-OT for speermint@ietf.org; Sun, 06 Aug 2006 12:38:30 -0400 Received: from [204.209.140.176] (helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9le0-0005D7-Ds for speermint@ietf.org; Sun, 06 Aug 2006 12:38:30 -0400 Received: from downstairs (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by wodka.aus-biz.com (Postfix) with ESMTP id 84BFB2E3F; Sun, 6 Aug 2006 12:36:32 -0400 (EDT) Subject: RE: DNS performance (was Re: [Speermint] TLs performance) From: Duane To: Henry Sinnreich In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D220C37C6@namail5.corp.adobe.com> References: <24CCCC428EFEA2469BF046DB3C7A8D220C37C6@namail5.corp.adobe.com> Content-Type: text/plain Date: Sun, 06 Aug 2006 12:38:21 -0400 Message-Id: <1154882301.10508.11.camel@downstairs> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Sun, 2006-08-06 at 08:24 -0700, Henry Sinnreich wrote: > 1. How many lookups are there in various peering scenarios? Can't really speak for others, however for e164.org: ;; Received 362 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 37 ms ;; Received 241 bytes from 204.74.112.1#53(TLD1.ULTRADNS.NET) in 46 ms ;; Received 310 bytes from 204.209.140.172#53(ns3.e164.org) in 64 ms We decided early not to allow NS records for other reasons, but it had the side effect of less NS lookups to obtain route information, or a failed query response. -- Best regards, Duane _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Aug 06 16:58:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9phe-0003Ur-LS; Sun, 06 Aug 2006 16:58:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9phd-0003Re-Ce for speermint@ietf.org; Sun, 06 Aug 2006 16:58:29 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G9phb-0004XW-UM for speermint@ietf.org; Sun, 06 Aug 2006 16:58:29 -0400 Received: from source ([192.150.20.142]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Sun, 06 Aug 2006 13:58:21 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k76KwOuv007091; Sun, 6 Aug 2006 13:58:25 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k76Kvw4Z020488; Sun, 6 Aug 2006 13:57:58 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Aug 2006 13:57:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DNS performance (was Re: [Speermint] TLs performance) Date: Sun, 6 Aug 2006 13:57:54 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D220C37D8@namail5.corp.adobe.com> In-Reply-To: <1154882301.10508.11.camel@downstairs> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS performance (was Re: [Speermint] TLs performance) Thread-Index: Aca5dsD52OPqKTniTxy5NJp7IBr6dAAI2EWw From: "Henry Sinnreich" To: "Duane" X-OriginalArrivalTime: 06 Aug 2006 20:57:58.0882 (UTC) FILETIME=[FF786420:01C6B99A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Thanks Duane, this is very encouraging.=20 These are local server responses. It seems propagation delays and occasional packet loss is not included. Have you also considered the scenario where DNS queries are made buy the SIP UA to find the outgoing SIP proxy, by a couple of SBCs in the path and by the incoming SIP proxy? What is the total number of DNS queries in some of such SPEERMINT scenarios? Thanks again, Henry -----Original Message----- From: Duane [mailto:duane@e164.org]=20 Sent: Sunday, August 06, 2006 9:38 AM To: Henry Sinnreich Cc: Michael Haberler; speermint@ietf.org Subject: RE: DNS performance (was Re: [Speermint] TLs performance) On Sun, 2006-08-06 at 08:24 -0700, Henry Sinnreich wrote: > 1. How many lookups are there in various peering scenarios? Can't really speak for others, however for e164.org: ;; Received 362 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 37 ms ;; Received 241 bytes from 204.74.112.1#53(TLD1.ULTRADNS.NET) in 46 ms ;; Received 310 bytes from 204.209.140.172#53(ns3.e164.org) in 64 ms We decided early not to allow NS records for other reasons, but it had the side effect of less NS lookups to obtain route information, or a failed query response. --=20 Best regards, Duane _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Aug 06 18:32:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9rAg-0003os-DP; Sun, 06 Aug 2006 18:32:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9rAf-0003ok-90 for speermint@ietf.org; Sun, 06 Aug 2006 18:32:33 -0400 Received: from [204.209.140.176] (helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9rAd-0006jD-W6 for speermint@ietf.org; Sun, 06 Aug 2006 18:32:33 -0400 Received: from downstairs (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by wodka.aus-biz.com (Postfix) with ESMTP id 90BE531FA; Sun, 6 Aug 2006 18:30:34 -0400 (EDT) Subject: RE: DNS performance (was Re: [Speermint] TLs performance) From: Duane To: Henry Sinnreich In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D220C37D8@namail5.corp.adobe.com> References: <24CCCC428EFEA2469BF046DB3C7A8D220C37D8@namail5.corp.adobe.com> Content-Type: text/plain Date: Sun, 06 Aug 2006 18:32:28 -0400 Message-Id: <1154903548.10508.20.camel@downstairs> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Sun, 2006-08-06 at 13:57 -0700, Henry Sinnreich wrote: > Thanks Duane, this is very encouraging. > These are local server responses. It seems propagation delays and > occasional packet loss is not included. Our updates occur basically once a minute, we don't send update out via AXFR, we use rsync instead, our most common TTL is set to 10 minutes > Have you also considered the scenario where DNS queries are made buy the > SIP UA to find the outgoing SIP proxy, by a couple of SBCs in the path > and by the incoming SIP proxy? As per my comment below, there is too many variables involved to state in a definitive way, examples of this also include people in South America and African regions having a lack of more direct access to the root servers etc. > What is the total number of DNS queries in some of such SPEERMINT > scenarios? That could vary wildly depending if you have SRV records, if it involves a country code and several sub zones and all that, or if it's hanging off the main root servers such as the gTLDs, and that's all assuming you don't have lookups occurring across multiple zones. -- Best regards, Duane _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Aug 06 22:13:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9ucV-0002hi-Rr; Sun, 06 Aug 2006 22:13:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9ucD-0002Yu-Es for speermint@ietf.org; Sun, 06 Aug 2006 22:13:13 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9uRv-0001ek-9D for speermint@ietf.org; Sun, 06 Aug 2006 22:02:36 -0400 Received: from PMelampy2 [68.189.242.21] by acmepacket.com with ESMTP (SMTPD-9.03) id AF430430; Sun, 06 Aug 2006 22:02:43 -0400 From: "Patrick Melampy" To: "'Henry Sinnreich'" , "'Duane'" Subject: RE: DNS performance (was Re: [Speermint] TLs performance) Date: Sun, 6 Aug 2006 22:02:32 -0400 Message-ID: <001101c6b9c5$8bfb5cc0$6401a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca5dsD52OPqKTniTxy5NJp7IBr6dAAI2EWwAArAgIA= In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D220C37D8@namail5.corp.adobe.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Henry --- I'm not sure there is an exact answer to your questions. It seems that like all DNS related activities, the intelligent caching and TTL management are keys for efficiency. If there is a peering situation, the only ENUM/DNS data that will NOT be cached in normal circumstances is the original ENUM query to get the NAPTR record that contains the full domain address (if found). Every other NAPTR and DNS record will most likely be in a local cache. The amount of cache hits would be increased as the number of adjacencies are kept to a reasonable number. So its possible that only one DNS transaction per call will be required. -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Sunday, August 06, 2006 4:58 PM To: Duane Cc: speermint@ietf.org Subject: RE: DNS performance (was Re: [Speermint] TLs performance) Thanks Duane, this is very encouraging. These are local server responses. It seems propagation delays and occasional packet loss is not included. Have you also considered the scenario where DNS queries are made buy the SIP UA to find the outgoing SIP proxy, by a couple of SBCs in the path and by the incoming SIP proxy? What is the total number of DNS queries in some of such SPEERMINT scenarios? Thanks again, Henry -----Original Message----- From: Duane [mailto:duane@e164.org] Sent: Sunday, August 06, 2006 9:38 AM To: Henry Sinnreich Cc: Michael Haberler; speermint@ietf.org Subject: RE: DNS performance (was Re: [Speermint] TLs performance) On Sun, 2006-08-06 at 08:24 -0700, Henry Sinnreich wrote: > 1. How many lookups are there in various peering scenarios? Can't really speak for others, however for e164.org: ;; Received 362 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 37 ms ;; Received 241 bytes from 204.74.112.1#53(TLD1.ULTRADNS.NET) in 46 ms ;; Received 310 bytes from 204.209.140.172#53(ns3.e164.org) in 64 ms We decided early not to allow NS records for other reasons, but it had the side effect of less NS lookups to obtain route information, or a failed query response. -- Best regards, Duane _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 07 01:57:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9y6x-0001RU-3q; Mon, 07 Aug 2006 01:57:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9y6w-0001RP-Ho for speermint@ietf.org; Mon, 07 Aug 2006 01:57:10 -0400 Received: from [86.59.12.252] (helo=sil1.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9y6v-0006ki-8a for speermint@ietf.org; Mon, 07 Aug 2006 01:57:10 -0400 Received: from ap2.stiwoll.mah.priv.at ([62.99.233.54] helo=[10.0.0.230]) by sil1.mah.priv.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1G9y6h-0001zO-Ap; Mon, 07 Aug 2006 07:56:55 +0200 Message-ID: <44D6D61E.4030400@inode.at> Date: Mon, 07 Aug 2006 07:56:46 +0200 From: Michael Haberler User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Patrick Melampy References: <001101c6b9c5$8bfb5cc0$6401a8c0@acmepacket.com> In-Reply-To: <001101c6b9c5$8bfb5cc0$6401a8c0@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 62.99.233.54 X-SA-Exim-Mail-From: mah@inode.at X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sil1.mah.priv.at X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Subject: Re: DNS performance (was Re: [Speermint] TLs performance) X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sil1.mah.priv.at) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Patrick Melampy schrieb: > ..kept to a reasonable number. So its possible that only one DNS transaction > per call will be required. > and this one is likely to come from a local replica of at least your country's worth of Infrastructure or private ENUM since I expect operators to run local copies (be it hidden secodanries or a database fed from the registry in some other way). so in the normal case (warm caches) you'd see no DNS interaction beyond your local caching server at all - pretty hard to beat by a DHT ;-) -Michael _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 07 11:13:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA6mt-0003d4-2D; Mon, 07 Aug 2006 11:13:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA6mr-0003bU-87 for speermint@ietf.org; Mon, 07 Aug 2006 11:13:01 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GA6eK-000746-8s for speermint@ietf.org; Mon, 07 Aug 2006 11:04:12 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-7.tower-121.messagelabs.com!1154962943!13657807!39 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 25378 invoked from network); 7 Aug 2006 15:04:07 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-7.tower-121.messagelabs.com with SMTP; 7 Aug 2006 15:04:07 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 44BA63B20034A2F1; Mon, 7 Aug 2006 11:04:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Secure RTP Date: Mon, 7 Aug 2006 11:04:04 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0D609477@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <02eb01c6b7df$30d4a4b0$9de6a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Secure RTP Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/AAABsDkAAAfWzgAJUuL3A= From: "Pfautz, Penn L, GBLAM" To: "Brian Rosen" , "Geoff Devine" , "Patrick Melampy" , "Michael Hammer \(mhammer\)" , "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Just one thing to be careful about in the American Idol situation - the call attempts don't get spread nicely across the busy hour. Media stimulated calling means getting all the load at once. The 1M calls looks more like 16K/s if you assume a minute is the time interval =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Friday, August 04, 2006 12:01 PM To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' Cc: speermint@ietf.org 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. =20 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. =20 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:gdevine@cedarpointcom.com] > Sent: Friday, August 04, 2006 11:35 AM > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); Hadriel Kaplan > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > 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. >=20 > Geoff >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, August 04, 2006 11:27 AM > To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > 'Hadriel Kaplan' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > 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. >=20 > Brian >=20 > > -----Original Message----- > > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > > Sent: Friday, August 04, 2006 11:01 AM > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); Hadriel > Kaplan > > Cc: speermint@ietf.org > > 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:br@brianrosen.net] > > Sent: Friday, August 04, 2006 10:20 AM > > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > Cc: speermint@ietf.org > > 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:PMelampy@acmepacket.com] > > > Sent: Friday, August 04, 2006 9:59 AM > > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > Cc: speermint@ietf.org > > > 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:br@brianrosen.net] > > > Sent: Friday, August 04, 2006 8:47 AM > > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > Cc: speermint@ietf.org > > > 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:mhammer@cisco.com] > > > > Sent: Thursday, August 03, 2006 3:13 PM > > > > To: Hadriel Kaplan; Brian Rosen > > > > Cc: speermint@ietf.org > > > > 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 > 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 Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 07 12:19:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA7pF-0002aT-0H; Mon, 07 Aug 2006 12:19:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA7pE-0002aO-6V for speermint@ietf.org; Mon, 07 Aug 2006 12:19:32 -0400 Received: from morbo.e-centre.net ([66.154.82.3] helo=cubert.e-centre.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA7pB-0002b7-4D for speermint@ietf.org; Mon, 07 Aug 2006 12:19:32 -0400 Received: from [10.3.1.19] (helo=barracuda2.stayonline.net) by cubert.e-centre.net with esmtp (Exim 4.50) id 1GA7pA-0003ah-GJ; Mon, 07 Aug 2006 12:19:28 -0400 X-ASG-Debug-ID: 1154967567-20456-29-0 X-Barracuda-URL: http://10.3.1.19:8000/cgi-bin/mark.cgi Received: from et-den-4.site.stayonline.net (unknown [66.198.222.2]) by barracuda2.stayonline.net (Spam Firewall) with ESMTP id 49FDE43CC74; Mon, 7 Aug 2006 12:19:28 -0400 (EDT) Received: from RSHOCKEYLTXP ([172.16.2.249]) by et-den-4.site.stayonline.net (8.12.6/8.12.6) with ESMTP id k77GIwQt023941; Mon, 7 Aug 2006 16:19:03 GMT From: "Richard Shockey" To: "'Michael Haberler'" , "'Patrick Melampy'" X-ASG-Orig-Subj: RE: DNS performance (was Re: [Speermint] TLs performance) Subject: RE: DNS performance (was Re: [Speermint] TLs performance) Date: Mon, 7 Aug 2006 12:19:08 -0400 Message-ID: <014a01c6ba3d$3a72a0c0$f90210ac@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Aca55mJVa0QHZsqbS6Cb/S2frT8+nwAVaOrg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44D6D61E.4030400@inode.at> X-Virus-Scanned: by Barracuda Spam Firewall at stayonline.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=4.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.18524 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael is entirely correct here... the may not be about the DNS at all but the ancillary use of DNS technology locally cached to maintain a full copy of a trusted routing registry. There are going to be various forms of routing data that will need to be either aggregated ( local cache) or queried (classic DNS) depending on the circumstances. The key discovery part of SPEERMINT is, perhaps, not about ENUM at all but the role of a trusted registry(s) and how is that data accessed. The local cache maintains fairly static number translation data necessary to complete a call either on the PSTN or IP end to end. This could include things like LNP under certain conditions. Basic mappings like TN to SIP AOR (point of interconnection) will not change that often. Internal network routing will probably be placed in these registries only validated. > -----Original Message----- > From: Michael Haberler [mailto:mah@inode.at] > Sent: Monday, August 07, 2006 1:57 AM > To: Patrick Melampy > Cc: speermint@ietf.org > Subject: Re: DNS performance (was Re: [Speermint] TLs performance) > > Patrick Melampy schrieb: > > ..kept to a reasonable number. So its possible that only one DNS > transaction > > per call will be required. > > > and this one is likely to come from a local replica of at least your > country's worth of Infrastructure or private ENUM since I expect > operators to run local copies (be it hidden secodanries or a database > fed from the registry in some other way). > > so in the normal case (warm caches) you'd see no DNS interaction beyond > your local caching server at all - pretty hard to beat by a DHT ;-) > > -Michael > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 07 17:08:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GACL3-0000nN-EZ; Mon, 07 Aug 2006 17:08:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GACL2-0000nI-6r for speermint@ietf.org; Mon, 07 Aug 2006 17:08:40 -0400 Received: from pne-smtpout2-sn1.fre.skanova.net ([81.228.11.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GACL0-00051O-RS for speermint@ietf.org; Mon, 07 Aug 2006 17:08:40 -0400 Received: from Misan (213.64.228.153) by pne-smtpout2-sn1.fre.skanova.net (7.2.075) id 44A135F10080FB8C for speermint@ietf.org; Mon, 7 Aug 2006 23:08:38 +0200 From: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= To: "speermint" Date: Mon, 7 Aug 2006 22:08:36 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [Speermint] Media requirements in draft-ietf-speermint-requirements-00 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1207596663==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1207596663== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BB_01C6BA6E.07EF73E0" This is a multi-part message in MIME format. ------=_NextPart_000_01BB_01C6BA6E.07EF73E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is a media section 3.3 in draft-ietf-speermint-requirements-00.txt (http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-00= .txt) Currently it only specifies default audio codecs. >From PSTN there is an important tradition to also carry real-time text = as part of the telephony service. Thus also for speermint, the default codec for real-time text should be = supported. The default codec mentioned in a number of other IETF specs is T.140, = with RTP transport as dfefined in RFC 4103. I suggest inserting a new bullet point in section 3.3 - the support of a compatible real-time text codec between communication = peers; the T.140 transported as specified in RFC 4103 MUST be supported. =20 I do not see any reason to limit the specification to audio in VoIP. At = least text and video should be included in this specification.=20 Regards Gunnar Hellstr=C3=B6m gunnar.hellstrom@omnitor.se =20 ------=_NextPart_000_01BB_01C6BA6E.07EF73E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF

There is = a media=20 section 3.3 in = draft-ietf-speermint-requirements-00.txt

(http://www.ietf.org/internet-drafts/draft-i= etf-speermint-requirements-00.txt)

Currently = it only=20 specifies default audio codecs.

From PSTN = there is an=20 important tradition to also carry real-time text as part of the = telephony=20 service.

Thus also = for=20 speermint, the default codec for real-time text should be=20 supported.

The = default codec=20 mentioned in a number of other IETF specs is T.140, with RTP = transport as=20 dfefined in RFC 4103.

I suggest = inserting a=20 new bullet point in section 3.3

- the support of a compatible = real-time text=20 codec between communication peers; the
   T.140 = transported as=20 specified in RFC 4103 MUST be supported.

 

I do not = see any=20 reason to limit the specification to audio in VoIP. At least text = and video=20 should be included in this specification. 

Regards

Gunnar=20 Hellstr=C3=B6m

gunnar.hellstrom@omnitor.se
 =20

 
------=_NextPart_000_01BB_01C6BA6E.07EF73E0-- --===============1207596663== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1207596663==-- From speermint-bounces@ietf.org Mon Aug 07 17:47:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GACwk-0006uM-Fy; Mon, 07 Aug 2006 17:47:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GACwk-0006uH-0H for speermint@ietf.org; Mon, 07 Aug 2006 17:47:38 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GACwi-0006ir-CF for speermint@ietf.org; Mon, 07 Aug 2006 17:47:37 -0400 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Mon, 07 Aug 2006 14:47:33 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k77Lleuv021505; Mon, 7 Aug 2006 14:47:47 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k77LlGR2002378; Mon, 7 Aug 2006 14:47:24 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Aug 2006 14:47:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speermint] Media requirements indraft-ietf-speermint-requirements-00 Date: Mon, 7 Aug 2006 14:47:16 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D220C3886@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Media requirements indraft-ietf-speermint-requirements-00 Thread-Index: Aca6ZbSy7r6XXAX8RjeLR7RIjlr+BgAATarQ From: "Henry Sinnreich" To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= , "speermint" X-OriginalArrivalTime: 07 Aug 2006 21:47:16.0896 (UTC) FILETIME=[0CFF4200:01C6BA6B] X-Spam-Score: 1.1 (+) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0680824104==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0680824104== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6BA6B.0C85BE80" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BA6B.0C85BE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gunnar, =20 > I do not see any reason to limit the specification to audio in=20 > VoIP. At least text and video should be included in this=20 > specification. =20 This is an excellent point and let's hope the SPEERMINT EG will accept = it. =20 Henry =20 ________________________________ From: Gunnar Hellstr=F6m [mailto:gunnar.hellstrom@omnitor.se]=20 Sent: Monday, August 07, 2006 2:09 PM To: speermint Subject: [Speermint] Media requirements = indraft-ietf-speermint-requirements-00 =20 There is a media section 3.3 in draft-ietf-speermint-requirements-00.txt (http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-00= .txt = ) Currently it only specifies default audio codecs. >From PSTN there is an important tradition to also carry real-time text = as part of the telephony service. Thus also for speermint, the default codec for real-time text should be = supported. The default codec mentioned in a number of other IETF specs is T.140, = with RTP transport as dfefined in RFC 4103. I suggest inserting a new bullet point in section 3.3 - the support of a compatible real-time text codec between communication = peers; the T.140 transported as specified in RFC 4103 MUST be supported. =20 I do not see any reason to limit the specification to audio in VoIP. At = least text and video should be included in this specification.=20 Regards Gunnar Hellstr=F6m gunnar.hellstrom@omnitor.se =20 =20 ------_=_NextPart_001_01C6BA6B.0C85BE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Gunnar,

=

 

> I do not see any reason to limit the specification to audio in

> VoIP. At least text and video should be included in this

> = specification.

 

This is an excellent point and let’s = hope the SPEERMINT EG will accept it.

 

Henry

 

From: = Gunnar Hellstr=F6m [mailto:gunnar.hellstrom@omnitor.se]
Sent: Monday, August 07, = 2006 2:09 PM
To: speermint
Subject: [Speermint] = Media requirements = indraft-ietf-speermint-requirements-00

 

There is a media section 3.3 in draft-ietf-speermint-requirements-00.txt

(http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirement= s-00.txt)

Currently it only specifies default audio = codecs.

From PSTN there is an important tradition to also = carry real-time text as part of the telephony = service.

Thus also for speermint, the default codec for real-time = text should be supported.

The default codec mentioned in a number of other = IETF specs is T.140, with RTP transport as dfefined in RFC = 4103.

I suggest inserting a new bullet point in section = 3.3

- the support of a compatible real-time text codec between communication = peers; the
   T.140 transported as specified in RFC 4103 MUST = be supported.

 

I do not see any reason to limit the specification = to audio in VoIP. At least text and video should be included in this specification. 

Regards

Gunnar Hellstr=F6m

gunnar.hellstrom@omnitor.se
 

 

------_=_NextPart_001_01C6BA6B.0C85BE80-- --===============0680824104== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0680824104==-- From speermint-bounces@ietf.org Mon Aug 07 18:51:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GADwP-00009k-Lq; Mon, 07 Aug 2006 18:51:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GADwO-00009f-Nc for speermint@ietf.org; Mon, 07 Aug 2006 18:51:20 -0400 Received: from ns.xittelecom.com ([205.151.16.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GADwN-0007cW-Es for speermint@ietf.org; Mon, 07 Aug 2006 18:51:20 -0400 Received: from fmenard (helo=localhost) by ns.xittelecom.com with local-esmtp (Exim 3.36 #1 (Debian)) id 1GADw3-0007JQ-00; Mon, 07 Aug 2006 17:50:59 -0500 Date: Mon, 7 Aug 2006 17:50:59 -0500 (EST) From: Francois Menard X-X-Sender: fmenard@localhost To: Richard Shockey Subject: RE: DNS performance (was Re: [Speermint] TLs performance) In-Reply-To: <014a01c6ba3d$3a72a0c0$f90210ac@cis.neustar.com> Message-ID: References: <014a01c6ba3d$3a72a0c0$f90210ac@cis.neustar.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I guess it all depends on how realtime you want your LNP to be... F. -- Francois D. Menard Project Manager/Charge de projet Xit telecom inc. 1350 Royale # 800 Trois-Rivieres, QC, G9A 4J4 Tel: +1 819 374 2556 x 268 Cell: +1 819 692 1383 fmenard@xittelecom.com On Mon, 7 Aug 2006, Richard Shockey wrote: > > Michael is entirely correct here... the may not be about the DNS at all but > the ancillary use of DNS technology locally cached to maintain a full copy > of a trusted routing registry. There are going to be various forms of > routing data that will need to be either aggregated ( local cache) or > queried (classic DNS) depending on the circumstances. > > The key discovery part of SPEERMINT is, perhaps, not about ENUM at all but > the role of a trusted registry(s) and how is that data accessed. > > The local cache maintains fairly static number translation data necessary to > complete a call either on the PSTN or IP end to end. This could include > things like LNP under certain conditions. > > Basic mappings like TN to SIP AOR (point of interconnection) will not change > that often. Internal network routing will probably be placed in these > registries only validated. > > >> -----Original Message----- >> From: Michael Haberler [mailto:mah@inode.at] >> Sent: Monday, August 07, 2006 1:57 AM >> To: Patrick Melampy >> Cc: speermint@ietf.org >> Subject: Re: DNS performance (was Re: [Speermint] TLs performance) >> >> Patrick Melampy schrieb: >>> ..kept to a reasonable number. So its possible that only one DNS >> transaction >>> per call will be required. >>> >> and this one is likely to come from a local replica of at least your >> country's worth of Infrastructure or private ENUM since I expect >> operators to run local copies (be it hidden secodanries or a database >> fed from the registry in some other way). >> >> so in the normal case (warm caches) you'd see no DNS interaction beyond >> your local caching server at all - pretty hard to beat by a DHT ;-) >> >> -Michael >> >> >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 07 20:17:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAFHd-000260-PJ; Mon, 07 Aug 2006 20:17:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAFHc-00025R-FE for speermint@ietf.org; Mon, 07 Aug 2006 20:17:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAEMx-0004FT-JX for speermint@ietf.org; Mon, 07 Aug 2006 19:18:47 -0400 Received: from [204.209.140.176] (helo=wodka.aus-biz.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAE9J-0006qU-9T for speermint@ietf.org; Mon, 07 Aug 2006 19:04:46 -0400 Received: from downstairs (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by wodka.aus-biz.com (Postfix) with ESMTP id C49E3323F; Mon, 7 Aug 2006 19:02:25 -0400 (EDT) Subject: RE: DNS performance (was Re: [Speermint] TLs performance) From: Duane To: Francois Menard In-Reply-To: References: <014a01c6ba3d$3a72a0c0$f90210ac@cis.neustar.com> Content-Type: text/plain Date: Mon, 07 Aug 2006 19:04:25 -0400 Message-Id: <1154991865.10508.56.camel@downstairs> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.8 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Mon, 2006-08-07 at 17:50 -0500, Francois Menard wrote: > I guess it all depends on how realtime you want your LNP to be... I doubt carriers anywhere would give you a time to change over in minutes, it would be closer to hours, so even having a 10 to 30 minutes TTL wouldn't harm things from LNP point of view... -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 07 21:11:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAG7a-0006i4-1F; Mon, 07 Aug 2006 21:11:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAG7Y-0006hx-Va for speermint@ietf.org; Mon, 07 Aug 2006 21:11:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAG7Y-0003L2-U0 for speermint@ietf.org; Mon, 07 Aug 2006 21:11:00 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAG7X-0000YC-9Z for speermint@ietf.org; Mon, 07 Aug 2006 21:11:00 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns3.neustar.com (Postfix) with ESMTP id 14C181759A; Tue, 8 Aug 2006 01:10:29 +0000 (GMT) Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Aug 2006 21:10:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DNS performance (was Re: [Speermint] TLs performance) Date: Mon, 7 Aug 2006 21:10:29 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS performance (was Re: [Speermint] TLs performance) Thread-Index: Aca6gAoVu4Ut71D3RySODfZaIVXfaAABfomw From: "Foster, Mark" To: "Duane" , "Francois Menard" X-OriginalArrivalTime: 08 Aug 2006 01:10:28.0620 (UTC) FILETIME=[6FD4B4C0:01C6BA87] X-Spam-Score: -5.9 (-----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Mon, 2006-08-07 at 19:04 -0500, Duane wrote: > > I guess it all depends on how realtime you want your LNP to be... >=20 > I doubt carriers anywhere would give you a time to change over in > minutes, it would be closer to hours, so even having a 10 to 30 minutes > TTL wouldn't harm things from LNP point of view... Well, in the US, carriers are required to propagate all NP routing changes within 15 min, but in practice usually do it in seconds to minimize potential SS7 routing loops. R, Mark -------------------------------------------------------------------- Mark D Foster | CTO, Co-Founder NeuStar, Inc. | 46000 Center Oak Plaza | Sterling, VA 20166 USA p: +1 571 434 5410 | f: +1 571 434 5489 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 05:51:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAOF3-00073X-Cg; Tue, 08 Aug 2006 05:51:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAOF2-00073P-3M for speermint@ietf.org; Tue, 08 Aug 2006 05:51:16 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=MAILSRV01.cedarpointcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAOEx-0001hG-PQ for speermint@ietf.org; Tue, 08 Aug 2006 05:51:16 -0400 Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 05:50:11 -0400 Content-class: urn:content-classes:message Subject: RE: DNS performance (was Re: [Speermint] TLs performance) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Aug 2006 05:50:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <402F25FC1EB2BD44831F8A4A4F6DF94203A688@MAIL02.cedarpointcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS performance (was Re: [Speermint] TLs performance) Thread-Index: Aca6gA59veXwMjYLQBGcjyq+JWnWUQATjTm+ References: <014a01c6ba3d$3a72a0c0$f90210ac@cis.neustar.com> <1154991865.10508.56.camel@downstairs> From: "Geoff Devine" To: "Duane" , "Francois Menard" X-OriginalArrivalTime: 08 Aug 2006 09:50:11.0056 (UTC) FILETIME=[0A02D700:01C6BAD0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org That's not the way LNP works today. =20 Class 5 offices have temporary triggers for the window where a number is = being ported. The definitive location of the subscriber is kept in the = LNP database. When that database is updated, all calls route to the = ported destination. You're violating the LNP requirements if you route = the call to the wrong class 5 switch after the LNP database has changed. = =20 There are 300 million telephone numbers in the United States. It's = unlikely many of them will be in a cache. This isn't like caching = "google.com". Geoff -----Original Message----- From: Duane [mailto:duane@e164.org] Sent: Mon 8/7/2006 7:04 PM To: Francois Menard Cc: speermint@ietf.org Subject: RE: DNS performance (was Re: [Speermint] TLs performance) =20 On Mon, 2006-08-07 at 17:50 -0500, Francois Menard wrote: > I guess it all depends on how realtime you want your LNP to be... I doubt carriers anywhere would give you a time to change over in minutes, it would be closer to hours, so even having a 10 to 30 minutes TTL wouldn't harm things from LNP point of view... --=20 Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 06:07:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAOUp-0007Qv-At; Tue, 08 Aug 2006 06:07:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAOUo-0007Qq-N5 for speermint@ietf.org; Tue, 08 Aug 2006 06:07:34 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAOUm-00056X-9S for speermint@ietf.org; Tue, 08 Aug 2006 06:07:34 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 4026321009F; Tue, 8 Aug 2006 12:07:31 +0200 (CEST) Message-ID: <44D86271.6050907@pernau.at> Date: Tue, 08 Aug 2006 12:07:45 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Geoff Devine Subject: Re: DNS performance (was Re: [Speermint] TLs performance) References: <014a01c6ba3d$3a72a0c0$f90210ac@cis.neustar.com> <1154991865.10508.56.camel@downstairs> <402F25FC1EB2BD44831F8A4A4F6DF94203A688@MAIL02.cedarpointcom.com> In-Reply-To: <402F25FC1EB2BD44831F8A4A4F6DF94203A688@MAIL02.cedarpointcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Geoff Devine wrote: > That's not the way LNP works today. > > Class 5 offices have temporary triggers for the window where a number > is being ported. The definitive location of the subscriber is kept > in the LNP database. When that database is updated, all calls route > to the ported destination. You're violating the LNP requirements if > you route the call to the wrong class 5 switch after the LNP database > has changed. Thus, for each call the central LNP database is queried? regards klaus > > There are 300 million telephone numbers in the United States. It's > unlikely many of them will be in a cache. This isn't like caching > "google.com". > > Geoff > > -----Original Message----- From: Duane [mailto:duane@e164.org] Sent: > Mon 8/7/2006 7:04 PM To: Francois Menard Cc: speermint@ietf.org > Subject: RE: DNS performance (was Re: [Speermint] TLs performance) > > On Mon, 2006-08-07 at 17:50 -0500, Francois Menard wrote: >> I guess it all depends on how realtime you want your LNP to be... > > I doubt carriers anywhere would give you a time to change over in > minutes, it would be closer to hours, so even having a 10 to 30 > minutes TTL wouldn't harm things from LNP point of view... > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 06:39:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAOzx-0006Iz-NK; Tue, 08 Aug 2006 06:39:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAOzw-0006Ik-P9 for speermint@ietf.org; Tue, 08 Aug 2006 06:39:44 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=MAILSRV01.cedarpointcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAOzv-0001EC-CI for speermint@ietf.org; Tue, 08 Aug 2006 06:39:44 -0400 Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 06:39:41 -0400 Content-class: urn:content-classes:message Subject: RE: DNS performance (was Re: [Speermint] TLs performance) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Aug 2006 06:39:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <402F25FC1EB2BD44831F8A4A4F6DF94203A68A@MAIL02.cedarpointcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS performance (was Re: [Speermint] TLs performance) Thread-Index: Aca60nb+ZtX46VgHQ/uBx18FHv3pmgAAj2CL References: <014a01c6ba3d$3a72a0c0$f90210ac@cis.neustar.com> <1154991865.10508.56.camel@downstairs> <402F25FC1EB2BD44831F8A4A4F6DF94203A688@MAIL02.cedarpointcom.com> <44D86271.6050907@pernau.at> From: "Geoff Devine" To: "Klaus Darilion" X-OriginalArrivalTime: 08 Aug 2006 10:39:41.0662 (UTC) FILETIME=[F4A157E0:01C6BAD6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org In the US? Yes. A centralized LNP database is queried. In many other countries, a huge file is distributed once per day. = Welcome to the stone age. Geoff -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Sent: Tue 8/8/2006 6:07 AM To: Geoff Devine Cc: Duane; Francois Menard; speermint@ietf.org Subject: Re: DNS performance (was Re: [Speermint] TLs performance) =20 Geoff Devine wrote: > That's not the way LNP works today. >=20 > Class 5 offices have temporary triggers for the window where a number > is being ported. The definitive location of the subscriber is kept > in the LNP database. When that database is updated, all calls route > to the ported destination. You're violating the LNP requirements if > you route the call to the wrong class 5 switch after the LNP database > has changed. Thus, for each call the central LNP database is queried? regards klaus >=20 > There are 300 million telephone numbers in the United States. It's > unlikely many of them will be in a cache. This isn't like caching > "google.com". >=20 > Geoff >=20 > -----Original Message----- From: Duane [mailto:duane@e164.org] Sent: > Mon 8/7/2006 7:04 PM To: Francois Menard Cc: speermint@ietf.org=20 > Subject: RE: DNS performance (was Re: [Speermint] TLs performance) >=20 > On Mon, 2006-08-07 at 17:50 -0500, Francois Menard wrote: >> I guess it all depends on how realtime you want your LNP to be... >=20 > I doubt carriers anywhere would give you a time to change over in=20 > minutes, it would be closer to hours, so even having a 10 to 30 > minutes TTL wouldn't harm things from LNP point of view... >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 08:54:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAR6d-0004nT-Au; Tue, 08 Aug 2006 08:54:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAR6b-0004nO-As for speermint@ietf.org; Tue, 08 Aug 2006 08:54:45 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAR6a-0000Bc-0x for speermint@ietf.org; Tue, 08 Aug 2006 08:54:45 -0400 Received: from [10.10.0.107] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Tue, 08 Aug 2006 14:54:40 +0200 id 0007C094.44D88990.00004A08 Message-ID: <44D88959.4040806@enum.at> Date: Tue, 08 Aug 2006 14:53:45 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: "=?UTF-8?B?R3VubmFyIEhlbGxzdHLDtm0=?=" Subject: Re: [Speermint] Media requirements in draft-ietf-speermint-requirements-00 References: In-Reply-To: X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.47 X-Spam-Score: 1.1 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Gunnar Hellstr=C3=B6m wrote: > There is a media section 3.3 in draft-ietf-speermint-requirements-00.t= xt > > (http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements= -00.txt) > > Currently it only specifies default audio codecs. > >>From PSTN there is an important tradition to also carry real-time text= as part of the telephony service. > > Thus also for speermint, the default codec for real-time text should b= e supported. Well, 1) currently the Introduction section says "... minimum set of requirements= for SIP-based _VoIP_ interconnection ..." (as well as the title). If we add eg. text, video, etc. we'd probably also need to change this i= nto "... SIP-based multimedia interconnection ...". 2) The text says those are "minimum" requirements. Anything that we shove i= nto that "minimum" as a MUST means that compliant implementations need to implement this, thus reducing the number of compliant implementations. I'll strongly vote to not bloat the "minimum requirements" - even more, = i'd try to keep those to the "very bare minimum requirements" wherever possi= ble. just my 2c Alex _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 09:18:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GARTG-0001bz-DN; Tue, 08 Aug 2006 09:18:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GARTE-0001bu-Bl for speermint@ietf.org; Tue, 08 Aug 2006 09:18:08 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GARTB-0005gB-UL for speermint@ietf.org; Tue, 08 Aug 2006 09:18:08 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1155042831!9235061!59 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 25800 invoked from network); 8 Aug 2006 13:18:04 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-6.tower-120.messagelabs.com with SMTP; 8 Aug 2006 13:18:04 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 44BA63B200374F6F; Tue, 8 Aug 2006 09:18:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Media requirementsin draft-ietf-speermint-requirements-00 Date: Tue, 8 Aug 2006 09:18:00 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0D646F74@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <44D88959.4040806@enum.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Media requirementsin draft-ietf-speermint-requirements-00 Thread-Index: Aca66dvFZlNSwdhTQTm3IlYD7i/kvQAAwwIA From: "Pfautz, Penn L, GBLAM" To: "Alexander Mayrhofer" , =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= X-Spam-Score: 1.1 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I agree with Alex. Only some telephony applications carry real-time = text.=20 -----Original Message----- From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at]=20 Sent: Tuesday, August 08, 2006 8:54 AM To: Gunnar Hellstr=F6m Cc: speermint Subject: Re: [Speermint] Media requirementsin = draft-ietf-speermint-requirements-00 Gunnar Hellstr=F6m wrote: > There is a media section 3.3 in = draft-ietf-speermint-requirements-00.txt >=20 > = (http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-00= .txt) >=20 > Currently it only specifies default audio codecs. >=20 >>From PSTN there is an important tradition to also carry real-time text = as part of the telephony service. >=20 > Thus also for speermint, the default codec for real-time text should = be supported. Well, 1) currently the Introduction section says "... minimum set of requirements = for SIP-based _VoIP_ interconnection ..." (as well as the title). If we add eg. text, video, etc. we'd probably also need to change this = into "... SIP-based multimedia interconnection ...". 2) The text says those are "minimum" requirements. Anything that we shove = into that "minimum" as a MUST means that compliant implementations need to implement this, thus reducing the number of compliant implementations. I'll strongly vote to not bloat the "minimum requirements" - even more, = i'd try to keep those to the "very bare minimum requirements" wherever = possible. just my 2c Alex _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 09:33:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GARiU-0006aI-6m; Tue, 08 Aug 2006 09:33:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GARiS-0006aD-IO for speermint@ietf.org; Tue, 08 Aug 2006 09:33:52 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GARiQ-00080c-79 for speermint@ietf.org; Tue, 08 Aug 2006 09:33:52 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GARiF-0007j3-2O; Tue, 08 Aug 2006 08:33:41 -0500 From: "Brian Rosen" To: "'Pfautz, Penn L, GBLAM'" , "'Alexander Mayrhofer'" , =?iso-8859-1?Q?'Gunnar_Hellstr=F6m'?= Subject: RE: [Speermint] Mediarequirementsin draft-ietf-speermint-requirements-00 Date: Tue, 8 Aug 2006 09:33:38 -0400 Message-ID: <07a601c6baef$4557f460$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca66dvFZlNSwdhTQTm3IlYD7i/kvQAAwwIAAAAsksA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0D646F74@ACCLUST02EVS1.ugd.att.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.1 (+) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: 'speermint' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Haven't we learned this lesson, and isn't the cost now low enough that = we can stop this argument? Every place you have audio, you could have = text, either interactive or message based. It's not unreasonable to require the interactive text codec be supported across the spectrum of interconnects, so that people who can't hear can = use the systems we build. In this context, supporting the text codec (as = long as there is only one to be concerned about, which is the case) = everywhere audio is supported is roughly zero cost in the peering system. It costs more to argue about it that it does to support it in the peering system. You have a better chance at not specifying a minimal video codec, = although as I keep repeating, SPEERMINT is not intended to be the playground of = soley the video impaired crowd. We need to recognize this. Likewise minimum codec for an IM peering exchange does not have audio in it. I'm really tired of people essentially saying "yes, yes, of course, but we REALLY = know this is for voice, that's where the money is". Sorry, money or not, = peering is for text (including IM) and video, and any other media that comes on through. There cannot be a SPEERMINT specified minimum codec set unless = it is qualified like "if voice is supported at all, then at least ...." Brian > -----Original Message----- > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > Sent: Tuesday, August 08, 2006 9:18 AM > To: Alexander Mayrhofer; Gunnar Hellstr=F6m > Cc: speermint > Subject: RE: [Speermint] Mediarequirementsin draft-ietf-speermint- > requirements-00 >=20 > I agree with Alex. Only some telephony applications carry real-time = text. >=20 > -----Original Message----- > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > Sent: Tuesday, August 08, 2006 8:54 AM > To: Gunnar Hellstr=F6m > Cc: speermint > Subject: Re: [Speermint] Media requirementsin draft-ietf-speermint- > requirements-00 >=20 > Gunnar Hellstr=F6m wrote: > > There is a media section 3.3 in = draft-ietf-speermint-requirements-00.txt > > > > = (http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements- > 00.txt) > > > > Currently it only specifies default audio codecs. > > > >>From PSTN there is an important tradition to also carry real-time = text > as part of the telephony service. > > > > Thus also for speermint, the default codec for real-time text should = be > supported. >=20 > Well, >=20 > 1) >=20 > currently the Introduction section says "... minimum set of = requirements > for > SIP-based _VoIP_ interconnection ..." (as well as the title). >=20 > If we add eg. text, video, etc. we'd probably also need to change this > into > "... SIP-based multimedia interconnection ...". >=20 > 2) >=20 > The text says those are "minimum" requirements. Anything that we shove > into > that "minimum" as a MUST means that compliant implementations need to > implement this, thus reducing the number of compliant implementations. >=20 > I'll strongly vote to not bloat the "minimum requirements" - even = more, > i'd > try to keep those to the "very bare minimum requirements" wherever > possible. >=20 > just my 2c >=20 > Alex >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 09:41:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GARqG-0004P3-5U; Tue, 08 Aug 2006 09:41:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GARqE-0004Ov-Fy for speermint@ietf.org; Tue, 08 Aug 2006 09:41:54 -0400 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GARqC-0000Ta-5z for speermint@ietf.org; Tue, 08 Aug 2006 09:41:54 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-11.tower-146.messagelabs.com!1155044459!393721!12 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 9664 invoked from network); 8 Aug 2006 13:41:50 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-11.tower-146.messagelabs.com with SMTP; 8 Aug 2006 13:41:50 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 44BA63B200376371; Tue, 8 Aug 2006 09:41:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Mediarequirementsin draft-ietf-speermint-requirements-00 Date: Tue, 8 Aug 2006 09:41:47 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0D646FE9@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <07a601c6baef$4557f460$9de6a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Mediarequirementsin draft-ietf-speermint-requirements-00 Thread-Index: Aca66dvFZlNSwdhTQTm3IlYD7i/kvQAAwwIAAAAsksAAAI8X8A== From: "Pfautz, Penn L, GBLAM" To: "Brian Rosen" , "Alexander Mayrhofer" , =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= X-Spam-Score: 1.1 (+) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian: Let me be clear. I'm not trying to exclude anything - and I don't think = we should be in the business of specifying voice codecs either. Let us = provide mechanisms for negotiation for supporting capabilities if = providers want to make use of them but to think that Speermint is going = to determine that all peering arrangements must support a particular = media type is just kidding ourselves. Penn -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, August 08, 2006 9:34 AM To: Pfautz, Penn L, GBLAM; 'Alexander Mayrhofer'; 'Gunnar Hellstr=F6m' Cc: 'speermint' Subject: RE: [Speermint] Mediarequirementsin = draft-ietf-speermint-requirements-00 Haven't we learned this lesson, and isn't the cost now low enough that = we can stop this argument? Every place you have audio, you could have = text, either interactive or message based. It's not unreasonable to require the interactive text codec be supported across the spectrum of interconnects, so that people who can't hear can = use the systems we build. In this context, supporting the text codec (as = long as there is only one to be concerned about, which is the case) = everywhere audio is supported is roughly zero cost in the peering system. It costs more to argue about it that it does to support it in the peering system. You have a better chance at not specifying a minimal video codec, = although as I keep repeating, SPEERMINT is not intended to be the playground of = soley the video impaired crowd. We need to recognize this. Likewise minimum codec for an IM peering exchange does not have audio in it. I'm really tired of people essentially saying "yes, yes, of course, but we REALLY = know this is for voice, that's where the money is". Sorry, money or not, = peering is for text (including IM) and video, and any other media that comes on through. There cannot be a SPEERMINT specified minimum codec set unless = it is qualified like "if voice is supported at all, then at least ...." Brian > -----Original Message----- > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > Sent: Tuesday, August 08, 2006 9:18 AM > To: Alexander Mayrhofer; Gunnar Hellstr=F6m > Cc: speermint > Subject: RE: [Speermint] Mediarequirementsin draft-ietf-speermint- > requirements-00 >=20 > I agree with Alex. Only some telephony applications carry real-time = text. >=20 > -----Original Message----- > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > Sent: Tuesday, August 08, 2006 8:54 AM > To: Gunnar Hellstr=F6m > Cc: speermint > Subject: Re: [Speermint] Media requirementsin draft-ietf-speermint- > requirements-00 >=20 > Gunnar Hellstr=F6m wrote: > > There is a media section 3.3 in = draft-ietf-speermint-requirements-00.txt > > > > = (http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements- > 00.txt) > > > > Currently it only specifies default audio codecs. > > > >>From PSTN there is an important tradition to also carry real-time = text > as part of the telephony service. > > > > Thus also for speermint, the default codec for real-time text should = be > supported. >=20 > Well, >=20 > 1) >=20 > currently the Introduction section says "... minimum set of = requirements > for > SIP-based _VoIP_ interconnection ..." (as well as the title). >=20 > If we add eg. text, video, etc. we'd probably also need to change this > into > "... SIP-based multimedia interconnection ...". >=20 > 2) >=20 > The text says those are "minimum" requirements. Anything that we shove > into > that "minimum" as a MUST means that compliant implementations need to > implement this, thus reducing the number of compliant implementations. >=20 > I'll strongly vote to not bloat the "minimum requirements" - even = more, > i'd > try to keep those to the "very bare minimum requirements" wherever > possible. >=20 > just my 2c >=20 > Alex >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 09:57:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAS4w-0003eF-RC; Tue, 08 Aug 2006 09:57:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAS4v-0003dm-1u for speermint@ietf.org; Tue, 08 Aug 2006 09:57:05 -0400 Received: from pmesmtp04.mci.com ([199.249.20.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAS4s-0002Qp-Lx for speermint@ietf.org; Tue, 08 Aug 2006 09:57:05 -0400 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0J3O00FEDMOTV2@firewall.mci.com> for speermint@ietf.org; Tue, 08 Aug 2006 13:55:41 +0000 (GMT) Received: from dgismtp06.wcomnet.com ([127.0.0.1]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0J3O00MLPMOT4Z@dgismtp06.mcilink.com> for speermint@ietf.org; Tue, 08 Aug 2006 13:55:41 +0000 (GMT) Received: from XS107V7775199 ([166.50.70.191]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0J3O00LAVMOST9@dgismtp06.mcilink.com> for speermint@ietf.org; Tue, 08 Aug 2006 13:55:41 +0000 (GMT) Date: Tue, 08 Aug 2006 08:55:40 -0500 From: Tim Dwight Subject: RE: DNS performance (was Re: [Speermint] TLs performance) In-reply-to: <402F25FC1EB2BD44831F8A4A4F6DF94203A68A@MAIL02.cedarpointcom.com> To: speermint@ietf.org Message-id: <000301c6baf2$55c4f160$bf4632a6@mcilink.com> Organization: MCI MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Thread-index: Aca60nb+ZtX46VgHQ/uBx18FHv3pmgAAj2CLAAZrryA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: timothy.dwight@verizon.com List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org There is in country code 1 a central database-of-record, operated by the NPAC, from which carriers download LNP data into systems within their own networks; "systems" being in theory SCPs although in practice this service is sometimes integrated into the STPs. Point being that while the database-of-record is centrally administered LNP resolution is performed in a decentralized manner within individual carrier networks. tim > -----Original Message----- > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > Sent: Tuesday, August 08, 2006 5:40 AM > To: Klaus Darilion > Cc: speermint@ietf.org > Subject: RE: DNS performance (was Re: [Speermint] TLs performance) > > In the US? Yes. A centralized LNP database is queried. > > In many other countries, a huge file is distributed once per > day. Welcome to the stone age. > > Geoff > > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Tue 8/8/2006 6:07 AM > To: Geoff Devine > Cc: Duane; Francois Menard; speermint@ietf.org > Subject: Re: DNS performance (was Re: [Speermint] TLs performance) > > Geoff Devine wrote: > > That's not the way LNP works today. > > > > Class 5 offices have temporary triggers for the window > where a number > > is being ported. The definitive location of the subscriber > is kept in > > the LNP database. When that database is updated, all calls > route to > > the ported destination. You're violating the LNP > requirements if you > > route the call to the wrong class 5 switch after the LNP > database has > > changed. > > Thus, for each call the central LNP database is queried? > > regards klaus > > > > > There are 300 million telephone numbers in the United States. It's > > unlikely many of them will be in a cache. This isn't like caching > > "google.com". > > > > Geoff > > > > -----Original Message----- From: Duane [mailto:duane@e164.org] Sent: > > Mon 8/7/2006 7:04 PM To: Francois Menard Cc: speermint@ietf.org > > Subject: RE: DNS performance (was Re: [Speermint] TLs performance) > > > > On Mon, 2006-08-07 at 17:50 -0500, Francois Menard wrote: > >> I guess it all depends on how realtime you want your LNP to be... > > > > I doubt carriers anywhere would give you a time to change over in > > minutes, it would be closer to hours, so even having a 10 to 30 > > minutes TTL wouldn't harm things from LNP point of view... > > > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 10:01:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAS8o-00066j-Og; Tue, 08 Aug 2006 10:01:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAS8n-00066e-8p for speermint@ietf.org; Tue, 08 Aug 2006 10:01:05 -0400 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAS8m-0002p7-15 for speermint@ietf.org; Tue, 08 Aug 2006 10:01:05 -0400 Received: from dgismtp02.mcilink.com ([166.38.58.142]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0J3O00322MXRN6@firewall.mci.com> for speermint@ietf.org; Tue, 08 Aug 2006 14:01:03 +0000 (GMT) Received: from dgismtp02.mcilink.com ([127.0.0.1]) by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0J3O0009JMXRCX@dgismtp02.mcilink.com> for speermint@ietf.org; Tue, 08 Aug 2006 14:01:03 +0000 (GMT) Received: from XS107V7775199 ([166.50.70.191]) by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0J3O00MHJMXRAY@dgismtp02.mcilink.com> for speermint@ietf.org; Tue, 08 Aug 2006 14:01:03 +0000 (GMT) Date: Tue, 08 Aug 2006 09:01:03 -0500 From: Tim Dwight Subject: RE: DNS performance (was Re: [Speermint] TLs performance) In-reply-to: <44D86271.6050907@pernau.at> To: speermint@ietf.org Message-id: <000a01c6baf3$15d1fb60$bf4632a6@mcilink.com> Organization: MCI MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Thread-index: Aca60n7OkyisIZ8ESH+bzKoUOK63FwAH+K4g X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: timothy.dwight@verizon.com List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > Geoff Devine wrote: > > That's not the way LNP works today. > > > > Class 5 offices have temporary triggers for the window where a number > > is being ported. The definitive location of the subscriber is kept in > > the LNP database. When that database is updated, all calls route to > > the ported destination. You're violating the LNP requirements if you > > route the call to the wrong class 5 switch after the LNP database has > > changed. It is possible that the originating switch doesn't support LNP. In such a case the call may arrive at the "donor" switch (the switch from which the number was ported). This isn't the norm but isn't "illegal" either. Donor switches are required (in GR-2936) to support LNP, which ensures that in such a case, calls are correctly routed (albeit with a bit of a dogleg in the middle). tim _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 11:05:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAT96-0006sg-Va; Tue, 08 Aug 2006 11:05:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAT96-0006sb-FB for speermint@ietf.org; Tue, 08 Aug 2006 11:05:28 -0400 Received: from 67.254.241.83.in-addr.dgcsystems.net ([83.241.254.67] helo=smtp.dgcsystems.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAT93-0003Yt-Nu for speermint@ietf.org; Tue, 08 Aug 2006 11:05:28 -0400 Received: from Misan ([217.13.240.136]) by smtp.dgcsystems.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 17:05:24 +0200 From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "Pfautz, Penn L, GBLAM" , "Brian Rosen" , "Alexander Mayrhofer" Subject: RE: [Speermint] Mediarequirementsin draft-ietf-speermint-requirements-00 Date: Tue, 8 Aug 2006 16:05:22 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0D646FE9@ACCLUST02EVS1.ugd.att.com> Importance: Normal X-OriginalArrivalTime: 08 Aug 2006 15:05:24.0272 (UTC) FILETIME=[132A9300:01C6BAFC] X-Spam-Score: 1.1 (+) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Explicitly including some codecs can become a very healthy harmonizing factor, increasing the opportunity to get media through. RFC 4504 "Sip Telephony device requirements" has made a good effort to list essential codecs etc.. Supporting them through peering arrangements would mean that terminal and network developments are in line. RFC 4504 specifies RFC 4103 for real-time text. It would be pointless to recommend it for terminals if inter-operator connections will not guarantee to carry it. Real-time text should be seen as a part of VoIP. Video belongs to Multimedia Telephony, also including audio and real-time text. It is reasonable to expect the peering arrangements to also support Multimedia Telephony, but that would certainly require either a new spec or a title and scope change. So if there is a reason to specify for VoIP, please go ahead with audio and real-time text. Gunnar -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Sent: Tuesday, August 08, 2006 2:42 PM To: Brian Rosen; Alexander Mayrhofer; Gunnar Hellström Cc: speermint Subject: RE: [Speermint] Mediarequirementsin draft-ietf-speermint-requirements-00 Brian: Let me be clear. I'm not trying to exclude anything - and I don't think we should be in the business of specifying voice codecs either. Let us provide mechanisms for negotiation for supporting capabilities if providers want to make use of them but to think that Speermint is going to determine that all peering arrangements must support a particular media type is just kidding ourselves. Penn -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, August 08, 2006 9:34 AM To: Pfautz, Penn L, GBLAM; 'Alexander Mayrhofer'; 'Gunnar Hellström' Cc: 'speermint' Subject: RE: [Speermint] Mediarequirementsin draft-ietf-speermint-requirements-00 Haven't we learned this lesson, and isn't the cost now low enough that we can stop this argument? Every place you have audio, you could have text, either interactive or message based. It's not unreasonable to require the interactive text codec be supported across the spectrum of interconnects, so that people who can't hear can use the systems we build. In this context, supporting the text codec (as long as there is only one to be concerned about, which is the case) everywhere audio is supported is roughly zero cost in the peering system. It costs more to argue about it that it does to support it in the peering system. You have a better chance at not specifying a minimal video codec, although as I keep repeating, SPEERMINT is not intended to be the playground of soley the video impaired crowd. We need to recognize this. Likewise minimum codec for an IM peering exchange does not have audio in it. I'm really tired of people essentially saying "yes, yes, of course, but we REALLY know this is for voice, that's where the money is". Sorry, money or not, peering is for text (including IM) and video, and any other media that comes on through. There cannot be a SPEERMINT specified minimum codec set unless it is qualified like "if voice is supported at all, then at least ...." Brian > -----Original Message----- > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > Sent: Tuesday, August 08, 2006 9:18 AM > To: Alexander Mayrhofer; Gunnar Hellström > Cc: speermint > Subject: RE: [Speermint] Mediarequirementsin draft-ietf-speermint- > requirements-00 > > I agree with Alex. Only some telephony applications carry real-time text. > > -----Original Message----- > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > Sent: Tuesday, August 08, 2006 8:54 AM > To: Gunnar Hellström > Cc: speermint > Subject: Re: [Speermint] Media requirementsin draft-ietf-speermint- > requirements-00 > > Gunnar Hellström wrote: > > There is a media section 3.3 in draft-ietf-speermint-requirements-00.txt > > > > (http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements- > 00.txt) > > > > Currently it only specifies default audio codecs. > > > >>From PSTN there is an important tradition to also carry real-time text > as part of the telephony service. > > > > Thus also for speermint, the default codec for real-time text should be > supported. > > Well, > > 1) > > currently the Introduction section says "... minimum set of requirements > for > SIP-based _VoIP_ interconnection ..." (as well as the title). > > If we add eg. text, video, etc. we'd probably also need to change this > into > "... SIP-based multimedia interconnection ...". > > 2) > > The text says those are "minimum" requirements. Anything that we shove > into > that "minimum" as a MUST means that compliant implementations need to > implement this, thus reducing the number of compliant implementations. > > I'll strongly vote to not bloat the "minimum requirements" - even more, > i'd > try to keep those to the "very bare minimum requirements" wherever > possible. > > just my 2c > > Alex > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 12:18:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAUHQ-00048h-GE; Tue, 08 Aug 2006 12:18:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAUHP-00048c-Hy for speermint@ietf.org; Tue, 08 Aug 2006 12:18:07 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAUHN-0006RE-Qn for speermint@ietf.org; Tue, 08 Aug 2006 12:18:07 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 08 Aug 2006 09:17:59 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,222,1151910000"; d="scan'208"; a="35155141:sNHT45050260" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k78GHwon008978; Tue, 8 Aug 2006 12:17:58 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k78GHwe2027924; Tue, 8 Aug 2006 12:17:58 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 12:17:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Secure RTP Date: Tue, 8 Aug 2006 12:17:56 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301C6E443@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Secure RTP Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/AAABsDkAAAfWzgAMpSRNA= From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Geoff Devine" , "Patrick Melampy" , "Hadriel Kaplan" X-OriginalArrivalTime: 08 Aug 2006 16:17:57.0395 (UTC) FILETIME=[35D46E30:01C6BB06] DKIM-Signature: a=rsa-sha1; q=dns; l=12203; t=1155053878; x=1155917878; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Secure=20RTP |To:=22Brian=20Rosen=22=20, =0A=20=20=20=20=20=20=20=20=22 Geoff=20Devine=22=20, =0A=20=20=20=20=20=20=20=20 =22Patrick=20Melampy=22=20, =0A=20=20=20=20=20=20=2 0=20=22Hadriel=20Kaplan=22=20; X=v=3Dcisco.com=3B=20h=3DTav7+aVDpl+QOgZ4O1J+VN4eGlM=3D; b=Ms2EdFC+hnhrYJm8qeA0CWWd9igej1oScUiwfkmBdLrJFyVry3OSccSQ1Bd7aZAFhKVgjJO3 ovIf6UE+RV8u5q91opSCTX/FnlSstrmcwwQbKR3VarXFOMy5/LuXd8bY; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org It is more like a telephone network than a Web service. How do you explain cascading failures, then? Also, the business economics don't allow you to have 90% of your servers sitting around doing nothing just waiting for peak traffic. Mike =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Friday, August 04, 2006 12:01 PM > To: 'Geoff Devine'; 'Patrick Melampy'; Michael Hammer=20 > (mhammer); 'Hadriel Kaplan' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > This isn't a telephone network. >=20 > We typically DON'T have overload conditions on well=20 > engineered networks. We presently have some mighty fine self=20 > limiting issues with media, but if we had proper QoS on the=20 > media, that would be, I think, very sufficient congestion=20 > control. I've never seen a well engineered SIP based network=20 > where the signaling issues were a big problem. It's almost=20 > all in the media. >=20 > I know all about "Americal Idol" night. The numbers just=20 > aren't scary any more. =20 >=20 > Do the math. A million BHCA is 278 calls per second. How=20 > many million do you want? Rack up the servers (best make=20 > them stateless, but that's not a problem). >=20 > Sure, you need a load balancer. Sure, you need a failover=20 > strategy with a good database. =20 >=20 > Now, every system has limits. We have an answer for those: busy. >=20 > More importantly, we actually can use some telephone=20 > engineering to predict the traffic at the peering point. We=20 > can engineer systems pretty straightforwardly to handle that=20 > traffic. We DO need some congestion control mechanisms,=20 > because the peering mechanisms we have do have finite=20 > capacity. However, I don't see much need for telephone style=20 > call gapping and only trivial metering. >=20 > Today, we can build peering systems where the actual peering=20 > happens at multiple places around the globe, where there is=20 > no effective limits on signaling bandwith (or for that=20 > matter, media bandwith) to and from the peering points. We=20 > can have SIP proxies that perform the actual peering function=20 > (take a call, do a dip to determine where it's going, use=20 > available DNS and other mechanisms to spread load) that are=20 > similarly spread out and redundant enough that we get the=20 > kind of reliability we expect. And we can engineer them to=20 > take load up to a static limit reliably. >=20 > What can't we do? >=20 > Brian >=20 >=20 > > -----Original Message----- > > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > > Sent: Friday, August 04, 2006 11:35 AM > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); Hadriel=20 > > Kaplan > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Secure RTP > >=20 > > Telephone networks don't and can't work that way. They=20 > have overload=20 > > conditions and you absolutely must have a mechanism for=20 > dealing with=20 > > them. In the legacy network, you can take SS#7 CICs out of service. > > You can implement call gapping and call metering. We need=20 > equivalent=20 > > mechanisms and can likely do far better than best common=20 > practices in=20 > > the legacy network. > >=20 > > Geoff > >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, August 04, 2006 11:27 AM > > To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)';=20 > > 'Hadriel Kaplan' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Secure RTP > >=20 > > There is no evidence that you can't do this with the mechanisms we=20 > > have, and some that we can. I believe in a contractual,=20 > static, limit=20 > > on traffic between peers. I don't think we need anything else. > >=20 > > Brian > >=20 > > > -----Original Message----- > > > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > > > Sent: Friday, August 04, 2006 11:01 AM > > > To: Brian Rosen; Patrick Melampy; Michael Hammer=20 > (mhammer); Hadriel > > Kaplan > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Secure RTP > > > > > > I'm with Patrick on this one. The requirements for a=20 > carrier-class=20 > > > telephone network are quite different from the requirements for a=20 > > > web server. A web server doesn't have the moral and ethical=20 > > > obligation to ensure that the network is stable to complete 911=20 > > > calls. If the > > network > > > floods a soft switch or media gateway controller with peering=20 > > > traffic with no notion of congestion control, flow=20 > control, or fault > > management, > > > you could kill somebody. In the real world, resources=20 > are finite,=20 > > > not infinite and the network architecture has to take=20 > that into account. > > > > > > Geoff > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, August 04, 2006 10:20 AM > > > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)';=20 > 'Hadriel Kaplan' > > > Cc: speermint@ietf.org > > > 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=20 > > > techniques to deal with SIP load. I certainly don't see=20 > reasons to=20 > > > make the originator aware of congestion issues at the terminating=20 > > > domain, beyond the contractual limits that may be in place. > > > > > > I don't see any reason why peers should be aware of=20 > element failures. > > > We > > > clearly understand how to have a set of boxes that appear=20 > to be one=20 > > > domain name that are always available. > > > > > > I don't agree we need anything like a BGP for SIP any time I can=20 > > > foresee. > > > The underlying network handles all the issues I am aware=20 > of. Given > > the > > > name > > > of a domain (or subdomain), normal SIP routing is quite=20 > sufficient I=20 > > > think. > > > We attempted this for a really simple subset of the=20 > problem (gateway=20 > > > selection, see TRIP), and we found it was not needed (or at least=20 > > > the complexity it introduced was not worth the value it provided). > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > > Sent: Friday, August 04, 2006 9:59 AM > > > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > Cc: speermint@ietf.org > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > Brian, > > > > > > > > I agree with you. However some aspects are protocol=20 > worthy. Path=20 > > > > determination -- or said another way -- the next hop network to=20 > > > > use > > to > > > > reach > > > > a destination domain, must be partially provisioned,=20 > and partially=20 > > > > 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=20 > 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.=20 > > > > The > > > actual > > > > phone numbers to send down the circuit are provisioned=20 > in SS7. In > > our > > > case > > > > to have a well managed service, we need an equivalent=20 > 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=20 > > > > NPA-NXX routing models which are hierarchical and well=20 > understood,=20 > > > > IP domains are amorphous and have very unpredictable=20 > intersection=20 > > > > points. This is why BGP was invented for routing IP=20 > packets. The=20 > > > > same is true for SIP based > > > sessions. > > > > If > > > > there is to be peering, there will need to be a domain=20 > > > > advertisement protocol that goes network to network. Thus a=20 > > > > 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=20 > > > > 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:br@brianrosen.net] > > > > Sent: Friday, August 04, 2006 8:47 AM > > > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > Cc: speermint@ietf.org > > > > 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=20 > > > > within > > a > > > > peering federation to discover policies that apply to=20 > 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=20 > specified=20 > > > > 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=20 > > > > rate > > > of > > > > calls is limited in some way, then we probably have to=20 > standardize > > the > > > > definition of limiting, but not the way to determine what the=20 > > > > limit > > > is. > > > > In > > > > that way, the vendor who builds the proxy for Peer A=20 > will be able=20 > > > > 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=20 > 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=20 > > > > need automatic provisioning mechanisms to discover these. Even=20 > > > > within a federation, I think it will be common that bilateral=20 > > > > arrangements > > > making > > > > further policy limitations will exist. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > > > Sent: Thursday, August 03, 2006 3:13 PM > > > > > To: Hadriel Kaplan; Brian Rosen > > > > > Cc: speermint@ietf.org > > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > > > The focus of Speermint should be centered around=20 > whether one can=20 > > > > > discover the policies of a potential peer and whether those > > policies > > > can > > > > > systematically describe the requirements on multiple=20 > levels that > > > will > > > > > need to be supported to have a successful communication with=20 > > > > > that > > > peer. > > > > > > > > > > It is not about specifying X, Y, Z, or favorite MUST > > > here> > > > > > > > > > > Is is about whether the policy can be stated so one=20 > knows that=20 > > > > > 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 > > > > > > > > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 12:34:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAUXS-0003k5-0s; Tue, 08 Aug 2006 12:34:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAUXQ-0003jZ-Q8 for speermint@ietf.org; Tue, 08 Aug 2006 12:34:40 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAUXP-0008QP-Gg for speermint@ietf.org; Tue, 08 Aug 2006 12:34:40 -0400 Received: from [10.10.0.107] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Tue, 08 Aug 2006 18:34:35 +0200 id 0007C089.44D8BD1B.00007643 Message-ID: <44D8BCE3.2000207@enum.at> Date: Tue, 08 Aug 2006 18:33:39 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable To: "=?ISO-8859-1?Q?Gunnar_Hellstr=F6m?=" Subject: Re: [Speermint] Mediarequirementsin draft-ietf-speermint-requirements-00 References: In-Reply-To: X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.47 X-Spam-Score: 1.1 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Gunnar Hellstr=F6m wrote: > Explicitly including some codecs can become a very healthy harmonizing > factor, increasing the opportunity to get media through. What do you mean by requiring certain codecs? Does that mean that: - the peer does not filter out the respective SDP line? - the peer is obliged to force his customers supporting the codec? (by w= hich mechanism, btw? "codec police"?) - that the peer MUST provide transcoding on behalf of the client for tha= t codec (and then, from what to what?) Perhaps we're talking about different issues here. My point is that if y= ou _require_ a VoIP peer to support eg. real time text, and this peer is an "open" peer ("open" in terms that he allows his customers to choose thei= r own equipment, endpoints, etc. and media streams run end to end), there would be almost certainly be an endpoint which does _not_ support that c= odec. Would that mean that such a peer would then not be compliant, because on= e of his customers does not support the REQUIRED codec? I can't imagine that'= s the intent. What about saying something like "Peers SHOULD NOT artificially limit th= e set of codecs on behalf of their clients. In case the peer provides transcoding services, the following codecs MUST be supported: ..."? BTW, "codecs" is not just the algorithm... the next rathole is "media pa= cket sizes" (30ms packets anyone? :) Do we want to go down there? cheers alex _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 12:45:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAUi3-0001na-7n; Tue, 08 Aug 2006 12:45:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAUi1-0001nV-Mh for speermint@ietf.org; Tue, 08 Aug 2006 12:45:37 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAUi1-0002Uk-32 for speermint@ietf.org; Tue, 08 Aug 2006 12:45:37 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GAUhr-0005Q2-Jh; Tue, 08 Aug 2006 11:45:28 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Geoff Devine'" , "'Patrick Melampy'" , "'Hadriel Kaplan'" Subject: RE: [Speermint] Secure RTP Date: Tue, 8 Aug 2006 12:45:29 -0400 Message-ID: <07da01c6bb0a$10e77870$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/AAABsDkAAAfWzgAMpSRNAAALXLQA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301C6E443@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I'm not so sure about that. I do think that some of the folks that are designing VoIP systems make them look like telephone systems and thereby inherit the problems. I think many of the architectures being put forth have way too many elements, when only one or two (replicated of course) need to be there. I am always amazed comparing statistics of two VoIP networks that started accepting customers at around the same time, where one had a cost to first customer north of 100M and the other was something under 10. The cost of the millionth customer ALSO favored the latter, and it never turned around, while customers perceived the services to be equivalent (I'm sure the carriers didn't). I'm not sure what you mean by "cascading failures" in this context. Please explain. I'm also not sure that business economics don't allow you to have servers waiting for peak traffic. That depends on how these systems are built only a little, it more depend on how they are priced. The "servers" here are the signaling elements, and they are just computers. You can have a heck of a lot of computer sitting around doing nothing waiting for peak traffic. That isn't necessarily true of the media, of course. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, August 08, 2006 12:18 PM > To: Brian Rosen; Geoff Devine; Patrick Melampy; Hadriel Kaplan > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP > > It is more like a telephone network than a Web service. > > How do you explain cascading failures, then? > > Also, the business economics don't allow you to have 90% of your servers > sitting around doing nothing just waiting for peak traffic. > > Mike > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, August 04, 2006 12:01 PM > > To: 'Geoff Devine'; 'Patrick Melampy'; Michael Hammer > > (mhammer); 'Hadriel Kaplan' > > Cc: speermint@ietf.org > > 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:gdevine@cedarpointcom.com] > > > Sent: Friday, August 04, 2006 11:35 AM > > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); Hadriel > > > Kaplan > > > Cc: speermint@ietf.org > > > 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:br@brianrosen.net] > > > Sent: Friday, August 04, 2006 11:27 AM > > > To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > 'Hadriel Kaplan' > > > Cc: speermint@ietf.org > > > 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:gdevine@cedarpointcom.com] > > > > Sent: Friday, August 04, 2006 11:01 AM > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer > > (mhammer); Hadriel > > > Kaplan > > > > Cc: speermint@ietf.org > > > > 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:br@brianrosen.net] > > > > Sent: Friday, August 04, 2006 10:20 AM > > > > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > 'Hadriel Kaplan' > > > > Cc: speermint@ietf.org > > > > 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:PMelampy@acmepacket.com] > > > > > Sent: Friday, August 04, 2006 9:59 AM > > > > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > > Cc: speermint@ietf.org > > > > > 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:br@brianrosen.net] > > > > > Sent: Friday, August 04, 2006 8:47 AM > > > > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > > Cc: speermint@ietf.org > > > > > 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:mhammer@cisco.com] > > > > > > Sent: Thursday, August 03, 2006 3:13 PM > > > > > > To: Hadriel Kaplan; Brian Rosen > > > > > > Cc: speermint@ietf.org > > > > > > 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 > 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 Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 12:59:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAUvr-00025m-V9; Tue, 08 Aug 2006 12:59:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAUvq-00025h-U0 for speermint@ietf.org; Tue, 08 Aug 2006 12:59:54 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAUvp-0006XB-Um for speermint@ietf.org; Tue, 08 Aug 2006 12:59:54 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GAUvi-0006nK-JF; Tue, 08 Aug 2006 11:59:47 -0500 From: "Brian Rosen" To: "'Patrick Melampy'" Subject: RE: [Speermint] Congestion and Load Balancing Date: Tue, 8 Aug 2006 12:59:49 -0400 Message-ID: <07e301c6bb0c$10ed32e0$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/AAABsDkAAAfWzgAAFrv3AAAfWesAABmq5AAACioaAANhVVQACPsrUw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <000401c6b8cf$9bccf740$6401a8c0@acmepacket.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d01c7b9466fe967a5df27b46fdb03146 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:PMelampy@acmepacket.com] > Sent: Saturday, August 05, 2006 4:42 PM > To: 'Brian Rosen' > Cc: speermint@ietf.org > 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:br@brianrosen.net] > Sent: Friday, August 04, 2006 2:28 PM > To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer > (mhammer)'; 'Hadriel Kaplan' > Cc: speermint@ietf.org > 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:rpenno@juniper.net] > > Sent: Friday, August 04, 2006 2:14 PM > > To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer > (mhammer); > > Hadriel Kaplan > > Cc: speermint@ietf.org > > 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:br@brianrosen.net] > > > Sent: Friday, August 04, 2006 10:47 AM > > > To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; > > > 'Hadriel Kaplan' > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Congestion and Load Balancing was Re: Secure > > RTP > > > > > > > > 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:PMelampy@acmepacket.com] > > > > Sent: Friday, August 04, 2006 12:39 PM > > > > To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; > > 'Hadriel > > > > Kaplan' > > > > Cc: speermint@ietf.org > > > > 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:br@brianrosen.net] > > > > Sent: Friday, August 04, 2006 12:01 PM > > > > To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > > 'Hadriel > > > > Kaplan' > > > > Cc: speermint@ietf.org > > > > 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:gdevine@cedarpointcom.com] > > > > > Sent: Friday, August 04, 2006 11:35 AM > > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > > Hadriel > > > > Kaplan > > > > > Cc: speermint@ietf.org > > > > > 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:br@brianrosen.net] > > > > > Sent: Friday, August 04, 2006 11:27 AM > > > > > To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > > > 'Hadriel Kaplan' > > > > > Cc: speermint@ietf.org > > > > > 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:gdevine@cedarpointcom.com] > > > > > > Sent: Friday, August 04, 2006 11:01 AM > > > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > > Hadriel > > > > > Kaplan > > > > > > Cc: speermint@ietf.org > > > > > > 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:br@brianrosen.net] > > > > > > Sent: Friday, August 04, 2006 10:20 AM > > > > > > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel > > Kaplan' > > > > > > Cc: speermint@ietf.org > > > > > > 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:PMelampy@acmepacket.com] > > > > > > > Sent: Friday, August 04, 2006 9:59 AM > > > > > > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel > > Kaplan' > > > > > > > Cc: speermint@ietf.org > > > > > > > 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:br@brianrosen.net] > > > > > > > Sent: Friday, August 04, 2006 8:47 AM > > > > > > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > > > > Cc: speermint@ietf.org > > > > > > > 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:mhammer@cisco.com] > > > > > > > > Sent: Thursday, August 03, 2006 3:13 PM > > > > > > > > To: Hadriel Kaplan; Brian Rosen > > > > > > > > Cc: speermint@ietf.org > > > > > > > > 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 > 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 > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 13:05:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAV1P-0004YS-2J; Tue, 08 Aug 2006 13:05:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAV1N-0004Y4-1X for speermint@ietf.org; Tue, 08 Aug 2006 13:05:37 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=MAILSRV01.cedarpointcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAV1M-0007J0-EA for speermint@ietf.org; Tue, 08 Aug 2006 13:05:37 -0400 Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 13:05:35 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Speermint] Secure RTP Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 8 Aug 2006 13:05:34 -0400 Message-ID: <402F25FC1EB2BD44831F8A4A4F6DF94214C6F8@MAIL02.cedarpointcom.com> In-Reply-To: <07da01c6bb0a$10e77870$9de6a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Secure RTP Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/AAABsDkAAAfWzgAMpSRNAAALXLQAAAhzvQ From: "Geoff Devine" To: "Brian Rosen" , "Michael Hammer \(mhammer\)" , "Patrick Melampy" , "Hadriel Kaplan" X-OriginalArrivalTime: 08 Aug 2006 17:05:35.0855 (UTC) FILETIME=[DD9ACFF0:01C6BB0C] X-Spam-Score: 0.0 (/) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian Rosen writes: > The "servers" here are the signaling elements, and they=20 > are just computers. You can have a heck of a lot of computer > sitting around doing nothing waiting for peak traffic. That > isn't necessarily true of the media, of course. ...and that is precisely the point. Media gateways and PSTN interconnect fees are the dominant cost in any VoIP deployment. The capital cost rises substantially when you introduce compression codecs since the DSP component is the expensive part of a media gateway. Because of these large costs, they are finite resources. At peak busy hour, you run out of these resources. The goal of traffic engineering is to add capacity at a rate that keeps call blocking acceptable at peak busy hour. It takes months to order extra inter-machine trunks to the PSTN so there are always periods where the media gateway resource does not have enough capacity to handle peak busy hour. PSTN->VoIP calls are also tied to a single SS#7 point code. If you run out of capacity at that set of media gateways, incoming calls start blocking even though the network may have many other media gateway groups with spare capacity. Blindly load balancing VoIP->PSTN calls can have very adverse effects on PSTN->VoIP resources. =20 Any peering architecture needs to take all of this into account. Making a pure VoIP network scale isn't the hard problem. It's dealing with fault and congestion in the PSTN interconnect that drives the architecture. You can't say "just use the web server model and horizontally scale your compute function" for this. Geoff -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, August 08, 2006 12:45 PM To: 'Michael Hammer (mhammer)'; Geoff Devine; 'Patrick Melampy'; 'Hadriel Kaplan' Cc: speermint@ietf.org Subject: RE: [Speermint] Secure RTP I'm not so sure about that. I do think that some of the folks that are designing VoIP systems make them look like telephone systems and thereby inherit the problems. I think many of the architectures being put forth have way too many elements, when only one or two (replicated of course) need to be there. I am always amazed comparing statistics of two VoIP networks that started accepting customers at around the same time, where one had a cost to first customer north of 100M and the other was something under 10. The cost of the millionth customer ALSO favored the latter, and it never turned around, while customers perceived the services to be equivalent (I'm sure the carriers didn't). I'm not sure what you mean by "cascading failures" in this context. Please explain. I'm also not sure that business economics don't allow you to have servers waiting for peak traffic. That depends on how these systems are built only a little, it more depend on how they are priced. The "servers" here are the signaling elements, and they are just computers. You can have a heck of a lot of computer sitting around doing nothing waiting for peak traffic. That isn't necessarily true of the media, of course. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, August 08, 2006 12:18 PM > To: Brian Rosen; Geoff Devine; Patrick Melampy; Hadriel Kaplan > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > It is more like a telephone network than a Web service. >=20 > How do you explain cascading failures, then? >=20 > Also, the business economics don't allow you to have 90% of your servers > sitting around doing nothing just waiting for peak traffic. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, August 04, 2006 12:01 PM > > To: 'Geoff Devine'; 'Patrick Melampy'; Michael Hammer > > (mhammer); 'Hadriel Kaplan' > > Cc: speermint@ietf.org > > 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:gdevine@cedarpointcom.com] > > > Sent: Friday, August 04, 2006 11:35 AM > > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); Hadriel > > > Kaplan > > > Cc: speermint@ietf.org > > > 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:br@brianrosen.net] > > > Sent: Friday, August 04, 2006 11:27 AM > > > To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > 'Hadriel Kaplan' > > > Cc: speermint@ietf.org > > > 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:gdevine@cedarpointcom.com] > > > > Sent: Friday, August 04, 2006 11:01 AM > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer > > (mhammer); Hadriel > > > Kaplan > > > > Cc: speermint@ietf.org > > > > 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:br@brianrosen.net] > > > > Sent: Friday, August 04, 2006 10:20 AM > > > > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > 'Hadriel Kaplan' > > > > Cc: speermint@ietf.org > > > > 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:PMelampy@acmepacket.com] > > > > > Sent: Friday, August 04, 2006 9:59 AM > > > > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > > Cc: speermint@ietf.org > > > > > 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:br@brianrosen.net] > > > > > Sent: Friday, August 04, 2006 8:47 AM > > > > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > > Cc: speermint@ietf.org > > > > > 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:mhammer@cisco.com] > > > > > > Sent: Thursday, August 03, 2006 3:13 PM > > > > > > To: Hadriel Kaplan; Brian Rosen > > > > > > Cc: speermint@ietf.org > > > > > > 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 > 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 Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 13:08:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAV3j-00051R-0A; Tue, 08 Aug 2006 13:08:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAV3g-00051B-SN for speermint@ietf.org; Tue, 08 Aug 2006 13:08:00 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAV3f-0007eZ-HY for speermint@ietf.org; Tue, 08 Aug 2006 13:08:00 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 08 Aug 2006 10:08:04 -0700 X-IronPort-AV: i="4.07,222,1151910000"; d="scan'208"; a="575561965:sNHT35194164" x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 Date: Tue, 8 Aug 2006 13:08:13 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2805182E3D@proton.jnpr.net> In-Reply-To: <44D8BCE3.2000207@enum.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 Thread-Index: Aca7CLqfd18vPd3fSDKEexKV6WNpuAAAkzGw From: "Reinaldo Penno" To: "Alexander Mayrhofer" , =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= X-Spam-Score: 1.1 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > -----Original Message----- > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > Sent: Tuesday, August 08, 2006 9:34 AM > To: Gunnar Hellstr=F6m > Cc: speermint > Subject: Re: [Speermint]Mediarequirementsin draft-ietf-speermint- > requirements-00 >=20 > Gunnar Hellstr=F6m wrote: > > Explicitly including some codecs can become a very healthy = harmonizing > > factor, increasing the opportunity to get media through. >=20 > What do you mean by requiring certain codecs? Does that mean that: >=20 > - the peer does not filter out the respective SDP line? > - the peer is obliged to force his customers supporting the codec? (by > which > mechanism, btw? "codec police"?) > - that the peer MUST provide transcoding on behalf of the client for = that > codec (and then, from what to what?) >=20 > Perhaps we're talking about different issues here. My point is that if = you > _require_ a VoIP peer to support eg. real time text, and this peer is = an > "open" peer ("open" in terms that he allows his customers to choose = their > own equipment, endpoints, etc. and media streams run end to end), = there > would be almost certainly be an endpoint which does _not_ support that > codec. >=20 [[Reinaldo]]=20 I think we are forgetting the business aspect here. Are there such ISPs in Europe that allow you to choose whatever = equipment you like and still support your installation? (This is a = legitimate question). I haven't lived in Europe long enough to notice = these things.=20 In the US when you buy DSL or Cable service you receive the modem by = mail. You can choose your modem but it has to be on a list of supported = modems, otherwise you are on your own. I cannot imagine an ISP = supporting any end device/modem/phone, it would be a money black hole.=20 I believe the real issue is at (or near) the peering point where you = will have to possibly perform transcoding. > Would that mean that such a peer would then not be compliant, because = one > of > his customers does not support the REQUIRED codec? I can't imagine = that's > the intent >=20 > What about saying something like "Peers SHOULD NOT artificially limit = the > set of codecs on behalf of their clients. In case the peer provides > transcoding services, the following codecs MUST be supported: ..."? >=20 > BTW, "codecs" is not just the algorithm... the next rathole is "media > packet > sizes" (30ms packets anyone? :) Do we want to go down there? >=20 > cheers >=20 > alex >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 13:33:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVST-0002Uo-Eg; Tue, 08 Aug 2006 13:33:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVSR-0002Sl-PS for speermint@ietf.org; Tue, 08 Aug 2006 13:33:35 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAVSR-0004Gb-0X for speermint@ietf.org; Tue, 08 Aug 2006 13:33:35 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GAVSF-0001Hn-PI; Tue, 08 Aug 2006 12:33:25 -0500 From: "Brian Rosen" To: "'Geoff Devine'" , "'Michael Hammer \(mhammer\)'" , "'Patrick Melampy'" , "'Hadriel Kaplan'" Subject: RE: [Speermint] Secure RTP Date: Tue, 8 Aug 2006 13:33:24 -0400 Message-ID: <07ea01c6bb10$c368bd50$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/AAABsDkAAAfWzgAMpSRNAAALXLQAAAhzvQAADO+gA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <402F25FC1EB2BD44831F8A4A4F6DF94214C6F8@MAIL02.cedarpointcom.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb7a33d18683bf5063a44e640cf125f1 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Huh? First, let's dismiss the PSTN interconnect issue. Sure, it's the dominant cost, and the dominant bottleneck today, but that isn't visible to peering. The terminating network, if it's going to route to PSTN (which presumably should be fairly rare, we're trying to get VoIP to VoIP peering after all), is going to route within its network, and if it runs out of gateway resource, it's out of resource and it returns busy. The peering system isn't going to be running out of resources, and can't affect the routing in the terminating network. The peering system does not have visibility to the PSTN gateway resource in the terminating network. I think we'll all concede that the media can get congested. I suspect that the peering system can be made to NOT be the bottleneck. Any VoIP network may have to deal with media congestion in a variety of ways, but I don't think they affect the peering UNLESS you make one (probably fatal) mistake, which would be to tie the media and the signaling to one box, which then becomes the bottleneck. Just don't do that. In the end, the PEERING can be done in such a matter that the media bandwidth is essentially unlimited. When it enters a network (B) that network will pick a box to send it to, if it's not taking it direct to the endpoint. However, that's strictly an internal matter for B, and not in scope for SPEERMINT. Similarly, A may have to choose a media anchor, but again, not an issue for SPEERMINT. The peering system itself is literally just routing packets. I think that can be made to be not an issue. So I think we get to the signaling issues, and not the media issues, when dealing with congestion in peering. The total number of messages or calls per unit time is, I think, just how much computer you have, and we can have a lot of that. The peering system DOES want to limit the traffic from A to B in some way, which is indeed probably limited by aggregate media handling issues more so than any other, but again, that really isn't visible at the peering point. All you get, I think, is the gross metrics of total calls, peak calling rate, etc. We can probably do aggregate bandwidth summation. I don't think it needs to get more complex than that. Brian > -----Original Message----- > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > Sent: Tuesday, August 08, 2006 1:06 PM > To: Brian Rosen; Michael Hammer (mhammer); Patrick Melampy; Hadriel Kaplan > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP > > Brian Rosen writes: > > The "servers" here are the signaling elements, and they > > are just computers. You can have a heck of a lot of computer > > sitting around doing nothing waiting for peak traffic. That > > isn't necessarily true of the media, of course. > > ...and that is precisely the point. Media gateways and PSTN > interconnect fees are the dominant cost in any VoIP deployment. The > capital cost rises substantially when you introduce compression codecs > since the DSP component is the expensive part of a media gateway. > Because of these large costs, they are finite resources. At peak busy > hour, you run out of these resources. The goal of traffic engineering > is to add capacity at a rate that keeps call blocking acceptable at peak > busy hour. It takes months to order extra inter-machine trunks to the > PSTN so there are always periods where the media gateway resource does > not have enough capacity to handle peak busy hour. > > PSTN->VoIP calls are also tied to a single SS#7 point code. If you run > out of capacity at that set of media gateways, incoming calls start > blocking even though the network may have many other media gateway > groups with spare capacity. Blindly load balancing VoIP->PSTN calls can > have very adverse effects on PSTN->VoIP resources. > > Any peering architecture needs to take all of this into account. Making > a pure VoIP network scale isn't the hard problem. It's dealing with > fault and congestion in the PSTN interconnect that drives the > architecture. You can't say "just use the web server model and > horizontally scale your compute function" for this. > > Geoff > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, August 08, 2006 12:45 PM > To: 'Michael Hammer (mhammer)'; Geoff Devine; 'Patrick Melampy'; > 'Hadriel Kaplan' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP > > I'm not so sure about that. > > I do think that some of the folks that are designing VoIP systems make > them > look like telephone systems and thereby inherit the problems. I think > many > of the architectures being put forth have way too many elements, when > only > one or two (replicated of course) need to be there. I am always amazed > comparing statistics of two VoIP networks that started accepting > customers > at around the same time, where one had a cost to first customer north of > 100M and the other was something under 10. The cost of the millionth > customer ALSO favored the latter, and it never turned around, while > customers perceived the services to be equivalent (I'm sure the carriers > didn't). > > I'm not sure what you mean by "cascading failures" in this context. > Please > explain. > > I'm also not sure that business economics don't allow you to have > servers > waiting for peak traffic. That depends on how these systems are built > only > a little, it more depend on how they are priced. > > The "servers" here are the signaling elements, and they are just > computers. > You can have a heck of a lot of computer sitting around doing nothing > waiting for peak traffic. That isn't necessarily true of the media, of > course. > > Brian > > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Tuesday, August 08, 2006 12:18 PM > > To: Brian Rosen; Geoff Devine; Patrick Melampy; Hadriel Kaplan > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Secure RTP > > > > It is more like a telephone network than a Web service. > > > > How do you explain cascading failures, then? > > > > Also, the business economics don't allow you to have 90% of your > servers > > sitting around doing nothing just waiting for peak traffic. > > > > Mike > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, August 04, 2006 12:01 PM > > > To: 'Geoff Devine'; 'Patrick Melampy'; Michael Hammer > > > (mhammer); 'Hadriel Kaplan' > > > Cc: speermint@ietf.org > > > 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:gdevine@cedarpointcom.com] > > > > Sent: Friday, August 04, 2006 11:35 AM > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > Hadriel > > > > Kaplan > > > > Cc: speermint@ietf.org > > > > 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:br@brianrosen.net] > > > > Sent: Friday, August 04, 2006 11:27 AM > > > > To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > > 'Hadriel Kaplan' > > > > Cc: speermint@ietf.org > > > > 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:gdevine@cedarpointcom.com] > > > > > Sent: Friday, August 04, 2006 11:01 AM > > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer > > > (mhammer); Hadriel > > > > Kaplan > > > > > Cc: speermint@ietf.org > > > > > 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:br@brianrosen.net] > > > > > Sent: Friday, August 04, 2006 10:20 AM > > > > > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > 'Hadriel Kaplan' > > > > > Cc: speermint@ietf.org > > > > > 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:PMelampy@acmepacket.com] > > > > > > Sent: Friday, August 04, 2006 9:59 AM > > > > > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel > Kaplan' > > > > > > Cc: speermint@ietf.org > > > > > > 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:br@brianrosen.net] > > > > > > Sent: Friday, August 04, 2006 8:47 AM > > > > > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > > > Cc: speermint@ietf.org > > > > > > 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:mhammer@cisco.com] > > > > > > > Sent: Thursday, August 03, 2006 3:13 PM > > > > > > > To: Hadriel Kaplan; Brian Rosen > > > > > > > Cc: speermint@ietf.org > > > > > > > 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 > > 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 Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 13:54:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVmJ-0005fT-44; Tue, 08 Aug 2006 13:54:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVmG-0005fJ-Lc for speermint@ietf.org; Tue, 08 Aug 2006 13:54:04 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAVmF-0007V1-F9 for speermint@ietf.org; Tue, 08 Aug 2006 13:54:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Aug 2006 13:53:33 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD1A632B@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [wg-business] draft-ietf-speermint-architecture-00 Expected Soon Thread-Index: Aca7E5CaVPElALTcQf61/R9nTr7aOg== From: "Livingood, Jason" To: X-OriginalArrivalTime: 08 Aug 2006 17:53:33.0737 (UTC) FILETIME=[90F4C190:01C6BB13] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Speermint] [wg-business] draft-ietf-speermint-architecture-00 Expected Soon X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org We're looking to make progress soon on an official WG architecture draft. We have had a few personal I-Ds on the subject, to spur WG debate. The most mature one was draft-khan-ip-serv-peer-arch-03, started by Sohel Khan, with Reinaldo Penno, Daryl Malas, Adam Uzelac, and Michael Hammer as co-authors. At IETF-66 in Montreal we also had presentations from Rohan Mahy and Michael Haberler that touched on architecture. =20 Now it is time to begin work on draft-ietf-speermint-architecture-00. We'll be having Reinaldo Penno serve as the editor of the document, using draft-khan-ip-serv-peer-arch-03 as a starting point. All of the contributors of that draft mentioned above have been working to take into account all of the feedback received at IETF-66 and afterwards on this list. We expect draft-ietf-speermint-architecture-00 to be published shortly and ask for your review and feedback. This will, of course, be one of the drafts reviewed at our interim meeting. =20 Regards Jason & Dave _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 18:23:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAZyT-0004s4-2M; Tue, 08 Aug 2006 18:22:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAZyR-0004rz-I0 for speermint@ietf.org; Tue, 08 Aug 2006 18:22:55 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=MAILSRV01.cedarpointcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAZyQ-0002ar-SZ for speermint@ietf.org; Tue, 08 Aug 2006 18:22:55 -0400 Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 18:22:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Secure RTP Date: Tue, 8 Aug 2006 18:22:53 -0400 Message-ID: <402F25FC1EB2BD44831F8A4A4F6DF94214C87D@MAIL02.cedarpointcom.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301C6E4BF@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Secure RTP Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/AAABsDkAAAfWzgAMpSRNAAALXLQAAC38tgAAjMvmA= From: "Geoff Devine" To: "Michael Hammer \(mhammer\)" , "Brian Rosen" , "Patrick Melampy" , "Hadriel Kaplan" X-OriginalArrivalTime: 08 Aug 2006 22:22:54.0449 (UTC) FILETIME=[317DB610:01C6BB39] X-Spam-Score: 0.0 (/) X-Scan-Signature: bfc9ec46aa2f66e5aee6a3bbffb0ebe9 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I agree 100% with this analysis of what can happen when you use 503. There is a real risk that it can cause the network to overload. That said, I think you guys are missing a use case: I have a media gateway in New York. My peer has a media gateway in San Francisco. One of my New York subscribers dials a San Francisco telephone number. This number is not a VoIP device. I want to use the peer media gateway in San Francisco whenever possible to avoid carrier charges. In this use case, PSTN gateway economics are certainly a consideration. The media gateway controller in San Francisco has finite resources and it would be a poor architecture to send INVITE messages to it from New York when it is congested. Geoff -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Tuesday, August 08, 2006 2:22 PM To: Brian Rosen; Geoff Devine; Patrick Melampy; Hadriel Kaplan Cc: speermint@ietf.org Subject: RE: [Speermint] Secure RTP Brian, When you get to the point that you can't keep up with new offered calls, you may send a 503 that causes another server to get the added load. If that server was also near it's thrashing point, it may also start rejecting calls with 503 leading to yet another server getting overloaded, and so on. Retransmissions of the new call can oscillate through your servers searching for one that can handle a new call. But, in the mean time it takes resources to reject a call. The call gapping tells upstream elements how to limit the new load so that there is no rejection of call resource consumption. In your case, by suggesting the load balancer, you have merely moved the problem into the receiving network, but now creating a new point of congestion at the load balancer. Yeah, they are just servers, but presumable they have software on them, and presumable the software vendors don't write software for altruistic reasons, but need to make money too. And since revenue from voice is being pushed lower, I don't see SPs buying into massive server farms with 90% sitting idle. I agree though that this shouldn't be based on PSTN GW economics, we are trying to bypass that in Speermint. However, the need to police borders and actually charge for calls may have an impact anyway. I was looking for the ability to dynamically direct calls to various signaling border elements based on a variety of business and possibly varying technical needs, congestion being only one aspect. In some ways, this may be akin to load balancing, since based on some multifaceted criteria, it is making visible to any potential peer which signaling peering point to direct traffic to. Or deny access altogether. Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, August 08, 2006 12:45 PM > To: Michael Hammer (mhammer); 'Geoff Devine'; 'Patrick=20 > Melampy'; 'Hadriel Kaplan' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > I'm not so sure about that. >=20 > I do think that some of the folks that are designing VoIP=20 > systems make them look like telephone systems and thereby=20 > inherit the problems. I think many of the architectures=20 > being put forth have way too many elements, when only one or=20 > two (replicated of course) need to be there. I am always=20 > amazed comparing statistics of two VoIP networks that started=20 > accepting customers at around the same time, where one had a=20 > cost to first customer north of 100M and the other was=20 > something under 10. The cost of the millionth customer ALSO=20 > favored the latter, and it never turned around, while=20 > customers perceived the services to be equivalent (I'm sure=20 > the carriers didn't). >=20 > I'm not sure what you mean by "cascading failures" in this=20 > context. Please explain. >=20 > I'm also not sure that business economics don't allow you to=20 > have servers waiting for peak traffic. That depends on how=20 > these systems are built only a little, it more depend on how=20 > they are priced. >=20 > The "servers" here are the signaling elements, and they are=20 > just computers. > You can have a heck of a lot of computer sitting around doing=20 > nothing waiting for peak traffic. That isn't necessarily=20 > true of the media, of course. >=20 > Brian >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Tuesday, August 08, 2006 12:18 PM > > To: Brian Rosen; Geoff Devine; Patrick Melampy; Hadriel Kaplan > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Secure RTP > >=20 > > It is more like a telephone network than a Web service. > >=20 > > How do you explain cascading failures, then? > >=20 > > Also, the business economics don't allow you to have 90% of your=20 > > servers sitting around doing nothing just waiting for peak traffic. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, August 04, 2006 12:01 PM > > > To: 'Geoff Devine'; 'Patrick Melampy'; Michael Hammer (mhammer);=20 > > > 'Hadriel Kaplan' > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Secure RTP > > > > > > This isn't a telephone network. > > > > > > We typically DON'T have overload conditions on well engineered=20 > > > networks. We presently have some mighty fine self=20 > limiting issues=20 > > > with media, but if we had proper QoS on the media, that=20 > would be, I=20 > > > think, very sufficient congestion control. I've never=20 > seen a well=20 > > > engineered SIP based network where the signaling issues=20 > were a big=20 > > > problem. It's almost all in the media. > > > > > > I know all about "Americal Idol" night. The numbers just aren't=20 > > > scary any more. > > > > > > Do the math. A million BHCA is 278 calls per second. How many=20 > > > million do you want? Rack up the servers (best make them=20 > stateless,=20 > > > but that's not a problem). > > > > > > Sure, you need a load balancer. Sure, you need a=20 > failover strategy=20 > > > with a good database. > > > > > > Now, every system has limits. We have an answer for those: busy. > > > > > > More importantly, we actually can use some telephone=20 > engineering to=20 > > > predict the traffic at the peering point. We can=20 > engineer systems=20 > > > pretty straightforwardly to handle that traffic. We DO need some=20 > > > congestion control mechanisms, because the peering mechanisms we=20 > > > have do have finite capacity. However, I don't see much need for=20 > > > telephone style call gapping and only trivial metering. > > > > > > Today, we can build peering systems where the actual=20 > peering happens=20 > > > at multiple places around the globe, where there is no effective=20 > > > limits on signaling bandwith (or for that matter, media=20 > bandwith) to=20 > > > and from the peering points. We can have SIP proxies=20 > that perform=20 > > > the actual peering function (take a call, do a dip to determine=20 > > > where it's going, use available DNS and other mechanisms=20 > to spread=20 > > > load) that are similarly spread out and redundant enough=20 > that we get=20 > > > the kind of reliability we expect. And we can engineer=20 > them to take=20 > > > load up to a static limit reliably. > > > > > > What can't we do? > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > > > > Sent: Friday, August 04, 2006 11:35 AM > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer);=20 > > > > Hadriel Kaplan > > > > Cc: speermint@ietf.org > > > > 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=20 > 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:br@brianrosen.net] > > > > Sent: Friday, August 04, 2006 11:27 AM > > > > To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer=20 > (mhammer)';=20 > > > > 'Hadriel Kaplan' > > > > Cc: speermint@ietf.org > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > There is no evidence that you can't do this with the=20 > mechanisms we=20 > > > > 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:gdevine@cedarpointcom.com] > > > > > Sent: Friday, August 04, 2006 11:01 AM > > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer > > > (mhammer); Hadriel > > > > Kaplan > > > > > Cc: speermint@ietf.org > > > > > 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=20 > requirements for=20 > > > > > a web server. A web server doesn't have the moral=20 > and ethical=20 > > > > > obligation to ensure that the network is stable to=20 > complete 911=20 > > > > > calls. If the > > > > network > > > > > floods a soft switch or media gateway controller with peering=20 > > > > > 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:br@brianrosen.net] > > > > > Sent: Friday, August 04, 2006 10:20 AM > > > > > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > 'Hadriel Kaplan' > > > > > Cc: speermint@ietf.org > > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > > > I don't think any of this is something we are=20 > chartered to do. =20 > > > > > 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=20 > > > > > handle > > > > HTTP > > > > > load, and I don't see any reason we shouldn't use all=20 > of those=20 > > > > > techniques to deal with SIP load. I certainly don't see > > > reasons to > > > > > make the originator aware of congestion issues at the=20 > > > > > terminating domain, beyond the contractual limits=20 > 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=20 > time I can=20 > > > > > 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=20 > > > > > least the complexity it introduced was not worth the=20 > value it provided). > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > > > > Sent: Friday, August 04, 2006 9:59 AM > > > > > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)';=20 > 'Hadriel Kaplan' > > > > > > Cc: speermint@ietf.org > > > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > > > > > Brian, > > > > > > > > > > > > I agree with you. However some aspects are protocol > > > worthy. Path > > > > > > determination -- or said another way -- the next=20 > hop network=20 > > > > > > to use > > > > to > > > > > > reach > > > > > > a destination domain, must be partially provisioned, > > > and partially > > > > > > discovered. The discovery aspects are the dynamic aspects.=20 > > > > > > 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=20 > the protocol > > > > family, > > > > > and > > > > > > ISUP messages are sent to bring circuits in and out=20 > 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,=20 > > > > > > maximum > > > > > sessions > > > > > > permitted, and maximum bandwidth to use. > > > > > > > > > > > > In #2 -- reachable domains -- Unlike the PSTN which=20 > uses the=20 > > > > > > 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=20 > > > > > > advertisement protocol that goes network to network. Thus a=20 > > > > > > protocol is required > > > > > here. > > > > > > > > > > > > In #3 -- congestion -- is dynamic and not=20 > 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=20 > also think we=20 > > > > > > need > > > > to > > > > > > leave > > > > > > to the individual networks, any and all decisions on how to=20 > > > > > > run > > > > their > > > > > > networks, choose next networks, etc. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Friday, August 04, 2006 8:47 AM > > > > > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > > > Cc: speermint@ietf.org > > > > > > 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=20 > for peers=20 > > > > > > 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=20 > mechanisms exist to > > > > > provision. > > > > > > So, for example, if one of the things peering means is that=20 > > > > > > the rate > > > > > of > > > > > > calls is limited in some way, then we probably have to > > > standardize > > > > the > > > > > > definition of limiting, but not the way to=20 > determine what the=20 > > > > > > 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. =20 > This is not=20 > > > > > > 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=20 > their values=20 > > > > > > are > > > > > limited > > > > > > to. > > > > > > It clearly WILL do that for some variables, and again, we=20 > > > > > > don't need automatic provisioning mechanisms to discover=20 > > > > > > these. Even within a federation, I think it will be common=20 > > > > > > that bilateral arrangements > > > > > making > > > > > > further policy limitations will exist. > > > > > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > > > > > Sent: Thursday, August 03, 2006 3:13 PM > > > > > > > To: Hadriel Kaplan; Brian Rosen > > > > > > > Cc: speermint@ietf.org > > > > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > > > > > > > The focus of Speermint should be centered around > > > whether one can > > > > > > > discover the policies of a potential peer and=20 > whether those > > > > policies > > > > > can > > > > > > > systematically describe the requirements on multiple > > > levels that > > > > > will > > > > > > > need to be supported to have a successful=20 > communication with=20 > > > > > > > that > > > > > peer. > > > > > > > > > > > > > > It is not about specifying X, Y, Z, or > > 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=20 > different MUSTs=20 > > > > > > > for > > > > each > > > > > > > category of choices we come up with. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 18:23:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAZyu-0005DW-CF; Tue, 08 Aug 2006 18:23:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAZyq-0005C1-Ly; Tue, 08 Aug 2006 18:23:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAY3t-0004UX-0P; Tue, 08 Aug 2006 16:20:25 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAXsY-0004G4-Ck; Tue, 08 Aug 2006 16:08:44 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 266762AC85; Tue, 8 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GAXaT-0005dL-QZ; Tue, 08 Aug 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 08 Aug 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-02.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Terminology Author(s) : D. Meyer Filename : draft-ietf-speermint-terminology-02.txt Pages : 13 Date : 2006-8-8 This document defines the terminology that is to be used by the Session PEERing for Multimedia INTerconnect Working Group (SPEERMINT). It has as its primary objective to focus the working group during its discussions, and when writing requirements, gap analysis and other solutions oriented documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-terminology-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-terminology-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-8121702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-terminology-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-terminology-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-8121702.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Tue Aug 08 18:43:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAaI7-0003Cv-IV; Tue, 08 Aug 2006 18:43:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAaI6-0003Cp-79 for speermint@ietf.org; Tue, 08 Aug 2006 18:43:14 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GAaI4-0000ca-Qh for speermint@ietf.org; Tue, 08 Aug 2006 18:43:14 -0400 Received: from source ([192.150.11.134]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Tue, 08 Aug 2006 15:42:56 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k78Mf1Bl013816; Tue, 8 Aug 2006 15:41:02 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k78MglR4011205; Tue, 8 Aug 2006 15:42:51 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 15:42:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 Date: Tue, 8 Aug 2006 15:42:46 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D220C39A4@namail5.corp.adobe.com> In-Reply-To: <44D8BCE3.2000207@enum.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 Thread-Index: Aca7CJHE1mHxEa2+TnyHDjRiJmpvQAAL9fNg From: "Henry Sinnreich" To: "Alexander Mayrhofer" , =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= X-OriginalArrivalTime: 08 Aug 2006 22:42:46.0922 (UTC) FILETIME=[F842A6A0:01C6BB3B] X-Spam-Score: 1.1 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > BTW, "codecs" is not just the algorithm... the next rathole is "media=20 > packet sizes" (30ms packets anyone? :) Do we want to go down there? Default codecs are not a rat hole.=20 Signaling standards for peering without media defaults are meaningless. Thanks, Henry -----Original Message----- From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at]=20 Sent: Tuesday, August 08, 2006 9:34 AM To: Gunnar Hellstr=F6m Cc: speermint Subject: Re: [Speermint]Mediarequirementsin = draft-ietf-speermint-requirements-00 Gunnar Hellstr=F6m wrote: > Explicitly including some codecs can become a very healthy harmonizing > factor, increasing the opportunity to get media through. What do you mean by requiring certain codecs? Does that mean that: - the peer does not filter out the respective SDP line? - the peer is obliged to force his customers supporting the codec? (by = which mechanism, btw? "codec police"?) - that the peer MUST provide transcoding on behalf of the client for = that codec (and then, from what to what?) Perhaps we're talking about different issues here. My point is that if = you _require_ a VoIP peer to support eg. real time text, and this peer is an "open" peer ("open" in terms that he allows his customers to choose = their own equipment, endpoints, etc. and media streams run end to end), there would be almost certainly be an endpoint which does _not_ support that = codec. Would that mean that such a peer would then not be compliant, because = one of his customers does not support the REQUIRED codec? I can't imagine = that's the intent. What about saying something like "Peers SHOULD NOT artificially limit = the set of codecs on behalf of their clients. In case the peer provides transcoding services, the following codecs MUST be supported: ..."? BTW, "codecs" is not just the algorithm... the next rathole is "media = packet sizes" (30ms packets anyone? :) Do we want to go down there? cheers alex _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 18:49:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAaOM-00078t-Lt; Tue, 08 Aug 2006 18:49:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAaOL-00078o-Jt for speermint@ietf.org; Tue, 08 Aug 2006 18:49:41 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAaOK-0002jC-24 for speermint@ietf.org; Tue, 08 Aug 2006 18:49:41 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k78MndtF015603 for ; Tue, 8 Aug 2006 15:49:39 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k78MnZEN015602 for speermint@ietf.org; Tue, 8 Aug 2006 15:49:35 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 8 Aug 2006 15:49:35 -0700 From: David Meyer To: speermint@ietf.org Subject: FYI -- [Internet-Drafts@ietf.org: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-02.txt] Message-ID: <20060808224935.GA15589@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0371556072==" Errors-To: speermint-bounces@ietf.org --===============0371556072== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I think I have everyone's comments in this rev... --dmm ----- Forwarded message from Internet-Drafts@ietf.org ----- > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Cc: speermint@ietf.org > Subject: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-02.txt= =20 > Date: Tue, 08 Aug 2006 15:50:01 -0400 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Session PEERing for Multimedia INTerconn= ect Working Group of the IETF. >=20 > Title : SPEERMINT Terminology > Author(s) : D. Meyer > Filename : draft-ietf-speermint-terminology-02.txt > Pages : 13 > Date : 2006-8-8 > =09 > This document defines the terminology that is to be used by the > Session PEERing for Multimedia INTerconnect Working Group > (SPEERMINT). It has as its primary objective to focus the working > group during its discussions, and when writing requirements, gap > analysis and other solutions oriented documents. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-02.t= xt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body of th= e message. =20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login with the usern= ame > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-speermint-terminology-02.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-speermint-terminology-02.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint ----- End forwarded message ----- --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFE2RT/ORgD1qCZ2KcRAl+OAJ0Snw7WpOdz/BFf2qKGgWeHoouYJwCfVgFs DtgDfMBv3CJEKp+4jmGkEv0= =l9Ic -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- --===============0371556072== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0371556072==-- From speermint-bounces@ietf.org Tue Aug 08 19:09:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAah5-00027u-IU; Tue, 08 Aug 2006 19:09:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAah4-000278-Ie for speermint@ietf.org; Tue, 08 Aug 2006 19:09:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAYpX-0007di-9b for speermint@ietf.org; Tue, 08 Aug 2006 17:09:39 -0400 Received: from pne-smtpout2-sn1.fre.skanova.net ([81.228.11.159]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAYVp-0004zH-2s for speermint@ietf.org; Tue, 08 Aug 2006 16:49:18 -0400 Received: from Misan (213.64.228.153) by pne-smtpout2-sn1.fre.skanova.net (7.2.075) id 44A135F100855D41; Tue, 8 Aug 2006 22:48:56 +0200 From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "Reinaldo Penno" , "Alexander Mayrhofer" Subject: RE: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 Date: Tue, 8 Aug 2006 21:48:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2805182E3D@proton.jnpr.net> Importance: Normal Content-Transfer-Encoding: Quoted-Printable X-Spam-Score: -1.9 (-) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org This wording seems good to me: >"Peers SHOULD NOT artificially limit the > set of codecs on behalf of their clients. In case the peer provides > transcoding services, the following codecs MUST be supported: ..."? You ask: > What do you mean by requiring certain codecs? Does that mean that: > > - the peer does not filter out the respective SDP line? > - the peer is obliged to force his customers supporting the codec? (by > which > mechanism, btw? "codec police"?) > - that the peer MUST provide transcoding on behalf of the client for th= at > codec (and then, from what to what?) I think it is the following: - the peer does not filter out the respective SDP line, convey the negotiation of a list of codecs and support transfer of their packets. > - that the peer MUST provide transcoding on behalf of the client for a specified list of codec pairs. ( A list of externally supported versus internally supported codecs). Example: You want to set up operations with terminals ONLY supporting ILBC audio, = RFC 4103 text and H.264 video. You set up your peering conditions to: Supported through: ilbc rfc4103 h.264 Transcoding: external<>internal G.711<>ilbc G.722<>ilbc h.263<>h.264 What should be specified in a peering requirement spec is the minimal sum= of the "supported through" and the external side of the transcoded pairs. That makes it possible for you to operate your network with cleanly specified terminals and still your customers may have calls with various kinds of terminals in peering networks in an ordered way. Agree? ANother dimension is to what degree you support passthrough of additional features as RFC 2833 DTMF transmission, redundancy or FEC coding and correction, hop-by-hop security methods, QOS etc. Gunnar -------------------------------------------------------------------------= --- - Gunnar Hellstr=F6m, Omnitor gunnar.hellstrom@omnitor.se Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Tuesday, August 08, 2006 6:08 PM To: Alexander Mayrhofer; Gunnar Hellstr=F6m Cc: speermint Subject: RE: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 > -----Original Message----- > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > Sent: Tuesday, August 08, 2006 9:34 AM > To: Gunnar Hellstr=F6m > Cc: speermint > Subject: Re: [Speermint]Mediarequirementsin draft-ietf-speermint- > requirements-00 > > Gunnar Hellstr=F6m wrote: > > Explicitly including some codecs can become a very healthy harmonizin= g > > factor, increasing the opportunity to get media through. > > What do you mean by requiring certain codecs? Does that mean that: > > - the peer does not filter out the respective SDP line? > - the peer is obliged to force his customers supporting the codec? (by > which > mechanism, btw? "codec police"?) > - that the peer MUST provide transcoding on behalf of the client for th= at > codec (and then, from what to what?) > > Perhaps we're talking about different issues here. My point is that if = you > _require_ a VoIP peer to support eg. real time text, and this peer is a= n > "open" peer ("open" in terms that he allows his customers to choose the= ir > own equipment, endpoints, etc. and media streams run end to end), there > would be almost certainly be an endpoint which does _not_ support that > codec. > [[Reinaldo]] I think we are forgetting the business aspect here. Are there such ISPs in Europe that allow you to choose whatever equipment you like and still support your installation? (This is a legitimate question). I haven't lived in Europe long enough to notice these things. In the US when you buy DSL or Cable service you receive the modem by mail= =2E You can choose your modem but it has to be on a list of supported modems, otherwise you are on your own. I cannot imagine an ISP supporting any end device/modem/phone, it would be a money black hole. I believe the real issue is at (or near) the peering point where you will have to possibly perform transcoding. > Would that mean that such a peer would then not be compliant, because o= ne > of > his customers does not support the REQUIRED codec? I can't imagine that= 's > the intent > > What about saying something like "Peers SHOULD NOT artificially limit t= he > set of codecs on behalf of their clients. In case the peer provides > transcoding services, the following codecs MUST be supported: ..."? > > BTW, "codecs" is not just the algorithm... the next rathole is "media > packet > sizes" (30ms packets anyone? :) Do we want to go down there? > > cheers > > alex > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 08 19:19:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAarE-0000h2-8U; Tue, 08 Aug 2006 19:19:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAarD-0000gx-95 for speermint@ietf.org; Tue, 08 Aug 2006 19:19:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAWgk-0005ge-4n for speermint@ietf.org; Tue, 08 Aug 2006 14:52:26 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAWDX-0002Bq-38 for speermint@ietf.org; Tue, 08 Aug 2006 14:22:18 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-2.cisco.com with ESMTP; 08 Aug 2006 11:22:14 -0700 X-IronPort-AV: i="4.07,222,1151910000"; d="scan'208"; a="334916750:sNHT71755770" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k78IMElS010010; Tue, 8 Aug 2006 11:22:14 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k78IMDuD027399; Tue, 8 Aug 2006 11:22:13 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 14:22:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Secure RTP Date: Tue, 8 Aug 2006 14:22:11 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301C6E4BF@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Secure RTP Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/AAABsDkAAAfWzgAMpSRNAAALXLQAAC38tg From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Geoff Devine" , "Patrick Melampy" , "Hadriel Kaplan" X-OriginalArrivalTime: 08 Aug 2006 18:22:12.0595 (UTC) FILETIME=[9179AC30:01C6BB17] DKIM-Signature: a=rsa-sha1; q=dns; l=17390; t=1155061334; x=1155925334; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Secure=20RTP; X=v=3Dcisco.com=3B=20h=3DTav7+aVDpl+QOgZ4O1J+VN4eGlM=3D; b=qyKhTC7PJUWmr4+zb46LYjTnIknRnP0cGlAdRV9e8L0Rt88xLo7CqsYNFD3Dk9rj0noHYHTT PCgQPnPUMg9jqraSjnqni//z2ISrPywTb+ino0OBujRzY2H3NX2eDi4F; Authentication-Results: sj-dkim-7.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 2c6813ed945e40b4b5bea39da243c669 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian, When you get to the point that you can't keep up with new offered calls, you may send a 503 that causes another server to get the added load. If that server was also near it's thrashing point, it may also start rejecting calls with 503 leading to yet another server getting overloaded, and so on. Retransmissions of the new call can oscillate through your servers searching for one that can handle a new call. But, in the mean time it takes resources to reject a call. The call gapping tells upstream elements how to limit the new load so that there is no rejection of call resource consumption. In your case, by suggesting the load balancer, you have merely moved the problem into the receiving network, but now creating a new point of congestion at the load balancer. Yeah, they are just servers, but presumable they have software on them, and presumable the software vendors don't write software for altruistic reasons, but need to make money too. And since revenue from voice is being pushed lower, I don't see SPs buying into massive server farms with 90% sitting idle. I agree though that this shouldn't be based on PSTN GW economics, we are trying to bypass that in Speermint. However, the need to police borders and actually charge for calls may have an impact anyway. I was looking for the ability to dynamically direct calls to various signaling border elements based on a variety of business and possibly varying technical needs, congestion being only one aspect. In some ways, this may be akin to load balancing, since based on some multifaceted criteria, it is making visible to any potential peer which signaling peering point to direct traffic to. Or deny access altogether. Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, August 08, 2006 12:45 PM > To: Michael Hammer (mhammer); 'Geoff Devine'; 'Patrick=20 > Melampy'; 'Hadriel Kaplan' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > I'm not so sure about that. >=20 > I do think that some of the folks that are designing VoIP=20 > systems make them look like telephone systems and thereby=20 > inherit the problems. I think many of the architectures=20 > being put forth have way too many elements, when only one or=20 > two (replicated of course) need to be there. I am always=20 > amazed comparing statistics of two VoIP networks that started=20 > accepting customers at around the same time, where one had a=20 > cost to first customer north of 100M and the other was=20 > something under 10. The cost of the millionth customer ALSO=20 > favored the latter, and it never turned around, while=20 > customers perceived the services to be equivalent (I'm sure=20 > the carriers didn't). >=20 > I'm not sure what you mean by "cascading failures" in this=20 > context. Please explain. >=20 > I'm also not sure that business economics don't allow you to=20 > have servers waiting for peak traffic. That depends on how=20 > these systems are built only a little, it more depend on how=20 > they are priced. >=20 > The "servers" here are the signaling elements, and they are=20 > just computers. > You can have a heck of a lot of computer sitting around doing=20 > nothing waiting for peak traffic. That isn't necessarily=20 > true of the media, of course. >=20 > Brian >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Tuesday, August 08, 2006 12:18 PM > > To: Brian Rosen; Geoff Devine; Patrick Melampy; Hadriel Kaplan > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Secure RTP > >=20 > > It is more like a telephone network than a Web service. > >=20 > > How do you explain cascading failures, then? > >=20 > > Also, the business economics don't allow you to have 90% of your=20 > > servers sitting around doing nothing just waiting for peak traffic. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, August 04, 2006 12:01 PM > > > To: 'Geoff Devine'; 'Patrick Melampy'; Michael Hammer (mhammer);=20 > > > 'Hadriel Kaplan' > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Secure RTP > > > > > > This isn't a telephone network. > > > > > > We typically DON'T have overload conditions on well engineered=20 > > > networks. We presently have some mighty fine self=20 > limiting issues=20 > > > with media, but if we had proper QoS on the media, that=20 > would be, I=20 > > > think, very sufficient congestion control. I've never=20 > seen a well=20 > > > engineered SIP based network where the signaling issues=20 > were a big=20 > > > problem. It's almost all in the media. > > > > > > I know all about "Americal Idol" night. The numbers just aren't=20 > > > scary any more. > > > > > > Do the math. A million BHCA is 278 calls per second. How many=20 > > > million do you want? Rack up the servers (best make them=20 > stateless,=20 > > > but that's not a problem). > > > > > > Sure, you need a load balancer. Sure, you need a=20 > failover strategy=20 > > > with a good database. > > > > > > Now, every system has limits. We have an answer for those: busy. > > > > > > More importantly, we actually can use some telephone=20 > engineering to=20 > > > predict the traffic at the peering point. We can=20 > engineer systems=20 > > > pretty straightforwardly to handle that traffic. We DO need some=20 > > > congestion control mechanisms, because the peering mechanisms we=20 > > > have do have finite capacity. However, I don't see much need for=20 > > > telephone style call gapping and only trivial metering. > > > > > > Today, we can build peering systems where the actual=20 > peering happens=20 > > > at multiple places around the globe, where there is no effective=20 > > > limits on signaling bandwith (or for that matter, media=20 > bandwith) to=20 > > > and from the peering points. We can have SIP proxies=20 > that perform=20 > > > the actual peering function (take a call, do a dip to determine=20 > > > where it's going, use available DNS and other mechanisms=20 > to spread=20 > > > load) that are similarly spread out and redundant enough=20 > that we get=20 > > > the kind of reliability we expect. And we can engineer=20 > them to take=20 > > > load up to a static limit reliably. > > > > > > What can't we do? > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > > > > Sent: Friday, August 04, 2006 11:35 AM > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer);=20 > > > > Hadriel Kaplan > > > > Cc: speermint@ietf.org > > > > 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=20 > 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:br@brianrosen.net] > > > > Sent: Friday, August 04, 2006 11:27 AM > > > > To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer=20 > (mhammer)';=20 > > > > 'Hadriel Kaplan' > > > > Cc: speermint@ietf.org > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > There is no evidence that you can't do this with the=20 > mechanisms we=20 > > > > 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:gdevine@cedarpointcom.com] > > > > > Sent: Friday, August 04, 2006 11:01 AM > > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer > > > (mhammer); Hadriel > > > > Kaplan > > > > > Cc: speermint@ietf.org > > > > > 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=20 > requirements for=20 > > > > > a web server. A web server doesn't have the moral=20 > and ethical=20 > > > > > obligation to ensure that the network is stable to=20 > complete 911=20 > > > > > calls. If the > > > > network > > > > > floods a soft switch or media gateway controller with peering=20 > > > > > 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:br@brianrosen.net] > > > > > Sent: Friday, August 04, 2006 10:20 AM > > > > > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > 'Hadriel Kaplan' > > > > > Cc: speermint@ietf.org > > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > > > I don't think any of this is something we are=20 > chartered to do. =20 > > > > > 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=20 > > > > > handle > > > > HTTP > > > > > load, and I don't see any reason we shouldn't use all=20 > of those=20 > > > > > techniques to deal with SIP load. I certainly don't see > > > reasons to > > > > > make the originator aware of congestion issues at the=20 > > > > > terminating domain, beyond the contractual limits=20 > 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=20 > time I can=20 > > > > > 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=20 > > > > > least the complexity it introduced was not worth the=20 > value it provided). > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > > > > Sent: Friday, August 04, 2006 9:59 AM > > > > > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)';=20 > 'Hadriel Kaplan' > > > > > > Cc: speermint@ietf.org > > > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > > > > > Brian, > > > > > > > > > > > > I agree with you. However some aspects are protocol > > > worthy. Path > > > > > > determination -- or said another way -- the next=20 > hop network=20 > > > > > > to use > > > > to > > > > > > reach > > > > > > a destination domain, must be partially provisioned, > > > and partially > > > > > > discovered. The discovery aspects are the dynamic aspects.=20 > > > > > > 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=20 > the protocol > > > > family, > > > > > and > > > > > > ISUP messages are sent to bring circuits in and out=20 > 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,=20 > > > > > > maximum > > > > > sessions > > > > > > permitted, and maximum bandwidth to use. > > > > > > > > > > > > In #2 -- reachable domains -- Unlike the PSTN which=20 > uses the=20 > > > > > > 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=20 > > > > > > advertisement protocol that goes network to network. Thus a=20 > > > > > > protocol is required > > > > > here. > > > > > > > > > > > > In #3 -- congestion -- is dynamic and not=20 > 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=20 > also think we=20 > > > > > > need > > > > to > > > > > > leave > > > > > > to the individual networks, any and all decisions on how to=20 > > > > > > run > > > > their > > > > > > networks, choose next networks, etc. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Friday, August 04, 2006 8:47 AM > > > > > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > > > Cc: speermint@ietf.org > > > > > > 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=20 > for peers=20 > > > > > > 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=20 > mechanisms exist to > > > > > provision. > > > > > > So, for example, if one of the things peering means is that=20 > > > > > > the rate > > > > > of > > > > > > calls is limited in some way, then we probably have to > > > standardize > > > > the > > > > > > definition of limiting, but not the way to=20 > determine what the=20 > > > > > > 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. =20 > This is not=20 > > > > > > 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=20 > their values=20 > > > > > > are > > > > > limited > > > > > > to. > > > > > > It clearly WILL do that for some variables, and again, we=20 > > > > > > don't need automatic provisioning mechanisms to discover=20 > > > > > > these. Even within a federation, I think it will be common=20 > > > > > > that bilateral arrangements > > > > > making > > > > > > further policy limitations will exist. > > > > > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > > > > > Sent: Thursday, August 03, 2006 3:13 PM > > > > > > > To: Hadriel Kaplan; Brian Rosen > > > > > > > Cc: speermint@ietf.org > > > > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > > > > > > > The focus of Speermint should be centered around > > > whether one can > > > > > > > discover the policies of a potential peer and=20 > whether those > > > > policies > > > > > can > > > > > > > systematically describe the requirements on multiple > > > levels that > > > > > will > > > > > > > need to be supported to have a successful=20 > communication with=20 > > > > > > > that > > > > > peer. > > > > > > > > > > > > > > It is not about specifying X, Y, Z, or > > 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=20 > different MUSTs=20 > > > > > > > for > > > > each > > > > > > > category of choices we come up with. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 07:46:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAmVy-00030Y-Al; Wed, 09 Aug 2006 07:46:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAmVx-00030T-Jc for speermint@ietf.org; Wed, 09 Aug 2006 07:46:21 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAmVw-0004DV-53 for speermint@ietf.org; Wed, 09 Aug 2006 07:46:21 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id EF1F621001A; Wed, 9 Aug 2006 13:46:14 +0200 (CEST) Message-ID: <44D9CB15.3080806@pernau.at> Date: Wed, 09 Aug 2006 13:46:29 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: timothy.dwight@verizon.com Subject: Re: DNS performance (was Re: [Speermint] TLs performance) References: <000301c6baf2$55c4f160$bf4632a6@mcilink.com> In-Reply-To: <000301c6baf2$55c4f160$bf4632a6@mcilink.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org What happens if there a number ported and the central LNP gets updated. How are the updates distributed to the carriers? Immediately pushed to the carriers? Or do the carriers fetch updates on a regular basis? regards klaus Tim Dwight wrote: > There is in country code 1 a central database-of-record, operated by the > NPAC, from which carriers download LNP data into systems within their own > networks; "systems" being in theory SCPs although in practice this service > is sometimes integrated into the STPs. Point being that while the > database-of-record is centrally administered LNP resolution is performed in > a decentralized manner within individual carrier networks. > > tim > > >> -----Original Message----- >> From: Geoff Devine [mailto:gdevine@cedarpointcom.com] >> Sent: Tuesday, August 08, 2006 5:40 AM >> To: Klaus Darilion >> Cc: speermint@ietf.org >> Subject: RE: DNS performance (was Re: [Speermint] TLs performance) >> >> In the US? Yes. A centralized LNP database is queried. >> >> In many other countries, a huge file is distributed once per >> day. Welcome to the stone age. >> >> Geoff >> >> -----Original Message----- >> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >> Sent: Tue 8/8/2006 6:07 AM >> To: Geoff Devine >> Cc: Duane; Francois Menard; speermint@ietf.org >> Subject: Re: DNS performance (was Re: [Speermint] TLs performance) >> >> Geoff Devine wrote: >>> That's not the way LNP works today. >>> >>> Class 5 offices have temporary triggers for the window >> where a number >>> is being ported. The definitive location of the subscriber >> is kept in >>> the LNP database. When that database is updated, all calls >> route to >>> the ported destination. You're violating the LNP >> requirements if you >>> route the call to the wrong class 5 switch after the LNP >> database has >>> changed. >> Thus, for each call the central LNP database is queried? >> >> regards klaus >> >>> There are 300 million telephone numbers in the United States. It's >>> unlikely many of them will be in a cache. This isn't like caching >>> "google.com". >>> >>> Geoff >>> >>> -----Original Message----- From: Duane [mailto:duane@e164.org] Sent: >>> Mon 8/7/2006 7:04 PM To: Francois Menard Cc: speermint@ietf.org >>> Subject: RE: DNS performance (was Re: [Speermint] TLs performance) >>> >>> On Mon, 2006-08-07 at 17:50 -0500, Francois Menard wrote: >>>> I guess it all depends on how realtime you want your LNP to be... >>> I doubt carriers anywhere would give you a time to change over in >>> minutes, it would be closer to hours, so even having a 10 to 30 >>> minutes TTL wouldn't harm things from LNP point of view... >>> >> >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint >> > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 07:59:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAmiI-00017f-Eo; Wed, 09 Aug 2006 07:59:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAmiH-00017a-BK for speermint@ietf.org; Wed, 09 Aug 2006 07:59:05 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAmiF-0005Nd-2z for speermint@ietf.org; Wed, 09 Aug 2006 07:59:05 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 5E8D321001A; Wed, 9 Aug 2006 13:59:02 +0200 (CEST) Message-ID: <44D9CE12.6090002@pernau.at> Date: Wed, 09 Aug 2006 13:59:14 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Speermint] Congestion and Load Balancing References: <07e301c6bb0c$10ed32e0$9de6a8c0@cis.neustar.com> In-Reply-To: <07e301c6bb0c$10ed32e0$9de6a8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 662324ecda47446db09bfd0a0092c4ba Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:PMelampy@acmepacket.com] >> Sent: Saturday, August 05, 2006 4:42 PM >> To: 'Brian Rosen' >> Cc: speermint@ietf.org >> 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:br@brianrosen.net] >> Sent: Friday, August 04, 2006 2:28 PM >> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer >> (mhammer)'; 'Hadriel Kaplan' >> Cc: speermint@ietf.org >> 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:rpenno@juniper.net] >>> Sent: Friday, August 04, 2006 2:14 PM >>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer >> (mhammer); >>> Hadriel Kaplan >>> Cc: speermint@ietf.org >>> 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:br@brianrosen.net] >>>> Sent: Friday, August 04, 2006 10:47 AM >>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; >>>> 'Hadriel Kaplan' >>>> Cc: speermint@ietf.org >>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: Secure >>> RTP >>>> >>> 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:PMelampy@acmepacket.com] >>>>> Sent: Friday, August 04, 2006 12:39 PM >>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; >>> 'Hadriel >>>>> Kaplan' >>>>> Cc: speermint@ietf.org >>>>> 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:br@brianrosen.net] >>>>> Sent: Friday, August 04, 2006 12:01 PM >>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; >>>>> 'Hadriel >>>>> Kaplan' >>>>> Cc: speermint@ietf.org >>>>> 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:gdevine@cedarpointcom.com] >>>>>> Sent: Friday, August 04, 2006 11:35 AM >>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); >>> Hadriel >>>>> Kaplan >>>>>> Cc: speermint@ietf.org >>>>>> 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:br@brianrosen.net] >>>>>> Sent: Friday, August 04, 2006 11:27 AM >>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; >>>>>> 'Hadriel Kaplan' >>>>>> Cc: speermint@ietf.org >>>>>> 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:gdevine@cedarpointcom.com] >>>>>>> Sent: Friday, August 04, 2006 11:01 AM >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); >>> Hadriel >>>>>> Kaplan >>>>>>> Cc: speermint@ietf.org >>>>>>> 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:br@brianrosen.net] >>>>>>> Sent: Friday, August 04, 2006 10:20 AM >>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel >>> Kaplan' >>>>>>> Cc: speermint@ietf.org >>>>>>> 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:PMelampy@acmepacket.com] >>>>>>>> Sent: Friday, August 04, 2006 9:59 AM >>>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel >>> Kaplan' >>>>>>>> Cc: speermint@ietf.org >>>>>>>> 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:br@brianrosen.net] >>>>>>>> Sent: Friday, August 04, 2006 8:47 AM >>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' >>>>>>>> Cc: speermint@ietf.org >>>>>>>> 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:mhammer@cisco.com] >>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM >>>>>>>>> To: Hadriel Kaplan; Brian Rosen >>>>>>>>> Cc: speermint@ietf.org >>>>>>>>> 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 >> 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 >>>> Speermint@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 08:04:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAmnT-0003i9-1g; Wed, 09 Aug 2006 08:04:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAmnS-0003i4-96 for speermint@ietf.org; Wed, 09 Aug 2006 08:04:26 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GAmnQ-0005uN-Ry for speermint@ietf.org; Wed, 09 Aug 2006 08:04:26 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1155125039!11048312!4 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 4644 invoked from network); 9 Aug 2006 12:04:22 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-5.tower-120.messagelabs.com with SMTP; 9 Aug 2006 12:04:22 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 44BA63B2003AA54A; Wed, 9 Aug 2006 08:04:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DNS performance (was Re: [Speermint] TLs performance) Date: Wed, 9 Aug 2006 08:04:19 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0D67A5DF@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <44D9CB15.3080806@pernau.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS performance (was Re: [Speermint] TLs performance) Thread-Index: Aca7qYJ2NS7OUxrDSP2KNqgnwyQ50wAAjuVA From: "Pfautz, Penn L, GBLAM" To: "Klaus Darilion" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org There is an immediate push from the central database to the carriers service management systems. Carriers then must update their realtime call processing databases.=20 -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 Sent: Wednesday, August 09, 2006 7:46 AM To: timothy.dwight@verizon.com Cc: speermint@ietf.org Subject: Re: DNS performance (was Re: [Speermint] TLs performance) What happens if there a number ported and the central LNP gets updated.=20 How are the updates distributed to the carriers? Immediately pushed to=20 the carriers? Or do the carriers fetch updates on a regular basis? regards klaus Tim Dwight wrote: > There is in country code 1 a central database-of-record, operated by the > NPAC, from which carriers download LNP data into systems within their own > networks; "systems" being in theory SCPs although in practice this service > is sometimes integrated into the STPs. Point being that while the > database-of-record is centrally administered LNP resolution is performed in > a decentralized manner within individual carrier networks. >=20 > tim >=20 >=20 >> -----Original Message----- >> From: Geoff Devine [mailto:gdevine@cedarpointcom.com]=20 >> Sent: Tuesday, August 08, 2006 5:40 AM >> To: Klaus Darilion >> Cc: speermint@ietf.org >> Subject: RE: DNS performance (was Re: [Speermint] TLs performance) >> >> In the US? Yes. A centralized LNP database is queried. >> >> In many other countries, a huge file is distributed once per=20 >> day. Welcome to the stone age. >> >> Geoff >> >> -----Original Message----- >> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >> Sent: Tue 8/8/2006 6:07 AM >> To: Geoff Devine >> Cc: Duane; Francois Menard; speermint@ietf.org >> Subject: Re: DNS performance (was Re: [Speermint] TLs performance) >> =20 >> Geoff Devine wrote: >>> That's not the way LNP works today. >>> >>> Class 5 offices have temporary triggers for the window=20 >> where a number=20 >>> is being ported. The definitive location of the subscriber=20 >> is kept in=20 >>> the LNP database. When that database is updated, all calls=20 >> route to=20 >>> the ported destination. You're violating the LNP=20 >> requirements if you=20 >>> route the call to the wrong class 5 switch after the LNP=20 >> database has=20 >>> changed. >> Thus, for each call the central LNP database is queried? >> >> regards klaus >> >>> There are 300 million telephone numbers in the United States. It's=20 >>> unlikely many of them will be in a cache. This isn't like caching=20 >>> "google.com". >>> >>> Geoff >>> >>> -----Original Message----- From: Duane [mailto:duane@e164.org] Sent: >>> Mon 8/7/2006 7:04 PM To: Francois Menard Cc: speermint@ietf.org >>> Subject: RE: DNS performance (was Re: [Speermint] TLs performance) >>> >>> On Mon, 2006-08-07 at 17:50 -0500, Francois Menard wrote: >>>> I guess it all depends on how realtime you want your LNP to be... >>> I doubt carriers anywhere would give you a time to change over in=20 >>> minutes, it would be closer to hours, so even having a 10 to 30=20 >>> minutes TTL wouldn't harm things from LNP point of view... >>> >> >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint >> >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 08:28:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAnAc-0008Bb-Py; Wed, 09 Aug 2006 08:28:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAnAb-0008BW-II for speermint@ietf.org; Wed, 09 Aug 2006 08:28:21 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAnAa-0007pc-IB for speermint@ietf.org; Wed, 09 Aug 2006 08:28:21 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 49665210014; Wed, 9 Aug 2006 14:28:19 +0200 (CEST) Message-ID: <44D9D4F2.7060803@pernau.at> Date: Wed, 09 Aug 2006 14:28:34 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Geoff Devine Subject: Re: [Speermint] Secure RTP References: <402F25FC1EB2BD44831F8A4A4F6DF94214C87D@MAIL02.cedarpointcom.com> In-Reply-To: <402F25FC1EB2BD44831F8A4A4F6DF94214C87D@MAIL02.cedarpointcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 426dd6ea860196690cb99367d860d19e Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Geoff Devine wrote: > I agree 100% with this analysis of what can happen when you use 503. > There is a real risk that it can cause the network to overload. > > That said, I think you guys are missing a use case: > > I have a media gateway in New York. My peer has a media gateway in San > Francisco. One of my New York subscribers dials a San Francisco > telephone number. This number is not a VoIP device. I want to use the > peer media gateway in San Francisco whenever possible to avoid carrier > charges. > > In this use case, PSTN gateway economics are certainly a consideration. > The media gateway controller in San Francisco has finite resources and > it would be a poor architecture to send INVITE messages to it from New > York when it is congested. If you have 2 GWs, both under your control, distributing the load status of the gateways is rather easy. But it gets complicated if there are lots of peers, and in a federation peering scenario you do not even know each of your peers. It really gets complicated to send all possible peers the current load of your ingress point. That does not scale. regards klaus > > Geoff > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, August 08, 2006 2:22 PM > To: Brian Rosen; Geoff Devine; Patrick Melampy; Hadriel Kaplan > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP > > Brian, > > When you get to the point that you can't keep up with new offered calls, > you may send a 503 that causes another server to get the added load. If > that server was also near it's thrashing point, it may also start > rejecting calls with 503 leading to yet another server getting > overloaded, and so on. Retransmissions of the new call can oscillate > through your servers searching for one that can handle a new call. But, > in the mean time it takes resources to reject a call. The call gapping > tells upstream elements how to limit the new load so that there is no > rejection of call resource consumption. > > In your case, by suggesting the load balancer, you have merely moved the > problem into the receiving network, but now creating a new point of > congestion at the load balancer. > > Yeah, they are just servers, but presumable they have software on them, > and presumable the software vendors don't write software for altruistic > reasons, but need to make money too. And since revenue from voice is > being pushed lower, I don't see SPs buying into massive server farms > with 90% sitting idle. > > I agree though that this shouldn't be based on PSTN GW economics, we are > trying to bypass that in Speermint. However, the need to police borders > and actually charge for calls may have an impact anyway. > > I was looking for the ability to dynamically direct calls to various > signaling border elements based on a variety of business and possibly > varying technical needs, congestion being only one aspect. In some > ways, this may be akin to load balancing, since based on some > multifaceted criteria, it is making visible to any potential peer which > signaling peering point to direct traffic to. Or deny access > altogether. > > Mike > > >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Tuesday, August 08, 2006 12:45 PM >> To: Michael Hammer (mhammer); 'Geoff Devine'; 'Patrick >> Melampy'; 'Hadriel Kaplan' >> Cc: speermint@ietf.org >> Subject: RE: [Speermint] Secure RTP >> >> I'm not so sure about that. >> >> I do think that some of the folks that are designing VoIP >> systems make them look like telephone systems and thereby >> inherit the problems. I think many of the architectures >> being put forth have way too many elements, when only one or >> two (replicated of course) need to be there. I am always >> amazed comparing statistics of two VoIP networks that started >> accepting customers at around the same time, where one had a >> cost to first customer north of 100M and the other was >> something under 10. The cost of the millionth customer ALSO >> favored the latter, and it never turned around, while >> customers perceived the services to be equivalent (I'm sure >> the carriers didn't). >> >> I'm not sure what you mean by "cascading failures" in this >> context. Please explain. >> >> I'm also not sure that business economics don't allow you to >> have servers waiting for peak traffic. That depends on how >> these systems are built only a little, it more depend on how >> they are priced. >> >> The "servers" here are the signaling elements, and they are >> just computers. >> You can have a heck of a lot of computer sitting around doing >> nothing waiting for peak traffic. That isn't necessarily >> true of the media, of course. >> >> Brian >> >>> -----Original Message----- >>> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >>> Sent: Tuesday, August 08, 2006 12:18 PM >>> To: Brian Rosen; Geoff Devine; Patrick Melampy; Hadriel Kaplan >>> Cc: speermint@ietf.org >>> Subject: RE: [Speermint] Secure RTP >>> >>> It is more like a telephone network than a Web service. >>> >>> How do you explain cascading failures, then? >>> >>> Also, the business economics don't allow you to have 90% of your >>> servers sitting around doing nothing just waiting for peak traffic. >>> >>> Mike >>> >>> >>>> -----Original Message----- >>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>> Sent: Friday, August 04, 2006 12:01 PM >>>> To: 'Geoff Devine'; 'Patrick Melampy'; Michael Hammer (mhammer); >>>> 'Hadriel Kaplan' >>>> Cc: speermint@ietf.org >>>> 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:gdevine@cedarpointcom.com] >>>>> Sent: Friday, August 04, 2006 11:35 AM >>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); >>>>> Hadriel Kaplan >>>>> Cc: speermint@ietf.org >>>>> 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:br@brianrosen.net] >>>>> Sent: Friday, August 04, 2006 11:27 AM >>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer >> (mhammer)'; >>>>> 'Hadriel Kaplan' >>>>> Cc: speermint@ietf.org >>>>> 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:gdevine@cedarpointcom.com] >>>>>> Sent: Friday, August 04, 2006 11:01 AM >>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer >>>> (mhammer); Hadriel >>>>> Kaplan >>>>>> Cc: speermint@ietf.org >>>>>> 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:br@brianrosen.net] >>>>>> Sent: Friday, August 04, 2006 10:20 AM >>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; >>>> 'Hadriel Kaplan' >>>>>> Cc: speermint@ietf.org >>>>>> 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:PMelampy@acmepacket.com] >>>>>>> Sent: Friday, August 04, 2006 9:59 AM >>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; >> 'Hadriel Kaplan' >>>>>>> Cc: speermint@ietf.org >>>>>>> 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:br@brianrosen.net] >>>>>>> Sent: Friday, August 04, 2006 8:47 AM >>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' >>>>>>> Cc: speermint@ietf.org >>>>>>> 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:mhammer@cisco.com] >>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM >>>>>>>> To: Hadriel Kaplan; Brian Rosen >>>>>>>> Cc: speermint@ietf.org >>>>>>>> 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 >>> 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 > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 08:31:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAnDs-00015J-Bn; Wed, 09 Aug 2006 08:31:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAnDr-000156-7P for speermint@ietf.org; Wed, 09 Aug 2006 08:31:43 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAnDp-00083W-Ta for speermint@ietf.org; Wed, 09 Aug 2006 08:31:43 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 52259210014; Wed, 9 Aug 2006 14:31:41 +0200 (CEST) Message-ID: <44D9D5BC.1030901@pernau.at> Date: Wed, 09 Aug 2006 14:31:56 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Reinaldo Penno Subject: Re: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 References: <9BD5D7887235424FA97DFC223CAE3C2805182E3D@proton.jnpr.net> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2805182E3D@proton.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Reinaldo Penno wrote: > > I think we are forgetting the business aspect here. > > Are there such ISPs in Europe that allow you to choose whatever > equipment you like and still support your installation? (This is a > legitimate question). I haven't lived in Europe long enough to notice > these things. Yes, there are such ISPs. You get your SIP provisioning data and can use any SIP client. regards klaus > > In the US when you buy DSL or Cable service you receive the modem by > mail. You can choose your modem but it has to be on a list of > supported modems, otherwise you are on your own. I cannot imagine an > ISP supporting any end device/modem/phone, it would be a money black > hole. > > I believe the real issue is at (or near) the peering point where you > will have to possibly perform transcoding. > > >> Would that mean that such a peer would then not be compliant, >> because one of his customers does not support the REQUIRED codec? I >> can't imagine that's the intent >> >> What about saying something like "Peers SHOULD NOT artificially >> limit the set of codecs on behalf of their clients. In case the >> peer provides transcoding services, the following codecs MUST be >> supported: ..."? >> >> BTW, "codecs" is not just the algorithm... the next rathole is >> "media packet sizes" (30ms packets anyone? :) Do we want to go down >> there? >> >> cheers >> >> alex >> >> _______________________________________________ Speermint mailing >> list Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing > list Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 08:37:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAnJ0-00049f-1A; Wed, 09 Aug 2006 08:37:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAnIz-00049a-Gq for speermint@ietf.org; Wed, 09 Aug 2006 08:37:01 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAnIy-0008Hx-70 for speermint@ietf.org; Wed, 09 Aug 2006 08:37:01 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 09 Aug 2006 05:37:05 -0700 X-IronPort-AV: i="4.07,224,1151910000"; d="scan'208"; a="575773929:sNHT35037992" x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 Date: Wed, 9 Aug 2006 08:37:15 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2805182F3C@proton.jnpr.net> In-Reply-To: <44D9D5BC.1030901@pernau.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 Thread-Index: Aca7r9tXeQo74NLpS8WpL8eGxEnmdwAAHj6A From: "Reinaldo Penno" To: "Klaus Darilion" X-Spam-Score: 1.1 (+) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Do they guarantee universal call completion? By that I mean, can you = make a call to anywhere and send/receive media? Do they perform = transcoding to achieve that? > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Wednesday, August 09, 2006 5:32 AM > To: Reinaldo Penno > Cc: Alexander Mayrhofer; Gunnar Hellstr=F6m; speermint > Subject: Re: [Speermint]Mediarequirementsin draft-ietf-speermint- > requirements-00 >=20 > Reinaldo Penno wrote: > > > > I think we are forgetting the business aspect here. > > > > Are there such ISPs in Europe that allow you to choose whatever > > equipment you like and still support your installation? (This is a > > legitimate question). I haven't lived in Europe long enough to = notice > > these things. >=20 > Yes, there are such ISPs. You get your SIP provisioning data and can = use > any SIP client. >=20 > regards > klaus >=20 > > > > In the US when you buy DSL or Cable service you receive the modem by > > mail. You can choose your modem but it has to be on a list of > > supported modems, otherwise you are on your own. I cannot imagine an > > ISP supporting any end device/modem/phone, it would be a money black > > hole. > > > > I believe the real issue is at (or near) the peering point where you > > will have to possibly perform transcoding. > > > > > >> Would that mean that such a peer would then not be compliant, > >> because one of his customers does not support the REQUIRED codec? I > >> can't imagine that's the intent > >> > >> What about saying something like "Peers SHOULD NOT artificially > >> limit the set of codecs on behalf of their clients. In case the > >> peer provides transcoding services, the following codecs MUST be > >> supported: ..."? > >> > >> BTW, "codecs" is not just the algorithm... the next rathole is > >> "media packet sizes" (30ms packets anyone? :) Do we want to go down > >> there? > >> > >> cheers > >> > >> alex > >> > >> _______________________________________________ Speermint mailing > >> list Speermint@ietf.org > >> https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ Speermint mailing > > list Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 09:38:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAoGU-0002Mf-LN; Wed, 09 Aug 2006 09:38:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAoGU-0002Ma-7L for speermint@ietf.org; Wed, 09 Aug 2006 09:38:30 -0400 Received: from 66.254.241.83.in-addr.dgcsystems.net ([83.241.254.66] helo=smtp.dgcsystems.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAoGS-0003r4-Ot for speermint@ietf.org; Wed, 09 Aug 2006 09:38:30 -0400 Received: from Misan ([217.13.240.136]) by smtp.dgcsystems.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 15:38:27 +0200 From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "Reinaldo Penno" , "Klaus Darilion" Subject: RE: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 Date: Wed, 9 Aug 2006 14:38:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2805182F3C@proton.jnpr.net> Importance: Normal X-OriginalArrivalTime: 09 Aug 2006 13:38:27.0313 (UTC) FILETIME=[18078E10:01C6BBB9] X-Spam-Score: 1.1 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I know ISP:s who enable SIP calls anywhere, but not with any transcoding. Gunnar -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Wednesday, August 09, 2006 1:37 PM To: Klaus Darilion Cc: Alexander Mayrhofer; Gunnar Hellström; speermint Subject: RE: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 Do they guarantee universal call completion? By that I mean, can you make a call to anywhere and send/receive media? Do they perform transcoding to achieve that? > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Wednesday, August 09, 2006 5:32 AM > To: Reinaldo Penno > Cc: Alexander Mayrhofer; Gunnar Hellström; speermint > Subject: Re: [Speermint]Mediarequirementsin draft-ietf-speermint- > requirements-00 > > Reinaldo Penno wrote: > > > > I think we are forgetting the business aspect here. > > > > Are there such ISPs in Europe that allow you to choose whatever > > equipment you like and still support your installation? (This is a > > legitimate question). I haven't lived in Europe long enough to notice > > these things. > > Yes, there are such ISPs. You get your SIP provisioning data and can use > any SIP client. > > regards > klaus > > > > > In the US when you buy DSL or Cable service you receive the modem by > > mail. You can choose your modem but it has to be on a list of > > supported modems, otherwise you are on your own. I cannot imagine an > > ISP supporting any end device/modem/phone, it would be a money black > > hole. > > > > I believe the real issue is at (or near) the peering point where you > > will have to possibly perform transcoding. > > > > > >> Would that mean that such a peer would then not be compliant, > >> because one of his customers does not support the REQUIRED codec? I > >> can't imagine that's the intent > >> > >> What about saying something like "Peers SHOULD NOT artificially > >> limit the set of codecs on behalf of their clients. In case the > >> peer provides transcoding services, the following codecs MUST be > >> supported: ..."? > >> > >> BTW, "codecs" is not just the algorithm... the next rathole is > >> "media packet sizes" (30ms packets anyone? :) Do we want to go down > >> there? > >> > >> cheers > >> > >> alex > >> > >> _______________________________________________ Speermint mailing > >> list Speermint@ietf.org > >> https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ Speermint mailing > > list Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 09:47:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAoPe-0005wS-8e; Wed, 09 Aug 2006 09:47:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAoPc-0005wN-T3 for speermint@ietf.org; Wed, 09 Aug 2006 09:47:56 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAoPb-0004pw-Ic for speermint@ietf.org; Wed, 09 Aug 2006 09:47:56 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 09 Aug 2006 06:48:00 -0700 X-IronPort-AV: i="4.07,225,1151910000"; d="scan'208"; a="570118252:sNHT35406756" x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 Date: Wed, 9 Aug 2006 09:48:11 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2805182F60@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 Thread-Index: Aca7uTXsVRXkJEk+TD+5FbiObwIQSgAAQfXA From: "Reinaldo Penno" To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= , "Klaus Darilion" X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hello Gunnar, Not sure I follow your explanation. Is there a website for such ISP(s) = that allows a user to use any SIP endpoint and guarantee call completion = across the planet? I'm really curious on how they opearate... Thanks, Reinaldo > -----Original Message----- > From: Gunnar Hellstr=F6m [mailto:gunnar.hellstrom@omnitor.se] > Sent: Wednesday, August 09, 2006 6:38 AM > To: Reinaldo Penno; Klaus Darilion > Cc: Alexander Mayrhofer; speermint > Subject: RE: [Speermint]Mediarequirementsin draft-ietf-speermint- > requirements-00 >=20 > I know ISP:s who enable SIP calls anywhere, but not with any = transcoding. >=20 > Gunnar >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Wednesday, August 09, 2006 1:37 PM > To: Klaus Darilion > Cc: Alexander Mayrhofer; Gunnar Hellstr=F6m; speermint > Subject: RE: [Speermint]Mediarequirementsin > draft-ietf-speermint-requirements-00 >=20 >=20 > Do they guarantee universal call completion? By that I mean, can you = make > a > call to anywhere and send/receive media? Do they perform transcoding = to > achieve that? >=20 >=20 >=20 > > -----Original Message----- > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > Sent: Wednesday, August 09, 2006 5:32 AM > > To: Reinaldo Penno > > Cc: Alexander Mayrhofer; Gunnar Hellstr=F6m; speermint > > Subject: Re: [Speermint]Mediarequirementsin draft-ietf-speermint- > > requirements-00 > > > > Reinaldo Penno wrote: > > > > > > I think we are forgetting the business aspect here. > > > > > > Are there such ISPs in Europe that allow you to choose whatever > > > equipment you like and still support your installation? (This is a > > > legitimate question). I haven't lived in Europe long enough to = notice > > > these things. > > > > Yes, there are such ISPs. You get your SIP provisioning data and can = use > > any SIP client. > > > > regards > > klaus > > > > > > > > In the US when you buy DSL or Cable service you receive the modem = by > > > mail. You can choose your modem but it has to be on a list of > > > supported modems, otherwise you are on your own. I cannot imagine = an > > > ISP supporting any end device/modem/phone, it would be a money = black > > > hole. > > > > > > I believe the real issue is at (or near) the peering point where = you > > > will have to possibly perform transcoding. > > > > > > > > >> Would that mean that such a peer would then not be compliant, > > >> because one of his customers does not support the REQUIRED codec? = I > > >> can't imagine that's the intent > > >> > > >> What about saying something like "Peers SHOULD NOT artificially > > >> limit the set of codecs on behalf of their clients. In case the > > >> peer provides transcoding services, the following codecs MUST be > > >> supported: ..."? > > >> > > >> BTW, "codecs" is not just the algorithm... the next rathole is > > >> "media packet sizes" (30ms packets anyone? :) Do we want to go = down > > >> there? > > >> > > >> cheers > > >> > > >> alex > > >> > > >> _______________________________________________ Speermint mailing > > >> list Speermint@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ Speermint mailing > > > list Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 09:48:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAoQc-0006EA-KS; Wed, 09 Aug 2006 09:48:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAoQb-0006Dw-AV for speermint@ietf.org; Wed, 09 Aug 2006 09:48:57 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAoQZ-0004wn-Vw for speermint@ietf.org; Wed, 09 Aug 2006 09:48:57 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GAoQT-0004w8-4a; Wed, 09 Aug 2006 08:48:49 -0500 From: "Brian Rosen" To: "'Reinaldo Penno'" , "'Klaus Darilion'" Subject: RE: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 Date: Wed, 9 Aug 2006 09:48:50 -0400 Message-ID: <095d01c6bbba$8d93e970$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7r9tXeQo74NLpS8WpL8eGxEnmdwAAHj6AAAJN5pA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2805182F3C@proton.jnpr.net> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.1 (+) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: 'speermint' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org One thing that may inform this discussion is that it's been common that requirements for emergency calls (1-1-2/9-1-1/...) often end up driving requirements elsewhere in telecommunications systems. We're doing some = work in ecrit on support of emergency calls on the Internet, and the subject = of codecs is in discussion there. =20 Looks like (no decisions yet) we WILL have a short list of codecs that = end up being MUST IMPLEMENT on phones (at least one of) and PSAPs (all of). SPEERMINT could reference that document, which will be a BCP. Clearly, = the problem there is acute; you must have a compatible codec between a = caller and the emergency center if you are to be able to get help. It could be that such a list ends up being MUST only for g.711 (at least A, probably mu), and SHOULD for things like AMR, EvRC, iLBC, and possibly g.729 as = well as AMR-WB and some form of g.722. Brian > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Wednesday, August 09, 2006 8:37 AM > To: Klaus Darilion > Cc: speermint > Subject: RE: [Speermint]Mediarequirementsin draft-ietf-speermint- > requirements-00 >=20 > Do they guarantee universal call completion? By that I mean, can you = make > a call to anywhere and send/receive media? Do they perform transcoding = to > achieve that? >=20 >=20 >=20 > > -----Original Message----- > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > Sent: Wednesday, August 09, 2006 5:32 AM > > To: Reinaldo Penno > > Cc: Alexander Mayrhofer; Gunnar Hellstr=F6m; speermint > > Subject: Re: [Speermint]Mediarequirementsin draft-ietf-speermint- > > requirements-00 > > > > Reinaldo Penno wrote: > > > > > > I think we are forgetting the business aspect here. > > > > > > Are there such ISPs in Europe that allow you to choose whatever > > > equipment you like and still support your installation? (This is a > > > legitimate question). I haven't lived in Europe long enough to = notice > > > these things. > > > > Yes, there are such ISPs. You get your SIP provisioning data and can = use > > any SIP client. > > > > regards > > klaus > > > > > > > > In the US when you buy DSL or Cable service you receive the modem = by > > > mail. You can choose your modem but it has to be on a list of > > > supported modems, otherwise you are on your own. I cannot imagine = an > > > ISP supporting any end device/modem/phone, it would be a money = black > > > hole. > > > > > > I believe the real issue is at (or near) the peering point where = you > > > will have to possibly perform transcoding. > > > > > > > > >> Would that mean that such a peer would then not be compliant, > > >> because one of his customers does not support the REQUIRED codec? = I > > >> can't imagine that's the intent > > >> > > >> What about saying something like "Peers SHOULD NOT artificially > > >> limit the set of codecs on behalf of their clients. In case the > > >> peer provides transcoding services, the following codecs MUST be > > >> supported: ..."? > > >> > > >> BTW, "codecs" is not just the algorithm... the next rathole is > > >> "media packet sizes" (30ms packets anyone? :) Do we want to go = down > > >> there? > > >> > > >> cheers > > >> > > >> alex > > >> > > >> _______________________________________________ Speermint mailing > > >> list Speermint@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ Speermint mailing > > > list Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 10:59:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GApX5-0003Yl-OI; Wed, 09 Aug 2006 10:59:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GApX3-0003WT-NQ for speermint@ietf.org; Wed, 09 Aug 2006 10:59:41 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=MAILSRV01.cedarpointcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GApX3-0003mY-09 for speermint@ietf.org; Wed, 09 Aug 2006 10:59:41 -0400 Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 10:59:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Congestion & load balancing Date: Wed, 9 Aug 2006 10:59:39 -0400 Message-ID: <402F25FC1EB2BD44831F8A4A4F6DF94214C9AF@MAIL02.cedarpointcom.com> In-Reply-To: <44D9D4F2.7060803@pernau.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Congestion & load balancing Thread-Index: Aca7r03HgtCuur2NQK27JFSr7IgwLwAFDqKw From: "Geoff Devine" To: "Klaus Darilion" X-OriginalArrivalTime: 09 Aug 2006 14:59:40.0155 (UTC) FILETIME=[70783CB0:01C6BBC4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4863a9796402a44fdb52482f353618fe Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Klaus wrote: > It really gets complicated to send all possible peers the current load > of your ingress point. That does not scale. Exactly. You aren't going to build your peering network as a fully interconnected mesh. I suspect the most workable approach to solve this is to have a hierarchy where higher points in the hierarchy understand the congestion levels of the entities lower down in the hierarchy. A load balancer that understands congestion, as it were. The whole point is to create an architecture where you never have to retry INVITES since the call rejection rate due to lack of resources is low enough to meet legacy telco requirements. Geoff -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 Sent: Wednesday, August 09, 2006 8:29 AM To: Geoff Devine Cc: Michael Hammer (mhammer); Brian Rosen; Patrick Melampy; Hadriel Kaplan; speermint@ietf.org Subject: Re: [Speermint] Secure RTP Geoff Devine wrote: > I agree 100% with this analysis of what can happen when you use 503. > There is a real risk that it can cause the network to overload. >=20 > That said, I think you guys are missing a use case: >=20 > I have a media gateway in New York. My peer has a media gateway in San > Francisco. One of my New York subscribers dials a San Francisco > telephone number. This number is not a VoIP device. I want to use the > peer media gateway in San Francisco whenever possible to avoid carrier > charges. >=20 > In this use case, PSTN gateway economics are certainly a consideration. > The media gateway controller in San Francisco has finite resources and > it would be a poor architecture to send INVITE messages to it from New > York when it is congested. If you have 2 GWs, both under your control, distributing the load status of the gateways is rather easy. But it gets complicated if there are=20 lots of peers, and in a federation peering scenario you do not even know each of your peers. It really gets complicated to send all possible=20 peers the current load of your ingress point. That does not scale. regards klaus >=20 > Geoff >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 > Sent: Tuesday, August 08, 2006 2:22 PM > To: Brian Rosen; Geoff Devine; Patrick Melampy; Hadriel Kaplan > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > Brian, >=20 > When you get to the point that you can't keep up with new offered calls, > you may send a 503 that causes another server to get the added load. If > that server was also near it's thrashing point, it may also start > rejecting calls with 503 leading to yet another server getting > overloaded, and so on. Retransmissions of the new call can oscillate > through your servers searching for one that can handle a new call. But, > in the mean time it takes resources to reject a call. The call gapping > tells upstream elements how to limit the new load so that there is no > rejection of call resource consumption. >=20 > In your case, by suggesting the load balancer, you have merely moved the > problem into the receiving network, but now creating a new point of > congestion at the load balancer. >=20 > Yeah, they are just servers, but presumable they have software on them, > and presumable the software vendors don't write software for altruistic > reasons, but need to make money too. And since revenue from voice is > being pushed lower, I don't see SPs buying into massive server farms > with 90% sitting idle. >=20 > I agree though that this shouldn't be based on PSTN GW economics, we are > trying to bypass that in Speermint. However, the need to police borders > and actually charge for calls may have an impact anyway. >=20 > I was looking for the ability to dynamically direct calls to various > signaling border elements based on a variety of business and possibly > varying technical needs, congestion being only one aspect. In some > ways, this may be akin to load balancing, since based on some > multifaceted criteria, it is making visible to any potential peer which > signaling peering point to direct traffic to. Or deny access > altogether. >=20 > Mike >=20 >=20 >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net]=20 >> Sent: Tuesday, August 08, 2006 12:45 PM >> To: Michael Hammer (mhammer); 'Geoff Devine'; 'Patrick=20 >> Melampy'; 'Hadriel Kaplan' >> Cc: speermint@ietf.org >> Subject: RE: [Speermint] Secure RTP >> >> I'm not so sure about that. >> >> I do think that some of the folks that are designing VoIP=20 >> systems make them look like telephone systems and thereby=20 >> inherit the problems. I think many of the architectures=20 >> being put forth have way too many elements, when only one or=20 >> two (replicated of course) need to be there. I am always=20 >> amazed comparing statistics of two VoIP networks that started=20 >> accepting customers at around the same time, where one had a=20 >> cost to first customer north of 100M and the other was=20 >> something under 10. The cost of the millionth customer ALSO=20 >> favored the latter, and it never turned around, while=20 >> customers perceived the services to be equivalent (I'm sure=20 >> the carriers didn't). >> >> I'm not sure what you mean by "cascading failures" in this=20 >> context. Please explain. >> >> I'm also not sure that business economics don't allow you to=20 >> have servers waiting for peak traffic. That depends on how=20 >> these systems are built only a little, it more depend on how=20 >> they are priced. >> >> The "servers" here are the signaling elements, and they are=20 >> just computers. >> You can have a heck of a lot of computer sitting around doing=20 >> nothing waiting for peak traffic. That isn't necessarily=20 >> true of the media, of course. >> >> Brian >> >>> -----Original Message----- >>> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >>> Sent: Tuesday, August 08, 2006 12:18 PM >>> To: Brian Rosen; Geoff Devine; Patrick Melampy; Hadriel Kaplan >>> Cc: speermint@ietf.org >>> Subject: RE: [Speermint] Secure RTP >>> >>> It is more like a telephone network than a Web service. >>> >>> How do you explain cascading failures, then? >>> >>> Also, the business economics don't allow you to have 90% of your=20 >>> servers sitting around doing nothing just waiting for peak traffic. >>> >>> Mike >>> >>> >>>> -----Original Message----- >>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>> Sent: Friday, August 04, 2006 12:01 PM >>>> To: 'Geoff Devine'; 'Patrick Melampy'; Michael Hammer (mhammer);=20 >>>> 'Hadriel Kaplan' >>>> Cc: speermint@ietf.org >>>> Subject: RE: [Speermint] Secure RTP >>>> >>>> This isn't a telephone network. >>>> >>>> We typically DON'T have overload conditions on well engineered=20 >>>> networks. We presently have some mighty fine self=20 >> limiting issues=20 >>>> with media, but if we had proper QoS on the media, that=20 >> would be, I=20 >>>> think, very sufficient congestion control. I've never=20 >> seen a well=20 >>>> engineered SIP based network where the signaling issues=20 >> were a big=20 >>>> problem. It's almost all in the media. >>>> >>>> I know all about "Americal Idol" night. The numbers just aren't=20 >>>> scary any more. >>>> >>>> Do the math. A million BHCA is 278 calls per second. How many=20 >>>> million do you want? Rack up the servers (best make them=20 >> stateless,=20 >>>> but that's not a problem). >>>> >>>> Sure, you need a load balancer. Sure, you need a=20 >> failover strategy=20 >>>> with a good database. >>>> >>>> Now, every system has limits. We have an answer for those: busy. >>>> >>>> More importantly, we actually can use some telephone=20 >> engineering to=20 >>>> predict the traffic at the peering point. We can=20 >> engineer systems=20 >>>> pretty straightforwardly to handle that traffic. We DO need some=20 >>>> congestion control mechanisms, because the peering mechanisms we=20 >>>> have do have finite capacity. However, I don't see much need for=20 >>>> telephone style call gapping and only trivial metering. >>>> >>>> Today, we can build peering systems where the actual=20 >> peering happens=20 >>>> at multiple places around the globe, where there is no effective=20 >>>> limits on signaling bandwith (or for that matter, media=20 >> bandwith) to=20 >>>> and from the peering points. We can have SIP proxies=20 >> that perform=20 >>>> the actual peering function (take a call, do a dip to determine=20 >>>> where it's going, use available DNS and other mechanisms=20 >> to spread=20 >>>> load) that are similarly spread out and redundant enough=20 >> that we get=20 >>>> the kind of reliability we expect. And we can engineer=20 >> them to take=20 >>>> load up to a static limit reliably. >>>> >>>> What can't we do? >>>> >>>> Brian >>>> >>>> >>>>> -----Original Message----- >>>>> From: Geoff Devine [mailto:gdevine@cedarpointcom.com] >>>>> Sent: Friday, August 04, 2006 11:35 AM >>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer);=20 >>>>> Hadriel Kaplan >>>>> Cc: speermint@ietf.org >>>>> 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=20 >> 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:br@brianrosen.net] >>>>> Sent: Friday, August 04, 2006 11:27 AM >>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer=20 >> (mhammer)';=20 >>>>> 'Hadriel Kaplan' >>>>> Cc: speermint@ietf.org >>>>> Subject: RE: [Speermint] Secure RTP >>>>> >>>>> There is no evidence that you can't do this with the=20 >> mechanisms we=20 >>>>> 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:gdevine@cedarpointcom.com] >>>>>> Sent: Friday, August 04, 2006 11:01 AM >>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer >>>> (mhammer); Hadriel >>>>> Kaplan >>>>>> Cc: speermint@ietf.org >>>>>> 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=20 >> requirements for=20 >>>>>> a web server. A web server doesn't have the moral=20 >> and ethical=20 >>>>>> obligation to ensure that the network is stable to=20 >> complete 911=20 >>>>>> calls. If the >>>>> network >>>>>> floods a soft switch or media gateway controller with peering=20 >>>>>> 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:br@brianrosen.net] >>>>>> Sent: Friday, August 04, 2006 10:20 AM >>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; >>>> 'Hadriel Kaplan' >>>>>> Cc: speermint@ietf.org >>>>>> Subject: RE: [Speermint] Secure RTP >>>>>> >>>>>> I don't think any of this is something we are=20 >> chartered to do. =20 >>>>>> 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=20 >>>>>> handle >>>>> HTTP >>>>>> load, and I don't see any reason we shouldn't use all=20 >> of those=20 >>>>>> techniques to deal with SIP load. I certainly don't see >>>> reasons to >>>>>> make the originator aware of congestion issues at the=20 >>>>>> terminating domain, beyond the contractual limits=20 >> 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=20 >> time I can=20 >>>>>> 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=20 >>>>>> least the complexity it introduced was not worth the=20 >> value it provided). >>>>>> Brian >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Patrick Melampy [mailto:PMelampy@acmepacket.com] >>>>>>> Sent: Friday, August 04, 2006 9:59 AM >>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)';=20 >> 'Hadriel Kaplan' >>>>>>> Cc: speermint@ietf.org >>>>>>> Subject: RE: [Speermint] Secure RTP >>>>>>> >>>>>>> Brian, >>>>>>> >>>>>>> I agree with you. However some aspects are protocol >>>> worthy. Path >>>>>>> determination -- or said another way -- the next=20 >> hop network=20 >>>>>>> to use >>>>> to >>>>>>> reach >>>>>>> a destination domain, must be partially provisioned, >>>> and partially >>>>>>> discovered. The discovery aspects are the dynamic aspects.=20 >>>>>>> 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=20 >> the protocol >>>>> family, >>>>>> and >>>>>>> ISUP messages are sent to bring circuits in and out=20 >> 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,=20 >>>>>>> maximum >>>>>> sessions >>>>>>> permitted, and maximum bandwidth to use. >>>>>>> >>>>>>> In #2 -- reachable domains -- Unlike the PSTN which=20 >> uses the=20 >>>>>>> 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=20 >>>>>>> advertisement protocol that goes network to network. Thus a=20 >>>>>>> protocol is required >>>>>> here. >>>>>>> In #3 -- congestion -- is dynamic and not=20 >> 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=20 >> also think we=20 >>>>>>> need >>>>> to >>>>>>> leave >>>>>>> to the individual networks, any and all decisions on how to=20 >>>>>>> run >>>>> their >>>>>>> networks, choose next networks, etc. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>>>> Sent: Friday, August 04, 2006 8:47 AM >>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' >>>>>>> Cc: speermint@ietf.org >>>>>>> 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=20 >> for peers=20 >>>>>>> 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=20 >> mechanisms exist to >>>>>> provision. >>>>>>> So, for example, if one of the things peering means is that=20 >>>>>>> the rate >>>>>> of >>>>>>> calls is limited in some way, then we probably have to >>>> standardize >>>>> the >>>>>>> definition of limiting, but not the way to=20 >> determine what the=20 >>>>>>> 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. =20 >> This is not=20 >>>>>>> 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=20 >> their values=20 >>>>>>> are >>>>>> limited >>>>>>> to. >>>>>>> It clearly WILL do that for some variables, and again, we=20 >>>>>>> don't need automatic provisioning mechanisms to discover=20 >>>>>>> these. Even within a federation, I think it will be common=20 >>>>>>> that bilateral arrangements >>>>>> making >>>>>>> further policy limitations will exist. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM >>>>>>>> To: Hadriel Kaplan; Brian Rosen >>>>>>>> Cc: speermint@ietf.org >>>>>>>> Subject: RE: [Speermint] Secure RTP >>>>>>>> >>>>>>>> The focus of Speermint should be centered around >>>> whether one can >>>>>>>> discover the policies of a potential peer and=20 >> whether those >>>>> policies >>>>>> can >>>>>>>> systematically describe the requirements on multiple >>>> levels that >>>>>> will >>>>>>>> need to be supported to have a successful=20 >> communication with=20 >>>>>>>> that >>>>>> peer. >>>>>>>> It is not about specifying X, Y, Z, or >>> 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=20 >> different MUSTs=20 >>>>>>>> for >>>>> each >>>>>>>> category of choices we come up with. >>>>>>>> >>>>>>>> Mike >>>>>>>> >>>>>>>> >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 11:01:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GApYT-00052M-Hz; Wed, 09 Aug 2006 11:01:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GApYR-00051c-Vy for speermint@ietf.org; Wed, 09 Aug 2006 11:01:07 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GApYO-0003qp-W1 for speermint@ietf.org; Wed, 09 Aug 2006 11:01:07 -0400 Received: from PMelampy2 [10.0.200.104] by acmepacket.com with ESMTP (SMTPD-9.03) id A8AF04E0; Wed, 09 Aug 2006 11:01:03 -0400 From: "Patrick Melampy" To: "'Klaus Darilion'" , "'Brian Rosen'" Subject: RE: [Speermint] Congestion and Load Balancing Date: Wed, 9 Aug 2006 11:00:51 -0400 Message-ID: <004401c6bbc4$9adb3840$6401a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7qzws7NbzSN1LT8m8YRn1xnkcVQAEbyjA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44D9CE12.6090002@pernau.at> X-Spam-Score: 0.1 (/) X-Scan-Signature: 1dbd668ceca1a76e1ad844a781a4818d Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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 3.) To be able to count the kilobytes of bandwidth the media is consuming 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 A stateless load balancer can't provide these. 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. -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Sent: Wednesday, August 09, 2006 7:59 AM To: Brian Rosen Cc: 'Patrick Melampy'; speermint@ietf.org 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:PMelampy@acmepacket.com] >> Sent: Saturday, August 05, 2006 4:42 PM >> To: 'Brian Rosen' >> Cc: speermint@ietf.org >> 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:br@brianrosen.net] >> Sent: Friday, August 04, 2006 2:28 PM >> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer >> (mhammer)'; 'Hadriel Kaplan' >> Cc: speermint@ietf.org >> 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:rpenno@juniper.net] >>> Sent: Friday, August 04, 2006 2:14 PM >>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer >> (mhammer); >>> Hadriel Kaplan >>> Cc: speermint@ietf.org >>> 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:br@brianrosen.net] >>>> Sent: Friday, August 04, 2006 10:47 AM >>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; >>>> 'Hadriel Kaplan' >>>> Cc: speermint@ietf.org >>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: Secure >>> RTP >>>> >>> 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:PMelampy@acmepacket.com] >>>>> Sent: Friday, August 04, 2006 12:39 PM >>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; >>> 'Hadriel >>>>> Kaplan' >>>>> Cc: speermint@ietf.org >>>>> 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:br@brianrosen.net] >>>>> Sent: Friday, August 04, 2006 12:01 PM >>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; >>>>> 'Hadriel >>>>> Kaplan' >>>>> Cc: speermint@ietf.org >>>>> 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:gdevine@cedarpointcom.com] >>>>>> Sent: Friday, August 04, 2006 11:35 AM >>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); >>> Hadriel >>>>> Kaplan >>>>>> Cc: speermint@ietf.org >>>>>> 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:br@brianrosen.net] >>>>>> Sent: Friday, August 04, 2006 11:27 AM >>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; >>>>>> 'Hadriel Kaplan' >>>>>> Cc: speermint@ietf.org >>>>>> 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:gdevine@cedarpointcom.com] >>>>>>> Sent: Friday, August 04, 2006 11:01 AM >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); >>> Hadriel >>>>>> Kaplan >>>>>>> Cc: speermint@ietf.org >>>>>>> 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:br@brianrosen.net] >>>>>>> Sent: Friday, August 04, 2006 10:20 AM >>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel >>> Kaplan' >>>>>>> Cc: speermint@ietf.org >>>>>>> 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:PMelampy@acmepacket.com] >>>>>>>> Sent: Friday, August 04, 2006 9:59 AM >>>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel >>> Kaplan' >>>>>>>> Cc: speermint@ietf.org >>>>>>>> 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:br@brianrosen.net] >>>>>>>> Sent: Friday, August 04, 2006 8:47 AM >>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' >>>>>>>> Cc: speermint@ietf.org >>>>>>>> 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:mhammer@cisco.com] >>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM >>>>>>>>> To: Hadriel Kaplan; Brian Rosen >>>>>>>>> Cc: speermint@ietf.org >>>>>>>>> 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 >> 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 >>>> Speermint@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 11:13:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GApkJ-0003a2-OM; Wed, 09 Aug 2006 11:13:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GApkI-0003Zv-A3 for speermint@ietf.org; Wed, 09 Aug 2006 11:13:22 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GApkH-000539-8l for speermint@ietf.org; Wed, 09 Aug 2006 11:13:22 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GApk6-0003Bq-Kg; Wed, 09 Aug 2006 10:13:13 -0500 From: "Brian Rosen" To: "'Patrick Melampy'" , "'Klaus Darilion'" Subject: RE: [Speermint] Congestion and Load Balancing Date: Wed, 9 Aug 2006 11:13:12 -0400 Message-ID: <097a01c6bbc6$58172b70$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7qzws7NbzSN1LT8m8YRn1xnkcVQAEbyjAAAIi10A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <004401c6bbc4$9adb3840$6401a8c0@acmepacket.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cf0511842947ba7c2eb8ab72c43e5b6 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I think anything the B carrier needs from your first 5 items, it can get from its equipment, and doesn't need any work here. I think you imply that the originating carrier (A) actually can limit simultaneous calls, the rate of calls, and the bandwidth of those calls to a contractual limit. There may be some SPEERMINT work to make at least the definitions consistent if not some mechanisms. Where we part company is 6. I am happy to have B do anything it wants to manage congestion on certain domains, but I don't think that is any work for SPEERMINT, because I don't think A does anything to help that. I don't see a need for mechanisms to distribute load from A to B in any but trivial ways (for each URI, you can limit calls, rate of calls and bandwidth). Brian > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Sent: Wednesday, August 09, 2006 11:01 AM > To: 'Klaus Darilion'; 'Brian Rosen' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing > > 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 > 3.) To be able to count the kilobytes of bandwidth the media is consuming > 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 > > A stateless load balancer can't provide these. > > 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. > > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Wednesday, August 09, 2006 7:59 AM > To: Brian Rosen > Cc: 'Patrick Melampy'; speermint@ietf.org > 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:PMelampy@acmepacket.com] > >> Sent: Saturday, August 05, 2006 4:42 PM > >> To: 'Brian Rosen' > >> Cc: speermint@ietf.org > >> 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:br@brianrosen.net] > >> Sent: Friday, August 04, 2006 2:28 PM > >> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff Devine'; 'Michael > Hammer > >> (mhammer)'; 'Hadriel Kaplan' > >> Cc: speermint@ietf.org > >> 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:rpenno@juniper.net] > >>> Sent: Friday, August 04, 2006 2:14 PM > >>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer > >> (mhammer); > >>> Hadriel Kaplan > >>> Cc: speermint@ietf.org > >>> 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:br@brianrosen.net] > >>>> Sent: Friday, August 04, 2006 10:47 AM > >>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; > >>>> 'Hadriel Kaplan' > >>>> Cc: speermint@ietf.org > >>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: Secure > >>> RTP > >>>> 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:PMelampy@acmepacket.com] > >>>>> Sent: Friday, August 04, 2006 12:39 PM > >>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; > >>> 'Hadriel > >>>>> Kaplan' > >>>>> Cc: speermint@ietf.org > >>>>> 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:br@brianrosen.net] > >>>>> Sent: Friday, August 04, 2006 12:01 PM > >>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > >>>>> 'Hadriel > >>>>> Kaplan' > >>>>> Cc: speermint@ietf.org > >>>>> 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:gdevine@cedarpointcom.com] > >>>>>> Sent: Friday, August 04, 2006 11:35 AM > >>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > >>> Hadriel > >>>>> Kaplan > >>>>>> Cc: speermint@ietf.org > >>>>>> 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:br@brianrosen.net] > >>>>>> Sent: Friday, August 04, 2006 11:27 AM > >>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > >>>>>> 'Hadriel Kaplan' > >>>>>> Cc: speermint@ietf.org > >>>>>> 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:gdevine@cedarpointcom.com] > >>>>>>> Sent: Friday, August 04, 2006 11:01 AM > >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > >>> Hadriel > >>>>>> Kaplan > >>>>>>> Cc: speermint@ietf.org > >>>>>>> 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:br@brianrosen.net] > >>>>>>> Sent: Friday, August 04, 2006 10:20 AM > >>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel > >>> Kaplan' > >>>>>>> Cc: speermint@ietf.org > >>>>>>> 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:PMelampy@acmepacket.com] > >>>>>>>> Sent: Friday, August 04, 2006 9:59 AM > >>>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel > >>> Kaplan' > >>>>>>>> Cc: speermint@ietf.org > >>>>>>>> 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:br@brianrosen.net] > >>>>>>>> Sent: Friday, August 04, 2006 8:47 AM > >>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > >>>>>>>> Cc: speermint@ietf.org > >>>>>>>> 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:mhammer@cisco.com] > >>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM > >>>>>>>>> To: Hadriel Kaplan; Brian Rosen > >>>>>>>>> Cc: speermint@ietf.org > >>>>>>>>> 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 >>> 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 > >>>> Speermint@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 11:47:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAqHE-0007Yr-Ss; Wed, 09 Aug 2006 11:47:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAqHE-0007Ym-3E for speermint@ietf.org; Wed, 09 Aug 2006 11:47:24 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAqHC-0003Zc-PU for speermint@ietf.org; Wed, 09 Aug 2006 11:47:24 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id EA1D4210025; Wed, 9 Aug 2006 17:47:21 +0200 (CEST) Message-ID: <44DA0397.9090900@pernau.at> Date: Wed, 09 Aug 2006 17:47:35 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Patrick Melampy Subject: Re: [Speermint] Congestion and Load Balancing References: <004401c6bbc4$9adb3840$6401a8c0@acmepacket.com> In-Reply-To: <004401c6bbc4$9adb3840$6401a8c0@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ad122f56a92d6ccd133117ee8a4b1ff3 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:klaus.mailinglists@pernau.at] > Sent: Wednesday, August 09, 2006 7:59 AM > To: Brian Rosen > Cc: 'Patrick Melampy'; speermint@ietf.org > 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:PMelampy@acmepacket.com] >>> Sent: Saturday, August 05, 2006 4:42 PM >>> To: 'Brian Rosen' >>> Cc: speermint@ietf.org >>> 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:br@brianrosen.net] >>> Sent: Friday, August 04, 2006 2:28 PM >>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer >>> (mhammer)'; 'Hadriel Kaplan' >>> Cc: speermint@ietf.org >>> 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:rpenno@juniper.net] >>>> Sent: Friday, August 04, 2006 2:14 PM >>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer >>> (mhammer); >>>> Hadriel Kaplan >>>> Cc: speermint@ietf.org >>>> 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:br@brianrosen.net] >>>>> Sent: Friday, August 04, 2006 10:47 AM >>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; >>>>> 'Hadriel Kaplan' >>>>> Cc: speermint@ietf.org >>>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: Secure >>>> RTP >>>>> >>>> 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:PMelampy@acmepacket.com] >>>>>> Sent: Friday, August 04, 2006 12:39 PM >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; >>>> 'Hadriel >>>>>> Kaplan' >>>>>> Cc: speermint@ietf.org >>>>>> 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:br@brianrosen.net] >>>>>> Sent: Friday, August 04, 2006 12:01 PM >>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; >>>>>> 'Hadriel >>>>>> Kaplan' >>>>>> Cc: speermint@ietf.org >>>>>> 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:gdevine@cedarpointcom.com] >>>>>>> Sent: Friday, August 04, 2006 11:35 AM >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); >>>> Hadriel >>>>>> Kaplan >>>>>>> Cc: speermint@ietf.org >>>>>>> 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:br@brianrosen.net] >>>>>>> Sent: Friday, August 04, 2006 11:27 AM >>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; >>>>>>> 'Hadriel Kaplan' >>>>>>> Cc: speermint@ietf.org >>>>>>> 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:gdevine@cedarpointcom.com] >>>>>>>> Sent: Friday, August 04, 2006 11:01 AM >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); >>>> Hadriel >>>>>>> Kaplan >>>>>>>> Cc: speermint@ietf.org >>>>>>>> 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:br@brianrosen.net] >>>>>>>> Sent: Friday, August 04, 2006 10:20 AM >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel >>>> Kaplan' >>>>>>>> Cc: speermint@ietf.org >>>>>>>> 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:PMelampy@acmepacket.com] >>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM >>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel >>>> Kaplan' >>>>>>>>> Cc: speermint@ietf.org >>>>>>>>> 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:br@brianrosen.net] >>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM >>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' >>>>>>>>> Cc: speermint@ietf.org >>>>>>>>> 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:mhammer@cisco.com] >>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM >>>>>>>>>> To: Hadriel Kaplan; Brian Rosen >>>>>>>>>> Cc: speermint@ietf.org >>>>>>>>>> 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 >>> 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 >>>>> Speermint@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/speermint >> >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 11:51:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAqKx-0008LM-RO; Wed, 09 Aug 2006 11:51:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAqKw-0008LG-TO for speermint@ietf.org; Wed, 09 Aug 2006 11:51:14 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAqKv-0004Pn-El for speermint@ietf.org; Wed, 09 Aug 2006 11:51:14 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id D05DE210025; Wed, 9 Aug 2006 17:51:12 +0200 (CEST) Message-ID: <44DA047F.1030901@pernau.at> Date: Wed, 09 Aug 2006 17:51:27 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Reinaldo Penno Subject: Re: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 References: <9BD5D7887235424FA97DFC223CAE3C2805182F60@proton.jnpr.net> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2805182F60@proton.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.1 (+) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org It is like in the email world. If you use a standard compliant email=20 client, email will work, regards what is your client and regardless who=20 is the provider. Of course these service providers do not guarantee that the service will=20 work when using non-supported SIP clients, but if you use a compliant=20 SIP client, it will work. regards klaus Reinaldo Penno wrote: > Hello Gunnar, >=20 > Not sure I follow your explanation. Is there a website for such ISP(s) = that allows a user to use any SIP endpoint and guarantee call completion = across the planet? I'm really curious on how they opearate... >=20 > Thanks, >=20 > Reinaldo >=20 >> -----Original Message----- >> From: Gunnar Hellstr=F6m [mailto:gunnar.hellstrom@omnitor.se] >> Sent: Wednesday, August 09, 2006 6:38 AM >> To: Reinaldo Penno; Klaus Darilion >> Cc: Alexander Mayrhofer; speermint >> Subject: RE: [Speermint]Mediarequirementsin draft-ietf-speermint- >> requirements-00 >> >> I know ISP:s who enable SIP calls anywhere, but not with any transcodi= ng. >> >> Gunnar >> >> -----Original Message----- >> From: Reinaldo Penno [mailto:rpenno@juniper.net] >> Sent: Wednesday, August 09, 2006 1:37 PM >> To: Klaus Darilion >> Cc: Alexander Mayrhofer; Gunnar Hellstr=F6m; speermint >> Subject: RE: [Speermint]Mediarequirementsin >> draft-ietf-speermint-requirements-00 >> >> >> Do they guarantee universal call completion? By that I mean, can you m= ake >> a >> call to anywhere and send/receive media? Do they perform transcoding t= o >> achieve that? >> >> >> >>> -----Original Message----- >>> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >>> Sent: Wednesday, August 09, 2006 5:32 AM >>> To: Reinaldo Penno >>> Cc: Alexander Mayrhofer; Gunnar Hellstr=F6m; speermint >>> Subject: Re: [Speermint]Mediarequirementsin draft-ietf-speermint- >>> requirements-00 >>> >>> Reinaldo Penno wrote: >>>> I think we are forgetting the business aspect here. >>>> >>>> Are there such ISPs in Europe that allow you to choose whatever >>>> equipment you like and still support your installation? (This is a >>>> legitimate question). I haven't lived in Europe long enough to notic= e >>>> these things. >>> Yes, there are such ISPs. You get your SIP provisioning data and can = use >>> any SIP client. >>> >>> regards >>> klaus >>> >>>> In the US when you buy DSL or Cable service you receive the modem by >>>> mail. You can choose your modem but it has to be on a list of >>>> supported modems, otherwise you are on your own. I cannot imagine an >>>> ISP supporting any end device/modem/phone, it would be a money black >>>> hole. >>>> >>>> I believe the real issue is at (or near) the peering point where you >>>> will have to possibly perform transcoding. >>>> >>>> >>>>> Would that mean that such a peer would then not be compliant, >>>>> because one of his customers does not support the REQUIRED codec? I >>>>> can't imagine that's the intent >>>>> >>>>> What about saying something like "Peers SHOULD NOT artificially >>>>> limit the set of codecs on behalf of their clients. In case the >>>>> peer provides transcoding services, the following codecs MUST be >>>>> supported: ..."? >>>>> >>>>> BTW, "codecs" is not just the algorithm... the next rathole is >>>>> "media packet sizes" (30ms packets anyone? :) Do we want to go down >>>>> there? >>>>> >>>>> cheers >>>>> >>>>> alex >>>>> >>>>> _______________________________________________ Speermint mailing >>>>> list Speermint@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/speermint >>>> _______________________________________________ Speermint mailing >>>> list Speermint@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 12:06:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAqZe-0001rT-Qt; Wed, 09 Aug 2006 12:06:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAqZe-0001rM-40 for speermint@ietf.org; Wed, 09 Aug 2006 12:06:26 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAqZb-0000CS-Qb for speermint@ietf.org; Wed, 09 Aug 2006 12:06:26 -0400 Received: from [10.10.0.107] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 09 Aug 2006 18:06:20 +0200 id 0007C08B.44DA07FD.00003920 Message-ID: <44DA07C3.2090904@enum.at> Date: Wed, 09 Aug 2006 18:05:23 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 References: <095d01c6bbba$8d93e970$9de6a8c0@cis.neustar.com> In-Reply-To: <095d01c6bbba$8d93e970$9de6a8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'speermint' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian Rosen wrote: > One thing that may inform this discussion is that it's been common that > requirements for emergency calls (1-1-2/9-1-1/...) often end up driving > requirements elsewhere in telecommunications systems. We're doing some work > in ecrit on support of emergency calls on the Internet, and the subject of > codecs is in discussion there. > > Looks like (no decisions yet) we WILL have a short list of codecs that end > up being MUST IMPLEMENT on phones (at least one of) and PSAPs (all of). > SPEERMINT could reference that document, which will be a BCP. Clearly, the > problem there is acute; you must have a compatible codec between a caller > and the emergency center if you are to be able to get help. It could be > that such a list ends up being MUST only for g.711 (at least A, probably > mu), and SHOULD for things like AMR, EvRC, iLBC, and possibly g.729 as well > as AMR-WB and some form of g.722. Emergency calls are probably a good tool to drive actual deployment. No vendor wants bad press about fatalaties because of failed codec negotiation. Re-using such work sounds definitely like a good idea to me, at least we should coordinate on that. Anything else that could be re-used from there? cheers alex _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 13:29:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GArsL-0006E4-CA; Wed, 09 Aug 2006 13:29:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GArsJ-00069f-V3 for speermint@ietf.org; Wed, 09 Aug 2006 13:29:47 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GArsI-0005HK-T1 for speermint@ietf.org; Wed, 09 Aug 2006 13:29:47 -0400 Received: from PMelampy2 [10.0.200.104] by acmepacket.com with ESMTP (SMTPD-9.03) id AB8F030C; Wed, 09 Aug 2006 13:29:51 -0400 From: "Patrick Melampy" To: "'Klaus Darilion'" Subject: RE: [Speermint] Congestion and Load Balancing Date: Wed, 9 Aug 2006 13:29:39 -0400 Message-ID: <007c01c6bbd9$64a01d30$6401a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44DA0397.9090900@pernau.at> X-Spam-Score: 0.1 (/) X-Scan-Signature: 3f5efd9d415d254aec2f521f63a5384c Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:klaus.mailinglists@pernau.at] Sent: Wednesday, August 09, 2006 11:48 AM To: Patrick Melampy Cc: 'Brian Rosen'; speermint@ietf.org 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:klaus.mailinglists@pernau.at] > Sent: Wednesday, August 09, 2006 7:59 AM > To: Brian Rosen > Cc: 'Patrick Melampy'; speermint@ietf.org > 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:PMelampy@acmepacket.com] >>> Sent: Saturday, August 05, 2006 4:42 PM >>> To: 'Brian Rosen' >>> Cc: speermint@ietf.org >>> 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:br@brianrosen.net] >>> Sent: Friday, August 04, 2006 2:28 PM >>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer >>> (mhammer)'; 'Hadriel Kaplan' >>> Cc: speermint@ietf.org >>> 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:rpenno@juniper.net] >>>> Sent: Friday, August 04, 2006 2:14 PM >>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer >>> (mhammer); >>>> Hadriel Kaplan >>>> Cc: speermint@ietf.org >>>> 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:br@brianrosen.net] >>>>> Sent: Friday, August 04, 2006 10:47 AM >>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; >>>>> 'Hadriel Kaplan' >>>>> Cc: speermint@ietf.org >>>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: Secure >>>> RTP >>>>> >>>> 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:PMelampy@acmepacket.com] >>>>>> Sent: Friday, August 04, 2006 12:39 PM >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; >>>> 'Hadriel >>>>>> Kaplan' >>>>>> Cc: speermint@ietf.org >>>>>> 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:br@brianrosen.net] >>>>>> Sent: Friday, August 04, 2006 12:01 PM >>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; >>>>>> 'Hadriel >>>>>> Kaplan' >>>>>> Cc: speermint@ietf.org >>>>>> 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:gdevine@cedarpointcom.com] >>>>>>> Sent: Friday, August 04, 2006 11:35 AM >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); >>>> Hadriel >>>>>> Kaplan >>>>>>> Cc: speermint@ietf.org >>>>>>> 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:br@brianrosen.net] >>>>>>> Sent: Friday, August 04, 2006 11:27 AM >>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; >>>>>>> 'Hadriel Kaplan' >>>>>>> Cc: speermint@ietf.org >>>>>>> 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:gdevine@cedarpointcom.com] >>>>>>>> Sent: Friday, August 04, 2006 11:01 AM >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); >>>> Hadriel >>>>>>> Kaplan >>>>>>>> Cc: speermint@ietf.org >>>>>>>> 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:br@brianrosen.net] >>>>>>>> Sent: Friday, August 04, 2006 10:20 AM >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel >>>> Kaplan' >>>>>>>> Cc: speermint@ietf.org >>>>>>>> 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:PMelampy@acmepacket.com] >>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM >>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel >>>> Kaplan' >>>>>>>>> Cc: speermint@ietf.org >>>>>>>>> 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:br@brianrosen.net] >>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM >>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' >>>>>>>>> Cc: speermint@ietf.org >>>>>>>>> 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:mhammer@cisco.com] >>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM >>>>>>>>>> To: Hadriel Kaplan; Brian Rosen >>>>>>>>>> Cc: speermint@ietf.org >>>>>>>>>> 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 >>> 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 >>>>> Speermint@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/speermint >> >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 13:42:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAs4k-00045l-6G; Wed, 09 Aug 2006 13:42:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAs4i-00045e-Pl for speermint@ietf.org; Wed, 09 Aug 2006 13:42:36 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAs4h-0006SJ-HB for speermint@ietf.org; Wed, 09 Aug 2006 13:42:36 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GAs4T-0006wQ-4b; Wed, 09 Aug 2006 12:42:24 -0500 From: "Brian Rosen" To: "'Alexander Mayrhofer'" Subject: RE: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 Date: Wed, 9 Aug 2006 13:42:23 -0400 Message-ID: <09a001c6bbdb$3002f550$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7zcOLuG7LNenXTWCJ5cv2fEQZtQADSMXw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44DA07C3.2090904@enum.at> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.1 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'speermint' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Well, maybe. The draft (currently draft-rosen-ecrit-phonebcp-01) says a lot of things that phones and proxies must do to support emergency calls. It provides a baseline of capabilities you can count on. Look at the draft. Brian > -----Original Message----- > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > Sent: Wednesday, August 09, 2006 12:05 PM > To: Brian Rosen > Cc: 'Reinaldo Penno'; 'Klaus Darilion'; 'speermint' > Subject: Re: [Speermint]Mediarequirementsin draft-ietf-speermint- > requirements-00 > > Brian Rosen wrote: > > One thing that may inform this discussion is that it's been common that > > requirements for emergency calls (1-1-2/9-1-1/...) often end up driving > > requirements elsewhere in telecommunications systems. We're doing some > work > > in ecrit on support of emergency calls on the Internet, and the subject > of > > codecs is in discussion there. > > > > Looks like (no decisions yet) we WILL have a short list of codecs that > end > > up being MUST IMPLEMENT on phones (at least one of) and PSAPs (all of). > > SPEERMINT could reference that document, which will be a BCP. Clearly, > the > > problem there is acute; you must have a compatible codec between a > caller > > and the emergency center if you are to be able to get help. It could be > > that such a list ends up being MUST only for g.711 (at least A, probably > > mu), and SHOULD for things like AMR, EvRC, iLBC, and possibly g.729 as > well > > as AMR-WB and some form of g.722. > > Emergency calls are probably a good tool to drive actual deployment. No > vendor wants bad press about fatalaties because of failed codec > negotiation. > > Re-using such work sounds definitely like a good idea to me, at least we > should coordinate on that. Anything else that could be re-used from there? > > cheers > > alex _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 15:21:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtc9-0004wx-7l; Wed, 09 Aug 2006 15:21:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtc7-0004vj-Pc for speermint@ietf.org; Wed, 09 Aug 2006 15:21:11 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAtWi-00078S-VU for speermint@ietf.org; Wed, 09 Aug 2006 15:15:37 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 09 Aug 2006 12:15:23 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="35367139:sNHT33013852" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79JFNWw001052; Wed, 9 Aug 2006 15:15:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k79JFNe2004281; Wed, 9 Aug 2006 15:15:23 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 15:15:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Secure RTP Date: Wed, 9 Aug 2006 15:15:21 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301CE92CB@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Secure RTP Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/AAABsDkAAAfWzgAMpSRNAAALXLQAAC38tgAAjMvmAALCZTMA== From: "Michael Hammer \(mhammer\)" To: "Geoff Devine" , "Brian Rosen" , "Patrick Melampy" , "Hadriel Kaplan" X-OriginalArrivalTime: 09 Aug 2006 19:15:22.0882 (UTC) FILETIME=[29729620:01C6BBE8] DKIM-Signature: a=rsa-sha1; q=dns; l=19849; t=1155150923; x=1156014923; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Secure=20RTP |To:=22Geoff=20Devine=22=20, =0A=20=20=20=20=20=20 =20=20=22Brian=20Rosen=22=20, =0A=20=20=20=20=20=20=20=20 =22Patrick=20Melampy=22=20, =0A=20=20=20=20=20=20=2 0=20=22Hadriel=20Kaplan=22=20; X=v=3Dcisco.com=3B=20h=3DTav7+aVDpl+QOgZ4O1J+VN4eGlM=3D; b=sz1P9p7euGomHjERARygKlFUFQ2c+it+F1XvlabZsyWlHAf8nAzG3au//nQrCeE6DWI1inKc 5ZdvoLKOvoQ5xAkeYPtcqAPOekqZyZP7K8AthClhixR1e1xMRyri1c4r; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 90f8d7cac99eccf384c4cdc57475e98c Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I think the point you bring up is valid, but an intra-domain issue, rather than a peering issue. Mike =20 > -----Original Message----- > From: Geoff Devine [mailto:gdevine@cedarpointcom.com]=20 > Sent: Tuesday, August 08, 2006 6:23 PM > To: Michael Hammer (mhammer); Brian Rosen; Patrick Melampy;=20 > Hadriel Kaplan > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > I agree 100% with this analysis of what can happen when you use 503. > There is a real risk that it can cause the network to overload. >=20 > That said, I think you guys are missing a use case: >=20 > I have a media gateway in New York. My peer has a media=20 > gateway in San Francisco. One of my New York subscribers=20 > dials a San Francisco telephone number. This number is not a=20 > VoIP device. I want to use the peer media gateway in San=20 > Francisco whenever possible to avoid carrier charges. >=20 > In this use case, PSTN gateway economics are certainly a=20 > consideration. > The media gateway controller in San Francisco has finite=20 > resources and it would be a poor architecture to send INVITE=20 > messages to it from New York when it is congested. >=20 > Geoff >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, August 08, 2006 2:22 PM > To: Brian Rosen; Geoff Devine; Patrick Melampy; Hadriel Kaplan > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > Brian, >=20 > When you get to the point that you can't keep up with new=20 > offered calls, you may send a 503 that causes another server=20 > to get the added load. If that server was also near it's=20 > thrashing point, it may also start rejecting calls with 503=20 > leading to yet another server getting overloaded, and so on. =20 > Retransmissions of the new call can oscillate through your=20 > servers searching for one that can handle a new call. But,=20 > in the mean time it takes resources to reject a call. The=20 > call gapping > tells upstream elements how to limit the new load so that=20 > there is no > rejection of call resource consumption. >=20 > In your case, by suggesting the load balancer, you have=20 > merely moved the problem into the receiving network, but now=20 > creating a new point of congestion at the load balancer. >=20 > Yeah, they are just servers, but presumable they have=20 > software on them, and presumable the software vendors don't=20 > write software for altruistic reasons, but need to make money=20 > too. And since revenue from voice is being pushed lower, I=20 > don't see SPs buying into massive server farms with 90% sitting idle. >=20 > I agree though that this shouldn't be based on PSTN GW=20 > economics, we are trying to bypass that in Speermint. =20 > However, the need to police borders and actually charge for=20 > calls may have an impact anyway. >=20 > I was looking for the ability to dynamically direct calls to=20 > various signaling border elements based on a variety of=20 > business and possibly varying technical needs, congestion=20 > being only one aspect. In some ways, this may be akin to=20 > load balancing, since based on some multifaceted criteria, it=20 > is making visible to any potential peer which signaling=20 > peering point to direct traffic to. Or deny access altogether. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, August 08, 2006 12:45 PM > > To: Michael Hammer (mhammer); 'Geoff Devine'; 'Patrick Melampy';=20 > > 'Hadriel Kaplan' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Secure RTP > >=20 > > I'm not so sure about that. > >=20 > > I do think that some of the folks that are designing VoIP=20 > systems make=20 > > them look like telephone systems and thereby inherit the=20 > problems. I=20 > > think many of the architectures being put forth have way too many=20 > > elements, when only one or two (replicated of course) need to be=20 > > there. I am always amazed comparing statistics of two VoIP=20 > networks=20 > > that started accepting customers at around the same time, where one=20 > > had a cost to first customer north of 100M and the other=20 > was something=20 > > under 10. The cost of the millionth customer ALSO favored=20 > the latter,=20 > > and it never turned around, while customers perceived the=20 > services to=20 > > be equivalent (I'm sure the carriers didn't). > >=20 > > I'm not sure what you mean by "cascading failures" in this=20 > context. =20 > > Please explain. > >=20 > > I'm also not sure that business economics don't allow you to have=20 > > servers waiting for peak traffic. That depends on how=20 > these systems=20 > > are built only a little, it more depend on how they are priced. > >=20 > > The "servers" here are the signaling elements, and they are just=20 > > computers. > > You can have a heck of a lot of computer sitting around=20 > doing nothing=20 > > waiting for peak traffic. That isn't necessarily true of=20 > the media,=20 > > of course. > >=20 > > Brian > >=20 > > > -----Original Message----- > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > Sent: Tuesday, August 08, 2006 12:18 PM > > > To: Brian Rosen; Geoff Devine; Patrick Melampy; Hadriel Kaplan > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Secure RTP > > >=20 > > > It is more like a telephone network than a Web service. > > >=20 > > > How do you explain cascading failures, then? > > >=20 > > > Also, the business economics don't allow you to have 90% of your=20 > > > servers sitting around doing nothing just waiting for=20 > peak traffic. > > >=20 > > > Mike > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Friday, August 04, 2006 12:01 PM > > > > To: 'Geoff Devine'; 'Patrick Melampy'; Michael Hammer=20 > (mhammer);=20 > > > > 'Hadriel Kaplan' > > > > Cc: speermint@ietf.org > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > This isn't a telephone network. > > > > > > > > We typically DON'T have overload conditions on well engineered=20 > > > > 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=20 > just aren't=20 > > > > scary any more. > > > > > > > > Do the math. A million BHCA is 278 calls per second. How many=20 > > > > 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=20 > 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=20 > need some=20 > > > > congestion control mechanisms, because the peering=20 > mechanisms we=20 > > > > have do have finite capacity. However, I don't see=20 > much need for=20 > > > > 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=20 > effective=20 > > > > 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=20 > > > > 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:gdevine@cedarpointcom.com] > > > > > Sent: Friday, August 04, 2006 11:35 AM > > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer);=20 > > > > > Hadriel Kaplan > > > > > Cc: speermint@ietf.org > > > > > 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:br@brianrosen.net] > > > > > Sent: Friday, August 04, 2006 11:27 AM > > > > > To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer > > (mhammer)'; > > > > > 'Hadriel Kaplan' > > > > > Cc: speermint@ietf.org > > > > > 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=20 > anything else. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > > > > > > Sent: Friday, August 04, 2006 11:01 AM > > > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer > > > > (mhammer); Hadriel > > > > > Kaplan > > > > > > Cc: speermint@ietf.org > > > > > > 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=20 > with peering=20 > > > > > > 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:br@brianrosen.net] > > > > > > Sent: Friday, August 04, 2006 10:20 AM > > > > > > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > > 'Hadriel Kaplan' > > > > > > Cc: speermint@ietf.org > > > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > > > > > I don't think any of this is something we are > > chartered to do. =20 > > > > > > I > > > > > don't > > > > > > think it's needed, at least for a long time,=20 > possibly forever. > > > > > > > > > > > > We have lots of experience building "farms" of servers that=20 > > > > > > 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=20 > > > > > > 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=20 > > > > > > least the complexity it introduced was not worth the > > value it provided). > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > > > > > Sent: Friday, August 04, 2006 9:59 AM > > > > > > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; > > 'Hadriel Kaplan' > > > > > > > Cc: speermint@ietf.org > > > > > > > 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=20 > aspects.=20 > > > > > > > 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,=20 > > > > > > > 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=20 > > > > > > > advertisement protocol that goes network to=20 > network. Thus a=20 > > > > > > > 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=20 > on how to=20 > > > > > > > run > > > > > their > > > > > > > networks, choose next networks, etc. > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > > Sent: Friday, August 04, 2006 8:47 AM > > > > > > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > > > > Cc: speermint@ietf.org > > > > > > > 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=20 > means is that=20 > > > > > > > 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. =20 > > 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=20 > > > > > > > don't need automatic provisioning mechanisms to discover=20 > > > > > > > these. Even within a federation, I think it will=20 > be common=20 > > > > > > > that bilateral arrangements > > > > > > making > > > > > > > further policy limitations will exist. > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Michael Hammer (mhammer)=20 > [mailto:mhammer@cisco.com] > > > > > > > > Sent: Thursday, August 03, 2006 3:13 PM > > > > > > > > To: Hadriel Kaplan; Brian Rosen > > > > > > > > Cc: speermint@ietf.org > > > > > > > > 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 > > > 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 > > > > > > > > > > > > > > > > > > > > > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 15:30:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtlV-0002PS-No; Wed, 09 Aug 2006 15:30:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtlU-0002PN-AF for speermint@ietf.org; Wed, 09 Aug 2006 15:30:52 -0400 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAtlT-0000Fv-2W for speermint@ietf.org; Wed, 09 Aug 2006 15:30:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Aug 2006 15:30:20 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD1A635C@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [wg-business] WGLC on draft-ietf-speermint-terminology-02 Thread-Index: Aca76kBb97nhmkbTRWSPswAGhnj8DA== From: "Livingood, Jason" To: X-OriginalArrivalTime: 09 Aug 2006 19:30:21.0726 (UTC) FILETIME=[41334BE0:01C6BBEA] X-Spam-Score: 1.1 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Speermint] [wg-business] WGLC on draft-ietf-speermint-terminology-02 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org This note begins the Working Group Last Call for comments on the draft:=20 "SPEERMINT Terminology" draft-ietf-speermint-terminology-02 see http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-02. txt --> Please take this final opportunity to review the document carefully, and send any feedback you may have to the list and to the author. =20 --> Please also indicate whether or not you believe that this document is ready to go to the IESG. This Working Group Last Call will end on 19 September at 1700 EDT (UTC/GMT-4), at the close of Speermint Interim Meeting #1. Thank you, Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 15:48:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAu2Q-0004dN-CH; Wed, 09 Aug 2006 15:48:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAu2P-0004bs-5c for speermint@ietf.org; Wed, 09 Aug 2006 15:48:21 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound2-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAtw2-0001ff-Rr for speermint@ietf.org; Wed, 09 Aug 2006 15:41:48 -0400 Received: from outbound2-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-cpk-R.bigfish.com (Postfix) with ESMTP id 8583810FB283; Wed, 9 Aug 2006 19:41:46 +0000 (UTC) Received: from mail10-cpk-R.bigfish.com (unknown [192.168.21.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound2-cpk.bigfish.com (Postfix) with ESMTP id 7C01010FB282; Wed, 9 Aug 2006 19:41:46 +0000 (UTC) Received: from mail10-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail10-cpk-R.bigfish.com (Postfix) with ESMTP id 543144E032B; Wed, 9 Aug 2006 19:41:46 +0000 (UTC) X-BigFish: V Received: by mail10-cpk (MessageSwitch) id 1155152506239531_3439; Wed, 9 Aug 2006 19:41:46 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail10-cpk.bigfish.com (Postfix) with ESMTP id F2BB84E0CC3; Wed, 9 Aug 2006 19:41:45 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k79Jfjqd008113; Wed, 9 Aug 2006 14:41:45 -0500 (CDT) Received: from pdawg06a.ad.sprint.com (PDAWG06A.corp.sprint.com [10.122.2.33]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k79Jfi320224; Wed, 9 Aug 2006 14:41:44 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by pdawg06a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 14:41:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Secure RTP Date: Wed, 9 Aug 2006 14:41:34 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A130291EDDF@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Secure RTP Thread-Index: Aca1na36tYaSHTm/RLGwkfZLoqHp+wAAneqwAACUySAAY1+W8AAkqk5AAAKQjqAAAIsS8AABjmAQAAE8v/AAABsDkAAAfWzgAMpSRNAAALXLQAAC38tgADXSRuA= From: "Khan, Sohel Q [CTO]" To: "Michael Hammer \(mhammer\)" , "Brian Rosen" , "Geoff Devine" , "Patrick Melampy" , "Hadriel Kaplan" X-OriginalArrivalTime: 09 Aug 2006 19:41:44.0725 (UTC) FILETIME=[D84CAC50:01C6BBEB] X-Spam-Score: 0.1 (/) X-Scan-Signature: bb7a33d18683bf5063a44e640cf125f1 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org FYI I think, three is a work item in SIPPING group on SIP Overload by Jonathan Rosenberg. =20 -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Tuesday, August 08, 2006 1:22 PM To: Brian Rosen; Geoff Devine; Patrick Melampy; Hadriel Kaplan Cc: speermint@ietf.org Subject: RE: [Speermint] Secure RTP Brian, When you get to the point that you can't keep up with new offered calls, you may send a 503 that causes another server to get the added load. If that server was also near it's thrashing point, it may also start rejecting calls with 503 leading to yet another server getting overloaded, and so on. Retransmissions of the new call can oscillate through your servers searching for one that can handle a new call. But, in the mean time it takes resources to reject a call. The call gapping tells upstream elements how to limit the new load so that there is no rejection of call resource consumption. In your case, by suggesting the load balancer, you have merely moved the problem into the receiving network, but now creating a new point of congestion at the load balancer. Yeah, they are just servers, but presumable they have software on them, and presumable the software vendors don't write software for altruistic reasons, but need to make money too. And since revenue from voice is being pushed lower, I don't see SPs buying into massive server farms with 90% sitting idle. I agree though that this shouldn't be based on PSTN GW economics, we are trying to bypass that in Speermint. However, the need to police borders and actually charge for calls may have an impact anyway. I was looking for the ability to dynamically direct calls to various signaling border elements based on a variety of business and possibly varying technical needs, congestion being only one aspect. In some ways, this may be akin to load balancing, since based on some multifaceted criteria, it is making visible to any potential peer which signaling peering point to direct traffic to. Or deny access altogether. Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, August 08, 2006 12:45 PM > To: Michael Hammer (mhammer); 'Geoff Devine'; 'Patrick Melampy';=20 > 'Hadriel Kaplan' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Secure RTP >=20 > I'm not so sure about that. >=20 > I do think that some of the folks that are designing VoIP systems make > them look like telephone systems and thereby inherit the problems. I=20 > think many of the architectures being put forth have way too many=20 > elements, when only one or two (replicated of course) need to be=20 > there. I am always amazed comparing statistics of two VoIP networks=20 > that started accepting customers at around the same time, where one=20 > had a cost to first customer north of 100M and the other was something > under 10. The cost of the millionth customer ALSO favored the latter, > and it never turned around, while customers perceived the services to=20 > be equivalent (I'm sure the carriers didn't). >=20 > I'm not sure what you mean by "cascading failures" in this context. =20 > Please explain. >=20 > I'm also not sure that business economics don't allow you to have=20 > servers waiting for peak traffic. That depends on how these systems=20 > are built only a little, it more depend on how they are priced. >=20 > The "servers" here are the signaling elements, and they are just=20 > computers. > You can have a heck of a lot of computer sitting around doing nothing=20 > waiting for peak traffic. That isn't necessarily true of the media,=20 > of course. >=20 > Brian >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Tuesday, August 08, 2006 12:18 PM > > To: Brian Rosen; Geoff Devine; Patrick Melampy; Hadriel Kaplan > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Secure RTP > >=20 > > It is more like a telephone network than a Web service. > >=20 > > How do you explain cascading failures, then? > >=20 > > Also, the business economics don't allow you to have 90% of your=20 > > servers sitting around doing nothing just waiting for peak traffic. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, August 04, 2006 12:01 PM > > > To: 'Geoff Devine'; 'Patrick Melampy'; Michael Hammer (mhammer);=20 > > > 'Hadriel Kaplan' > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Secure RTP > > > > > > This isn't a telephone network. > > > > > > We typically DON'T have overload conditions on well engineered=20 > > > 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=20 > > > scary any more. > > > > > > Do the math. A million BHCA is 278 calls per second. How many=20 > > > 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=20 > > > congestion control mechanisms, because the peering mechanisms we=20 > > > have do have finite capacity. However, I don't see much need for=20 > > > 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=20 > > > 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=20 > > > 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:gdevine@cedarpointcom.com] > > > > Sent: Friday, August 04, 2006 11:35 AM > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer);=20 > > > > Hadriel Kaplan > > > > Cc: speermint@ietf.org > > > > 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:br@brianrosen.net] > > > > Sent: Friday, August 04, 2006 11:27 AM > > > > To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer > (mhammer)'; > > > > 'Hadriel Kaplan' > > > > Cc: speermint@ietf.org > > > > 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:gdevine@cedarpointcom.com] > > > > > Sent: Friday, August 04, 2006 11:01 AM > > > > > To: Brian Rosen; Patrick Melampy; Michael Hammer > > > (mhammer); Hadriel > > > > Kaplan > > > > > Cc: speermint@ietf.org > > > > > 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=20 > > > > > 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:br@brianrosen.net] > > > > > Sent: Friday, August 04, 2006 10:20 AM > > > > > To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > 'Hadriel Kaplan' > > > > > Cc: speermint@ietf.org > > > > > Subject: RE: [Speermint] Secure RTP > > > > > > > > > > I don't think any of this is something we are > chartered to do. =20 > > > > > 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=20 > > > > > 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=20 > > > > > 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=20 > > > > > least the complexity it introduced was not worth the > value it provided). > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > > > > Sent: Friday, August 04, 2006 9:59 AM > > > > > > To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; > 'Hadriel Kaplan' > > > > > > Cc: speermint@ietf.org > > > > > > 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.=20 > > > > > > 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,=20 > > > > > > 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=20 > > > > > > advertisement protocol that goes network to network. Thus a=20 > > > > > > 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=20 > > > > > > run > > > > their > > > > > > networks, choose next networks, etc. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Friday, August 04, 2006 8:47 AM > > > > > > To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > > > Cc: speermint@ietf.org > > > > > > 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=20 > > > > > > 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. =20 > 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=20 > > > > > > don't need automatic provisioning mechanisms to discover=20 > > > > > > these. Even within a federation, I think it will be common=20 > > > > > > that bilateral arrangements > > > > > making > > > > > > further policy limitations will exist. > > > > > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > > > > > Sent: Thursday, August 03, 2006 3:13 PM > > > > > > > To: Hadriel Kaplan; Brian Rosen > > > > > > > Cc: speermint@ietf.org > > > > > > > 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 > > 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 > > > > > > > > > > > > > > > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 15:49:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAu3Q-0005ww-OE; Wed, 09 Aug 2006 15:49:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAu3P-0005rA-7v for speermint@ietf.org; Wed, 09 Aug 2006 15:49:23 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAu3O-0003S2-5D for speermint@ietf.org; Wed, 09 Aug 2006 15:49:23 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 8D40734DE; Wed, 9 Aug 2006 15:49:15 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 15:49:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Congestion and Load Balancing Date: Wed, 9 Aug 2006 15:49:13 -0400 Message-ID: In-Reply-To: <007c01c6bbd9$64a01d30$6401a8c0@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Congestion and Load Balancing thread-index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAUxpPA= From: "Uzelac, Adam" To: "Patrick Melampy" , "Klaus Darilion" X-OriginalArrivalTime: 09 Aug 2006 19:49:15.0339 (UTC) FILETIME=[E4E2E9B0:01C6BBEC] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0dcdaa57c570c86b2e4beb0ed476393e Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org One issue here is this - how dependant is Network B on Network A doing the right thing, or anything, with the information that Network B provides? I can tell all my peers that I will only accept 100 sessions at a time, or I only support CODEC X - but that doesn't ensure more than 100 sessions will be attempted, or other CODECs are attempted. For a fact, I am pumping tons of 503s today because folks are exceeding what I told them they should send. And the CODECs that are being offered lists is comedy to observe. An exchange of information between Network A and Network B can only potentially mitigate the risk of violating what Network B wants. =20 -AU PS - The "You can take to the bank" comment makes me think of bad Steven Seagal movies from the 80s. -----Original Message----- From: Patrick Melampy [mailto:PMelampy@acmepacket.com]=20 Sent: Wednesday, August 09, 2006 1:30 PM To: 'Klaus Darilion' Cc: speermint@ietf.org 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:klaus.mailinglists@pernau.at] Sent: Wednesday, August 09, 2006 11:48 AM To: Patrick Melampy Cc: 'Brian Rosen'; speermint@ietf.org Subject: Re: [Speermint] Congestion and Load Balancing Patrick Melampy wrote: > Klaus --- What the carrier needs is four basic requirements (the=20 > receiving or B carrier): >=20 > 1.) To be able to receive calls > 2.) To be able to count the simultaneous calls =3D dialog-statefull proxy > 3.) To be able to count the kilobytes of bandwidth the media is=20 > consuming =3D calls x bandwidth per call. > 4.) To be able to settle accounts in some way >=20 > 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.=20 Rerouting can happen in network B or in network A (SIP redirect 3xx) >=20 > 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=20 > technology you and Brian speak to works. However, none of that=20 > technology helps solve the above problems. The above problems will=20 > 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=20 > 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=20 > 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 >=20 > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Wednesday, August 09, 2006 7:59 AM > To: Brian Rosen > Cc: 'Patrick Melampy'; speermint@ietf.org > Subject: Re: [Speermint] Congestion and Load Balancing >=20 > Some more practical LB issues. >=20 > If the LB is used for load balancing only, there is no need to be=20 > transaction stateful - it depends on the distribution logic of the LB. > If there is a random component within the LB-logic, you need a=20 > 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. >=20 > In-dialog requests will be routed by SIP's loose routing logic, thus=20 > the LB is not needed for in-dialog requests. >=20 > Of course if you imply that a LB also has to do topology hiding and=20 > counting the number of active calls than you need a session-stateful=20 > element. >=20 > regards > klaus >=20 >=20 > Brian Rosen wrote: >> I think the A proxy has a "load balancer", but it's a byproduct of=20 >> 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=20 >> 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=20 >> visible > in >> every message. Of course if the leaf proxies are stateless, so is=20 >> 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=20 >> replicated LB is pretty simple. You do have to model the failure=20 >> cases > and >> make sure the entire load is shouldered by, and distributed to, the=20 >> remaining replicas. >> >> Brian >> >>> -----Original Message----- >>> From: Patrick Melampy [mailto:PMelampy@acmepacket.com] >>> Sent: Saturday, August 05, 2006 4:42 PM >>> To: 'Brian Rosen' >>> Cc: speermint@ietf.org >>> 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=20 >>> proxy and B proxy would require load balancers. The load leaving A=20 >>> might be easily sent to a single very high capacity load balancer=20 >>> that B owns. This load balancer would likely be stateless, and as=20 >>> such unable to really manage the relationship parameters (# of=20 >>> calls, amount of bandwidth, call rate). > Most >>> of the scalable load balancers today are at best TCP stateful with=20 >>> some > L5 >>> cookie mashing to keep TCP socket requests going to the same place.=20 >>> 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=20 >>> process a >>> very large amount of traffic -- lets say in excess of 10,000 calls=20 >>> per second. >>> >>> If B's load balancer was transaction stateful, then B could balance=20 >>> the traffic by transactions. Also note that if B terminated and=20 >>> reoriginated TCP sockets for security association reasons, then B=20 >>> would be required to be transaction stateful at a minimum to=20 >>> remember where messages need to be sent. Problem with B's=20 >>> loadbalancer being transaction stateful, is that > it >>> runs significantly slower. I would bet that it would be at least=20 >>> 1/20 of the performance of the totally stateless model -- lets say=20 >>> 500 calls per second (1000 Transactions per second, 3500 Sip=20 >>> Messages per second...) >>> >>> One problem we have now with B's load balancer, is that B can't=20 >>> really know or control how many real calls are coming from A. For=20 >>> example, A could be >>> sending lots of transactions that are failing. Conversely, A could=20 >>> be sending a very slow rate of transactions that keep sessions up=20 >>> for hours at a time. Obviously, there is still a lack of controls=20 >>> 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=20 >>> that is transaction stateful all the way through a B2BUA like the=20 >>> edge of an IMS network. Now B could keep track of total sessions=20 >>> established coming from >>> A. >>> >>> Probably, A has the same issue that B has ... How many calls coming=20 >>> 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=20 >>> balancer). The concentrator might manage the relationship with B,=20 >>> and provide statefull management of the traffic destined for B. >>> >>> Why is all this required? Well frankly, much of the traffic will=20 >>> have "media" based bandwidth limitations. One could consider a=20 >>> central PDF function to manage the relationship. Either way, the=20 >>> 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=20 >>> 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=20 >>> HTTP where the TCP session and the HTTP session were directly=20 >>> connected -- > with >>> COOKIES binding the physical sessions into logical application=20 >>> sessions, then we could more readily use your suggestions. Last I=20 >>> looked, SIP transactions and dialogues are pretty nasty to=20 >>> recognize, and add retransmissions, cancels, and other nasty things=20 >>> 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=20 >>> is balancing traffic based on established sessions -- you pretty=20 >>> much have a >>> device that wont scale big enough to have one-size fits all....now=20 >>> you have the problem that I suggested. How does A find B's "load=20 >>> balancers" -- which I stated as "how does A find B's proxies, and=20 >>> their attributes. >>> >>> >>> >>> -----Original Message----- >>> From: Brian Rosen [mailto:br@brianrosen.net] >>> Sent: Friday, August 04, 2006 2:28 PM >>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff Devine'; 'Michael=20 >>> Hammer (mhammer)'; 'Hadriel Kaplan' >>> Cc: speermint@ietf.org >>> Subject: RE: [Speermint] Congestion and Load Balancing was Re:=20 >>> Secure RTP >>> >>> In my opinion, the Load Balancer belongs to Proxy B, and it can do=20 >>> anything it likes. PAx sends to LB, and is not aware, and doesn't=20 >>> 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:rpenno@juniper.net] >>>> Sent: Friday, August 04, 2006 2:14 PM >>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer >>> (mhammer); >>>> Hadriel Kaplan >>>> Cc: speermint@ietf.org >>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re:=20 >>>> Secure >>> RTP >>>> Hello Brian, >>>> >>>> Are you assuming some kind of public peering or third party run=20 >>>> 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=20 >>>> distributed _to_ peer's A proxy from peer's A end users. It only=20 >>>> 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=20 >>>> 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=20 >>>> your proposal? >>>> >>>> Thanks, >>>> >>>> Reinaldo >>>> >>>>> -----Original Message----- >>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>> Sent: Friday, August 04, 2006 10:47 AM >>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; >>>>> 'Hadriel Kaplan' >>>>> Cc: speermint@ietf.org >>>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re:=20 >>>>> Secure >>>> RTP >>>>> >>>> Secure >>>>> RTP> >>>>> >>>>> I fail to see why any of this is a standardization issue: I don't=20 >>>>> 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=20 >>>>> the other end do something related to it other than normal SIP=20 >>>>> operations. I certainly don't think it would be advisable to=20 >>>>> introduce such an interface. >>>>> >>>>> I don't think this has much to do with location. Most commercial=20 >>>>> load balancers more or less assume everything is collocated, but=20 >>>>> they don't have to be, and there are simple ways to distribute to=20 >>>>> multiple instances >>>> of >>>>> load >>>>> balancing, which might indeed be the source of the call related,=20 >>>>> 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=20 >>>>> "near" (in an >>>> L3 >>>>> sense) the NY and Miami IXPs and PeerB happens to have facilities=20 >>>>> at, >>>> or >>>>> "near" NY and San Jose. So, the peering exchange might indeed=20 >>>>> 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=20 >>>>> 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=20 >>>>> 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=20 >>>>> traffic, which would cause the originator to try another IP=20 >>>>> address. You can do that with DNS, you can do that with the=20 >>>>> peering database, and there are other mechanisms, none of which=20 >>>>> need any new work in SPEERMINT or SIP. I >>>> don't >>>>> even think we need to enumerate them; it's all something one end=20 >>>>> does itself. >>>>> >>>>> Brian >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Patrick Melampy [mailto:PMelampy@acmepacket.com] >>>>>> Sent: Friday, August 04, 2006 12:39 PM >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; >>>> 'Hadriel >>>>>> Kaplan' >>>>>> Cc: speermint@ietf.org >>>>>> 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=20 >>>>>> the >>>> F5) >>>>>> actually understand and maintain proxy state. Lets explore some=20 >>>>>> 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=20 >>>>>> 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=20 >>>>>> farm) >>>> -- >>>>>> think about balancing load at other locations in the middle of=20 >>>>>> 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=20 >>>>>> put >>>> the >>>>>> load >>>>>> balancer? How do I configure it? What are the data models that=20 >>>>>> could support such a multi-loadbalancer architecture? >>>>>> >>>>>> I urge you to continue developing your load balancer concept.... >>>>>> >>>>>> -----Original Message----- >>>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>>> Sent: Friday, August 04, 2006 12:01 PM >>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer=20 >>>>>> (mhammer)'; 'Hadriel Kaplan' >>>>>> Cc: speermint@ietf.org >>>>>> 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,=20 >>>>>> but >>>> if >>>>> we >>>>>> had proper QoS on the media, that would be, I think, very=20 >>>>>> 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=20 >>>>>> 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=20 >>>>>> that's >>>> not >>>>> a >>>>>> problem). >>>>>> >>>>>> Sure, you need a load balancer. Sure, you need a failover=20 >>>>>> 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=20 >>>>>> to predict the traffic at the peering point. We can engineer=20 >>>>>> systems pretty straightforwardly to handle that traffic. We DO=20 >>>>>> need some >>>> congestion >>>>>> control mechanisms, because the peering mechanisms we have do=20 >>>>>> have >>>>> finite >>>>>> capacity. However, I don't see much need for telephone style=20 >>>>>> call >>>>> gapping >>>>>> and only trivial metering. >>>>>> >>>>>> Today, we can build peering systems where the actual peering=20 >>>>>> happens >>>> at >>>>>> multiple places around the globe, where there is no effective=20 >>>>>> limits >>>> on >>>>>> signaling bandwith (or for that matter, media bandwith) to and=20 >>>>>> 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,=20 >>>>>> use available DNS and other mechanisms to spread load) that are=20 >>>>>> similarly spread >>>> out >>>>> and >>>>>> redundant enough that we get the kind of reliability we expect. =20 >>>>>> 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:gdevine@cedarpointcom.com] >>>>>>> Sent: Friday, August 04, 2006 11:35 AM >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); >>>> Hadriel >>>>>> Kaplan >>>>>>> Cc: speermint@ietf.org >>>>>>> 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=20 >>>>>>> practices >>>> in >>>>>>> the legacy network. >>>>>>> >>>>>>> Geoff >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>>>> Sent: Friday, August 04, 2006 11:27 AM >>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; >>>>>>> 'Hadriel Kaplan' >>>>>>> Cc: speermint@ietf.org >>>>>>> Subject: RE: [Speermint] Secure RTP >>>>>>> >>>>>>> There is no evidence that you can't do this with the mechanisms=20 >>>>>>> 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:gdevine@cedarpointcom.com] >>>>>>>> Sent: Friday, August 04, 2006 11:01 AM >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); >>>> Hadriel >>>>>>> Kaplan >>>>>>>> Cc: speermint@ietf.org >>>>>>>> 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=20 >>>>>>>> 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:br@brianrosen.net] >>>>>>>> Sent: Friday, August 04, 2006 10:20 AM >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel >>>> Kaplan' >>>>>>>> Cc: speermint@ietf.org >>>>>>>> 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=20 >>>>>>>> techniques to deal with SIP load. I certainly don't see=20 >>>>>>>> reasons to make the originator aware of congestion issues at=20 >>>>>>>> the terminating domain, beyond the contractual limits that may=20 >>>>>>>> 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=20 >>>>>>>> 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:PMelampy@acmepacket.com] >>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM >>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel >>>> Kaplan' >>>>>>>>> Cc: speermint@ietf.org >>>>>>>>> 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:br@brianrosen.net] >>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM >>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' >>>>>>>>> Cc: speermint@ietf.org >>>>>>>>> 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:mhammer@cisco.com] >>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM >>>>>>>>>> To: Hadriel Kaplan; Brian Rosen >>>>>>>>>> Cc: speermint@ietf.org >>>>>>>>>> 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 >>> 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 >>>>> Speermint@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/speermint >> >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 15:50:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAu4B-0006Fp-Jn; Wed, 09 Aug 2006 15:50:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAu42-0006EQ-Iu; Wed, 09 Aug 2006 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAu42-0003WW-7d; Wed, 09 Aug 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 303EF32886; Wed, 9 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GAu42-0002fr-24; Wed, 09 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 09 Aug 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-architecture-00.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Peering Architecture Author(s) : R. Penno Filename : draft-ietf-speermint-architecture-00.txt Pages : 19 Date : 2006-8-9 This document defines a SPEERMINT peering reference architecture, its functional components and peering interface functions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-architecture-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-architecture-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-architecture-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-9105008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-architecture-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-architecture-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-9105008.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Wed Aug 09 15:50:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAu4B-0006Ff-CL; Wed, 09 Aug 2006 15:50:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAu42-0006EO-Hw; Wed, 09 Aug 2006 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAu42-0003WX-7g; Wed, 09 Aug 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 2B58432881; Wed, 9 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GAu42-0002fo-0E; Wed, 09 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 09 Aug 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-architecture-00.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Peering Architecture Author(s) : R. Penno Filename : draft-ietf-speermint-architecture-00.txt Pages : 19 Date : 2006-8-9 This document defines a SPEERMINT peering reference architecture, its functional components and peering interface functions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-architecture-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-architecture-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-architecture-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-9104935.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-architecture-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-architecture-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-9104935.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Wed Aug 09 16:49:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuzw-0004fF-EB; Wed, 09 Aug 2006 16:49:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuzv-0004fA-4b for speermint@ietf.org; Wed, 09 Aug 2006 16:49:51 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAuzr-0001bk-VK for speermint@ietf.org; Wed, 09 Aug 2006 16:49:51 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GAuze-0005sW-RI; Wed, 09 Aug 2006 15:49:37 -0500 From: "Brian Rosen" To: "'Patrick Melampy'" , "'Klaus Darilion'" Subject: RE: [Speermint] Congestion and Load Balancing Date: Wed, 9 Aug 2006 16:49:35 -0400 Message-ID: <0a1701c6bbf5$57aa2d70$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <007c01c6bbd9$64a01d30$6401a8c0@acmepacket.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: c5360d8dc5896b7620777c236feb980a Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:PMelampy@acmepacket.com] > Sent: Wednesday, August 09, 2006 1:30 PM > To: 'Klaus Darilion' > Cc: 'Brian Rosen'; speermint@ietf.org > 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:klaus.mailinglists@pernau.at] > Sent: Wednesday, August 09, 2006 11:48 AM > To: Patrick Melampy > Cc: 'Brian Rosen'; speermint@ietf.org > 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:klaus.mailinglists@pernau.at] > > Sent: Wednesday, August 09, 2006 7:59 AM > > To: Brian Rosen > > Cc: 'Patrick Melampy'; speermint@ietf.org > > 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:PMelampy@acmepacket.com] > >>> Sent: Saturday, August 05, 2006 4:42 PM > >>> To: 'Brian Rosen' > >>> Cc: speermint@ietf.org > >>> 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:br@brianrosen.net] > >>> Sent: Friday, August 04, 2006 2:28 PM > >>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff Devine'; 'Michael > Hammer > >>> (mhammer)'; 'Hadriel Kaplan' > >>> Cc: speermint@ietf.org > >>> 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:rpenno@juniper.net] > >>>> Sent: Friday, August 04, 2006 2:14 PM > >>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer > >>> (mhammer); > >>>> Hadriel Kaplan > >>>> Cc: speermint@ietf.org > >>>> 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:br@brianrosen.net] > >>>>> Sent: Friday, August 04, 2006 10:47 AM > >>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; > >>>>> 'Hadriel Kaplan' > >>>>> Cc: speermint@ietf.org > >>>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: > Secure > >>>> RTP > >>>>> 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:PMelampy@acmepacket.com] > >>>>>> Sent: Friday, August 04, 2006 12:39 PM > >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; > >>>> 'Hadriel > >>>>>> Kaplan' > >>>>>> Cc: speermint@ietf.org > >>>>>> 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:br@brianrosen.net] > >>>>>> Sent: Friday, August 04, 2006 12:01 PM > >>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > >>>>>> 'Hadriel > >>>>>> Kaplan' > >>>>>> Cc: speermint@ietf.org > >>>>>> 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:gdevine@cedarpointcom.com] > >>>>>>> Sent: Friday, August 04, 2006 11:35 AM > >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > >>>> Hadriel > >>>>>> Kaplan > >>>>>>> Cc: speermint@ietf.org > >>>>>>> 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:br@brianrosen.net] > >>>>>>> Sent: Friday, August 04, 2006 11:27 AM > >>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > >>>>>>> 'Hadriel Kaplan' > >>>>>>> Cc: speermint@ietf.org > >>>>>>> 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:gdevine@cedarpointcom.com] > >>>>>>>> Sent: Friday, August 04, 2006 11:01 AM > >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > >>>> Hadriel > >>>>>>> Kaplan > >>>>>>>> Cc: speermint@ietf.org > >>>>>>>> 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:br@brianrosen.net] > >>>>>>>> Sent: Friday, August 04, 2006 10:20 AM > >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel > >>>> Kaplan' > >>>>>>>> Cc: speermint@ietf.org > >>>>>>>> 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:PMelampy@acmepacket.com] > >>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM > >>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel > >>>> Kaplan' > >>>>>>>>> Cc: speermint@ietf.org > >>>>>>>>> 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:br@brianrosen.net] > >>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM > >>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > >>>>>>>>> Cc: speermint@ietf.org > >>>>>>>>> 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:mhammer@cisco.com] > >>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM > >>>>>>>>>> To: Hadriel Kaplan; Brian Rosen > >>>>>>>>>> Cc: speermint@ietf.org > >>>>>>>>>> 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 >>>> 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 > >>>>> Speermint@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/speermint > >> > >> > >> _______________________________________________ > >> Speermint mailing list > >> Speermint@ietf.org > >> https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 17:06:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvGS-0001Gj-Ok; Wed, 09 Aug 2006 17:06:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvGR-0001Ge-Jd for speermint@ietf.org; Wed, 09 Aug 2006 17:06:55 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAvGQ-0003IS-8X for speermint@ietf.org; Wed, 09 Aug 2006 17:06:55 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 09 Aug 2006 14:06:59 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="575914555:sNHT37867578" x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 Date: Wed, 9 Aug 2006 17:07:08 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2805183058@proton.jnpr.net> In-Reply-To: <44DA047F.1030901@pernau.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00 Thread-Index: Aca7y9USak9q1Ea9Rt+Svb+FkOdOcQAK7LaQ From: "Reinaldo Penno" To: "Klaus Darilion" X-Spam-Score: 1.1 (+) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I'm sorry, the whole point that somebody made before is that you could = use _any_ client and things you would work. If now you are saying that = you need to use a compliant client, then that's just like other = carriers.=20 > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Wednesday, August 09, 2006 8:51 AM > To: Reinaldo Penno > Cc: Gunnar Hellstr=F6m; Alexander Mayrhofer; speermint > Subject: Re: [Speermint]Mediarequirementsin draft-ietf-speermint- > requirements-00 >=20 > It is like in the email world. If you use a standard compliant email > client, email will work, regards what is your client and regardless = who > is the provider. >=20 > Of course these service providers do not guarantee that the service = will > work when using non-supported SIP clients, but if you use a compliant > SIP client, it will work. >=20 > regards > klaus >=20 > Reinaldo Penno wrote: > > Hello Gunnar, > > > > Not sure I follow your explanation. Is there a website for such = ISP(s) > that allows a user to use any SIP endpoint and guarantee call = completion > across the planet? I'm really curious on how they opearate... > > > > Thanks, > > > > Reinaldo > > > >> -----Original Message----- > >> From: Gunnar Hellstr=F6m [mailto:gunnar.hellstrom@omnitor.se] > >> Sent: Wednesday, August 09, 2006 6:38 AM > >> To: Reinaldo Penno; Klaus Darilion > >> Cc: Alexander Mayrhofer; speermint > >> Subject: RE: [Speermint]Mediarequirementsin draft-ietf-speermint- > >> requirements-00 > >> > >> I know ISP:s who enable SIP calls anywhere, but not with any > transcoding. > >> > >> Gunnar > >> > >> -----Original Message----- > >> From: Reinaldo Penno [mailto:rpenno@juniper.net] > >> Sent: Wednesday, August 09, 2006 1:37 PM > >> To: Klaus Darilion > >> Cc: Alexander Mayrhofer; Gunnar Hellstr=F6m; speermint > >> Subject: RE: [Speermint]Mediarequirementsin > >> draft-ietf-speermint-requirements-00 > >> > >> > >> Do they guarantee universal call completion? By that I mean, can = you > make > >> a > >> call to anywhere and send/receive media? Do they perform = transcoding to > >> achieve that? > >> > >> > >> > >>> -----Original Message----- > >>> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > >>> Sent: Wednesday, August 09, 2006 5:32 AM > >>> To: Reinaldo Penno > >>> Cc: Alexander Mayrhofer; Gunnar Hellstr=F6m; speermint > >>> Subject: Re: [Speermint]Mediarequirementsin draft-ietf-speermint- > >>> requirements-00 > >>> > >>> Reinaldo Penno wrote: > >>>> I think we are forgetting the business aspect here. > >>>> > >>>> Are there such ISPs in Europe that allow you to choose whatever > >>>> equipment you like and still support your installation? (This is = a > >>>> legitimate question). I haven't lived in Europe long enough to = notice > >>>> these things. > >>> Yes, there are such ISPs. You get your SIP provisioning data and = can > use > >>> any SIP client. > >>> > >>> regards > >>> klaus > >>> > >>>> In the US when you buy DSL or Cable service you receive the modem = by > >>>> mail. You can choose your modem but it has to be on a list of > >>>> supported modems, otherwise you are on your own. I cannot imagine = an > >>>> ISP supporting any end device/modem/phone, it would be a money = black > >>>> hole. > >>>> > >>>> I believe the real issue is at (or near) the peering point where = you > >>>> will have to possibly perform transcoding. > >>>> > >>>> > >>>>> Would that mean that such a peer would then not be compliant, > >>>>> because one of his customers does not support the REQUIRED = codec? I > >>>>> can't imagine that's the intent > >>>>> > >>>>> What about saying something like "Peers SHOULD NOT artificially > >>>>> limit the set of codecs on behalf of their clients. In case the > >>>>> peer provides transcoding services, the following codecs MUST be > >>>>> supported: ..."? > >>>>> > >>>>> BTW, "codecs" is not just the algorithm... the next rathole is > >>>>> "media packet sizes" (30ms packets anyone? :) Do we want to go = down > >>>>> there? > >>>>> > >>>>> cheers > >>>>> > >>>>> alex > >>>>> > >>>>> _______________________________________________ Speermint = mailing > >>>>> list Speermint@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/speermint > >>>> _______________________________________________ Speermint mailing > >>>> list Speermint@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 17:09:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvIY-0001eF-1J; Wed, 09 Aug 2006 17:09:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvIW-0001e7-HQ for speermint@ietf.org; Wed, 09 Aug 2006 17:09:04 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAvIV-0003Qj-3O for speermint@ietf.org; Wed, 09 Aug 2006 17:09:04 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 09 Aug 2006 14:09:02 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="1845697947:sNHT38902080" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79L927e019514; Wed, 9 Aug 2006 14:09:02 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k79L91IZ007698; Wed, 9 Aug 2006 14:09:01 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 17:09:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Congestion and Load Balancing Date: Wed, 9 Aug 2006 17:08:59 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301CE9351@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Congestion and Load Balancing Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMA== From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Patrick Melampy" , "Klaus Darilion" X-OriginalArrivalTime: 09 Aug 2006 21:09:00.0962 (UTC) FILETIME=[09570820:01C6BBF8] DKIM-Signature: a=rsa-sha1; q=dns; l=38107; t=1155157742; x=1156021742; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Congestion=20and=20Load=20Balancing; X=v=3Dcisco.com=3B=20h=3DD+ZIob6N7qWaKrQ323RA13TkaLI=3D; b=D2Zhj9ig/5cRPfGWFj8yZJlfTu8oTK5oOWBHddph8gV3a8iHlpJ89bc4RTP1rWUKZ4u7VtzS xZfyGMEvPH/WkWO90G06TRs7BZDXY/aaleInHBZuQc+cTg8N5sL0toDM; Authentication-Results: sj-dkim-6.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a524c7c9e934f9a0c4cc31bc9e9e4c51 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:br@brianrosen.net]=20 > Sent: Wednesday, August 09, 2006 4:50 PM > To: 'Patrick Melampy'; 'Klaus Darilion' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing >=20 > I don't think there is anything particularly dynamic about=20 > what A knows about B, because it will be subject to contract.=20 > I do not think we know enough to design congestion control=20 > mechanisms that work across the peering boundary. I am not=20 > aware of experimental work that would point towards what=20 > kinds of mechanisms are appropriate, and in the absence of=20 > some working examples, I fail to see why we should even=20 > consider it. We can limit calls per unit of time, and=20 > bandwidth, on a list of proxies and I think that's it. >=20 > The design of congestion control protocols is fraught with=20 > failures on things that ought to have worked. The congestion=20 > control mechanisms we see in the PSTN are wholly unsuitable=20 > for the Internet. What we will need for the Internet has yet=20 > to be investigated. I encourage such investigation. > I'd be very interested in reports describing new mechanisms=20 > and how well they work, both on simulated and real traffic. >=20 > But unless you can point to something that appears to work,=20 > it's out of bounds for this group, in my opinion. >=20 > Brian >=20 > > -----Original Message----- > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Sent: Wednesday, August 09, 2006 1:30 PM > > To: 'Klaus Darilion' > > Cc: 'Brian Rosen'; speermint@ietf.org > > Subject: RE: [Speermint] Congestion and Load Balancing > >=20 > > Network A needs to know things about Network B (dynamic=20 > things). This=20 > > is what spearmint is about. A needs to know where B's=20 > proxies are, and=20 > > how to use them. A will have many possible ways of reaching=20 > downstream=20 > > domains. A needs to be able to efficiently route traffic. This=20 > > requires information about B's capabilities (speeds, rates,=20 > volumes). > >=20 > > Its all very simple. Either A has to provision everything=20 > based on B's=20 > > information, or we need to develop a protocol for exchanging this=20 > > information. > >=20 > > The advantage of a protocol, is that the information can be=20 > dynamic,=20 > > and the same protocol can be used for congestion control > >=20 > > You pooh-pooh congestion control. Service Provider Peering=20 > will never=20 > > work if it doesn't have congestion control. You can take=20 > that to the bank. > >=20 > > --- Patrick > > -----Original Message----- > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > Sent: Wednesday, August 09, 2006 11:48 AM > > To: Patrick Melampy > > Cc: 'Brian Rosen'; speermint@ietf.org > > Subject: Re: [Speermint] Congestion and Load Balancing > >=20 > > 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 > >=20 > > =3D dialog-statefull proxy > >=20 > > > 3.) To be able to count the kilobytes of bandwidth the media is > > consuming > >=20 > > =3D calls x bandwidth per call. > >=20 > > > 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 > >=20 > > Manage congestions have 2 results: either tell A that there=20 > is no way=20 > > to route this call in network B, or reroute the call to an=20 > idle node. > > Rerouting can happen in network B or in network A (SIP redirect 3xx) > > > > > > A stateless load balancer can't provide these. > >=20 > > IMO a load balancer is a load balancer, and beeing statefull at SIP=20 > > layser is different to knowing the state (load) on the SIP=20 > proxies and=20 > > media gateways inside your network. A LB can be SIP stateless, but=20 > > still knows the status of the SIP nodes in the network and may=20 > > distribute the calls accordingly to the SIP nodes (ok, here a=20 > > transaction stateful LB would be good, but a session=20 > statefull LB is=20 > > not required) > >=20 > > > I believe that semi-stateless load-balancers are required. All of=20 > > > the technology you and Brian speak to works. However, none of that > > technology > > > helps solve the above problems. The above problems will=20 > ultimately=20 > > > call > > for > > > distributed session state with distributed admission=20 > control. I also > > believe > > > that the load balancers will be semi-stateful (slightly=20 > slower than=20 > > > a redirect, but more reliable from B's point of view) and=20 > will not=20 > > > scale > > to > > > the point where only one is required. I would suggest=20 > that locating > > these > > > semi-stateful proxies and their attributes (distributed admission > > control > > > parameters) will be important topics for this group. > >=20 > > IMO this is inside of network B, thus out of scope for SPEERMINT. > >=20 > > regards > > klaus > >=20 > >=20 > > > > > > -----Original Message----- > > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > > Sent: Wednesday, August 09, 2006 7:59 AM > > > To: Brian Rosen > > > Cc: 'Patrick Melampy'; speermint@ietf.org > > > 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=20 > > > transaction stateful - it depends on the distribution=20 > logic of the LB. > > > If there is a random component within the LB-logic, you need a=20 > > > transaction statefull LB to ensure proper handling of=20 > retransmissions. > > > But if the LB-logic is based on some part of the message (e.g.=20 > > > callid, R-URI), then the LB will route retransmissions=20 > always to the same proxy. > > > > > > In-dialog requests will be routed by SIP's loose routing=20 > logic, thus=20 > > > the LB is not needed for in-dialog requests. > > > > > > Of course if you imply that a LB also has to do topology=20 > hiding and=20 > > > counting the number of active calls than you need a=20 > session-stateful=20 > > > element. > > > > > > regards > > > klaus > > > > > > > > > Brian Rosen wrote: > > >> I think the A proxy has a "load balancer", but it's a=20 > byproduct of=20 > > >> how > > it > > >> assigns registrants to outgoing proxy servers. > > >> > > >> There are a couple of ways to load balance SIP. One of=20 > the nicest=20 > > >> is a redirect proxy. Another is a transaction aware, but not=20 > > >> transaction stateful LB (might have to be session aware,=20 > depending=20 > > >> on what the leaf proxy did). SIP effectively does have=20 > "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=20 > stateless, so is=20 > > >> 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=20 > calls to the=20 > > >> replicated LB is pretty simple. You do have to model=20 > the failure=20 > > >> cases > > > and > > >> make sure the entire load is shouldered by, and=20 > distributed to, the=20 > > >> remaining replicas. > > >> > > >> Brian > > >> > > >>> -----Original Message----- > > >>> From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > >>> Sent: Saturday, August 05, 2006 4:42 PM > > >>> To: 'Brian Rosen' > > >>> Cc: speermint@ietf.org > > >>> Subject: RE: [Speermint] Congestion and Load Balancing > > >>> > > >>> Assuming that Domain B was determined to be the next domain=20 > > >>> (through a > > > yet > > >>> unknown means), I partially agree. I think in practice,=20 > both the A > > proxy > > >>> and > > >>> B proxy would require load balancers. The load leaving=20 > A might be > > easily > > >>> sent to a single very high capacity load balancer that B owns.=20 > > >>> This > > load > > >>> balancer would likely be stateless, and as such unable to really > > manage > > >>> the > > >>> relationship parameters (# of calls, amount of=20 > bandwidth, call rate). > > > Most > > >>> of the scalable load balancers today are at best TCP=20 > stateful with > > some > > > L5 > > >>> cookie mashing to keep TCP socket requests going to the=20 > same place. > > This > > >>> of > > >>> course will not work for SIP unless we open a new=20 > 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=20 > 10,000 calls=20 > > >>> per second. > > >>> > > >>> If B's load balancer was transaction stateful, then B could=20 > > >>> balance > > the > > >>> traffic by transactions. Also note that if B terminated and > > reoriginated > > >>> TCP > > >>> sockets for security association reasons, then B would=20 > be required=20 > > >>> to > > be > > >>> transaction stateful at a minimum to remember where=20 > messages need=20 > > >>> to > > be > > >>> sent. Problem with B's loadbalancer being transaction=20 > stateful, is > > that > > > it > > >>> runs significantly slower. I would bet that it would be=20 > at least=20 > > >>> 1/20 > > of > > >>> the > > >>> performance of the totally stateless model -- lets say=20 > 500 calls=20 > > >>> per second (1000 Transactions per second, 3500 Sip Messages per=20 > > >>> second...) > > >>> > > >>> One problem we have now with B's load balancer, is that B can't=20 > > >>> really know or control how many real calls are coming=20 > from A. For=20 > > >>> example, A could > > be > > >>> sending lots of transactions that are failing.=20 > Conversely, A could=20 > > >>> be sending a very slow rate of transactions that keep=20 > sessions up=20 > > >>> for > > hours > > >>> at > > >>> a time. Obviously, there is still a lack of controls=20 > for enforcing=20 > > >>> the relationship between B and A. --- Whats missing? > > >>> > > >>> B may require that the load balancer be session stateful. This=20 > > >>> could > > be > > >>> any > > >>> range of possible solutions, including a record route=20 > proxy that=20 > > >>> is transaction stateful all the way through a B2BUA=20 > like the edge=20 > > >>> of an > > IMS > > >>> network. Now B could keep track of total sessions established=20 > > >>> coming > > from > > >>> A. > > >>> > > >>> Probably, A has the same issue that B has ... How many calls=20 > > >>> coming > > from > > > a > > >>> variety of proxies is actually traversing into B's load=20 > balancer.=20 > > >>> I > > would > > >>> suggest that A might need a "concentrator" (the=20 > opposite of a load=20 > > >>> balancer). The concentrator might manage the=20 > relationship with B,=20 > > >>> and provide statefull management of the traffic destined for B. > > >>> > > >>> Why is all this required? Well frankly, much of the=20 > traffic will=20 > > >>> have "media" based bandwidth limitations. One could consider a=20 > > >>> central PDF function to manage the relationship. Either=20 > way, the=20 > > >>> load balancer has > > > the > > >>> same issues. > > >>> > > >>> What if B can't process the communication request? Where does A=20 > > >>> send > > it? > > >>> Is > > >>> there an alternative? How can A determine if there is another=20 > > >>> network > > > (say > > >>> C) that can process the communication? How would A share=20 > > >>> 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=20 > > >>> like > > HTTP > > >>> where the TCP session and the HTTP session were=20 > directly connected=20 > > >>> -- > > > with > > >>> COOKIES binding the physical sessions into logical application > > sessions, > > >>> then we could more readily use your suggestions. Last I looked,=20 > > >>> SIP transactions and dialogues are pretty nasty to=20 > recognize, and=20 > > >>> add retransmissions, cancels, and other nasty things that make=20 > > >>> load > > balancing > > >>> difficult if not impossible with out being a full SIP=20 > participant. > > >>> > > >>> If a load balancer is a full SIP participant, and the load=20 > > >>> balancer is balancing traffic based on established=20 > sessions -- you=20 > > >>> pretty much > > have > > a > > >>> device that wont scale big enough to have one-size fits=20 > all....now=20 > > >>> you have the problem that I suggested. How does A find=20 > B's "load=20 > > >>> balancers" -- which I stated as "how does A find B's=20 > proxies, and=20 > > >>> their attributes. > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: Brian Rosen [mailto:br@brianrosen.net] > > >>> Sent: Friday, August 04, 2006 2:28 PM > > >>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff=20 > Devine'; 'Michael > > Hammer > > >>> (mhammer)'; 'Hadriel Kaplan' > > >>> Cc: speermint@ietf.org > > >>> Subject: RE: [Speermint] Congestion and Load Balancing was Re:=20 > > >>> Secure > > RTP > > >>> > > >>> In my opinion, the Load Balancer belongs to Proxy B,=20 > and it can do=20 > > >>> anything it likes. PAx sends to LB, and is not aware,=20 > and doesn't=20 > > >>> 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:rpenno@juniper.net] > > >>>> Sent: Friday, August 04, 2006 2:14 PM > > >>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer > > >>> (mhammer); > > >>>> Hadriel Kaplan > > >>>> Cc: speermint@ietf.org > > >>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re:=20 > > >>>> 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=20 > 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=20 > > >>>> 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=20 > > >>>> perspective. > > >>>> > > >>>> Would this load balancer be able to probe peer's B=20 > proxy dynamic > > "state" > > >>>> (alive, dead, too many calls, too much bandwidth,=20 > etc)? Is that=20 > > >>>> your proposal? > > >>>> > > >>>> Thanks, > > >>>> > > >>>> Reinaldo > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Brian Rosen [mailto:br@brianrosen.net] > > >>>>> Sent: Friday, August 04, 2006 10:47 AM > > >>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer=20 > > >>>>> (mhammer)'; 'Hadriel Kaplan' > > >>>>> Cc: speermint@ietf.org > > >>>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: > > Secure > > >>>> RTP > > >>>>> thread on > > Secure > > >>>>> RTP> > > >>>>> > > >>>>> I fail to see why any of this is a standardization issue: I=20 > > >>>>> 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=20 > > >>>>> that > > the > > >>>>> other > > >>>>> end do something related to it other than normal SIP=20 > operations. =20 > > >>>>> I certainly don't think it would be advisable to=20 > introduce such=20 > > >>>>> an interface. > > >>>>> > > >>>>> I don't think this has much to do with location. Most=20 > > >>>>> commercial > > load > > >>>>> balancers more or less assume everything is=20 > collocated, but they > > don't > > >>>>> have > > >>>>> to be, and there are simple ways to distribute to multiple=20 > > >>>>> instances > > >>>> of > > >>>>> load > > >>>>> balancing, which might indeed be the source of the=20 > call related,=20 > > >>>>> but again, not something that needs standardization. > > >>>>> > > >>>>> Let's take an example: > > >>>>> > > >>>>> Suppose that a peering system has peering connections=20 > at 3 IXPs=20 > > >>>>> in > > San > > >>>>> Jose, > > >>>>> NY and Miami. PeerA happens to have facilities at, or "near"=20 > > >>>>> (in an > > >>>> L3 > > >>>>> sense) the NY and Miami IXPs and PeerB happens to have=20 > > >>>>> facilities > > at, > > >>>> or > > >>>>> "near" NY and San Jose. So, the peering exchange=20 > might indeed=20 > > >>>>> want > > to > > >>>> try > > >>>>> to send traffic between PeerA and PeerB that=20 > originate in their=20 > > >>>>> NY facilities to the other's proxy in New York. =20 > However, if NY=20 > > >>>>> 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=20 > 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=20 > is not able=20 > > >>>>> to > > >>>> take > > >>>>> the > > >>>>> entire load on a failure, you may need some other=20 > 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.=20 > You can=20 > > >>>>> do > > that > > >>>>> with > > >>>>> DNS, you can do that with the peering database, and there are=20 > > >>>>> other mechanisms, none of which need any new work in=20 > SPEERMINT=20 > > >>>>> or SIP. I > > >>>> don't > > >>>>> even think we need to enumerate them; it's all=20 > something one end > > does > > >>>>> itself. > > >>>>> > > >>>>> Brian > > >>>>> > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > >>>>>> Sent: Friday, August 04, 2006 12:39 PM > > >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer=20 > (mhammer)'; > > >>>> 'Hadriel > > >>>>>> Kaplan' > > >>>>>> Cc: speermint@ietf.org > > >>>>>> 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=20 > load balancer? > > >>>> We > > >>>>> have > > >>>>>> seen these techniques used successfully, and the good ones=20 > > >>>>>> (like > > the > > >>>> F5) > > >>>>>> actually understand and maintain proxy state. Lets=20 > explore some > > more > > >>>> on > > >>>>>> what > > >>>>>> we would want in an ideal load balancer.... > > >>>>>> > > >>>>>> 1.) We would want to balance load based on proxy=20 > responsiveness > > >>>>>> 2.) We might want to balance load based on a fairness=20 > > >>>>>> mechanisms > > >>>> (why > > >>>>> not) > > >>>>>> based on incoming request addresses > > >>>>>> 3.) We might further want to fine tune the balancer to=20 > > >>>>>> 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=20 > > >>>>>> load balancer? > > >>>>>> > > >>>>>> NOW--- and MOST IMPORANTLY--- unlike in a HTTP load balancing > > >>>>> application, > > >>>>>> where there is only one load balancing location (at=20 > the server > > farm) > > >>>> -- > > >>>>>> think about balancing load at other locations in the=20 > middle of=20 > > >>>>>> the network. > > >>>>>> Assume here there are HTTP requests that MUST be proxied or > > >>>> processed by > > >>>>>> your network infrastructure. How would one balance=20 > the load here? > > >>>> What > > >>>>>> would > > >>>>>> the data requirements be? In this case, the=20 > from/to/source/TLS > > >>>> socket > > >>>>>> connections are being multi-plexed at the proxy. So=20 > where do I=20 > > >>>>>> put > > >>>> the > > >>>>>> load > > >>>>>> balancer? How do I configure it? What are the data=20 > models that > > could > > >>>>>> support > > >>>>>> such a multi-loadbalancer architecture? > > >>>>>> > > >>>>>> I urge you to continue developing your load balancer=20 > concept.... > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Brian Rosen [mailto:br@brianrosen.net] > > >>>>>> Sent: Friday, August 04, 2006 12:01 PM > > >>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer=20 > > >>>>>> (mhammer)'; 'Hadriel Kaplan' > > >>>>>> Cc: speermint@ietf.org > > >>>>>> Subject: RE: [Speermint] Secure RTP > > >>>>>> > > >>>>>> This isn't a telephone network. > > >>>>>> > > >>>>>> We typically DON'T have overload conditions on well=20 > engineered > > >>>> networks. > > >>>>>> We > > >>>>>> presently have some mighty fine self limiting issues with=20 > > >>>>>> 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=20 > > >>>>>> based > > >>>> network > > >>>>>> where the signaling issues were a big problem. It's=20 > almost all=20 > > >>>>>> in > > >>>> the > > >>>>>> media. > > >>>>>> > > >>>>>> I know all about "Americal Idol" night. The numbers just=20 > > >>>>>> aren't > > >>>> scary > > >>>>> any > > >>>>>> more. > > >>>>>> > > >>>>>> Do the math. A million BHCA is 278 calls per=20 > 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=20 > > >>>>>> strategy > > >>>> with > > >>>>> a > > >>>>>> good database. > > >>>>>> > > >>>>>> Now, every system has limits. We have an answer for=20 > those: busy. > > >>>>>> > > >>>>>> More importantly, we actually can use some telephone=20 > > >>>>>> engineering to predict the traffic at the peering point. We=20 > > >>>>>> can engineer systems pretty straightforwardly to handle that=20 > > >>>>>> traffic. We DO need some > > >>>> congestion > > >>>>>> control mechanisms, because the peering mechanisms=20 > we have do=20 > > >>>>>> have > > >>>>> finite > > >>>>>> capacity. However, I don't see much need for=20 > telephone style=20 > > >>>>>> 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=20 > bandwith) to and=20 > > >>>>>> from > > >>>> the > > >>>>>> peering points. We can have SIP proxies that perform the=20 > > >>>>>> actual > > >>>> peering > > >>>>>> function (take a call, do a dip to determine where=20 > it's going,=20 > > >>>>>> use available DNS and other mechanisms to spread=20 > load) that are=20 > > >>>>>> similarly spread > > >>>> out > > >>>>> and > > >>>>>> redundant enough that we get the kind of reliability=20 > 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:gdevine@cedarpointcom.com] > > >>>>>>> Sent: Friday, August 04, 2006 11:35 AM > > >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > > >>>> Hadriel > > >>>>>> Kaplan > > >>>>>>> Cc: speermint@ietf.org > > >>>>>>> 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=20 > > >>>>>>> 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=20 > > >>>>>>> practices > > >>>> in > > >>>>>>> the legacy network. > > >>>>>>> > > >>>>>>> Geoff > > >>>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Brian Rosen [mailto:br@brianrosen.net] > > >>>>>>> Sent: Friday, August 04, 2006 11:27 AM > > >>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer=20 > > >>>>>>> (mhammer)'; 'Hadriel Kaplan' > > >>>>>>> Cc: speermint@ietf.org > > >>>>>>> Subject: RE: [Speermint] Secure RTP > > >>>>>>> > > >>>>>>> There is no evidence that you can't do this with the=20 > > >>>>>>> mechanisms we > > >>>>> have, > > >>>>>>> and > > >>>>>>> some that we can. I believe in a contractual,=20 > static, limit=20 > > >>>>>>> on > > >>>>> traffic > > >>>>>>> between peers. I don't think we need anything else. > > >>>>>>> > > >>>>>>> Brian > > >>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > > >>>>>>>> Sent: Friday, August 04, 2006 11:01 AM > > >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > > >>>> Hadriel > > >>>>>>> Kaplan > > >>>>>>>> Cc: speermint@ietf.org > > >>>>>>>> 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=20 > requirements=20 > > >>>>>>>> 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=20 > calls. If=20 > > >>>>>>>> the > > >>>>>>> network > > >>>>>>>> floods a soft switch or media gateway controller=20 > with peering > > >>>>> traffic > > >>>>>>>> with no notion of congestion control, flow=20 > 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:br@brianrosen.net] > > >>>>>>>> Sent: Friday, August 04, 2006 10:20 AM > > >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel > > >>>> Kaplan' > > >>>>>>>> Cc: speermint@ietf.org > > >>>>>>>> Subject: RE: [Speermint] Secure RTP > > >>>>>>>> > > >>>>>>>> I don't think any of this is something we are=20 > chartered to do. > > >>>> I > > >>>>>>> don't > > >>>>>>>> think it's needed, at least for a long time,=20 > 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=20 > > >>>>>>>> those techniques to deal with SIP load. I certainly don't=20 > > >>>>>>>> see reasons to make the originator aware of=20 > congestion issues=20 > > >>>>>>>> at the terminating domain, beyond the contractual=20 > limits that=20 > > >>>>>>>> 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=20 > appear to=20 > > >>>>>>>> be > > >>>> one > > >>>>>>>> domain > > >>>>>>>> name that are always available. > > >>>>>>>> > > >>>>>>>> I don't agree we need anything like a BGP for SIP=20 > any time I=20 > > >>>>>>>> can foresee. > > >>>>>>>> The underlying network handles all the issues I am=20 > 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=20 > it provided). > > >>>>>>>> > > >>>>>>>> Brian > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> -----Original Message----- > > >>>>>>>>> From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > >>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM > > >>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel > > >>>> Kaplan' > > >>>>>>>>> Cc: speermint@ietf.org > > >>>>>>>>> Subject: RE: [Speermint] Secure RTP > > >>>>>>>>> > > >>>>>>>>> Brian, > > >>>>>>>>> > > >>>>>>>>> I agree with you. However some aspects are=20 > protocol worthy. > > >>>> Path > > >>>>>>>>> determination -- or said another way -- the next=20 > 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=20 > to how SS7=20 > > >>>>>>>>> is > > >>>> used > > >>>>>>> to > > >>>>>>>> set > > >>>>>>>>> the service states on each and every DS0. SS7 is the=20 > > >>>>>>>>> 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=20 > 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=20 > which uses the > > >>>> NPA- > > >>>>> NXX > > >>>>>>>>> routing > > >>>>>>>>> models which are hierarchical and well understood, IP=20 > > >>>>>>>>> domains > > >>>> are > > >>>>>>>>> amorphous > > >>>>>>>>> and have very unpredictable intersection points.=20 > 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=20 > provisionable. It=20 > > >>>>>>>>> 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=20 > also think=20 > > >>>>>>>>> we > > >>>>> need > > >>>>>>> to > > >>>>>>>>> leave > > >>>>>>>>> to the individual networks, any and all decisions=20 > on how to > > >>>> run > > >>>>>>> their > > >>>>>>>>> networks, choose next networks, etc. > > >>>>>>>>> > > >>>>>>>>> -----Original Message----- > > >>>>>>>>> From: Brian Rosen [mailto:br@brianrosen.net] > > >>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM > > >>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > >>>>>>>>> Cc: speermint@ietf.org > > >>>>>>>>> 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=20 > > >>>>>>>>> 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=20 > mechanisms exist=20 > > >>>>>>>>> to > > >>>>>>>> provision. > > >>>>>>>>> So, for example, if one of the things peering=20 > 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=20 > > >>>>>>>>> the > > >>>>> limit > > >>>>>>>> is. > > >>>>>>>>> In > > >>>>>>>>> that way, the vendor who builds the proxy for=20 > Peer A will be > > >>>> able > > >>>>> to > > >>>>>>>> build > > >>>>>>>>> in it the ability to meet the policy for Peer B. This is=20 > > >>>>>>>>> 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=20 > 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:mhammer@cisco.com] > > >>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM > > >>>>>>>>>> To: Hadriel Kaplan; Brian Rosen > > >>>>>>>>>> Cc: speermint@ietf.org > > >>>>>>>>>> Subject: RE: [Speermint] Secure RTP > > >>>>>>>>>> > > >>>>>>>>>> The focus of Speermint should be centered around whether=20 > > >>>>>>>>>> one > > >>>> can > > >>>>>>>>>> discover the policies of a potential peer and=20 > whether those > > >>>>>>> policies > > >>>>>>>> can > > >>>>>>>>>> systematically describe the requirements on=20 > multiple levels > > >>>> that > > >>>>>>>> will > > >>>>>>>>>> need to be supported to have a successful communication=20 > > >>>>>>>>>> with > > >>>>> that > > >>>>>>>> peer. > > >>>>>>>>>> It is not about specifying X, Y, Z, or 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=20 > different MUSTs > > >>>> for > > >>>>>>> each > > >>>>>>>>>> category of choices we come up with. > > >>>>>>>>>> > > >>>>>>>>>> Mike > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Speermint mailing list > > >>>>> Speermint@ietf.org > > >>>>> https://www1.ietf.org/mailman/listinfo/speermint > > >> > > >> > > >> _______________________________________________ > > >> Speermint mailing list > > >> Speermint@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/speermint > > > > > > >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 17:37:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvkR-0007db-DV; Wed, 09 Aug 2006 17:37:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvkQ-0007d3-Cx for speermint@ietf.org; Wed, 09 Aug 2006 17:37:54 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAvkP-0005yz-2n for speermint@ietf.org; Wed, 09 Aug 2006 17:37:54 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GAvk4-0001GO-1h; Wed, 09 Aug 2006 16:37:41 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Patrick Melampy'" , "'Klaus Darilion'" Subject: RE: [Speermint] Congestion and Load Balancing Date: Wed, 9 Aug 2006 17:37:36 -0400 Message-ID: <0a2b01c6bbfc$0ed6d1f0$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301CE9351@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cc86a703c278c87994154428627571f Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:mhammer@cisco.com] > Sent: Wednesday, August 09, 2006 5:09 PM > To: Brian Rosen; Patrick Melampy; Klaus Darilion > Cc: speermint@ietf.org > 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 > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, August 09, 2006 4:50 PM > > To: 'Patrick Melampy'; 'Klaus Darilion' > > Cc: speermint@ietf.org > > 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:PMelampy@acmepacket.com] > > > Sent: Wednesday, August 09, 2006 1:30 PM > > > To: 'Klaus Darilion' > > > Cc: 'Brian Rosen'; speermint@ietf.org > > > 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:klaus.mailinglists@pernau.at] > > > Sent: Wednesday, August 09, 2006 11:48 AM > > > To: Patrick Melampy > > > Cc: 'Brian Rosen'; speermint@ietf.org > > > 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:klaus.mailinglists@pernau.at] > > > > Sent: Wednesday, August 09, 2006 7:59 AM > > > > To: Brian Rosen > > > > Cc: 'Patrick Melampy'; speermint@ietf.org > > > > 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:PMelampy@acmepacket.com] > > > >>> Sent: Saturday, August 05, 2006 4:42 PM > > > >>> To: 'Brian Rosen' > > > >>> Cc: speermint@ietf.org > > > >>> 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:br@brianrosen.net] > > > >>> Sent: Friday, August 04, 2006 2:28 PM > > > >>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff > > Devine'; 'Michael > > > Hammer > > > >>> (mhammer)'; 'Hadriel Kaplan' > > > >>> Cc: speermint@ietf.org > > > >>> 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:rpenno@juniper.net] > > > >>>> Sent: Friday, August 04, 2006 2:14 PM > > > >>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer > > > >>> (mhammer); > > > >>>> Hadriel Kaplan > > > >>>> Cc: speermint@ietf.org > > > >>>> 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:br@brianrosen.net] > > > >>>>> Sent: Friday, August 04, 2006 10:47 AM > > > >>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer > > > >>>>> (mhammer)'; 'Hadriel Kaplan' > > > >>>>> Cc: speermint@ietf.org > > > >>>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: > > > Secure > > > >>>> RTP > > > >>>>> > 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:PMelampy@acmepacket.com] > > > >>>>>> Sent: Friday, August 04, 2006 12:39 PM > > > >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer > > (mhammer)'; > > > >>>> 'Hadriel > > > >>>>>> Kaplan' > > > >>>>>> Cc: speermint@ietf.org > > > >>>>>> 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:br@brianrosen.net] > > > >>>>>> Sent: Friday, August 04, 2006 12:01 PM > > > >>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer > > > >>>>>> (mhammer)'; 'Hadriel Kaplan' > > > >>>>>> Cc: speermint@ietf.org > > > >>>>>> 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:gdevine@cedarpointcom.com] > > > >>>>>>> Sent: Friday, August 04, 2006 11:35 AM > > > >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > > > >>>> Hadriel > > > >>>>>> Kaplan > > > >>>>>>> Cc: speermint@ietf.org > > > >>>>>>> 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:br@brianrosen.net] > > > >>>>>>> Sent: Friday, August 04, 2006 11:27 AM > > > >>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer > > > >>>>>>> (mhammer)'; 'Hadriel Kaplan' > > > >>>>>>> Cc: speermint@ietf.org > > > >>>>>>> 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:gdevine@cedarpointcom.com] > > > >>>>>>>> Sent: Friday, August 04, 2006 11:01 AM > > > >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > > > >>>> Hadriel > > > >>>>>>> Kaplan > > > >>>>>>>> Cc: speermint@ietf.org > > > >>>>>>>> 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:br@brianrosen.net] > > > >>>>>>>> Sent: Friday, August 04, 2006 10:20 AM > > > >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel > > > >>>> Kaplan' > > > >>>>>>>> Cc: speermint@ietf.org > > > >>>>>>>> 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:PMelampy@acmepacket.com] > > > >>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM > > > >>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel > > > >>>> Kaplan' > > > >>>>>>>>> Cc: speermint@ietf.org > > > >>>>>>>>> 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:br@brianrosen.net] > > > >>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM > > > >>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > >>>>>>>>> Cc: speermint@ietf.org > > > >>>>>>>>> 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:mhammer@cisco.com] > > > >>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM > > > >>>>>>>>>> To: Hadriel Kaplan; Brian Rosen > > > >>>>>>>>>> Cc: speermint@ietf.org > > > >>>>>>>>>> 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 > 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 > > > >>>>> Speermint@ietf.org > > > >>>>> https://www1.ietf.org/mailman/listinfo/speermint > > > >> > > > >> > > > >> _______________________________________________ > > > >> Speermint mailing list > > > >> Speermint@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 20:11:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAy92-0004do-0p; Wed, 09 Aug 2006 20:11:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAy90-0004dj-9b for speermint@ietf.org; Wed, 09 Aug 2006 20:11:26 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAy8y-0008D1-T6 for speermint@ietf.org; Wed, 09 Aug 2006 20:11:26 -0400 Received: from pb94.dyndns.org (localhost [127.0.0.1]) by pb94.dyndns.org (Postfix) with ESMTP id D12EF21008E; Thu, 10 Aug 2006 02:11:23 +0200 (CEST) Received: from 212.17.67.197 (SquirrelMail authenticated user klaus.mailinglists@pernau.at) by pb94.dyndns.org with HTTP; Thu, 10 Aug 2006 02:11:23 +0200 (CEST) Message-ID: <62872.212.17.67.197.1155168683.squirrel@pb94.dyndns.org> In-Reply-To: <007c01c6bbd9$64a01d30$6401a8c0@acmepacket.com> References: <44DA0397.9090900@pernau.at> <007c01c6bbd9$64a01d30$6401a8c0@acmepacket.com> Date: Thu, 10 Aug 2006 02:11:23 +0200 (CEST) Subject: RE: [Speermint] Congestion and Load Balancing From: "Klaus Darilion" To: "Patrick Melampy" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f0068523cb6bca15634130f00012b297 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Wed, August 9, 2006 19:29, Patrick Melampy said: > Network A needs to know things about Network B (dynamic things). This i= s > 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 informatio= n > about B's capabilities (speeds, rates, volumes). Aren't that policy issues, which are part of an interconnect agreement? I do not think that such dynamics update will work. E.g. a simple scenario. Provider T peers with A and B. T can handle 100 concurrent calls. Thus it announces to both ( A and B) that 100 calls are available. Once B makes a call, it announces to both that now only 99 calls are available and so on. You will generate much more traffic with dynamic updates than with SIP signalling. We should keep things simple, and we should not build PSTN over IP, and w= e should not over engineer things. > 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, an= d > the > same protocol can be used for congestion control There are other scenarios besides mutual peering. There may be federations, and maybe some providers will have open URIs. In such scenarios, where you do not know each possible peer in advance, in advanc= e provisioning is not possible. > > You pooh-pooh congestion control. Service Provider Peering will never w= ork > if it doesn't have congestion control. You can take that to the bank. Maybe we should first specify what congestion control exactly requires (and btw: how is congestion control done in the PSTN?). I'm sure lots of this requirements canbe fulfilled with pure SIP, which will ease things. regards klaus > > --- Patrick > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Wednesday, August 09, 2006 11:48 AM > To: Patrick Melampy > Cc: 'Brian Rosen'; speermint@ietf.org > 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 > > =3D dialog-statefull proxy > >> 3.) To be able to count the kilobytes of bandwidth the media is >> consuming > > =3D 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 t= o > 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 stil= l > 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 cal= l > 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:klaus.mailinglists@pernau.at] >> Sent: Wednesday, August 09, 2006 7:59 AM >> To: Brian Rosen >> Cc: 'Patrick Melampy'; speermint@ietf.org >> 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 prox= y. >> >> In-dialog requests will be routed by SIP's loose routing logic, thus t= he >> 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 ho= w >>> 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 le= af >>> 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 th= e > 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 cas= es >> and >>> make sure the entire load is shouldered by, and distributed to, the >>> remaining replicas. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: Patrick Melampy [mailto:PMelampy@acmepacket.com] >>>> Sent: Saturday, August 05, 2006 4:42 PM >>>> To: 'Brian Rosen' >>>> Cc: speermint@ietf.org >>>> 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 p= er >>>> 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 t= o >>>> 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/2= 0 >>>> 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 real= ly >>>> know >>>> or control how many real calls are coming from A. For example, A cou= ld > be >>>> sending lots of transactions that are failing. Conversely, A could b= e >>>> 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 t= he >>>> 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, an= d >>>> provide statefull management of the traffic destined for B. >>>> >>>> Why is all this required? Well frankly, much of the traffic will hav= e >>>> "media" based bandwidth limitations. One could consider a central PD= F >>>> function to manage the relationship. Either way, the load balancer h= as >> 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 networ= k >> (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 y= ou >>>> 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:br@brianrosen.net] >>>> Sent: Friday, August 04, 2006 2:28 PM >>>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff Devine'; 'Michael >>>> Hammer >>>> (mhammer)'; 'Hadriel Kaplan' >>>> Cc: speermint@ietf.org >>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: Secur= e > 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, whic= h > PBy >>>> gets the call. SIP handles this well. >>>> >>>> Of course LB is a single point of failure. >>>> >>>> Brian >>>> >>>>> -----Original Message----- >>>>> From: Reinaldo Penno [mailto:rpenno@juniper.net] >>>>> Sent: Friday, August 04, 2006 2:14 PM >>>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer >>>> (mhammer); >>>>> Hadriel Kaplan >>>>> Cc: speermint@ietf.org >>>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: Secu= re >>>> 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 you= r >>>>> proposal? >>>>> >>>>> Thanks, >>>>> >>>>> Reinaldo >>>>> >>>>>> -----Original Message----- >>>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>>> Sent: Friday, August 04, 2006 10:47 AM >>>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; >>>>>> 'Hadriel Kaplan' >>>>>> Cc: speermint@ietf.org >>>>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: >>>>>> Secure >>>>> RTP >>>>>> >>>>> 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 instanc= es >>>>> of >>>>>> load >>>>>> balancing, which might indeed be the source of the call related, b= ut >>>>>> 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 wan= t >>>>>> 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 t= o >>>>> 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 othe= r >>>>>> 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:PMelampy@acmepacket.com] >>>>>>> Sent: Friday, August 04, 2006 12:39 PM >>>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; >>>>> 'Hadriel >>>>>>> Kaplan' >>>>>>> Cc: speermint@ietf.org >>>>>>> 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 accommodat= e >>>>> 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 th= e >>>>>>> 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 pu= t >>>>> 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:br@brianrosen.net] >>>>>>> Sent: Friday, August 04, 2006 12:01 PM >>>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer (mhammer)'= ; >>>>>>> 'Hadriel >>>>>>> Kaplan' >>>>>>> Cc: speermint@ietf.org >>>>>>> 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 i= n >>>>> 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 strate= gy >>>>> 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 hav= e >>>>>> finite >>>>>>> capacity. However, I don't see much need for telephone style cal= l >>>>>> 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 fr= om >>>>> 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, us= e >>>>>>> available >>>>>>> DNS and other mechanisms to spread load) that are similarly sprea= d >>>>> 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:gdevine@cedarpointcom.com] >>>>>>>> Sent: Friday, August 04, 2006 11:35 AM >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); >>>>> Hadriel >>>>>>> Kaplan >>>>>>>> Cc: speermint@ietf.org >>>>>>>> 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 practic= es >>>>> in >>>>>>>> the legacy network. >>>>>>>> >>>>>>>> Geoff >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>>>>> Sent: Friday, August 04, 2006 11:27 AM >>>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; >>>>>>>> 'Hadriel Kaplan' >>>>>>>> Cc: speermint@ietf.org >>>>>>>> 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:gdevine@cedarpointcom.com] >>>>>>>>> Sent: Friday, August 04, 2006 11:01 AM >>>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); >>>>> Hadriel >>>>>>>> Kaplan >>>>>>>>> Cc: speermint@ietf.org >>>>>>>>> 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 th= e >>>>>>>> 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:br@brianrosen.net] >>>>>>>>> Sent: Friday, August 04, 2006 10:20 AM >>>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel >>>>> Kaplan' >>>>>>>>> Cc: speermint@ietf.org >>>>>>>>> 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 th= e >>>>>>>>> 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 ca= n >>>>>>>>> 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:PMelampy@acmepacket.com] >>>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM >>>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel >>>>> Kaplan' >>>>>>>>>> Cc: speermint@ietf.org >>>>>>>>>> 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:br@brianrosen.net] >>>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM >>>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' >>>>>>>>>> Cc: speermint@ietf.org >>>>>>>>>> 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:mhammer@cisco.com] >>>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM >>>>>>>>>>> To: Hadriel Kaplan; Brian Rosen >>>>>>>>>>> Cc: speermint@ietf.org >>>>>>>>>>> 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 >>>> 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 >>>>>> Speermint@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/speermint >>> >>> >>> _______________________________________________ >>> Speermint mailing list >>> Speermint@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speermint >> >> > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 20:28:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAyPd-0008O9-0n; Wed, 09 Aug 2006 20:28:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAyPc-0008O4-Di for speermint@ietf.org; Wed, 09 Aug 2006 20:28:36 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAyPb-0001HU-0N for speermint@ietf.org; Wed, 09 Aug 2006 20:28:36 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GAyPM-0005Pb-Qq; Wed, 09 Aug 2006 19:28:21 -0500 From: "Brian Rosen" To: "'Daryl Malas'" Subject: Re: [Speermint] Congestion and Load Balancing Date: Wed, 9 Aug 2006 20:28:24 -0400 Message-ID: <0a6a01c6bc13$e7ac5830$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca8ASisH7mtSEP2TJKx1Y4ZhsjHQAACLyEgAAJigZA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:daryl@level3.net] > Sent: Wednesday, August 09, 2006 6:12 PM > To: Brian Rosen > Cc: 'Michael Hammer (mhammer)'; 'Patrick Melampy'; 'Klaus Darilion'; > speermint@ietf.org > 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:mhammer@cisco.com] > > > Sent: Wednesday, August 09, 2006 5:09 PM > > > To: Brian Rosen; Patrick Melampy; Klaus Darilion > > > Cc: speermint@ietf.org > > > 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 > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 09 22:28:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB0Hv-0002vT-Ly; Wed, 09 Aug 2006 22:28:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB0Hu-0002vO-Gx for speermint@ietf.org; Wed, 09 Aug 2006 22:28:46 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB0Ht-0000FS-9N for speermint@ietf.org; Wed, 09 Aug 2006 22:28:46 -0400 Received: from PMelampy2 [68.189.242.21] by acmepacket.com with ESMTP (SMTPD-9.03) id A9D10150; Wed, 09 Aug 2006 22:28:33 -0400 From: "Patrick Melampy" To: "'Brian Rosen'" , "'Klaus Darilion'" Subject: RE: [Speermint] Congestion and Load Balancing Date: Wed, 9 Aug 2006 22:28:32 -0400 Message-ID: <001801c6bc24$ad448030$6401a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAACxw7YA== In-Reply-To: <0a1701c6bbf5$57aa2d70$9de6a8c0@cis.neustar.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 40dcdfec62eed13950fa8e354a820e1d Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Maybe its simple when its two networks to understand why dynamic protocols aren't required. Lets consider the following -- and try to imagine just how complicated a real life situation would be. 3 carriers A, B, and C each having hosted enterprise SIP domains labeled e1, e2 ... en. Consider this topology... A<--------->B<------------->C | | | +--e1 +--e3 +--e3 | | | +--e2 +--e4 +--e6 | | | +--en +--en +--en In the above network, there are en sip domains hosted by carriers A, B, and C. Question for you...... 1.) How will C discover that B offers trusted SIPS proxy routing services to domains e1, and e2 hosted by carrier A? 2.) How will A notify B and C that its hosting a new enterprise domain en? 3.) What if e6 moves from carrier C to carrier A? 4.) e3 is available through both carrier B and carrier C. Which is better? I know that if there were no transit or peering carriers, these problems would be solved by ENUM and DNS and standard internet routing. But this working group is tasked with studying the vary problems that occur when we add session peering to establish trusted interconnects to build large networks that are manageable and predictable. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, August 09, 2006 4:50 PM To: 'Patrick Melampy'; 'Klaus Darilion' Cc: speermint@ietf.org 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:PMelampy@acmepacket.com] > Sent: Wednesday, August 09, 2006 1:30 PM > To: 'Klaus Darilion' > Cc: 'Brian Rosen'; speermint@ietf.org > 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:klaus.mailinglists@pernau.at] > Sent: Wednesday, August 09, 2006 11:48 AM > To: Patrick Melampy > Cc: 'Brian Rosen'; speermint@ietf.org > 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:klaus.mailinglists@pernau.at] > > Sent: Wednesday, August 09, 2006 7:59 AM > > To: Brian Rosen > > Cc: 'Patrick Melampy'; speermint@ietf.org > > 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:PMelampy@acmepacket.com] > >>> Sent: Saturday, August 05, 2006 4:42 PM > >>> To: 'Brian Rosen' > >>> Cc: speermint@ietf.org > >>> 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:br@brianrosen.net] > >>> Sent: Friday, August 04, 2006 2:28 PM > >>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff Devine'; 'Michael > Hammer > >>> (mhammer)'; 'Hadriel Kaplan' > >>> Cc: speermint@ietf.org > >>> 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:rpenno@juniper.net] > >>>> Sent: Friday, August 04, 2006 2:14 PM > >>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer > >>> (mhammer); > >>>> Hadriel Kaplan > >>>> Cc: speermint@ietf.org > >>>> 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:br@brianrosen.net] > >>>>> Sent: Friday, August 04, 2006 10:47 AM > >>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; > >>>>> 'Hadriel Kaplan' > >>>>> Cc: speermint@ietf.org > >>>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: > Secure > >>>> RTP > >>>>> 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:PMelampy@acmepacket.com] > >>>>>> Sent: Friday, August 04, 2006 12:39 PM > >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; > >>>> 'Hadriel > >>>>>> Kaplan' > >>>>>> Cc: speermint@ietf.org > >>>>>> 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:br@brianrosen.net] > >>>>>> Sent: Friday, August 04, 2006 12:01 PM > >>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > >>>>>> 'Hadriel > >>>>>> Kaplan' > >>>>>> Cc: speermint@ietf.org > >>>>>> 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:gdevine@cedarpointcom.com] > >>>>>>> Sent: Friday, August 04, 2006 11:35 AM > >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > >>>> Hadriel > >>>>>> Kaplan > >>>>>>> Cc: speermint@ietf.org > >>>>>>> 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:br@brianrosen.net] > >>>>>>> Sent: Friday, August 04, 2006 11:27 AM > >>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > >>>>>>> 'Hadriel Kaplan' > >>>>>>> Cc: speermint@ietf.org > >>>>>>> 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:gdevine@cedarpointcom.com] > >>>>>>>> Sent: Friday, August 04, 2006 11:01 AM > >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > >>>> Hadriel > >>>>>>> Kaplan > >>>>>>>> Cc: speermint@ietf.org > >>>>>>>> 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:br@brianrosen.net] > >>>>>>>> Sent: Friday, August 04, 2006 10:20 AM > >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel > >>>> Kaplan' > >>>>>>>> Cc: speermint@ietf.org > >>>>>>>> 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:PMelampy@acmepacket.com] > >>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM > >>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel > >>>> Kaplan' > >>>>>>>>> Cc: speermint@ietf.org > >>>>>>>>> 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:br@brianrosen.net] > >>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM > >>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > >>>>>>>>> Cc: speermint@ietf.org > >>>>>>>>> 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:mhammer@cisco.com] > >>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM > >>>>>>>>>> To: Hadriel Kaplan; Brian Rosen > >>>>>>>>>> Cc: speermint@ietf.org > >>>>>>>>>> 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 >>>> 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 > >>>>> Speermint@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/speermint > >> > >> > >> _______________________________________________ > >> Speermint mailing list > >> Speermint@ietf.org > >> https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 10 02:03:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB3dV-0004Ui-AY; Thu, 10 Aug 2006 02:03:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB3dU-0004Ua-HG for speermint@ietf.org; Thu, 10 Aug 2006 02:03:16 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB3dT-00071Y-0y for speermint@ietf.org; Thu, 10 Aug 2006 02:03:16 -0400 Received: from pb94.dyndns.org (localhost [127.0.0.1]) by pb94.dyndns.org (Postfix) with ESMTP id 63B20210069; Thu, 10 Aug 2006 08:03:14 +0200 (CEST) Received: from 212.17.67.197 (SquirrelMail authenticated user klaus.mailinglists@pernau.at) by pb94.dyndns.org with HTTP; Thu, 10 Aug 2006 08:03:14 +0200 (CEST) Message-ID: <63976.212.17.67.197.1155189794.squirrel@pb94.dyndns.org> In-Reply-To: <001801c6bc24$ad448030$6401a8c0@acmepacket.com> References: <0a1701c6bbf5$57aa2d70$9de6a8c0@cis.neustar.com> <001801c6bc24$ad448030$6401a8c0@acmepacket.com> Date: Thu, 10 Aug 2006 08:03:14 +0200 (CEST) Subject: RE: [Speermint] Congestion and Load Balancing From: "Klaus Darilion" To: "Patrick Melampy" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 96ace3b0d55c752b49ad5cebce8c2b2a Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi! These topics are not related to congestion control, but yes, these problems are currently addressed as well in the SPEERMINT group. You can solve this by using SRV/NAPTR records to announce the ingress point and transit peerings. regards klaus On Thu, August 10, 2006 4:28, Patrick Melampy said: > Maybe its simple when its two networks to understand why dynamic protoc= ols > aren't required. Lets consider the following -- and try to imagine just > how > complicated a real life situation would be. > > 3 carriers A, B, and C each having hosted enterprise SIP domains labele= d > e1, > e2 ... en. > > Consider this topology... > > A<--------->B<------------->C > | | | > +--e1 +--e3 +--e3 > | | | > +--e2 +--e4 +--e6 > | | | > +--en +--en +--en > > In the above network, there are en sip domains hosted by carriers A, B, > and > C. Question for you...... > > 1.) How will C discover that B offers trusted SIPS proxy routing servic= es > to > domains e1, and e2 hosted by carrier A? > > 2.) How will A notify B and C that its hosting a new enterprise domain = en? > > 3.) What if e6 moves from carrier C to carrier A? > > 4.) e3 is available through both carrier B and carrier C. Which is bett= er? > > I know that if there were no transit or peering carriers, these problem= s > would be solved by ENUM and DNS and standard internet routing. But this > working group is tasked with studying the vary problems that occur when= we > add session peering to establish trusted interconnects to build large > networks that are manageable and predictable. > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, August 09, 2006 4:50 PM > To: 'Patrick Melampy'; 'Klaus Darilion' > Cc: speermint@ietf.org > 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 kno= w > 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 investigatio= n. > I'd be very interested in reports describing new mechanisms and how wel= l > 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:PMelampy@acmepacket.com] >> Sent: Wednesday, August 09, 2006 1:30 PM >> To: 'Klaus Darilion' >> Cc: 'Brian Rosen'; speermint@ietf.org >> 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 ho= w >> to >> use them. A will have many possible ways of reaching downstream domain= s. >> A >> needs to be able to efficiently route traffic. This requires informati= on >> 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, a= nd >> 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:klaus.mailinglists@pernau.at] >> Sent: Wednesday, August 09, 2006 11:48 AM >> To: Patrick Melampy >> Cc: 'Brian Rosen'; speermint@ietf.org >> 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 >> >> =3D dialog-statefull proxy >> >> > 3.) To be able to count the kilobytes of bandwidth the media is >> consuming >> >> =3D 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 sti= ll >> knows the status of the SIP nodes in the network and may distribute th= e >> 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 th= e >> > 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 sca= le >> 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:klaus.mailinglists@pernau.at] >> > Sent: Wednesday, August 09, 2006 7:59 AM >> > To: Brian Rosen >> > Cc: 'Patrick Melampy'; speermint@ietf.org >> > 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 L= B. >> > If there is a random component within the LB-logic, you need a >> > transaction statefull LB to ensure proper handling of retransmission= s. >> > But if the LB-logic is based on some part of the message (e.g. calli= d, >> > 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 transactio= n >> >> 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:PMelampy@acmepacket.com] >> >>> Sent: Saturday, August 05, 2006 4:42 PM >> >>> To: 'Brian Rosen' >> >>> Cc: speermint@ietf.org >> >>> Subject: RE: [Speermint] Congestion and Load Balancing >> >>> >> >>> Assuming that Domain B was determined to be the next domain (throu= gh >> 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. Thi= s >> 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 balanc= e >> 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 p= er >> >>> 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 cou= ld >> be >> >>> any >> >>> range of possible solutions, including a record route proxy that i= s >> >>> transaction stateful all the way through a B2BUA like the edge of = an >> IMS >> >>> network. Now B could keep track of total sessions established comi= ng >> from >> >>> A. >> >>> >> >>> Probably, A has the same issue that B has ... How many calls comin= g >> 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 se= nd >> 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 informati= on >> 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 lik= e >> 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, SI= P >> >>> 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 balance= r >> 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:br@brianrosen.net] >> >>> Sent: Friday, August 04, 2006 2:28 PM >> >>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff Devine'; 'Michael >> Hammer >> >>> (mhammer)'; 'Hadriel Kaplan' >> >>> Cc: speermint@ietf.org >> >>> 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:rpenno@juniper.net] >> >>>> Sent: Friday, August 04, 2006 2:14 PM >> >>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer >> >>> (mhammer); >> >>>> Hadriel Kaplan >> >>>> Cc: speermint@ietf.org >> >>>> 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 th= e >> 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:br@brianrosen.net] >> >>>>> Sent: Friday, August 04, 2006 10:47 AM >> >>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)= '; >> >>>>> 'Hadriel Kaplan' >> >>>>> Cc: speermint@ietf.org >> >>>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: >> Secure >> >>>> RTP >> >>>>> > 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 tha= t >> 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 commercia= l >> 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" (i= n >> an >> >>>> L3 >> >>>>> sense) the NY and Miami IXPs and PeerB happens to have facilitie= s >> 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 wen= t >> >>>> 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 d= o >> 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:PMelampy@acmepacket.com] >> >>>>>> Sent: Friday, August 04, 2006 12:39 PM >> >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; >> >>>> 'Hadriel >> >>>>>> Kaplan' >> >>>>>> Cc: speermint@ietf.org >> >>>>>> 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 (lik= e >> 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 mechanism= s >> >>>> (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 lo= ad >> >>>>>> 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 her= e? >> >>>> 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:br@brianrosen.net] >> >>>>>> Sent: Friday, August 04, 2006 12:01 PM >> >>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer >> (mhammer)'; >> >>>>>> 'Hadriel >> >>>>>> Kaplan' >> >>>>>> Cc: speermint@ietf.org >> >>>>>> 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 base= d >> >>>> 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: bus= y. >> >>>>>> >> >>>>>> More importantly, we actually can use some telephone engineerin= g >> to >> >>>>>> predict >> >>>>>> the traffic at the peering point. We can engineer systems pret= ty >> >>>>>> 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 actua= l >> >>>> 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:gdevine@cedarpointcom.com] >> >>>>>>> Sent: Friday, August 04, 2006 11:35 AM >> >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); >> >>>> Hadriel >> >>>>>> Kaplan >> >>>>>>> Cc: speermint@ietf.org >> >>>>>>> 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 dealin= g >> >>>> 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:br@brianrosen.net] >> >>>>>>> Sent: Friday, August 04, 2006 11:27 AM >> >>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)= '; >> >>>>>>> 'Hadriel Kaplan' >> >>>>>>> Cc: speermint@ietf.org >> >>>>>>> Subject: RE: [Speermint] Secure RTP >> >>>>>>> >> >>>>>>> There is no evidence that you can't do this with the mechanism= s >> we >> >>>>> have, >> >>>>>>> and >> >>>>>>> some that we can. I believe in a contractual, static, limit o= n >> >>>>> traffic >> >>>>>>> between peers. I don't think we need anything else. >> >>>>>>> >> >>>>>>> Brian >> >>>>>>> >> >>>>>>>> -----Original Message----- >> >>>>>>>> From: Geoff Devine [mailto:gdevine@cedarpointcom.com] >> >>>>>>>> Sent: Friday, August 04, 2006 11:01 AM >> >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); >> >>>> Hadriel >> >>>>>>> Kaplan >> >>>>>>>> Cc: speermint@ietf.org >> >>>>>>>> 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 f= or >> >>>> 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:br@brianrosen.net] >> >>>>>>>> Sent: Friday, August 04, 2006 10:20 AM >> >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel >> >>>> Kaplan' >> >>>>>>>> Cc: speermint@ietf.org >> >>>>>>>> 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 thos= e >> >>>>>>>> techniques to >> >>>>>>>> deal with SIP load. I certainly don't see reasons to make th= e >> >>>>>>>> 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:PMelampy@acmepacket.com] >> >>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM >> >>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel >> >>>> Kaplan' >> >>>>>>>>> Cc: speermint@ietf.org >> >>>>>>>>> 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 i= s >> >>>> used >> >>>>>>> to >> >>>>>>>> set >> >>>>>>>>> the service states on each and every DS0. SS7 is the protoco= l >> >>>>>>> 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 SS= 7. >> >>>> 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 domain= s >> >>>> 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:br@brianrosen.net] >> >>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM >> >>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' >> >>>>>>>>> Cc: speermint@ietf.org >> >>>>>>>>> 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 peer= s >> >>>>> 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 th= e >> >>>>> 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 no= t >> >>>> 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:mhammer@cisco.com] >> >>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM >> >>>>>>>>>> To: Hadriel Kaplan; Brian Rosen >> >>>>>>>>>> Cc: speermint@ietf.org >> >>>>>>>>>> Subject: RE: [Speermint] Secure RTP >> >>>>>>>>>> >> >>>>>>>>>> The focus of Speermint should be centered around whether on= e >> >>>> 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 wit= h >> >>>>> that >> >>>>>>>> peer. >> >>>>>>>>>> It is not about specifying X, Y, Z, or > >>>> 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 >> >>>>> Speermint@ietf.org >> >>>>> https://www1.ietf.org/mailman/listinfo/speermint >> >> >> >> >> >> _______________________________________________ >> >> Speermint mailing list >> >> Speermint@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/speermint >> > >> > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 10 06:02:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB7MV-00031D-Q6; Thu, 10 Aug 2006 06:01:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB7MT-000318-Oy for speermint@ietf.org; Thu, 10 Aug 2006 06:01:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB7MT-0006q7-M3 for speermint@ietf.org; Thu, 10 Aug 2006 06:01:57 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GB7MQ-0007Cx-Uf for speermint@ietf.org; Thu, 10 Aug 2006 06:01:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-architecture-00.txt Date: Thu, 10 Aug 2006 12:00:55 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C50B6@oefeg-s04.oefeg.loc> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-architecture-00.txt Thread-Index: Aca77OkrE3E4nlErTDO3r29AD2ACtwAbVDRg From: "Stastny Richard" To: X-Spam-Score: -2.6 (--) X-Scan-Signature: 225414c974e0d6437992164e91287a51 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Folks, I have some serious problems with this draft: Here only the major issues: 1. Figure 1 on page 4 Figure 1 shows the Public Internet and a Service Provider Private Network. It also shows a Layer 3 peering point (obviously a NAT/SBC), which is out of scope. The remainder of the document is basically only talking about peering via the public Internet and also on page 3 there is no Interconnection between public and private networks. So why not dump the private part completely if there is no use case describing the interworking? 1a: In figure 1 there is also a distinction between SPs and enterprises, which is not used later in the document 2. Section 3 Procedures on page 5 is listing 8 procedures which have only a slight mapping the 4 functions mentioned in section 4. 3. Section 4 Functions general IMO the scope of the functions still needs some work, as also elaborated later. Especially the LF is a bit getting ahead of itself by developing end-users IP address and port in front of PF and SF. 4. Location function 4a. Section 5.1.1 is out of scope, but may be useful for information. What is missing in section 5.1.1 is the analysis and treatment of non-E.164 numbers (emergency numbers and others) 4b Section 5.1.2 to 5.1.4 ENUM is basically out of scope in spearmint, but could be useful for information. IMO opinion the User ENUM Lookup is only optional (also on the calling user side). A SP may only query User ENUM if the end-user wants it. 5.1.3 should be called Infrastructure ENUM. What is missing here is the optional querying of private ENUM 4c. Section 5.1.5 This is where Speermint starts, either receiving a SIP URI direct or via ENUM.=20 IMO it is now to early to start talking about RFC3263, because We first need to look-up the policy for this SIP URI.=20 5. You first need to use the PF to detect if you may peer and under what conditions.=20 e.g. if you exchange the next hop attributes such as location of the proxies ... Although, I always thought this is done with the SRV records, (one also may do simple load balancing with SRV records) BTW, I am not sure what maximum allowed bandwidth has to do here IMO the prime goal of the policy function is to detect if you may send an INVITE to the target SP or not. 6. TLS In the PF only the detection of the certificate is handled, the establishment of the TLS connection belongs already to the SF These are my major issues Richard Stastny > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, August 09, 2006 9:50 PM > To: i-d-announce@ietf.org > Cc: speermint@ietf.org > Subject: [Speermint] I-D ACTION:draft-ietf-speermint-architecture-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session PEERing for Multimedia > INTerconnect Working Group of the IETF. >=20 > Title : SPEERMINT Peering Architecture > Author(s) : R. Penno > Filename : draft-ietf-speermint-architecture-00.txt > Pages : 19 > Date : 2006-8-9 >=20 > This document defines a SPEERMINT peering reference architecture, its > functional components and peering interface functions. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-speermint-architecture- > 00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-speermint-architecture-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-speermint-architecture-00.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 10 09:15:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBANT-0001q0-6L; Thu, 10 Aug 2006 09:15:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBANS-0001pv-5j for speermint@ietf.org; Thu, 10 Aug 2006 09:15:10 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBANP-00032r-Tt for speermint@ietf.org; Thu, 10 Aug 2006 09:15:10 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GBANE-0003eD-VI; Thu, 10 Aug 2006 08:14:58 -0500 From: "Brian Rosen" To: "'Patrick Melampy'" , "'Klaus Darilion'" Subject: RE: [Speermint] Congestion and Load Balancing Date: Thu, 10 Aug 2006 09:14:57 -0400 Message-ID: <0b0201c6bc7e$fce560f0$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAACxw7YAAXHDCA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <001801c6bc24$ad448030$6401a8c0@acmepacket.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 99e9171ba9600a19593168acf7232900 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org To answer the question, I have to have you answer a question. Is the "address" used to establish a session between any subscribers of A, B and C restricted, at least for now, to a telephone number? If the answer to that question is "yes", then my answer to your question is ENUM and DNS and standard internet routing, plus some static routing table for a peering federation that supports transit networks that maps carriers not in the federation to transit networks that are. You dip ENUM to determine the terminating carrier. If that carrier is in one of your federations, send the call direct. If it's not, look it up in the transit network table(s) and select from among the choice you find, or route via the PSTN. It's conceivable that you can combine these operations if you don't treat ENUM as public, and strictly a 'real' DNS query. I have no interest in making selection between multiple potential transit networks anything but an internal matter for the originating carrier. Specifically, I really think we are NOT going to try to reflect congestion into such a selection. I note that except for some strictly internal operations, this does NOT happen on the PSTN. Transit network selection is almost always based on cost of termination. If the answer is "no", then I suspect the answer is DNS and standard Internet routing and there is no carrier. I suspect the more complex (and thus expensive) we make peering, the sooner the answer will be "no". Brian > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Sent: Wednesday, August 09, 2006 10:29 PM > To: 'Brian Rosen'; 'Klaus Darilion' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing > > Maybe its simple when its two networks to understand why dynamic protocols > aren't required. Lets consider the following -- and try to imagine just > how > complicated a real life situation would be. > > 3 carriers A, B, and C each having hosted enterprise SIP domains labeled > e1, > e2 ... en. > > Consider this topology... > > A<--------->B<------------->C > | | | > +--e1 +--e3 +--e3 > | | | > +--e2 +--e4 +--e6 > | | | > +--en +--en +--en > > In the above network, there are en sip domains hosted by carriers A, B, > and > C. Question for you...... > > 1.) How will C discover that B offers trusted SIPS proxy routing services > to > domains e1, and e2 hosted by carrier A? > > 2.) How will A notify B and C that its hosting a new enterprise domain en? > > 3.) What if e6 moves from carrier C to carrier A? > > 4.) e3 is available through both carrier B and carrier C. Which is better? > > I know that if there were no transit or peering carriers, these problems > would be solved by ENUM and DNS and standard internet routing. But this > working group is tasked with studying the vary problems that occur when we > add session peering to establish trusted interconnects to build large > networks that are manageable and predictable. > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, August 09, 2006 4:50 PM > To: 'Patrick Melampy'; 'Klaus Darilion' > Cc: speermint@ietf.org > 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:PMelampy@acmepacket.com] > > Sent: Wednesday, August 09, 2006 1:30 PM > > To: 'Klaus Darilion' > > Cc: 'Brian Rosen'; speermint@ietf.org > > 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:klaus.mailinglists@pernau.at] > > Sent: Wednesday, August 09, 2006 11:48 AM > > To: Patrick Melampy > > Cc: 'Brian Rosen'; speermint@ietf.org > > 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:klaus.mailinglists@pernau.at] > > > Sent: Wednesday, August 09, 2006 7:59 AM > > > To: Brian Rosen > > > Cc: 'Patrick Melampy'; speermint@ietf.org > > > 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:PMelampy@acmepacket.com] > > >>> Sent: Saturday, August 05, 2006 4:42 PM > > >>> To: 'Brian Rosen' > > >>> Cc: speermint@ietf.org > > >>> 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:br@brianrosen.net] > > >>> Sent: Friday, August 04, 2006 2:28 PM > > >>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff Devine'; 'Michael > > Hammer > > >>> (mhammer)'; 'Hadriel Kaplan' > > >>> Cc: speermint@ietf.org > > >>> 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:rpenno@juniper.net] > > >>>> Sent: Friday, August 04, 2006 2:14 PM > > >>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer > > >>> (mhammer); > > >>>> Hadriel Kaplan > > >>>> Cc: speermint@ietf.org > > >>>> 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:br@brianrosen.net] > > >>>>> Sent: Friday, August 04, 2006 10:47 AM > > >>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; > > >>>>> 'Hadriel Kaplan' > > >>>>> Cc: speermint@ietf.org > > >>>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: > > Secure > > >>>> RTP > > >>>>> > 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:PMelampy@acmepacket.com] > > >>>>>> Sent: Friday, August 04, 2006 12:39 PM > > >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; > > >>>> 'Hadriel > > >>>>>> Kaplan' > > >>>>>> Cc: speermint@ietf.org > > >>>>>> 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:br@brianrosen.net] > > >>>>>> Sent: Friday, August 04, 2006 12:01 PM > > >>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer > (mhammer)'; > > >>>>>> 'Hadriel > > >>>>>> Kaplan' > > >>>>>> Cc: speermint@ietf.org > > >>>>>> 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:gdevine@cedarpointcom.com] > > >>>>>>> Sent: Friday, August 04, 2006 11:35 AM > > >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > > >>>> Hadriel > > >>>>>> Kaplan > > >>>>>>> Cc: speermint@ietf.org > > >>>>>>> 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:br@brianrosen.net] > > >>>>>>> Sent: Friday, August 04, 2006 11:27 AM > > >>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > >>>>>>> 'Hadriel Kaplan' > > >>>>>>> Cc: speermint@ietf.org > > >>>>>>> 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:gdevine@cedarpointcom.com] > > >>>>>>>> Sent: Friday, August 04, 2006 11:01 AM > > >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > > >>>> Hadriel > > >>>>>>> Kaplan > > >>>>>>>> Cc: speermint@ietf.org > > >>>>>>>> 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:br@brianrosen.net] > > >>>>>>>> Sent: Friday, August 04, 2006 10:20 AM > > >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel > > >>>> Kaplan' > > >>>>>>>> Cc: speermint@ietf.org > > >>>>>>>> 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:PMelampy@acmepacket.com] > > >>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM > > >>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel > > >>>> Kaplan' > > >>>>>>>>> Cc: speermint@ietf.org > > >>>>>>>>> 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:br@brianrosen.net] > > >>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM > > >>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > >>>>>>>>> Cc: speermint@ietf.org > > >>>>>>>>> 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:mhammer@cisco.com] > > >>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM > > >>>>>>>>>> To: Hadriel Kaplan; Brian Rosen > > >>>>>>>>>> Cc: speermint@ietf.org > > >>>>>>>>>> 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 > >>>> 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 > > >>>>> Speermint@ietf.org > > >>>>> https://www1.ietf.org/mailman/listinfo/speermint > > >> > > >> > > >> _______________________________________________ > > >> Speermint mailing list > > >> Speermint@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 10 13:31:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBENH-0002Dl-Be; Thu, 10 Aug 2006 13:31:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBENF-0002Dg-PU for speermint@ietf.org; Thu, 10 Aug 2006 13:31:13 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBENE-0007Ya-AU for speermint@ietf.org; Thu, 10 Aug 2006 13:31:13 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GBEN3-0008LX-Cj; Thu, 10 Aug 2006 12:31:02 -0500 From: "Brian Rosen" To: "'Khan, Sohel Q [CTO]'" , "'Daryl Malas'" Subject: RE: [Speermint] Congestion and Load Balancing Date: Thu, 10 Aug 2006 13:31:04 -0400 Message-ID: <004101c6bca2$c3de2fc0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <858217C310A3D94182FA8AAE42860A1302999F93@PLSWB08C.ad.sprint.com> Thread-Index: Aca8ASisH7mtSEP2TJKx1Y4ZhsjHQAACLyEgAAJigZAAIzMkIAAAfMCA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:Sohel.Q.Khan@sprint.com] > Sent: Thursday, August 10, 2006 1:20 PM > To: Brian Rosen; Daryl Malas > Cc: speermint@ietf.org > 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:br@brianrosen.net] > Sent: Wednesday, August 09, 2006 7:28 PM > To: 'Daryl Malas' > Cc: speermint@ietf.org > 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:daryl@level3.net] > > Sent: Wednesday, August 09, 2006 6:12 PM > > To: Brian Rosen > > Cc: 'Michael Hammer (mhammer)'; 'Patrick Melampy'; 'Klaus Darilion'; > > speermint@ietf.org > > 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:mhammer@cisco.com] > > > > Sent: Wednesday, August 09, 2006 5:09 PM > > > > To: Brian Rosen; Patrick Melampy; Klaus Darilion > > > > Cc: speermint@ietf.org > > > > 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 > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 10 13:34:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBEPw-0003lB-VZ; Thu, 10 Aug 2006 13:34:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBEPv-0003l1-PJ for speermint@ietf.org; Thu, 10 Aug 2006 13:33:59 -0400 Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound1-blu-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBEPt-0007jG-Cp for speermint@ietf.org; Thu, 10 Aug 2006 13:33:59 -0400 Received: from outbound1-blu.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-blu-R.bigfish.com (Postfix) with ESMTP id 3AEB9E69BB1; Thu, 10 Aug 2006 17:33:57 +0000 (UTC) Received: from mail12-blu-R.bigfish.com (unknown [10.1.252.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by outbound1-blu.bigfish.com (Postfix) with ESMTP id 2F85F100AB; Thu, 10 Aug 2006 17:33:57 +0000 (UTC) Received: from mail12-blu (localhost.localdomain [127.0.0.1]) by mail12-blu-R.bigfish.com (Postfix) with ESMTP id C1A704187C5; Thu, 10 Aug 2006 17:33:56 +0000 (UTC) X-BigFish: V Received: by mail12-blu (MessageSwitch) id 1155231236710182_1507; Thu, 10 Aug 2006 17:33:56 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail12-blu.bigfish.com (Postfix) with ESMTP id 59695164805C; Thu, 10 Aug 2006 17:33:56 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k7AHXfqd001752; Thu, 10 Aug 2006 12:33:41 -0500 (CDT) Received: from pdawg06a.ad.sprint.com (PDAWG06A.corp.sprint.com [10.122.2.33]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k7AHXfh19048; Thu, 10 Aug 2006 12:33:41 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by pdawg06a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 12:33:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-architecture-00.txt Date: Thu, 10 Aug 2006 12:33:35 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A1302999FFF@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-architecture-00.txt Thread-Index: Aca77OkrE3E4nlErTDO3r29AD2ACtwAbVDRgABIcqDA= From: "Khan, Sohel Q [CTO]" To: "Stastny Richard" , X-OriginalArrivalTime: 10 Aug 2006 17:33:41.0239 (UTC) FILETIME=[1EFF8070:01C6BCA3] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Thanks Richard for the input.=20 While we will consider your input prior the interim meeting, it will be nice to work this out face to face during the interim meeting.=20 IMHO we certainly need to add use case for the private network and interworking between private and public networks. -- Sohel =20 -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, August 10, 2006 5:01 AM To: speermint@ietf.org Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-architecture-00.txt=20 Folks, I have some serious problems with this draft: Here only the major issues: 1. Figure 1 on page 4 Figure 1 shows the Public Internet and a Service Provider Private Network. It also shows a Layer 3 peering point (obviously a NAT/SBC), which is out of scope. The remainder of the document is basically only talking about peering via the public Internet and also on page 3 there is no Interconnection between public and private networks. So why not dump the private part completely if there is no use case describing the interworking? 1a: In figure 1 there is also a distinction between SPs and enterprises, which is not used later in the document 2. Section 3 Procedures on page 5 is listing 8 procedures which have only a slight mapping the 4 functions mentioned in section 4. 3. Section 4 Functions general IMO the scope of the functions still needs some work, as also elaborated later. Especially the LF is a bit getting ahead of itself by developing end-users IP address and port in front of PF and SF. 4. Location function 4a. Section 5.1.1 is out of scope, but may be useful for information. What is missing in section 5.1.1 is the analysis and treatment of non-E.164 numbers (emergency numbers and others) 4b Section 5.1.2 to 5.1.4 ENUM is basically out of scope in spearmint, but could be useful for information. IMO opinion the User ENUM Lookup is only optional (also on the calling user side). A SP may only query User ENUM if the end-user wants it. 5.1.3 should be called Infrastructure ENUM. What is missing here is the optional querying of private ENUM 4c. Section 5.1.5 This is where Speermint starts, either receiving a SIP URI direct or via ENUM.=20 IMO it is now to early to start talking about RFC3263, because We first need to look-up the policy for this SIP URI.=20 5. You first need to use the PF to detect if you may peer and under what conditions.=20 e.g. if you exchange the next hop attributes such as location of the proxies ... Although, I always thought this is done with the SRV records, (one also may do simple load balancing with SRV records) BTW, I am not sure what maximum allowed bandwidth has to do here IMO the prime goal of the policy function is to detect if you may send an INVITE to the target SP or not. 6. TLS In the PF only the detection of the certificate is handled, the establishment of the TLS connection belongs already to the SF These are my major issues Richard Stastny > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, August 09, 2006 9:50 PM > To: i-d-announce@ietf.org > Cc: speermint@ietf.org > Subject: [Speermint] I-D ACTION:draft-ietf-speermint-architecture-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Session PEERing for Multimedia=20 > INTerconnect Working Group of the IETF. >=20 > Title : SPEERMINT Peering Architecture > Author(s) : R. Penno > Filename : draft-ietf-speermint-architecture-00.txt > Pages : 19 > Date : 2006-8-9 >=20 > This document defines a SPEERMINT peering reference architecture, its=20 > functional components and peering interface functions. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-speermint-architecture- > 00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then > "get draft-ietf-speermint-architecture-00.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-speermint-architecture-00.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 10 13:40:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBEWe-0000Kk-2I; Thu, 10 Aug 2006 13:40:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBEWd-0000Kf-5z for speermint@ietf.org; Thu, 10 Aug 2006 13:40:55 -0400 Received: from outbound-ash.frontbridge.com ([206.16.192.249] helo=outbound1-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBEWc-00088D-P5 for speermint@ietf.org; Thu, 10 Aug 2006 13:40:55 -0400 Received: from outbound1-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-ash-R.bigfish.com (Postfix) with ESMTP id 9F822110E6CB; Thu, 10 Aug 2006 17:40:39 +0000 (UTC) Received: from mail66-ash-R.bigfish.com (unknown [172.18.2.3]) by outbound1-ash.bigfish.com (Postfix) with ESMTP id 96C24110C213; Thu, 10 Aug 2006 17:40:39 +0000 (UTC) Received: from mail66-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail66-ash-R.bigfish.com (Postfix) with ESMTP id 8BC065A2C77; Thu, 10 Aug 2006 17:40:39 +0000 (UTC) X-BigFish: V Received: by mail66-ash (MessageSwitch) id 1155231639487829_6465; Thu, 10 Aug 2006 17:40:39 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail66-ash.bigfish.com (Postfix) with ESMTP id 628CD5A1AE4; Thu, 10 Aug 2006 17:40:39 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k7AHecl8022082; Thu, 10 Aug 2006 12:40:38 -0500 (CDT) Received: from plswg01a.ad.sprint.com (PLSWG01A.corp.sprint.com [10.214.11.47]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k7AHeTh21639; Thu, 10 Aug 2006 12:40:29 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg01a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 12:40:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Congestion and Load Balancing Date: Thu, 10 Aug 2006 12:40:24 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A130299A034@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Congestion and Load Balancing Thread-Index: Aca8ASisH7mtSEP2TJKx1Y4ZhsjHQAACLyEgAAJigZAAIzMkIAAAfMCAAABiB/A= From: "Khan, Sohel Q [CTO]" To: "Brian Rosen" , "Daryl Malas" X-OriginalArrivalTime: 10 Aug 2006 17:40:28.0855 (UTC) FILETIME=[11F4C470:01C6BCA4] X-Spam-Score: 0.1 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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 =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, August 10, 2006 12:31 PM To: Khan, Sohel Q [CTO]; 'Daryl Malas' Cc: speermint@ietf.org 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:Sohel.Q.Khan@sprint.com] > Sent: Thursday, August 10, 2006 1:20 PM > To: Brian Rosen; Daryl Malas > Cc: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing >=20 >=20 >=20 >=20 >=20 > I think in old ATM days, there were significant research and=20 > simulation studies conducted on Available Bit Rate (ABR) flow control=20 > and congestion control. I do not know whether anyone implemented it,=20 > any insight? >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, August 09, 2006 7:28 PM > To: 'Daryl Malas' > Cc: speermint@ietf.org > Subject: Re: [Speermint] Congestion and Load Balancing >=20 > I am aware of the congestion control (overload) work going on. So=20 > far, I'm suspicious of it, because I don't see any experimental or=20 > simulation studies that show the effects of trying to control congestion in SIP. > We'll see how it develops. >=20 > I'm very suspicious of what looks like very simple dynamic feedback=20 > control on the peering point. We've seen this kind of thing many=20 > times before. The Internet is very fast, and feedback loops tend to=20 > oscillate wildly really easily. You almost always need a dampener,=20 > 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=20 > 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. >=20 > Please dream up a mechanism and go try it. Let us know how it does. > There are some pretty useful simulation mechanisms for networks=20 > around, simulation results rarely match real world results, but they=20 > are informative. Better if you could try it on real networks. >=20 > But please don't just propose a dynamic feedback type "loop control" > without a good set of definitions, an understanding of what and how=20 > you are measuring, a viable control mechanism, a filter/dampener and=20 > some inkling of how well it works on real or simulated traffic. >=20 > Brian >=20 > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: Wednesday, August 09, 2006 6:12 PM > > To: Brian Rosen > > Cc: 'Michael Hammer (mhammer)'; 'Patrick Melampy'; 'Klaus Darilion'; > > speermint@ietf.org > > Subject: RE: [Speermint] Congestion and Load Balancing > > > > I apologize if I am restating or missing this, but I am going to=20 > > jump in...so a shut up and go away is acceptable. ;-) > > > > Just to throw in my two cents...I think there are two different=20 > > issues >=20 > > to solve here. First, dynamic congestion control in SIP. =20 > > Rosenberg, Hilt, and myself are working on this problem...but=20 > > definitely appreciate input. Second, policy based congestion=20 > > 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 >=20 > > of the policy function in the peering architecture. Now, how does=20 > > it dynamically update the sender...I had initially recommended a=20 > > subscribe mechanism where an expiry timer will essential force the=20 > > peer to re-subscribe to gain new policy information...this could=20 > > include updated congestion information for changing the destination=20 > > signaling function...or may say...go away...I can't handle any more=20 > > traffic. Either way, this second method is in addition to the SIP=20 > > 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=20 > > > belief in running code. > > > > > > While occasionally we actually just document something that=20 > > > exists, we usually end up extending somewhat from something we know works. > > > We have pretty bad experience inventing major new functionality=20 > > > 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=20 > > > machinery, >=20 > > > but it's built on a base of work we KNOW will work. ICE may have=20 > > > a bunch of text to tweak as we gain some implementation=20 > > > 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=20 > > > 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=20 > > > opposed to trying to say that info varies from call to call, but=20 > > > 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:mhammer@cisco.com] > > > > Sent: Wednesday, August 09, 2006 5:09 PM > > > > To: Brian Rosen; Patrick Melampy; Klaus Darilion > > > > Cc: speermint@ietf.org > > > > 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=20 > > > > peers is the only way to go. I presume that VSPs in a=20 > > > > federation may come and go, and that traffic between peers will come and go. >=20 > > > > It seems like on some time scale slower than call setup and=20 > > > > faster >=20 > > > > than a contract negotiation, there ought to be a way to adjust=20 > > > > 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=20 > > > > to tell > > a > > > > peer which has shown it is part of a federation which proxy=20 > > > > (farm) >=20 > > > > to use and what parameters to stay within. > > > > > > > > Mike > > > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 10 13:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBEon-0003SG-Nc; Thu, 10 Aug 2006 13:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBEom-0003SB-Ki for speermint@ietf.org; Thu, 10 Aug 2006 13:59:40 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBEom-00015x-35 for speermint@ietf.org; Thu, 10 Aug 2006 13:59:40 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GBEoc-00021p-Mr; Thu, 10 Aug 2006 12:59:31 -0500 From: "Brian Rosen" To: "'Khan, Sohel Q [CTO]'" , "'Daryl Malas'" Subject: RE: [Speermint] Congestion and Load Balancing Date: Thu, 10 Aug 2006 13:59:34 -0400 Message-ID: <006101c6bca6$bea7aa50$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <858217C310A3D94182FA8AAE42860A130299A034@PLSWB08C.ad.sprint.com> Thread-Index: Aca8ASisH7mtSEP2TJKx1Y4ZhsjHQAACLyEgAAJigZAAIzMkIAAAfMCAAABiB/AAAEygoA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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 > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Thursday, August 10, 2006 1:40 PM > To: Brian Rosen; Daryl Malas > Cc: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing > > 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:br@brianrosen.net] > Sent: Thursday, August 10, 2006 12:31 PM > To: Khan, Sohel Q [CTO]; 'Daryl Malas' > Cc: speermint@ietf.org > 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:Sohel.Q.Khan@sprint.com] > > Sent: Thursday, August 10, 2006 1:20 PM > > To: Brian Rosen; Daryl Malas > > Cc: speermint@ietf.org > > 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:br@brianrosen.net] > > Sent: Wednesday, August 09, 2006 7:28 PM > > To: 'Daryl Malas' > > Cc: speermint@ietf.org > > 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:daryl@level3.net] > > > Sent: Wednesday, August 09, 2006 6:12 PM > > > To: Brian Rosen > > > Cc: 'Michael Hammer (mhammer)'; 'Patrick Melampy'; 'Klaus Darilion'; > > > > speermint@ietf.org > > > 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:mhammer@cisco.com] > > > > > Sent: Wednesday, August 09, 2006 5:09 PM > > > > > To: Brian Rosen; Patrick Melampy; Klaus Darilion > > > > > Cc: speermint@ietf.org > > > > > 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 > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 10 14:52:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBFda-0001nv-B6; Thu, 10 Aug 2006 14:52:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBFdZ-0001nl-Ee for speermint@ietf.org; Thu, 10 Aug 2006 14:52:09 -0400 Received: from pmesmtp04.mci.com ([199.249.20.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBFdX-000649-Bv for speermint@ietf.org; Thu, 10 Aug 2006 14:52:09 -0400 Received: from pmismtp02.mcilink.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0J3S0061QPO509@firewall.mci.com> for speermint@ietf.org; Thu, 10 Aug 2006 18:50:29 +0000 (GMT) Received: from pmismtp02.mcilink.com ([127.0.0.1]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0J3S00MG8PO4WH@pmismtp02.mcilink.com> for speermint@ietf.org; Thu, 10 Aug 2006 18:50:29 +0000 (GMT) Received: from ASHSRV144.mcilink.com ([153.39.68.170]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0J3S00M36PO4WF@pmismtp02.mcilink.com> for speermint@ietf.org; Thu, 10 Aug 2006 18:50:28 +0000 (GMT) Received: from ASHEVS010.mcilink.com ([153.39.69.135]) by ASHSRV144.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 18:50:28 +0000 Date: Thu, 10 Aug 2006 18:50:27 +0000 From: "Dwight, Timothy M (Tim)" Subject: RE: [Speermint] Congestion and Load Balancing To: Brian Rosen , "Khan, Sohel Q [CTO]" , Daryl Malas Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: [Speermint] Congestion and Load Balancing Thread-index: Aca8ASisH7mtSEP2TJKx1Y4ZhsjHQAACLyEgAAJigZAAIzMkIAAAfMCAAABiB/AAAEygoAAB/B8L X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <006101c6bca6$bea7aa50$640fa8c0@cis.neustar.com> X-OriginalArrivalTime: 10 Aug 2006 18:50:28.0520 (UTC) FILETIME=[D926CA80:01C6BCAD] X-Spam-Score: 0.5 (/) X-Scan-Signature: 39821207e2a2cade5c69c89d23fb80ee Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1116933528==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1116933528== Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C6BCAD.D8AC52FB" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BCAD.D8AC52FB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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. =20 tim ________________________________ From: Brian Rosen [mailto:br@brianrosen.net] Sent: Thu 08/10/2006 5:59 PM To: 'Khan, Sohel Q [CTO]'; 'Daryl Malas' Cc: speermint@ietf.org Subject: RE: [Speermint] Congestion and Load Balancing 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.=20 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.=20 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 > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Thursday, August 10, 2006 1:40 PM > To: Brian Rosen; Daryl Malas > Cc: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing > > 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:br@brianrosen.net] > Sent: Thursday, August 10, 2006 12:31 PM > To: Khan, Sohel Q [CTO]; 'Daryl Malas' > Cc: speermint@ietf.org > 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:Sohel.Q.Khan@sprint.com] > > Sent: Thursday, August 10, 2006 1:20 PM > > To: Brian Rosen; Daryl Malas > > Cc: speermint@ietf.org > > 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:br@brianrosen.net] > > Sent: Wednesday, August 09, 2006 7:28 PM > > To: 'Daryl Malas' > > Cc: speermint@ietf.org > > 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:daryl@level3.net] > > > Sent: Wednesday, August 09, 2006 6:12 PM > > > To: Brian Rosen > > > Cc: 'Michael Hammer (mhammer)'; 'Patrick Melampy'; 'Klaus = Darilion'; > > > > speermint@ietf.org > > > 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:mhammer@cisco.com] > > > > > Sent: Wednesday, August 09, 2006 5:09 PM > > > > > To: Brian Rosen; Patrick Melampy; Klaus Darilion > > > > > Cc: speermint@ietf.org > > > > > 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 > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint = = > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint = = > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint = = ------_=_NextPart_001_01C6BCAD.D8AC52FB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: [Speermint] Congestion and Load Balancing=0A= =0A= =0A=
=0A=
An ABR-like = congestion =0A= control scheme, if such existed, would in thepry provide for bandwidth = sharing =0A= amongst "elastic" sessions.  That doesn't seem like the problem = we're =0A= dealing with here, though.
=0A=
 
=0A=
tim
=0A=

=0A=
=0A= From: Brian Rosen =0A= [mailto:br@brianrosen.net]
Sent: Thu 08/10/2006 5:59 = PM
To: =0A= 'Khan, Sohel Q [CTO]'; 'Daryl Malas'
Cc: =0A= speermint@ietf.org
Subject: RE: [Speermint] Congestion and = Load =0A= Balancing

=0A= =0A= =0A= =0A= ------_=_NextPart_001_01C6BCAD.D8AC52FB-- --===============1116933528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1116933528==-- From speermint-bounces@ietf.org Thu Aug 10 15:56:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBGeE-0006FG-G2; Thu, 10 Aug 2006 15:56:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBGeC-0006Em-RD for speermint@ietf.org; Thu, 10 Aug 2006 15:56:52 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBGe9-00050g-HL for speermint@ietf.org; Thu, 10 Aug 2006 15:56:52 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 607271A378; Thu, 10 Aug 2006 21:56:48 +0200 (CEST) Date: Thu, 10 Aug 2006 21:56:48 +0200 From: Otmar Lendl To: Patrick Melampy Subject: Re: [Speermint] Congestion and Load Balancing Message-ID: <20060810195648.GK19113@nic.at> Mail-Followup-To: Otmar Lendl , Patrick Melampy , 'Brian Rosen' , speermint@ietf.org References: <0a1701c6bbf5$57aa2d70$9de6a8c0@cis.neustar.com> <001801c6bc24$ad448030$6401a8c0@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001801c6bc24$ad448030$6401a8c0@acmepacket.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/08/10 04:08, Patrick Melampy wrote: > Maybe its simple when its two networks to understand why dynamic protocols > aren't required. Lets consider the following -- and try to imagine just how > complicated a real life situation would be. I like your scenario: these are exactly the question we have to answer in Speermint. > I know that if there were no transit or peering carriers, these problems > would be solved by ENUM and DNS and standard internet routing. But this > working group is tasked with studying the vary problems that occur when we > add session peering to establish trusted interconnects to build large > networks that are manageable and predictable. I don't think that ENUM will help us here. After all, it should not matter whether numbers or URIs were dialed in the first place. So we only have the SIP URIs to work with in the Speermint space. Our drafts add extensions to the SIP routing algorithm which provide solutions for the cases you describe. The -02 versions should appear on the ietf pages soon, for a preview have a look at http://www.enum.at/ietf/draft-lendl-speermint-federations-02.txt and http://www.enum.at/ietf/draft-lendl-domain-policy-ddds-02.txt. We've incorporated results from the discussions in Montreal: The non-terminal NAPTRs in the Domain Policy DDDS are now defined to do signaling referral as well as policy referral. Please have a look. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 10 16:14:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBGv2-0002yh-6a; Thu, 10 Aug 2006 16:14:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBGv0-0002yW-B3 for speermint@ietf.org; Thu, 10 Aug 2006 16:14:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBEMh-0007XV-PQ for speermint@ietf.org; Thu, 10 Aug 2006 13:30:39 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound1-cpk-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GBECG-0006Wy-2x for speermint@ietf.org; Thu, 10 Aug 2006 13:19:54 -0400 Received: from outbound1-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-cpk-R.bigfish.com (Postfix) with ESMTP id 7E23811B36BE; Thu, 10 Aug 2006 17:19:49 +0000 (UTC) Received: from mail22-cpk-R.bigfish.com (unknown [192.168.21.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound1-cpk.bigfish.com (Postfix) with ESMTP id 76A7D11B36CA; Thu, 10 Aug 2006 17:19:49 +0000 (UTC) Received: from mail22-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail22-cpk-R.bigfish.com (Postfix) with ESMTP id 654FD4D4CC3; Thu, 10 Aug 2006 17:19:49 +0000 (UTC) X-BigFish: V Received: by mail22-cpk (MessageSwitch) id 1155230389316956_28039; Thu, 10 Aug 2006 17:19:49 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail22-cpk.bigfish.com (Postfix) with ESMTP id C26404D4BFB; Thu, 10 Aug 2006 17:19:48 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k7AHJlqd000637; Thu, 10 Aug 2006 12:19:47 -0500 (CDT) Received: from plswg01a.ad.sprint.com (PLSWG01A.corp.sprint.com [10.214.11.47]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k7AHJl316850; Thu, 10 Aug 2006 12:19:47 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg01a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 12:19:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Congestion and Load Balancing Date: Thu, 10 Aug 2006 12:19:37 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A1302999F93@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Congestion and Load Balancing Thread-Index: Aca8ASisH7mtSEP2TJKx1Y4ZhsjHQAACLyEgAAJigZAAIzMkIA== From: "Khan, Sohel Q [CTO]" To: "Brian Rosen" , "Daryl Malas" X-OriginalArrivalTime: 10 Aug 2006 17:19:46.0739 (UTC) FILETIME=[2D98E830:01C6BCA1] X-Spam-Score: -2.6 (--) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 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:br@brianrosen.net]=20 Sent: Wednesday, August 09, 2006 7:28 PM To: 'Daryl Malas' Cc: speermint@ietf.org 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:daryl@level3.net] > Sent: Wednesday, August 09, 2006 6:12 PM > To: Brian Rosen > Cc: 'Michael Hammer (mhammer)'; 'Patrick Melampy'; 'Klaus Darilion';=20 > speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing >=20 > I apologize if I am restating or missing this, but I am going to jump=20 > in...so a shut up and go away is acceptable. ;-) >=20 > Just to throw in my two cents...I think there are two different issues > to solve here. First, dynamic congestion control in SIP. Rosenberg,=20 > Hilt, and myself are working on this problem...but definitely=20 > appreciate input. Second, policy based congestion control for=20 > peering. I think this second aspect is the beast we are trying to=20 > 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=20 > dynamically update the sender...I had initially recommended a=20 > subscribe mechanism where an expiry timer will essential force the=20 > peer to re-subscribe to gain new policy information...this could=20 > include updated congestion information for changing the destination=20 > signaling function...or may say...go away...I can't handle any more=20 > traffic. Either way, this second method is in addition to the SIP=20 > congestion/overload method...yet specific for the peering environment. >=20 > What do you think? >=20 > --Daryl >=20 > 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=20 > > in running code. > > > > While occasionally we actually just document something that exists,=20 > > we usually end up extending somewhat from something we know works. =20 > > We have pretty bad experience inventing major new functionality=20 > > 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=20 > > 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=20 > > bunch of text to tweak as we gain some implementation experience,=20 > > 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=20 > > proxy > domain > > names, call rates and bandwidth limits rather than provisioning. =20 > > I'm skeptical they would be used, but it's simple enough. I am=20 > > opposed to trying to say that info varies from call to call, but=20 > > 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:mhammer@cisco.com] > > > Sent: Wednesday, August 09, 2006 5:09 PM > > > To: Brian Rosen; Patrick Melampy; Klaus Darilion > > > Cc: speermint@ietf.org > > > 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=20 > > > peers is the only way to go. I presume that VSPs in a federation=20 > > > 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=20 > > > 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=20 > > > 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 > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 10 17:02:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBHfI-0004hU-0T; Thu, 10 Aug 2006 17:02:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBHfG-0004hO-SI for speermint@ietf.org; Thu, 10 Aug 2006 17:02:02 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GBHfF-00015D-CE for speermint@ietf.org; Thu, 10 Aug 2006 17:02:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Aug 2006 23:01:09 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B4E@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-lendl-speermint-federations-02.txt Thread-Index: Aca8trFtB/E7N7wXTqCRZnWlIlVCiwACH5hV References: From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: otmar.lendl@enum.at Subject: [Speermint] Re: I-D ACTION:draft-lendl-speermint-federations-02.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Nice draft =20 It would be nice to have also an example on the non-terminal NAPTRs =20 BTW, I have a bit a problem with non-terminals. Another option would be to use another policy type such as "SIP:fedtr" and a DNS URI pointing to the=20 domain name of the transit federation. =20 A minor point: In your second example with the two federations you should not use the ORDER field, the PREFERENCE is IMO better. =20 Richard ________________________________ Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Gesendet: Do 10.08.2006 21:50 An: i-d-announce@ietf.org Betreff: I-D ACTION:draft-lendl-speermint-federations-02.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : A Federation based VoIP Peering Architecture Author(s) : O. Lendl, et al. Filename : draft-lendl-speermint-federations-02.txt Pages : 12 Date : 2006-8-10 =20 This document defines the federation concept and proposes a peering and routing architecture for SIP-based applications. Federations can be used to establish selective peerings e.g. in the Voice over IP and Instant Messaging space. Service providers may announce federation membership as domain attributes. This document contains the policy- type definition for federations within the Domain Policy DDDS Application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lendl-speermint-federations-02.= txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lendl-speermint-federations-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE = /internet-drafts/draft-lendl-speermint-federations-02.txt". =20 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail = readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =20 =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 10 23:07:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBNNA-0003ov-5o; Thu, 10 Aug 2006 23:07:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBNN7-0003oq-U2 for speermint@ietf.org; Thu, 10 Aug 2006 23:07:41 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBNN5-0002yJ-Lg for speermint@ietf.org; Thu, 10 Aug 2006 23:07:41 -0400 Received: from PMelampy2 [68.189.242.21] by acmepacket.com with ESMTP (SMTPD-9.03) id A46D02C4; Thu, 10 Aug 2006 23:07:25 -0400 From: "Patrick Melampy" To: "'Klaus Darilion'" Subject: RE: [Speermint] Congestion and Load Balancing Date: Thu, 10 Aug 2006 23:07:25 -0400 Message-ID: <001501c6bcf3$45c5e5f0$6401a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca8QqsJss2CDQ39QJe4sMjRt3qIWwAsIvfA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <63976.212.17.67.197.1155189794.squirrel@pb94.dyndns.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 23776db464f2bef49f6ef0d6857b4195 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Klaus... Can you explain how ENUM and NAPTR records can answer questions 1 through 4? Please provide some details? -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Sent: Thursday, August 10, 2006 2:03 AM To: Patrick Melampy Cc: 'Brian Rosen'; speermint@ietf.org Subject: RE: [Speermint] Congestion and Load Balancing Hi! These topics are not related to congestion control, but yes, these problems are currently addressed as well in the SPEERMINT group. You can solve this by using SRV/NAPTR records to announce the ingress point and transit peerings. regards klaus On Thu, August 10, 2006 4:28, Patrick Melampy said: > Maybe its simple when its two networks to understand why dynamic protocols > aren't required. Lets consider the following -- and try to imagine just > how > complicated a real life situation would be. > > 3 carriers A, B, and C each having hosted enterprise SIP domains labeled > e1, > e2 ... en. > > Consider this topology... > > A<--------->B<------------->C > | | | > +--e1 +--e3 +--e3 > | | | > +--e2 +--e4 +--e6 > | | | > +--en +--en +--en > > In the above network, there are en sip domains hosted by carriers A, B, > and > C. Question for you...... > > 1.) How will C discover that B offers trusted SIPS proxy routing services > to > domains e1, and e2 hosted by carrier A? > > 2.) How will A notify B and C that its hosting a new enterprise domain en? > > 3.) What if e6 moves from carrier C to carrier A? > > 4.) e3 is available through both carrier B and carrier C. Which is better? > > I know that if there were no transit or peering carriers, these problems > would be solved by ENUM and DNS and standard internet routing. But this > working group is tasked with studying the vary problems that occur when we > add session peering to establish trusted interconnects to build large > networks that are manageable and predictable. > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, August 09, 2006 4:50 PM > To: 'Patrick Melampy'; 'Klaus Darilion' > Cc: speermint@ietf.org > 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:PMelampy@acmepacket.com] >> Sent: Wednesday, August 09, 2006 1:30 PM >> To: 'Klaus Darilion' >> Cc: 'Brian Rosen'; speermint@ietf.org >> 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:klaus.mailinglists@pernau.at] >> Sent: Wednesday, August 09, 2006 11:48 AM >> To: Patrick Melampy >> Cc: 'Brian Rosen'; speermint@ietf.org >> 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:klaus.mailinglists@pernau.at] >> > Sent: Wednesday, August 09, 2006 7:59 AM >> > To: Brian Rosen >> > Cc: 'Patrick Melampy'; speermint@ietf.org >> > 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:PMelampy@acmepacket.com] >> >>> Sent: Saturday, August 05, 2006 4:42 PM >> >>> To: 'Brian Rosen' >> >>> Cc: speermint@ietf.org >> >>> 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:br@brianrosen.net] >> >>> Sent: Friday, August 04, 2006 2:28 PM >> >>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff Devine'; 'Michael >> Hammer >> >>> (mhammer)'; 'Hadriel Kaplan' >> >>> Cc: speermint@ietf.org >> >>> 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:rpenno@juniper.net] >> >>>> Sent: Friday, August 04, 2006 2:14 PM >> >>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer >> >>> (mhammer); >> >>>> Hadriel Kaplan >> >>>> Cc: speermint@ietf.org >> >>>> 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:br@brianrosen.net] >> >>>>> Sent: Friday, August 04, 2006 10:47 AM >> >>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; >> >>>>> 'Hadriel Kaplan' >> >>>>> Cc: speermint@ietf.org >> >>>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: >> Secure >> >>>> RTP >> >>>>> > 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:PMelampy@acmepacket.com] >> >>>>>> Sent: Friday, August 04, 2006 12:39 PM >> >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; >> >>>> 'Hadriel >> >>>>>> Kaplan' >> >>>>>> Cc: speermint@ietf.org >> >>>>>> 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:br@brianrosen.net] >> >>>>>> Sent: Friday, August 04, 2006 12:01 PM >> >>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer >> (mhammer)'; >> >>>>>> 'Hadriel >> >>>>>> Kaplan' >> >>>>>> Cc: speermint@ietf.org >> >>>>>> 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:gdevine@cedarpointcom.com] >> >>>>>>> Sent: Friday, August 04, 2006 11:35 AM >> >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); >> >>>> Hadriel >> >>>>>> Kaplan >> >>>>>>> Cc: speermint@ietf.org >> >>>>>>> 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:br@brianrosen.net] >> >>>>>>> Sent: Friday, August 04, 2006 11:27 AM >> >>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; >> >>>>>>> 'Hadriel Kaplan' >> >>>>>>> Cc: speermint@ietf.org >> >>>>>>> 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:gdevine@cedarpointcom.com] >> >>>>>>>> Sent: Friday, August 04, 2006 11:01 AM >> >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); >> >>>> Hadriel >> >>>>>>> Kaplan >> >>>>>>>> Cc: speermint@ietf.org >> >>>>>>>> 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:br@brianrosen.net] >> >>>>>>>> Sent: Friday, August 04, 2006 10:20 AM >> >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel >> >>>> Kaplan' >> >>>>>>>> Cc: speermint@ietf.org >> >>>>>>>> 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:PMelampy@acmepacket.com] >> >>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM >> >>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel >> >>>> Kaplan' >> >>>>>>>>> Cc: speermint@ietf.org >> >>>>>>>>> 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:br@brianrosen.net] >> >>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM >> >>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' >> >>>>>>>>> Cc: speermint@ietf.org >> >>>>>>>>> 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:mhammer@cisco.com] >> >>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM >> >>>>>>>>>> To: Hadriel Kaplan; Brian Rosen >> >>>>>>>>>> Cc: speermint@ietf.org >> >>>>>>>>>> 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 > >>>> 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 >> >>>>> Speermint@ietf.org >> >>>>> https://www1.ietf.org/mailman/listinfo/speermint >> >> >> >> >> >> _______________________________________________ >> >> Speermint mailing list >> >> Speermint@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/speermint >> > >> > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 11 04:22:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBSI4-0000EY-VZ; Fri, 11 Aug 2006 04:22:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBSI2-0008M4-DF for speermint@ietf.org; Fri, 11 Aug 2006 04:22:46 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GBSHy-0000IQ-Hs for speermint@ietf.org; Fri, 11 Aug 2006 04:22:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Congestion and Load Balancing Date: Fri, 11 Aug 2006 10:21:46 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C50B8@oefeg-s04.oefeg.loc> In-Reply-To: <001501c6bcf3$45c5e5f0$6401a8c0@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Congestion and Load Balancing Thread-Index: Aca8QqsJss2CDQ39QJe4sMjRt3qIWwAsIvfAAArvAAA= From: "Stastny Richard" To: "Patrick Melampy" , "Klaus Darilion" X-Spam-Score: 0.0 (/) X-Scan-Signature: f34f1a9669a3689774341b8fed347618 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > Can you explain how ENUM and NAPTR records can answer questions 1 through > 4? First half of the answer: ENUM does NOT solve any problems related to the routing of SIP URIs Richard Stastny > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Sent: Friday, August 11, 2006 5:07 AM > To: 'Klaus Darilion' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing >=20 > Klaus... >=20 > Can you explain how ENUM and NAPTR records can answer questions 1 through > 4? > Please provide some details? >=20 > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Thursday, August 10, 2006 2:03 AM > To: Patrick Melampy > Cc: 'Brian Rosen'; speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing >=20 > Hi! >=20 > These topics are not related to congestion control, but yes, these > problems are currently addressed as well in the SPEERMINT group. You can > solve this by using SRV/NAPTR records to announce the ingress point and > transit peerings. >=20 > regards > klaus >=20 > On Thu, August 10, 2006 4:28, Patrick Melampy said: > > Maybe its simple when its two networks to understand why dynamic > protocols > > aren't required. Lets consider the following -- and try to imagine just > > how > > complicated a real life situation would be. > > > > 3 carriers A, B, and C each having hosted enterprise SIP domains labeled > > e1, > > e2 ... en. > > > > Consider this topology... > > > > A<--------->B<------------->C > > | | | > > +--e1 +--e3 +--e3 > > | | | > > +--e2 +--e4 +--e6 > > | | | > > +--en +--en +--en > > > > In the above network, there are en sip domains hosted by carriers A, B, > > and > > C. Question for you...... > > > > 1.) How will C discover that B offers trusted SIPS proxy routing > services > > to > > domains e1, and e2 hosted by carrier A? > > > > 2.) How will A notify B and C that its hosting a new enterprise domain > en? > > > > 3.) What if e6 moves from carrier C to carrier A? > > > > 4.) e3 is available through both carrier B and carrier C. Which is > better? > > > > I know that if there were no transit or peering carriers, these problems > > would be solved by ENUM and DNS and standard internet routing. But this > > working group is tasked with studying the vary problems that occur when > we > > add session peering to establish trusted interconnects to build large > > networks that are manageable and predictable. > > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, August 09, 2006 4:50 PM > > To: 'Patrick Melampy'; 'Klaus Darilion' > > Cc: speermint@ietf.org > > 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:PMelampy@acmepacket.com] > >> Sent: Wednesday, August 09, 2006 1:30 PM > >> To: 'Klaus Darilion' > >> Cc: 'Brian Rosen'; speermint@ietf.org > >> 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:klaus.mailinglists@pernau.at] > >> Sent: Wednesday, August 09, 2006 11:48 AM > >> To: Patrick Melampy > >> Cc: 'Brian Rosen'; speermint@ietf.org > >> 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 > >> > >> =3D dialog-statefull proxy > >> > >> > 3.) To be able to count the kilobytes of bandwidth the media is > >> consuming > >> > >> =3D 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:klaus.mailinglists@pernau.at] > >> > Sent: Wednesday, August 09, 2006 7:59 AM > >> > To: Brian Rosen > >> > Cc: 'Patrick Melampy'; speermint@ietf.org > >> > 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:PMelampy@acmepacket.com] > >> >>> Sent: Saturday, August 05, 2006 4:42 PM > >> >>> To: 'Brian Rosen' > >> >>> Cc: speermint@ietf.org > >> >>> 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:br@brianrosen.net] > >> >>> Sent: Friday, August 04, 2006 2:28 PM > >> >>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff Devine'; 'Michael > >> Hammer > >> >>> (mhammer)'; 'Hadriel Kaplan' > >> >>> Cc: speermint@ietf.org > >> >>> 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:rpenno@juniper.net] > >> >>>> Sent: Friday, August 04, 2006 2:14 PM > >> >>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer > >> >>> (mhammer); > >> >>>> Hadriel Kaplan > >> >>>> Cc: speermint@ietf.org > >> >>>> 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:br@brianrosen.net] > >> >>>>> Sent: Friday, August 04, 2006 10:47 AM > >> >>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer > (mhammer)'; > >> >>>>> 'Hadriel Kaplan' > >> >>>>> Cc: speermint@ietf.org > >> >>>>> Subject: RE: [Speermint] Congestion and Load Balancing was Re: > >> Secure > >> >>>> RTP > >> >>>>> >> 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:PMelampy@acmepacket.com] > >> >>>>>> Sent: Friday, August 04, 2006 12:39 PM > >> >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; > >> >>>> 'Hadriel > >> >>>>>> Kaplan' > >> >>>>>> Cc: speermint@ietf.org > >> >>>>>> 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:br@brianrosen.net] > >> >>>>>> Sent: Friday, August 04, 2006 12:01 PM > >> >>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer > >> (mhammer)'; > >> >>>>>> 'Hadriel > >> >>>>>> Kaplan' > >> >>>>>> Cc: speermint@ietf.org > >> >>>>>> 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:gdevine@cedarpointcom.com] > >> >>>>>>> Sent: Friday, August 04, 2006 11:35 AM > >> >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > >> >>>> Hadriel > >> >>>>>> Kaplan > >> >>>>>>> Cc: speermint@ietf.org > >> >>>>>>> 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:br@brianrosen.net] > >> >>>>>>> Sent: Friday, August 04, 2006 11:27 AM > >> >>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer > (mhammer)'; > >> >>>>>>> 'Hadriel Kaplan' > >> >>>>>>> Cc: speermint@ietf.org > >> >>>>>>> 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:gdevine@cedarpointcom.com] > >> >>>>>>>> Sent: Friday, August 04, 2006 11:01 AM > >> >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); > >> >>>> Hadriel > >> >>>>>>> Kaplan > >> >>>>>>>> Cc: speermint@ietf.org > >> >>>>>>>> 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:br@brianrosen.net] > >> >>>>>>>> Sent: Friday, August 04, 2006 10:20 AM > >> >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel > >> >>>> Kaplan' > >> >>>>>>>> Cc: speermint@ietf.org > >> >>>>>>>> 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:PMelampy@acmepacket.com] > >> >>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM > >> >>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel > >> >>>> Kaplan' > >> >>>>>>>>> Cc: speermint@ietf.org > >> >>>>>>>>> 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:br@brianrosen.net] > >> >>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM > >> >>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > >> >>>>>>>>> Cc: speermint@ietf.org > >> >>>>>>>>> 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:mhammer@cisco.com] > >> >>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM > >> >>>>>>>>>> To: Hadriel Kaplan; Brian Rosen > >> >>>>>>>>>> Cc: speermint@ietf.org > >> >>>>>>>>>> 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 >> >>>> 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 > >> >>>>> Speermint@ietf.org > >> >>>>> https://www1.ietf.org/mailman/listinfo/speermint > >> >> > >> >> > >> >> _______________________________________________ > >> >> Speermint mailing list > >> >> Speermint@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/speermint > >> > > >> > > > > > > > > > >=20 >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 11 06:52:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBUcf-0000tj-VO; Fri, 11 Aug 2006 06:52:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBUcf-0000te-II for speermint@ietf.org; Fri, 11 Aug 2006 06:52:13 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBUce-0007Uz-3f for speermint@ietf.org; Fri, 11 Aug 2006 06:52:13 -0400 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Fri, 11 Aug 2006 12:52:09 +0200 id 0007C09A.44DC6159.00006F3B Message-ID: <44DC611C.7050904@enum.at> Date: Fri, 11 Aug 2006 12:51:08 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: speermint , David Meyer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Subject: [Speermint] review (NITS and general comments) of draft-ietf-speermint-terminology X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi, i've done a nits review on the terminology draft (and also included some "non-NIT" comments, see below): - "technical" nits: none (the draft passes the idnits checker without any warnings) - acronyms: There are a bunch of acronyms that are not expanded on their first use: ENUM, VoIP, SIP, NAPTR, URI, SRV, SMTP, MX, L5. In contrary, "DNS" does not need to be expanded, it's on the RFC Editor's "well known" list. - References: I'm missing them for a bunch of the mentioned protocols (most notable "SIP"). The E.164 reference is outdated as Klaus Nieminen recently pointed out on the ENUM mailing list (there is a 2005 revision). - I'd put "(SPEERMINT)" after "Session peering for multi.." in the Introduction, line 7 - just to make the connection (i didn't see it anywhere else in the draft) - simple one: Figure 1 includes two double lines, so the "i.e. above the double line in.." should be corrected to eg. "... above both double lines .." [I'm proably nit-picking a bit over the next sections, but for terminology every word is important, by definition, so... ] - Section 3.1: This not only defines the CRD, but also the terminus "ingress point". If we need the term "ingress point", we should prabably define it seperately - there is already use for it in section 3.2. I'm unsure whether we need to differentiate between "destination" and "ingress point" (a "destination netfork" is for sure something different than the ingress point) Additionally, the definition of "ingress" point specifically mentions SRV record type routing, which could lead to the impression that RFC3263-style (or federation-rule) routing destinations are _not_ ingress points... also note that a CRD which already contains is port number would skip SRV lookup - so the SRV stuff is imho too specific for the definition. - Seciton 3.2: This section leaves open whether the "destination" is _always_ a "ingress point" - if yes, wording should be unified. - Section 3.3: The definition would exclude packet-switched "PSTN-style" networks, like eg. NGN/UMTS/IMS release5 (?) stuff. However, i don't see any better method than using the "circuit switched" parameter for the definition.. - Section 3.4: "Overlaying" the term "Network" could be confusing, because that would mean everytime we talk about any other network (eg. ethernet) in the context of SPEERMINT we'd need to specifically say that it's eg. an "Ethernet Network". What about changing that to "Peer Network" or something, so that we don't "cast" the generic work "Network"? We'd probably end up with the need to say "a RFCXXX, 3.4 network" each time we mention the structure defined here. Additionally, we're already using the term "peer network" in the draft itself (4.1, eg.) - Section 4.1/4.2: Is "peering" taking place between "Networks" or "Service Providers"? I don't think that "Service providers" can be "interconnected", only their networks can. - Section 4.3/4.4: The term "domain" is not defined in the document. That makes the definition a bit unsharp. should those be "networks" or "service providers" instead? - Section 5.1: The term "service provider" ins this section (taken from the infrastructure enum requirements draft) clashes with the "service provider" of the speermint terminology draft itself). Maybe we should use something different here (draft-ietf-enum-validation-arch uses "communication service provider" for that - another option would be to simply use "entity" here?) - Section 5.2 (small): There seems to be "over" missing at the end of line 4 in the first paragraph. - Section 5.3: The first sentence looks incomplete to me: " ... the use of a seperate branch the e164.arpa tree ...". The second sentence is a bit unsharp, imho. Is it exchanging "phone numbers to Call Routing data" in order to find "Ingress Points" or "Peer Networks"? - Section 6: There are a few acronyms / unreferenced stuff: X.509, GRX, CA that's all - Alex _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 11 09:09:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBWlm-0002Bl-FI; Fri, 11 Aug 2006 09:09:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBWll-00028l-0y for speermint@ietf.org; Fri, 11 Aug 2006 09:09:45 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBR1G-0001pd-5V for speermint@ietf.org; Fri, 11 Aug 2006 03:01:22 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GBQKv-00081b-0c for speermint@ietf.org; Fri, 11 Aug 2006 02:17:38 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 9F1082100E1; Fri, 11 Aug 2006 08:17:31 +0200 (CEST) Message-ID: <44DC210B.5010806@pernau.at> Date: Fri, 11 Aug 2006 08:17:47 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Patrick Melampy Subject: Re: [Speermint] Congestion and Load Balancing References: <001501c6bcf3$45c5e5f0$6401a8c0@acmepacket.com> In-Reply-To: <001501c6bcf3$45c5e5f0$6401a8c0@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Patrick Melampy wrote: > Klaus... > > Can you explain how ENUM and NAPTR records can answer questions 1 through 4? > Please provide some details? Hi Patrick The details are in the drafts referred by Otmar. Non-terminal NAPTRs in the domainpolicy DNS records can be used to announce transit peers or to redirect all calls to the SIP provider hosting this domain. regards klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 11 10:03:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBXbX-0007lN-RQ; Fri, 11 Aug 2006 10:03:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBXbW-0007lF-Nf for speermint@ietf.org; Fri, 11 Aug 2006 10:03:14 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBXbV-0003D4-9M for speermint@ietf.org; Fri, 11 Aug 2006 10:03:14 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k7BE37GE007520; Fri, 11 Aug 2006 07:03:07 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k7BE30gL007519; Fri, 11 Aug 2006 07:03:00 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 11 Aug 2006 07:03:00 -0700 From: David Meyer To: Alexander Mayrhofer Message-ID: <20060811140300.GA7509@1-4-5.net> References: <44DC611C.7050904@enum.at> Mime-Version: 1.0 In-Reply-To: <44DC611C.7050904@enum.at> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 1.1 (+) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: speermint Subject: [Speermint] Re: review (NITS and general comments) of draft-ietf-speermint-terminology X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1428894784==" Errors-To: speermint-bounces@ietf.org --===============1428894784== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alex,=20 Thanks for the detailed comments. I'll update accordingly and build a -03. Thnx, --dmm On Fri, Aug 11, 2006 at 12:51:08PM +0200, Alexander Mayrhofer wrote: > Hi, >=20 > i've done a nits review on the terminology draft (and also included some > "non-NIT" comments, see below): >=20 > - "technical" nits: none (the draft passes the idnits checker without any > warnings) >=20 > - acronyms: There are a bunch of acronyms that are not expanded on their > first use: ENUM, VoIP, SIP, NAPTR, URI, SRV, SMTP, MX, L5. In > contrary, "DNS" does not need to be expanded, it's on the RFC Editor's "w= ell > known" list. >=20 > - References: I'm missing them for a bunch of the mentioned protocols (mo= st > notable "SIP"). The E.164 reference is outdated as Klaus Nieminen recently > pointed out on the ENUM mailing list (there is a 2005 revision). >=20 > - I'd put "(SPEERMINT)" after "Session peering for multi.." in the > Introduction, line 7 - just to make the connection (i didn't see it anywh= ere > else in the draft) >=20 > - simple one: Figure 1 includes two double lines, so the "i.e. above the > double line in.." should be corrected to eg. "... above both double lines= .." >=20 > [I'm proably nit-picking a bit over the next sections, but for terminology > every word is important, by definition, so... ] >=20 > - Section 3.1: This not only defines the CRD, but also the terminus "ingr= ess > point". If we need the term "ingress point", we should prabably define it > seperately - there is already use for it in section 3.2. I'm unsure wheth= er > we need to differentiate between "destination" and "ingress point" (a > "destination netfork" is for sure something different than the ingress po= int) >=20 > Additionally, the definition of "ingress" point specifically mentions SRV > record type routing, which could lead to the impression that RFC3263-style > (or federation-rule) routing destinations are _not_ ingress points... also > note that a CRD which already contains is port number would skip SRV look= up > - so the SRV stuff is imho too specific for the definition. >=20 > - Seciton 3.2: This section leaves open whether the "destination" is > _always_ a "ingress point" - if yes, wording should be unified. >=20 >=20 > - Section 3.3: The definition would exclude packet-switched "PSTN-style" > networks, like eg. NGN/UMTS/IMS release5 (?) stuff. However, i don't see = any > better method than using the "circuit switched" parameter for the definit= ion.. >=20 > - Section 3.4: "Overlaying" the term "Network" could be confusing, because > that would mean everytime we talk about any other network (eg. ethernet) = in > the context of SPEERMINT we'd need to specifically say that it's eg. an > "Ethernet Network". What about changing that to "Peer Network" or somethi= ng, > so that we don't "cast" the generic work "Network"? We'd probably end up > with the need to say "a RFCXXX, 3.4 network" each time we mention the > structure defined here. >=20 > Additionally, we're already using the term "peer network" in the draft > itself (4.1, eg.) >=20 > - Section 4.1/4.2: Is "peering" taking place between "Networks" or "Servi= ce > Providers"? I don't think that "Service providers" can be "interconnected= ", > only their networks can. >=20 > - Section 4.3/4.4: The term "domain" is not defined in the document. That > makes the definition a bit unsharp. should those be "networks" or "service > providers" instead? >=20 > - Section 5.1: The term "service provider" ins this section (taken from t= he > infrastructure enum requirements draft) clashes with the "service provide= r" > of the speermint terminology draft itself). Maybe we should use something > different here (draft-ietf-enum-validation-arch uses "communication servi= ce > provider" for that - another option would be to simply use "entity" here?) >=20 > - Section 5.2 (small): There seems to be "over" missing at the end of lin= e 4 > in the first paragraph. >=20 > - Section 5.3: The first sentence looks incomplete to me: " ... the use o= f a > seperate branch the e164.arpa tree ...". The second sentence is a bit > unsharp, imho. Is it exchanging "phone numbers to Call Routing data" in > order to find "Ingress Points" or "Peer Networks"? >=20 > - Section 6: There are a few acronyms / unreferenced stuff: X.509, GRX, CA >=20 > that's all - >=20 > Alex --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFE3I4UORgD1qCZ2KcRAkkFAKCMWTfldUKyMXbsGKutJlFCXAmXqwCeLB5x qKYVi5U3a8IW46F0RIOLDR4= =Gk2T -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- --===============1428894784== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1428894784==-- From speermint-bounces@ietf.org Fri Aug 11 14:04:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbMu-0008Vt-IQ; Fri, 11 Aug 2006 14:04:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbMt-0008P8-5T for speermint@ietf.org; Fri, 11 Aug 2006 14:04:23 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBbMq-0001cs-Pl for speermint@ietf.org; Fri, 11 Aug 2006 14:04:23 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k7BI4GIe012602; Fri, 11 Aug 2006 11:04:16 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k7BI4BXI012600; Fri, 11 Aug 2006 11:04:11 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 11 Aug 2006 11:04:11 -0700 From: David Meyer To: Alexander Mayrhofer Message-ID: <20060811180411.GA12579@1-4-5.net> References: <44DC611C.7050904@enum.at> Mime-Version: 1.0 In-Reply-To: <44DC611C.7050904@enum.at> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 1.1 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: speermint Subject: [Speermint] Re: review (NITS and general comments) of draft-ietf-speermint-terminology X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0011727490==" Errors-To: speermint-bounces@ietf.org --===============0011727490== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've updated with your comments (and a few others). -03 is on =20 http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-03.txt --dmm --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFE3MabORgD1qCZ2KcRAhrPAJ98TlhiaFZsQMJcMOcx8xDTQU6AkgCeI82i c9UlEMnOM5v+1kAAt4jebZk= =VFiQ -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- --===============0011727490== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0011727490==-- From speermint-bounces@ietf.org Fri Aug 11 17:50:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBetA-0004Pq-3C; Fri, 11 Aug 2006 17:49:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBet8-0004JH-KF for speermint@ietf.org; Fri, 11 Aug 2006 17:49:54 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBet7-0002aq-UI for speermint@ietf.org; Fri, 11 Aug 2006 17:49:54 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id B58731A379; Fri, 11 Aug 2006 23:49:51 +0200 (CEST) Date: Fri, 11 Aug 2006 23:49:51 +0200 From: Otmar Lendl To: David Meyer Message-ID: <20060811214951.GM19113@nic.at> Mail-Followup-To: Otmar Lendl , David Meyer , speermint Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 1.1 (+) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: speermint Subject: [Speermint] More comments on draft-ietf-speermint-terminology X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/08/11 20:08, David Meyer wrote: > > I've updated with your comments (and a few others). -03 Meanwhile, I've had a closer look at -02, here are my comments: ------------------ > >3. General Definitions > >3.1. Call Routing Data > > Call Routing Data, or CRD, is a SIP URI used to route a call (real- > time, voice or other type) to the called domain's ingress point. A > domain's ingress point can be thought of as the location pointed to > by the SRV record that resulted from the resolution of the CRD (i.e., > a SIP URI). I don't consider this definition to be intuitive. I'd prefer to use Call Routing Data to be the output of the Speermint Routing algorithm. In my mind, that should be * Destination SIP URI (most likely to be identical to the input) * SIP proxy to send the INVITE to - FQDN - Port - Transport Protocol (udp/tcp/tls) * Security Parameters - TLS cert to use - TLS cert to expect - TLS cert verification setting * Congestion Control parameters - Static settings - Which dynamic protocol to use Eventually, the CRD could even be a priorized list of such parameters which defines a number of alternative routes. As I see it, the CRD is the set of parameters the outgoing border elements needs to complete the call. I'd use "Call Addressing Data" for your definition of CRD. >3.2. Call Routing > > Call routing is the set of processes, rules, and CRD used to route a > call to its proper (SIP) destination. More generally, call routing > can be thought of as the set of processes, rules and CRD which are > used to route a real-time session to its termination (ingress) point. I see the CRD as the output of the call routing process. >3.4. Network > > For purposes of this document and the SPEERMINT and ENUM Working > Groups, a network is defined to be the set of SIP servers and end- > users (customers) that are controlled by a single administrative > domain and can be reached via layer 3 (IP) peering. The network may > also contain end-users who are located on the PSTN, as long as they > are also reachable via layer 3 (IP) peering. I don't understand this definition. SIP servers are layer 5 devices, but the rest of this definition talks about layer 3 issues. This definition certainly applies to an integrated Layer3 + Layer5 provider (e.g. a cable isp which supplies VoIP services to its customers), but I have troubles understanding if this definition applies to the Vonage case where the SIP layer is independent of the IP layer. If this definitions is supposed to differentiate between these who cases I suggest we use a clearer term like "integrated L3/L5 network" or "vertical silo network". >3.5. Service Provider (SP) > > A Service Provider (or SP) is defined to be an entity that controls a > "network" as defined in Section 3.4, and provides transport of SIP > signaling and media packets. If the intention here is use SP for providers of both L3 and L5 services, then I suggest we use something like an "Integrated SP" for this special case. >3.6. Voice Service Provider (VSP) > > A Voice Service Provider (or VSP) is an entity that provides > transport of SIP signaling (and possibly media streams) to its > customers. Such a service provider may additionally be > interconnected with other service providers; that is, it may "peer" > with other service providers. A VSP may also interconnect with the > PSTN. > > Note that as soon as a ingress point is advertised via a SRV record, > anyone can find that ingress point and hence can send calls there. > This is very similar to sending mail to a SMTP server based on the > existence of a MX record. > > Finally, note the concept of a VSP is a subset of the possible SP > types. That is, a VSP is an SP, but it is not necessary that an SP > be a VSP. I think we're mixing a few issues here in our taxonomy of service providers. Let's take a step back and look at the properties we can use to classify service providers: * Which service is provided? Layer 3 or Layer 5? * L3 / L5 integration See the comment on "network" above. * Callable by RFC 3261/3263 procedures on the public Internet The existence of SRV records does IMHO not imply that the SIP server to which these records point to will accept any call from the Internet. (the latter two are orthogonal properties) As the term Service Provider (SP) doesn't indicate whether we're talking about Layer3 or Layer5 services, I propose that we use ISP: the SP which provides Layer 3 services (IP connectivity) VSP: the SP which provides Layer 5 services (SIP service) That leaves us to define terms to distinguish between L3/L5 integrated SP vs. L5 only VSPs and open vs. closed ones. What about "IVSP" for L3/L5 Integrated VoIP Service Provider? We could then call VSPs which are not IVSPs (the vonage model) "nIVSP" for non-integrated VSP. Regarding reachability via the Internet, I propose to use "open VSPs" versus "closed VSPs". >4.3. Direct Peering > > Direct peering describes those cases in which two domains > interconnect without using an intervening layer 5 network. Both > domains must have a trust relationship established (for example, they > may know they belong to the same federation; see Section 6 below) > before opening up a secure layer 5 communication path. > >4.4. Indirect (Transit) Peering > > Indirect (transit) peering refers to the establishment of a secure > signaling path via one (or more) referral or transit network(s). In > this case it is required that a trust relationship is established > between the originating domain and the transit network on one side, > and the transit network and the termination network on the other > side. Both trust relationships must exist before opening up a secure > communication path on L5. There may be a third way of peering, let's call it "Assisted Peering". That would be the XConnect model where a federation employs a central SIP proxy (which is in itself not a VSP) to bridge calls between participating networks. That's a bit like the BGP route-reflectors employed at various L3 Internet Exchanges, which are present in the L3 routing protocol, but not in the actual L3 packet routing. Regarding trust: I wouldn't say that trust "must exist before opening up a secure communication path" as trust could be established during this opening phase, e.g. through the use of TLS certs. >5. ENUM >5.2. User ENUM We might add here that User ENUM implies that the URIs published therein refer to open VSPs. >5.3. Infrastructure ENUM > > In infrastructure ENUM, only the COR may enter data in the > corresponding domain. The COR may also enter CRD (i.e., a SIP URI) > to allow other SPs to to route sessions to its network. I'd note here that this SIP URI does not need to be hosted at an open VSP. >6. Federations > > The domain policy DDDS application [I-D.lendl-domain-policy-ddds] > defines a method with which a domain owner can announce the policy it > will use to accept incoming calls. This section introduces a policy > type for use with that framework, known as federations > [I-D.lendl-speermint-federations]. > > Note that [I-D.lendl-domain-policy-ddds] does not define what these That should be [I-D.lendl-speermint-federations] > rules can be or how they might be communicated to the members of a > federation. Further, there is no requirement that such rules are in > any way public. > >6.1. Federation Functionality > > A federation may provide some or all of the following functionality: > > * Common policies > > + Policy might be ah-hoc, and published in the DNS (e.g., > [I-D.lendl-domain-policy-ddds], or I'll submit another I-D soon which will discuss this in more detail than the examples section of the DP-DDDS draft. > + Policy might also be managed by a federation entity In which case the DNS just refers to a named policy. > * A federated ENUM root > > * Address resolution mechanisms > > * Session signaling (via federation policy) > > * Media streams (via federation policy) > > * Federation security policies > > * Interconnection policies > > * Other layer 2 and layer 3 policies > > Finally, note that a SP can be a member of > > * No federation (e.g., the SP has only bilateral peering > agreements) > > * A single federation > > * Multiple federations > > and an SP can have any combination of bi-lateral and multi-lateral > (i.e., federated) interconnections. One could argue that bi-lateral peerings are just special cases of federations (i.e. a federation with two members). >6.2. Announcement of Federation Membership > > Announcement of federation membership is typically made by the > terminating SP, using one or more of the following mechanisms: > > * I-ENUM What do you have in mind here? Richard Stastny's Enum resolution Context draft? > * A Private ENUM Federation discovery mechanism > > * DNS > >6.3. Example Federation Rules > > Example federation rules might include the following: > > o A set of SPs form an association and agree to accept calls from > each other via the public Internet as long as the SIP call uses > TCP/TLS as transport protocol and presents a X.509 cert which was > signed by the association's own CA. > > o A set of SPs build a L3 network dedicated to VoIP peering (e.g., > the 3GPP GRX). The further agree to accept calls from all > participants in that network and bill each other via a > clearinghouse. > > o A set of SPs agree to accept calls originating from within the > same country. They use a set of firewall rules to block calls > from abroad. This example seems to have confused many people. I've replaced it in my latest draft by o A group of VoIP service providers agree to accept calls originating from each other. They use firewall rules to block calls from all other networks. -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 14 10:14:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCdCZ-00006a-8n; Mon, 14 Aug 2006 10:13:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCdCX-00006U-JI for speermint@ietf.org; Mon, 14 Aug 2006 10:13:57 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCdCW-0007Xy-SF for speermint@ietf.org; Mon, 14 Aug 2006 10:13:57 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k7EEDs4v008897; Mon, 14 Aug 2006 07:13:54 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k7EEDrTK008896; Mon, 14 Aug 2006 07:13:53 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 14 Aug 2006 07:13:53 -0700 From: David Meyer To: Otmar Lendl , speermint Message-ID: <20060814141353.GA8872@1-4-5.net> References: <20060811214951.GM19113@nic.at> Mime-Version: 1.0 In-Reply-To: <20060811214951.GM19113@nic.at> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 1.1 (+) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Cc: Subject: [Speermint] Re: More comments on draft-ietf-speermint-terminology X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1504670931==" Errors-To: speermint-bounces@ietf.org --===============1504670931== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thanks, will update accordingly. --dmm On Fri, Aug 11, 2006 at 11:49:51PM +0200, Otmar Lendl wrote: > On 2006/08/11 20:08, David Meyer wrote: > >=20 > > I've updated with your comments (and a few others). -03 >=20 > Meanwhile, I've had a closer look at -02, here are my comments: >=20 > ------------------ > > > >3. General Definitions > > > >3.1. Call Routing Data > > > > Call Routing Data, or CRD, is a SIP URI used to route a call (real- > > time, voice or other type) to the called domain's ingress point. A > > domain's ingress point can be thought of as the location pointed to > > by the SRV record that resulted from the resolution of the CRD (i.e., > > a SIP URI). >=20 > I don't consider this definition to be intuitive. I'd prefer to use > Call Routing Data to be the output of the Speermint Routing algorithm. > In my mind, that should be >=20 > * Destination SIP URI (most likely to be identical to the input) > * SIP proxy to send the INVITE to > - FQDN > - Port > - Transport Protocol (udp/tcp/tls) > * Security Parameters > - TLS cert to use > - TLS cert to expect > - TLS cert verification setting > * Congestion Control parameters > - Static settings > - Which dynamic protocol to use >=20 > Eventually, the CRD could even be a priorized list of such parameters whi= ch > defines a number of alternative routes. >=20 > As I see it, the CRD is the set of parameters the outgoing border > elements needs to complete the call. >=20 > I'd use "Call Addressing Data" for your definition of CRD. >=20 > >3.2. Call Routing > > > > Call routing is the set of processes, rules, and CRD used to route a > > call to its proper (SIP) destination. More generally, call routing > > can be thought of as the set of processes, rules and CRD which are > > used to route a real-time session to its termination (ingress) point. >=20 > I see the CRD as the output of the call routing process. >=20 > >3.4. Network > > > > For purposes of this document and the SPEERMINT and ENUM Working > > Groups, a network is defined to be the set of SIP servers and end- > > users (customers) that are controlled by a single administrative > > domain and can be reached via layer 3 (IP) peering. The network may > > also contain end-users who are located on the PSTN, as long as they > > are also reachable via layer 3 (IP) peering. >=20 > I don't understand this definition. SIP servers are layer 5 devices, > but the rest of this definition talks about layer 3 issues. >=20 > This definition certainly applies to an integrated Layer3 + Layer5 provid= er > (e.g. a cable isp which supplies VoIP services to its customers), but > I have troubles understanding if this definition applies to the=20 > Vonage case where the SIP layer is independent of the IP layer. >=20 > If this definitions is supposed to differentiate between these who cases= =20 > I suggest we use a clearer term like "integrated L3/L5 network" or > "vertical silo network". >=20 > >3.5. Service Provider (SP) > > > > A Service Provider (or SP) is defined to be an entity that controls a > > "network" as defined in Section 3.4, and provides transport of SIP > > signaling and media packets. >=20 > If the intention here is use SP for providers of both L3 and L5 services, > then I suggest we use something like an "Integrated SP" for this > special case. >=20 > >3.6. Voice Service Provider (VSP) > > > > A Voice Service Provider (or VSP) is an entity that provides > > transport of SIP signaling (and possibly media streams) to its > > customers. Such a service provider may additionally be > > interconnected with other service providers; that is, it may "peer" > > with other service providers. A VSP may also interconnect with the > > PSTN. > > > > Note that as soon as a ingress point is advertised via a SRV record, > > anyone can find that ingress point and hence can send calls there. > > This is very similar to sending mail to a SMTP server based on the > > existence of a MX record. > > > > Finally, note the concept of a VSP is a subset of the possible SP > > types. That is, a VSP is an SP, but it is not necessary that an SP > > be a VSP. >=20 > I think we're mixing a few issues here in our taxonomy of service > providers. Let's take a step back and look at the properties we can > use to classify service providers: >=20 > * Which service is provided? Layer 3 or Layer 5? >=20 > * L3 / L5 integration >=20 > See the comment on "network" above. >=20 > * Callable by RFC 3261/3263 procedures on the public Internet >=20 > The existence of SRV records does IMHO not imply that the > SIP server to which these records point to will accept any > call from the Internet.=09 >=20 > (the latter two are orthogonal properties) >=20 > As the term Service Provider (SP) doesn't indicate whether we're > talking about Layer3 or Layer5 services, I propose that we use >=20 > ISP: the SP which provides Layer 3 services (IP connectivity) > VSP: the SP which provides Layer 5 services (SIP service) >=20 > That leaves us to define terms to distinguish between L3/L5 integrated > SP vs. L5 only VSPs and open vs. closed ones. >=20 > What about "IVSP" for L3/L5 Integrated VoIP Service Provider? > We could then call VSPs which are not IVSPs (the vonage model) "nIVSP" > for non-integrated VSP. >=20 > Regarding reachability via the Internet, I propose to use=20 > "open VSPs" versus "closed VSPs". >=20 > >4.3. Direct Peering > > > > Direct peering describes those cases in which two domains > > interconnect without using an intervening layer 5 network. Both > > domains must have a trust relationship established (for example, they > > may know they belong to the same federation; see Section 6 below) > > before opening up a secure layer 5 communication path. > > > >4.4. Indirect (Transit) Peering > > > > Indirect (transit) peering refers to the establishment of a secure > > signaling path via one (or more) referral or transit network(s). In > > this case it is required that a trust relationship is established > > between the originating domain and the transit network on one side, > > and the transit network and the termination network on the other > > side. Both trust relationships must exist before opening up a secure > > communication path on L5. >=20 > There may be a third way of peering, let's call it "Assisted Peering". > That would be the XConnect model where a federation employs a > central SIP proxy (which is in itself not a VSP) to bridge calls > between participating networks. That's a bit like the BGP route-reflectors > employed at various L3 Internet Exchanges, which are present in > the L3 routing protocol, but not in the actual L3 packet routing. >=20 > Regarding trust: I wouldn't say that trust "must exist before opening > up a secure communication path" as trust could be established during > this opening phase, e.g. through the use of TLS certs. >=20 > >5. ENUM > >5.2. User ENUM >=20 > We might add here that User ENUM implies that the URIs published > therein refer to open VSPs. >=20 > >5.3. Infrastructure ENUM > > > > In infrastructure ENUM, only the COR may enter data in the > > corresponding domain. The COR may also enter CRD (i.e., a SIP URI) > > to allow other SPs to to route sessions to its network. >=20 > I'd note here that this SIP URI does not need to be hosted at an open VSP. >=20 > >6. Federations > > > > The domain policy DDDS application [I-D.lendl-domain-policy-ddds] > > defines a method with which a domain owner can announce the policy it > > will use to accept incoming calls. This section introduces a policy > > type for use with that framework, known as federations > > [I-D.lendl-speermint-federations]. > > > > Note that [I-D.lendl-domain-policy-ddds] does not define what these >=20 > That should be [I-D.lendl-speermint-federations] > =20 > > rules can be or how they might be communicated to the members of a > > federation. Further, there is no requirement that such rules are in > > any way public. > > > >6.1. Federation Functionality > > > > A federation may provide some or all of the following functionality: > > > > * Common policies > > > > + Policy might be ah-hoc, and published in the DNS (e.g., > > [I-D.lendl-domain-policy-ddds], or >=20 > I'll submit another I-D soon which will discuss this in more detail > than the examples section of the DP-DDDS draft.=20 >=20 > > + Policy might also be managed by a federation entity >=20 > In which case the DNS just refers to a named policy. >=20 > > * A federated ENUM root > > > > * Address resolution mechanisms > > > > * Session signaling (via federation policy) > > > > * Media streams (via federation policy) > > > > * Federation security policies > > > > * Interconnection policies > > > > * Other layer 2 and layer 3 policies > > > > Finally, note that a SP can be a member of > > > > * No federation (e.g., the SP has only bilateral peering > > agreements) > > > > * A single federation > > > > * Multiple federations > > > > and an SP can have any combination of bi-lateral and multi-lateral > > (i.e., federated) interconnections. >=20 > One could argue that bi-lateral peerings are just special cases of > federations (i.e. a federation with two members). >=20 > >6.2. Announcement of Federation Membership > > > > Announcement of federation membership is typically made by the > > terminating SP, using one or more of the following mechanisms: > > > > * I-ENUM >=20 > What do you have in mind here? Richard Stastny's Enum resolution Context > draft? >=20 > > * A Private ENUM Federation discovery mechanism > > > > * DNS > > > >6.3. Example Federation Rules > > > > Example federation rules might include the following: > > > > o A set of SPs form an association and agree to accept calls from > > each other via the public Internet as long as the SIP call uses > > TCP/TLS as transport protocol and presents a X.509 cert which was > > signed by the association's own CA. > > > > o A set of SPs build a L3 network dedicated to VoIP peering (e.g., > > the 3GPP GRX). The further agree to accept calls from all > > participants in that network and bill each other via a > > clearinghouse. > > > > o A set of SPs agree to accept calls originating from within the > > same country. They use a set of firewall rules to block calls > > from abroad. >=20 > This example seems to have confused many people. I've replaced it in > my latest draft by >=20 > o A group of VoIP service providers agree to accept calls > originating from each other. They use firewall rules to > block calls from all other networks. >=20 > --=20 > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFE4IUhORgD1qCZ2KcRAnyuAJ0cw2jy9BJ77hfp+FwzdptW1z3CtwCfeD/L 9+TB0iqf69vtbOmD2qKmPfE= =AWWZ -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- --===============1504670931== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1504670931==-- From speermint-bounces@ietf.org Mon Aug 14 15:50:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCiRu-0001Wh-AJ; Mon, 14 Aug 2006 15:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCiRm-0001VV-TQ; Mon, 14 Aug 2006 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCiRm-0000B6-Hz; Mon, 14 Aug 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7CAB932872; Mon, 14 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GCiRm-0006RD-BR; Mon, 14 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 14 Aug 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-03.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Terminology Author(s) : D. Meyer Filename : draft-ietf-speermint-terminology-03.txt Pages : 13 Date : 2006-8-14 This document defines the terminology that is to be used by the Session PEERing for Multimedia INTerconnect Working Group (SPEERMINT). It has as its primary objective to focus the working group during its discussions, and when writing requirements, gap analysis and other solutions oriented documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-terminology-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-terminology-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-14115958.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-terminology-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-terminology-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-14115958.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Mon Aug 14 16:09:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCiki-0003p9-Ck; Mon, 14 Aug 2006 16:09:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCikh-0003ol-RU for speermint@ietf.org; Mon, 14 Aug 2006 16:09:35 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCikg-0001UH-HW for speermint@ietf.org; Mon, 14 Aug 2006 16:09:35 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GCikW-0000Lh-5T; Mon, 14 Aug 2006 15:09:24 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Patrick Melampy'" , "'Klaus Darilion'" Subject: Re: [Speermint] Congestion and Load Balancing Date: Mon, 14 Aug 2006 16:09:28 -0400 Message-ID: <065501c6bfdd$8dba43f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAAGD/IAABsKNQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I agree that people confuse media congestion issues and signaling congestion issues and really need to keep them straight. I can't see how PSTN call gapping can be applied usefully, especially in any non-trivial way, to SIP signaling. Perhaps there is something fundamental that I'm missing, but none of the techniques I know can usefully be applied. Perhaps you could share some thoughts there. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, August 14, 2006 3:14 PM > To: Brian Rosen; Patrick Melampy; Klaus Darilion > Cc: speermint@ietf.org > 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:br@brianrosen.net] > > Sent: Wednesday, August 09, 2006 5:38 PM > > To: Michael Hammer (mhammer); 'Patrick Melampy'; 'Klaus Darilion' > > Cc: speermint@ietf.org > > 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 Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 15 08:55:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCySU-0002jh-Cy; Tue, 15 Aug 2006 08:55:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCkDB-0005PH-Hh for speermint@ietf.org; Mon, 14 Aug 2006 17:43:05 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCkDA-0004rV-1O for speermint@ietf.org; Mon, 14 Aug 2006 17:43:05 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GCkCx-0000Sg-Ox; Mon, 14 Aug 2006 16:42:52 -0500 From: "Brian Rosen" To: "'Patrick Melampy'" , "'Michael Hammer \(mhammer\)'" , "'Klaus Darilion'" Subject: RE: [Speermint] Congestion and Load Balancing Date: Mon, 14 Aug 2006 17:42:55 -0400 Message-ID: <068a01c6bfea$9c5b00e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <00ca01c6bfe6$d5df1cb0$6501a8c0@acmepacket.com> Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAA/o7gAAA6O7w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: dfc1655f2189092f4fafe696b2c0f089 X-Mailman-Approved-At: Tue, 15 Aug 2006 08:55:48 -0400 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I think you need a different work group for a different problem. I think we have been consistently talking about federations, and not adhoc routing by individual bilateral peering relationships. This is not a BGP network. I think that we will allow transit networks, but I expect them to be simplistic and uncommon and if the federations themselves don't arrange transit among themseleves, one or two carriers will. The number of cases where there are more than three hops between carriers will be small, and overoptimizing such cases, especially on first pass, is unwise. The probability of a transit carrier being a bottleneck is just not worth spending time on now. It's just too easy to engineer the probabilities low enough that simple mechanisms suffice. I keep imagining you think it's hard to build transit networks that support 400% of the peak busy hour bandwidth between federations with 5 nines reliability. I don't see it that way. Certainly, with respect to signaling, that is just the kind of normal capacity we create now. Media could be a different problem, but we agree we aren't talking about media. Brian > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Sent: Monday, August 14, 2006 5:16 PM > To: 'Michael Hammer (mhammer)'; 'Brian Rosen'; 'Klaus Darilion' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing > > Agreed -- lets just focus on signaling. > > I believe the congestion controls that are required From speermint-bounces@ietf.org Tue Aug 15 08:55:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCySU-0002jh-Cy; Tue, 15 Aug 2006 08:55:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCkDB-0005PH-Hh for speermint@ietf.org; Mon, 14 Aug 2006 17:43:05 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCkDA-0004rV-1O for speermint@ietf.org; Mon, 14 Aug 2006 17:43:05 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GCkCx-0000Sg-Ox; Mon, 14 Aug 2006 16:42:52 -0500 From: "Brian Rosen" To: "'Patrick Melampy'" , "'Michael Hammer \(mhammer\)'" , "'Klaus Darilion'" Subject: RE: [Speermint] Congestion and Load Balancing Date: Mon, 14 Aug 2006 17:42:55 -0400 Message-ID: <068a01c6bfea$9c5b00e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <00ca01c6bfe6$d5df1cb0$6501a8c0@acmepacket.com> Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAA/o7gAAA6O7w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: dfc1655f2189092f4fafe696b2c0f089 X-Mailman-Approved-At: Tue, 15 Aug 2006 08:55:48 -0400 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I think you need a different work group for a different problem. I think we have been consistently talking about federations, and not adhoc routing by individual bilateral peering relationships. This is not a BGP network. I think that we will allow transit networks, but I expect them to be simplistic and uncommon and if the federations themselves don't arrange transit among themseleves, one or two carriers will. The number of cases where there are more than three hops between carriers will be small, and overoptimizing such cases, especially on first pass, is unwise. The probability of a transit carrier being a bottleneck is just not worth spending time on now. It's just too easy to engineer the probabilities low enough that simple mechanisms suffice. I keep imagining you think it's hard to build transit networks that support 400% of the peak busy hour bandwidth between federations with 5 nines reliability. I don't see it that way. Certainly, with respect to signaling, that is just the kind of normal capacity we create now. Media could be a different problem, but we agree we aren't talking about media. Brian > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Sent: Monday, August 14, 2006 5:16 PM > To: 'Michael Hammer (mhammer)'; 'Brian Rosen'; 'Klaus Darilion' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing > > Agreed -- lets just focus on signaling. > > I believe the congestion controls that are required need a new name, as > its > confusing everybody but me. I believe the issue (and I do not have a > solution) is introduced when you introduce peering. Thus peering will > create > the need. Let me explain.... > > Consider VoIP Domains A, B, C, D, E, F, G, and H > > Lets also assume that somehow they have exchanged information such that a > network of connectivity has been established. Let me draw it below > > > A---D-----E---+ > | | > B---C H > | | > F-----G---+ > > The above adjacencies and business relationships are all established. The > list of adjacencies include: > > A-D > D-E > D-C > B-C > C-F > F-G > E-H > G-H > > It is easy to understand that A can communicate with Domain H through D > via > two paths... > > 1.) A-D-E-H > 2.) A-D-C-F-G-H > > Domain D has to choose -- which path to take, 1 or 2. > > Obviously, the best path is out of scope for Speermint, and is likely to > be > based on policy local to domain D. However, Path 1 and Path 2 are not > limitless, and may experience overload conditions not detectable at A or > H. > For example, What if B had a large volume of traffic destined for E or the > path was diminished by equipment failures. A and H are not be affected, > but > one of the intermediate domains on one of the paths is. > > So at the egress of D, Domain D must decide which next hop to use. Where > will D get information that traffic to E may effect choosing a route to > take? > > I believe that one could make really complex examples that are indeed very > likely. > > One could argue that service provider peering has forced this problem on > us, > and if we dis-intermediate all of the domains that are not terminal, the > problem goes away. > > What we need is a way to report that Path 1 is either down or diminished. > > I have no idea how to make this work just yet. But I think we need to > explore that fact that disintermediation creates this problem, and thus > this > problem needs to be solved. > > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, August 14, 2006 3:14 PM > To: Brian Rosen; Patrick Melampy; Klaus Darilion > Cc: speermint@ietf.org > 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:br@brianrosen.net] > > Sent: Wednesday, August 09, 2006 5:38 PM > > To: Michael Hammer (mhammer); 'Patrick Melampy'; 'Klaus Darilion' > > Cc: speermint@ietf.org > > 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 pneed a new name, as > its > confusing everybody but me. I believe the issue (and I do not have a > solution) is introduced when you introduce peering. Thus peering will > create > the need. Let me explain.... > > Consider VoIP Domains A, B, C, D, E, F, G, and H > > Lets also assume that somehow they have exchanged information such that a > network of connectivity has been established. Let me draw it below > > > A---D-----E---+ > | | > B---C H > | | > F-----G---+ > > The above adjacencies and business relationships are all established. The > list of adjacencies include: > > A-D > D-E > D-C > B-C > C-F > F-G > E-H > G-H > > It is easy to understand that A can communicate with Domain H through D > via > two paths... > > 1.) A-D-E-H > 2.) A-D-C-F-G-H > > Domain D has to choose -- which path to take, 1 or 2. > > Obviously, the best path is out of scope for Speermint, and is likely to > be > based on policy local to domain D. However, Path 1 and Path 2 are not > limitless, and may experience overload conditions not detectable at A or > H. > For example, What if B had a large volume of traffic destined for E or the > path was diminished by equipment failures. A and H are not be affected, > but > one of the intermediate domains on one of the paths is. > > So at the egress of D, Domain D must decide which next hop to use. Where > will D get information that traffic to E may effect choosing a route to > take? > > I believe that one could make really complex examples that are indeed very > likely. > > One could argue that service provider peering has forced this problem on > us, > and if we dis-intermediate all of the domains that are not terminal, the > problem goes away. > > What we need is a way to report that Path 1 is either down or diminished. > > I have no idea how to make this work just yet. But I think we need to > explore that fact that disintermediation creates this problem, and thus > this > problem needs to be solved. > > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, August 14, 2006 3:14 PM > To: Brian Rosen; Patrick Melampy; Klaus Darilion > Cc: speermint@ietf.org > 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:br@brianrosen.net] > > Sent: Wednesday, August 09, 2006 5:38 PM > > To: Michael Hammer (mhammer); 'Patrick Melampy'; 'Klaus Darilion' > > Cc: speermint@ietf.org > > 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 > > > > > -----Original Message----- > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > Sent: Wednesday, August 09, 2006 5:09 PM > > > To: Brian Rosen; Patrick Melampy; Klaus Darilion > > > Cc: speermint@ietf.org > > > 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 > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Wednesday, August 09, 2006 4:50 PM > > > > To: 'Patrick Melampy'; 'Klaus Darilion' > > > > Cc: speermint@ietf.org > > > > 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:PMelampy@acmepacket.com] > > > > > Sent: Wednesday, August 09, 2006 1:30 PM > > > > > To: 'Klaus Darilion' > > > > > Cc: 'Brian Rosen'; speermint@ietf.org > > > > > 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 sroxy 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:mhammer@cisco.com] > > > Sent: Wednesday, August 09, 2006 5:09 PM > > > To: Brian Rosen; Patrick Melampy; Klaus Darilion > > > Cc: speermint@ietf.org > > > 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 > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Wednesday, August 09, 2006 4:50 PM > > > > To: 'Patrick Melampy'; 'Klaus Darilion' > > > > Cc: speermint@ietf.org > > > > 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:PMelampy@acmepacket.com] > > > > > Sent: Wednesday, August 09, 2006 1:30 PM > > > > > To: 'Klaus Darilion' > > > > > Cc: 'Brian Rosen'; speermint@ietf.org > > > > > 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:klaus.mailinglists@pernau.at] > > > > > Sent: Wednesday, August 09, 2006 11:48 AM > > > > > To: Patrick Melampy > > > > > Cc: 'Brian Rosen'; speermint@ietf.org > > > > > 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:klaus.mailinglists@pernau.at] > > > > > > Sent: Wednesday, August 09, 2006 7:59 AM > > > > > > To: Brian Rosen > > > > > > Cc: 'Patrick Melampy'; speermint@ietf.org > > > > > > 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), theame 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:klaus.mailinglists@pernau.at] > > > > > Sent: Wednesday, August 09, 2006 11:48 AM > > > > > To: Patrick Melampy > > > > > Cc: 'Brian Rosen'; speermint@ietf.org > > > > > 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:klaus.mailinglists@pernau.at] > > > > > > Sent: Wednesday, August 09, 2006 7:59 AM > > > > > > To: Brian Rosen > > > > > > Cc: 'Patrick Melampy'; speermint@ietf.org > > > > > > 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:PMelampy@acmepacket.com] > > > > > >>> Sent: Saturday, August 05, 2006 4:42 PM > > > > > >>> To: 'Brian Rosen' > > > > > >>> Cc: speermint@ietf.org > > > > > >>> 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 significann 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:PMelampy@acmepacket.com] > > > > > >>> Sent: Saturday, August 05, 2006 4:42 PM > > > > > >>> To: 'Brian Rosen' > > > > > >>> Cc: speermint@ietf.org > > > > > >>> 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----- > > > > > >>tly 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:br@brianrosen.net] > > > > > >>> Sent: Friday, August 04, 2006 2:28 PM > > > > > >>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff > > > > Devine'; 'Michael > > > > > Hammer > > > > > >>> (mhammer)'; 'Hadriel Kaplan' > > > > > >>> Cc: speermint@ietf.org > > > > > >>> 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:rpenno@juniper.net] > > > > > >>>> Sent: Friday, August 04, 2006 2:14 PM > > > > > >>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael > > > > > >>>> Hammer > > > > > >>> (mhammer); > > > > > >>>> Hadriel Kaplan > > > > > >>>> Cc: speermint@ietf.org > > > > > >>>> 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:br@brianrosen.net] > > > > > >>>>> Sent: Friday, August 04, 2006 10:47 AM > > > > > >>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer > > > > > >>>>> (mhammer)'; 'Hadriel Kaplan' > > > > > >>>>> Cc: speermint@ietf.org > > > > > >>>>> Subject: RE: [Speermint] Congestion and Load > > Balancing was Re: > > > > > Secure > > > > > >>>> RTP > > > > > >>>>> > > > 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 > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > >>> Sent: Friday, August 04, 2006 2:28 PM > > > > > >>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff > > > > Devine'; 'Michael > > > > > Hammer > > > > > >>> (mhammer)'; 'Hadriel Kaplan' > > > > > >>> Cc: speermint@ietf.org > > > > > >>> 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:rpenno@juniper.net] > > > > > >>>> Sent: Friday, August 04, 2006 2:14 PM > > > > > >>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael > > > > > >>>> Hammer > > > > > >>> (mhammer); > > > > > >>>> Hadriel Kaplan > > > > > >>>> Cc: speermint@ietf.org > > > > > >>>> 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:br@brianrosen.net] > > > > > >>>>> Sent: Friday, August 04, 2006 10:47 AM > > > > > >>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer > > > > > >>>>> (mhammer)'; 'Hadriel Kaplan' > > > > > >>>>> Cc: speermint@ietf.org > > > > > >>>>> Subject: RE: [Speermint] Congestion and Load > > Balancing was Re: > > > > > Secure > > > > > >>>> RTP > > > > > >>>>> > > > 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:PMelampy@acmepacket.com] > > > > > >>>>>> Sent: Friday, August 04, 2006 12:39 PM > > > > > >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer > > > > (mhammer)'; > > > > > >>>> 'Hadriel > > > > > >>>>>> Kaplan' > > > > > >>>>>> Cc: speermint@ietf.org > > > > > >>>>>> 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 > > > > > > > > >>>> 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:PMelampy@acmepacket.com] > > > > > >>>>>> Sent: Friday, August 04, 2006 12:39 PM > > > > > >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer > > > > (mhammer)'; > > > > > >>>> 'Hadriel > > > > > >>>>>> Kaplan' > > > > > >>>>>> Cc: speermint@ietf.org > > > > > >>>>>> 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:br@brianrosen.net] > > > > > >>>>>> Sent: Friday, August 04, 2006 12:01 PM > > > > > >>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer > > > > > >>>>>> (mhammer)'; 'Hadriel Kaplan' > > > > > >>>>>> Cc: speermint@ietf.org > > > > > >>>>>> 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. > > > > > >>>>>> > >> > >>>> 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:br@brianrosen.net] > > > > > >>>>>> Sent: Friday, August 04, 2006 12:01 PM > > > > > >>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer > > > > > >>>>>> (mhammer)'; 'Hadriel Kaplan' > > > > > >>>>>> Cc: speermint@ietf.org > > > > > >>>>>> 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:gdevine@cedarpointcom.com] > > > > > >>>>>>> Sent: Friday, August 04, 2006 11:35 AM > > > > > >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer > > > > > >>>>>>> (mhammer); > > > > > >>>> Hadriel > > > > > >>>>>> Kaplan > > > > > >>>>>>> Cc: speermint@ietf.org > > > > > >>>>>>> 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:br@brianrosen.net] > > > > > >>>>>>> Sent: Friday, August 04, 2006 11:27 AM > > > > > >>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer > > > > > >>>>>>> (mhammer)'; 'Hadriel Kaplan' > > > > > >>>>>>> Cc: speermint@ietf.org > > > > > >>>>>>> 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:gdevine@cedarpointcom.com] > > > > > >>>>>>>> Sent: Friday, August 04, 2006 11:01 AM > > > > > >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer > > > > > >>>>>>>> (mhammer); > > > > > >>>> Hadriel > > > > > >>>>>>> Kaplan > > > > > >>>>>>>> Cc: speermint@ietf.org > > > > > >>>>>>>> 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 > > > > > >>>>> tra > > > >>>>>> 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:gdevine@cedarpointcom.com] > > > > > >>>>>>> Sent: Friday, August 04, 2006 11:35 AM > > > > > >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer > > > > > >>>>>>> (mhammer); > > > > > >>>> Hadriel > > > > > >>>>>> Kaplan > > > > > >>>>>>> Cc: speermint@ietf.org > > > > > >>>>>>> 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:br@brianrosen.net] > > > > > >>>>>>> Sent: Friday, August 04, 2006 11:27 AM > > > > > >>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer > > > > > >>>>>>> (mhammer)'; 'Hadriel Kaplan' > > > > > >>>>>>> Cc: speermint@ietf.org > > > > > >>>>>>> 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:gdevine@cedarpointcom.com] > > > > > >>>>>>>> Sent: Friday, August 04, 2006 11:01 AM > > > > > >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer > > > > > >>>>>>>> (mhammer); > > > > > >>>> Hadriel > > > > > >>>>>>> Kaplan > > > > > >>>>>>>> Cc: speermint@ietf.org > > > > > >>>>>>>> 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:br@brianrosen.net] > > > > > >>>>>>>> Sent: Friday, August 04, 2006 10:20 AM > > > > > >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > > > >>>>>>>> 'Hadriel > > > > > >>>> Kaplan' > > > > > >>>>>>>> Cc: speermint@ietf.org > > > > > >>>>>>>> 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:PMelampy@acmepacket.com] > > > > > >>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM > > > > > >>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer > > (mhammer)'; 'Hadriel > > > > > >>>> Kaplan' > > > > > >>>>>>>>> Cc: speermint@ietf.org > > > > > >>>>>>>>> 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 > > > > > >>>>>ffic > > > > > >>>>>>>> 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:br@brianrosen.net] > > > > > >>>>>>>> Sent: Friday, August 04, 2006 10:20 AM > > > > > >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > > > >>>>>>>> 'Hadriel > > > > > >>>> Kaplan' > > > > > >>>>>>>> Cc: speermint@ietf.org > > > > > >>>>>>>> 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:PMelampy@acmepacket.com] > > > > > >>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM > > > > > >>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer > > (mhammer)'; 'Hadriel > > > > > >>>> Kaplan' > > > > > >>>>>>>>> Cc: speermint@ietf.org > > > > > >>>>>>>>> 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:br@brianrosen.net] > > > > > >>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM > > > > > >>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > > >>>>>>>>> Cc: speermint@ietf.org > > > > > >>>>>>>>> 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. > > > > > >>>>> 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:br@brianrosen.net] > > > > > >>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM > > > > > >>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > > >>>>>>>>> Cc: speermint@ietf.org > > > > > >>>>>>>>> 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:mhammer@cisco.com] > > > > > >>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM > > > > > >>>>>>>>>> To: Hadriel Kaplan; Brian Rosen > > > > > >>>>>>>>>> Cc: speermint@ietf.org > > > > > >>>>>>>>>> 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 > > > 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 > > > > > >>>>> Speermint@ietf.org > > > > > >>>>> https://www1.ietf.org/mailman/listinfo/speermint > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> Speermint mailing list > > > > > >> Speermint@ietf.org > > > > > >> https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 15 08:55:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCySU-0002jV-6S; Tue, 15 Aug 2006 08:55:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCjn6-0004cW-8o for speermint@ietf.org; Mon, 14 Aug 2006 17:16:08 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] hel>>>>>>>> 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:mhammer@cisco.com] > > > > > >>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM > > > > > >>>>>>>>>> To: Hadriel Kaplan; Brian Rosen > > > > > >>>>>>>>>> Cc: speermint@ietf.org > > > > > >>>>>>>>>> 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 > > > 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 > > > > > >>>>> Speermint@ietf.org > > > > > >>>>> https://www1.ietf.org/mailman/listinfo/speermint > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> Speermint mailing list > > > > > >> Speermint@ietf.org > > > > > >> https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 15 08:55:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCySU-0002jV-6S; Tue, 15 Aug 2006 08:55:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCjn6-0004cW-8o for speermint@ietf.org; Mon, 14 Aug 2006 17:16:08 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCjn4-0002eB-Pa for speermint@ietf.org; Mon, 14 Aug 2006 17:16:08 -0400 Received: from PMelampy2 [10.0.200.104] by acmepacket.com with ESMTP (SMTPD-9.03) id A80D03E8; Mon, 14 Aug 2006 17:15:57 -0400 From: "Patrick Melampy" To: "'Michael Hammer \(mhammer\)'" , "'Brian Rosen'" , "'Klaus Darilion'" Subject: RE: [Speermint] Congestion and Load Balancing Date: Mon, 14 Aug 2006 17:15:57 -0400 Message-ID: <00ca01c6bfe6$d5df1cb0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAA/o7gA== In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301CE9B99@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.3 (+) X-Scan-Signature: e757c5fc4111242d37629bd94b9648e7 X-Mailman-Approved-At: Tue, 15 Aug 2006 08:55:48 -0400 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Agreed -- lets just focus on signaling. I believe the congestion controls that are required need a new name, as its confusing everybody but me. I believe the issue (and I do not have a solution) is introduced when you introduce peering. Thus peering will create the need. Let me explain.... Consider VoIP Domains A, B, C, D, E, F, G, and H Lets also assume that somehow they have exchanged information such that a network of connectivity has been established. Let me draw it below A---D-----E---+ | | B---C H | | F-----G---+ The above adjacencies and business relationships are all established. The list of adjacencies include: A-D D-E D-C B-C C-F F-G E-H G-H It is easy to understand that A can communicate with Domain H through D via two paths... 1.) A-D-E-H 2.) A-D-C-F-G-H Domain D has to choose -- which path to take, 1 or 2. Obviously, the best path is out of scope for Speermint, and is likely to be based on policy local to domain D. However, Path 1 and Path 2 are not limitless, and may experience overload conditions not detectable at A or H. For example, What if B had a large volume of traffic destined for E or the path was diminished by equipment failures. A and H are not be affected, but one of the intermediate domains on one of the paths is. So at the egress of D, Domain D must decide which next hop to use. Where will D get information that traffic to E may effect choosing a route to take? I believe that one could make really complex examples that are indeed very likely. One could argue that service provider peering has forced this problem on us, and if we dis-intermediate all of the domains that are not terminal, the problem goes away. What we need is a way to report that Path 1 is either down or diminished. I have no idea how to make this work just yet. But I think we need to explore that fact that disintermediation creates this problem, and thus this problem needs to be solved. -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Monday, August 14, 2006 3:14 PM To: Brian Rosen; Patrick Melampy; Klaus Darilion Cc: speermint@ietf.org 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. o=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCjn4-0002eB-Pa for speermint@ietf.org; Mon, 14 Aug 2006 17:16:08 -0400 Received: from PMelampy2 [10.0.200.104] by acmepacket.com with ESMTP (SMTPD-9.03) id A80D03E8; Mon, 14 Aug 2006 17:15:57 -0400 From: "Patrick Melampy" To: "'Michael Hammer \(mhammer\)'" , "'Brian Rosen'" , "'Klaus Darilion'" Subject: RE: [Speermint] Congestion and Load Balancing Date: Mon, 14 Aug 2006 17:15:57 -0400 Message-ID: <00ca01c6bfe6$d5df1cb0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAA/o7gA== In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301CE9B99@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.3 (+) X-Scan-Signature: e757c5fc4111242d37629bd94b9648e7 X-Mailman-Approved-At: Tue, 15 Aug 2006 08:55:48 -0400 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Agreed -- lets just focus on signaling. I believe the congestion controls that are required need a new name, as its confusing everybody but me. I believe the issue (and I do not have a solution) is introduced when you introduce peering. Thus peering will create the need. Let me explain.... Consider VoIP Domains A, B, C, D, E, F, G, and H Lets also assume that somehow they have exchanged information such that a network of connectivity has been established. Let me draw it below A---D-----E---+ | | B---C H | | F-----G---+ The above adjacencies and business relationships are all established. The list of adjacencies include: A-D D-E D-C B-C C-F F-G E-H G-H It is easy to understand that A can communicate with Domain H through D via two paths... 1.) A-D-E-H 2.) A-D-C-F-G-H Domain D has to choose -- which path to take, 1 or 2. Obviously, the best path is out of scope for Speermint, and is likely to be based on policy local to domain D. However, Path 1 and Path 2 are not limitless, and may experience overload conditions not detectable at A or H. For example, What if B had a large volume of traffic destined for E or the path was diminished by equipment failures. A and H are not be affected, but one of the intermediate domains on one of the paths is. So at the egress of D, Domain D must decide which next hop to use. Where will D get information that traffic to E may effect choosing a route to take? I believe that one could make really complex examples that are indeed very likely. One could argue that service provider peering has forced this problem on us, and if we dis-intermediate all of the domains that are not terminal, the problem goes away. What we need is a way to report that Path 1 is either down or diminished. I have no idea how to make this work just yet. But I think we need to explore that fact that disintermediation creates this problem, and thus this problem needs to be solved. -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Monday, August 14, 2006 3:14 PM To: Brian Rosen; Patrick Melampy; Klaus Darilion Cc: speermint@ietf.org 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:br@brianrosen.net] > Sent: Wednesday, August 09, 2006 5:38 PM > To: Michael Hammer (mhammer); 'Patrick Melampy'; 'Klaus Darilion' > Cc: speermint@ietf.org > 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 > > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Wednesday, August 09, 2006 5:09 PM > > To: Brian Rosen; Patrick Melampy; Klaus Darilion > > Cc: speermint@ietf.org > > 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 > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, August 09, 2006 4:50 PM > > > To: 'Patrick Melampy'; 'Klaus Darilion' > > > Cc: speermint@ietf.org > > > 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 aSome 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:br@brianrosen.net] > Sent: Wednesday, August 09, 2006 5:38 PM > To: Michael Hammer (mhammer); 'Patrick Melampy'; 'Klaus Darilion' > Cc: speermint@ietf.org > 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 > > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Wednesday, August 09, 2006 5:09 PM > > To: Brian Rosen; Patrick Melampy; Klaus Darilion > > Cc: speermint@ietf.org > > 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 > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, August 09, 2006 4:50 PM > > > To: 'Patrick Melampy'; 'Klaus Darilion' > > > Cc: speermint@ietf.org > > > 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:PMelampy@acmepacket.com] > > > > Sent: Wednesday, August 09, 2006 1:30 PM > > > > To: 'Klaus Darilion' > > > > Cc: 'Brian Rosen'; speermint@ietf.org > > > > 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:klaus.mailinglists@pernau.at] > > > > Sent: Wednesday, August 09, 2006 11:48 AM > > > > To: Patrick Melampy > > > > Cc: 'Brian Rosen'; speermint@ietf.org > > > > 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 > > > wire 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:PMelampy@acmepacket.com] > > > > Sent: Wednesday, August 09, 2006 1:30 PM > > > > To: 'Klaus Darilion' > > > > Cc: 'Brian Rosen'; speermint@ietf.org > > > > 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:klaus.mailinglists@pernau.at] > > > > Sent: Wednesday, August 09, 2006 11:48 AM > > > > To: Patrick Melampy > > > > Cc: 'Brian Rosen'; speermint@ietf.org > > > > 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:klaus.mailinglists@pernau.at] > > > > > Sent: Wednesday, August 09, 2006 7:59 AM > > > > > To: Brian Rosen > > > > > Cc: 'Patrick Melampy'; speermint@ietf.org > > > > > 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:PMelampy@acmepacket.com] > > > > >>> Sent: Saturday, August 05, 2006 4:42 PM > > > > >>> To: 'Brian Rosen' > > > > >>> Cc: speermint@ietf.org > > > > >>> 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 ll 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:klaus.mailinglists@pernau.at] > > > > > Sent: Wednesday, August 09, 2006 7:59 AM > > > > > To: Brian Rosen > > > > > Cc: 'Patrick Melampy'; speermint@ietf.org > > > > > 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:PMelampy@acmepacket.com] > > > > >>> Sent: Saturday, August 05, 2006 4:42 PM > > > > >>> To: 'Brian Rosen' > > > > >>> Cc: speermint@ietf.org > > > > >>> 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 > 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:br@brianrosen.net] > > > > >>> Sent: Friday, August 04, 2006 2:28 PM > > > > >>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff > > > Devine'; 'Michael > > > > Hammer > > > > >>> (mhammer)'; 'Hadriel Kaplan' > > > > >>> Cc: speermint@ietf.org > > > > >>> 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:rpenno@juniper.net] > > > > >>>> Sent: Friday, August 04, 2006 2:14 PM > > > > >>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael > > > > >>>> Hammer > > > > >>> (mhammer); > > > > >>>> Hadriel Kaplan > > > > >>>> Cc: speermint@ietf.org > > > > >>>> 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:br@brianrosen.net] > > > > >>>>> Sent: Friday, August 04, 2006 10:47 AM > > > > >>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer > > > > >>>>> (mhammer)'; 'Hadriel Kaplan' > > > > >>>>> Cc: speermint@ietf.org > > > > >>>>> Subject: RE: [Speermint] Congestion and Load > Balancing was Re: > > > > Secure > > > > >>>> RTP > > > > >>>>> > > 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 > >> > > >>> 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:br@brianrosen.net] > > > > >>> Sent: Friday, August 04, 2006 2:28 PM > > > > >>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff > > > Devine'; 'Michael > > > > Hammer > > > > >>> (mhammer)'; 'Hadriel Kaplan' > > > > >>> Cc: speermint@ietf.org > > > > >>> 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:rpenno@juniper.net] > > > > >>>> Sent: Friday, August 04, 2006 2:14 PM > > > > >>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael > > > > >>>> Hammer > > > > >>> (mhammer); > > > > >>>> Hadriel Kaplan > > > > >>>> Cc: speermint@ietf.org > > > > >>>> 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:br@brianrosen.net] > > > > >>>>> Sent: Friday, August 04, 2006 10:47 AM > > > > >>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer > > > > >>>>> (mhammer)'; 'Hadriel Kaplan' > > > > >>>>> Cc: speermint@ietf.org > > > > >>>>> Subject: RE: [Speermint] Congestion and Load > Balancing was Re: > > > > Secure > > > > >>>> RTP > > > > >>>>> > > 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:PMelampy@acmepacket.com] > > > > >>>>>> Sent: Friday, August 04, 2006 12:39 PM > > > > >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer > > > (mhammer)'; > > > > >>>> 'Hadriel > > > > >>>>>> Kaplan' > > > > >>>>>> Cc: speermint@ietf.org > > > > >>>>>> 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 > > >>>>> 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:PMelampy@acmepacket.com] > > > > >>>>>> Sent: Friday, August 04, 2006 12:39 PM > > > > >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer > > > (mhammer)'; > > > > >>>> 'Hadriel > > > > >>>>>> Kaplan' > > > > >>>>>> Cc: speermint@ietf.org > > > > >>>>>> 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:br@brianrosen.net] > > > > >>>>>> Sent: Friday, August 04, 2006 12:01 PM > > > > >>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer > > > > >>>>>> (mhammer)'; 'Hadriel Kaplan' > > > > >>>>>> Cc: speermint@ietf.org > > > > >>>>>> 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 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:br@brianrosen.net] > > > > >>>>>> Sent: Friday, August 04, 2006 12:01 PM > > > > >>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer > > > > >>>>>> (mhammer)'; 'Hadriel Kaplan' > > > > >>>>>> Cc: speermint@ietf.org > > > > >>>>>> 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:gdevine@cedarpointcom.com] > > > > >>>>>>> Sent: Friday, August 04, 2006 11:35 AM > > > > >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer > > > > >>>>>>> (mhammer); > > > > >>>> Hadriel > > > > >>>>>> Kaplan > > > > >>>>>>> Cc: speermint@ietf.org > > > > >>>>>>> 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:br@brianrosen.net] > > > > >>>>>>> Sent: Friday, August 04, 2006 11:27 AM > > > > >>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer > > > > >>>>>>> (mhammer)'; 'Hadriel Kaplan' > > > > >>>>>>> Cc: speermint@ietf.org > > > > >>>>>>> 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:gdevine@cedarpointcom.com] > > > > >>>>>>>> Sent: Friday, August 04, 2006 11:01 AM > > > > >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer > > > > >>>>>>>> (mhammer); > > > > >>>> Hadriel > > > > >>>>>>> Kaplan > > > > >>>>>>>> Cc: speermint@ietf.org > > > > >>>>>>>> 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 > > > > >>>>>>> manag> > > > >>>>>> 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:gdevine@cedarpointcom.com] > > > > >>>>>>> Sent: Friday, August 04, 2006 11:35 AM > > > > >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer > > > > >>>>>>> (mhammer); > > > > >>>> Hadriel > > > > >>>>>> Kaplan > > > > >>>>>>> Cc: speermint@ietf.org > > > > >>>>>>> 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:br@brianrosen.net] > > > > >>>>>>> Sent: Friday, August 04, 2006 11:27 AM > > > > >>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer > > > > >>>>>>> (mhammer)'; 'Hadriel Kaplan' > > > > >>>>>>> Cc: speermint@ietf.org > > > > >>>>>>> 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:gdevine@cedarpointcom.com] > > > > >>>>>>>> Sent: Friday, August 04, 2006 11:01 AM > > > > >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer > > > > >>>>>>>> (mhammer); > > > > >>>> Hadriel > > > > >>>>>>> Kaplan > > > > >>>>>>>> Cc: speermint@ietf.org > > > > >>>>>>>> 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:br@brianrosen.net] > > > > >>>>>>>> Sent: Friday, August 04, 2006 10:20 AM > > > > >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > > >>>>>>>> 'Hadriel > > > > >>>> Kaplan' > > > > >>>>>>>> Cc: speermint@ietf.org > > > > >>>>>>>> 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:PMelampy@acmepacket.com] > > > > >>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM > > > > >>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer > (mhammer)'; 'Hadriel > > > > >>>> Kaplan' > > > > >>>>>>>>> Cc: speermint@ietf.org > > > > >>>>>>>>> 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. > > > > >>>>> Theement, > > > > >>>>>>>> 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:br@brianrosen.net] > > > > >>>>>>>> Sent: Friday, August 04, 2006 10:20 AM > > > > >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; > > > > >>>>>>>> 'Hadriel > > > > >>>> Kaplan' > > > > >>>>>>>> Cc: speermint@ietf.org > > > > >>>>>>>> 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:PMelampy@acmepacket.com] > > > > >>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM > > > > >>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer > (mhammer)'; 'Hadriel > > > > >>>> Kaplan' > > > > >>>>>>>>> Cc: speermint@ietf.org > > > > >>>>>>>>> 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:br@brianrosen.net] > > > > >>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM > > > > >>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > >>>>>>>>> Cc: speermint@ietf.org > > > > >>>>>>>>> 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 > > > > >>>>>>>> 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:br@brianrosen.net] > > > > >>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM > > > > >>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > >>>>>>>>> Cc: speermint@ietf.org > > > > >>>>>>>>> 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:mhammer@cisco.com] > > > > >>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM > > > > >>>>>>>>>> To: Hadriel Kaplan; Brian Rosen > > > > >>>>>>>>>> Cc: speermint@ietf.org > > > > >>>>>>>>>> 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 > > 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 > > > > >>>>> Speermint@ietf.org > > > > >>>>> https://www1.ietf.org/mailman/listinfo/speermint > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> Speermint mailing list > > > > >> Speermint@ietf.org > > > > >> https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint 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:mhammer@cisco.com] > > > > >>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM > > > > >>>>>>>>>> To: Hadriel Kaplan; Brian Rosen > > > > >>>>>>>>>> Cc: speermint@ietf.org > > > > >>>>>>>>>> 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 > > 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 > > > > >>>>> Speermint@ietf.org > > > > >>>>> https://www1.ietf.org/mailman/listinfo/speermint > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> Speermint mailing list > > > > >> Speermint@ietf.org > > > > >> https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 15 08:55:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCySU-0002jt-LJ; Tue, 15 Aug 2006 08:55:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GClK7-0008GN-9T for speermint@ietf.org; Mon, 14 Aug 2006 18:54:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCiMc-0007z5-Ii for speermint@ietf.org; Mon, 14 Aug 2006 15:44:42 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GChsa-0001rv-0h for speermint@ietf.org; Mon, 14 Aug 2006 15:13:46 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 14 Aug 2006 15:13:39 -0400 X-IronPort-AV: i="4.08,122,1154923200"; d="scan'208"; a="96783779:sNHT46295382" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7EJDdDf032075; Mon, 14 Aug 2006 15:13:39 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7EJDcKH006081; Mon, 14 Aug 2006 15:13:38 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 15:13:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Congestion and Load Balancing Date: Mon, 14 Aug 2006 15:13:37 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301CE9B99@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Congestion and Load Balancing Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpA= From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Patrick Melampy" , "Klaus Darilion" X-OriginalArrivalTime: 14 Aug 2006 19:13:38.0932 (UTC) FILETIME=[BF8DD340:01C6BFD5] DKIM-Signature: a=rsa-sha1; q=dns; l=45634; t=1155582819; x=1156446819; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Congestion=20and=20Load=20Balancing |To:=22Brian=20Rosen=22=20, =0A=20=20=20=20=20=20=20=20=22 Patrick=20Melampy=22=20, =0A=20=20=20=20=20=20=20=2 0=22Klaus=20Darilion=22=20; X=v=3Dcisco.com=3B=20h=3DD+ZIob6N7qWaKrQ323RA13TkaLI=3D; b=LF2ie0rI/LRsVAg9XljJnmJDsyCYE8GJyKHMRMVrVnTKEiYR/L4yXlbOxF+cclr2mDigLxTU CkDivxBsYibtaPqMocXezvCyil6H+/ORwxYEEVQk0TIKQ0DOAkKXu9QU; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -1.3 (-) X-Scan-Signature: 8500135f65d7c251ba11be3bcad20d45 X-Mailman-Approved-At: Tue, 15 Aug 2006 08:55:48 -0400 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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 =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, August 09, 2006 5:38 PM > To: Michael Hammer (mhammer); 'Patrick Melampy'; 'Klaus Darilion' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing >=20 > Please don't get me started on the IETF's abandonment of its=20 > belief in running code. >=20 > While occasionally we actually just document something that=20 > exists, we usually end up extending somewhat from something=20 > we know works. We have pretty bad experience inventing major=20 > new functionality ESPECIALLY IN CONGESTION CONTROL, and=20 > seeing it work. It almost never does. >=20 > So, sure, we can invent some new stuff, as long as it is some=20 > likely-to-work extension of stuff we pretty much know works. >=20 > Let me cite an example. ICE is a pretty complex piece of=20 > machinery, but it's built on a base of work we KNOW will=20 > work. ICE may have a bunch of text to tweak as we gain some=20 > implementation experience, but we know it will work. >=20 > I'm not aware of any work in this area we know works we can=20 > build from. Can you cite some? >=20 > I'm not particularly opposed to having discovery mechanisms=20 > for proxy domain names, call rates and bandwidth limits=20 > rather than provisioning. I'm skeptical they would be used,=20 > but it's simple enough. I am opposed to trying to say that=20 > info varies from call to call, but something faster than a=20 > contract negotiation does seem practical. >=20 > That's a far cry from anything we would consider to be=20 > dynamic congestion control. >=20 > Brian >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Wednesday, August 09, 2006 5:09 PM > > To: Brian Rosen; Patrick Melampy; Klaus Darilion > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Congestion and Load Balancing > >=20 > > So, we can't invent anything new unless it has already been=20 > invented? > >=20 > > I don't think I agree that only manual methods of=20 > configuring peers is=20 > > the only way to go. I presume that VSPs in a federation=20 > may come and=20 > > go, and that traffic between peers will come and go. It=20 > seems like on=20 > > some time scale slower than call setup and faster than a contract=20 > > negotiation, there ought to be a way to adjust parameters=20 > of peers to=20 > > reflect a balance between traffic offered and resources available. > >=20 > > When contacted based on a DNS lookup, it doesn't seem that=20 > bad to tell=20 > > a peer which has shown it is part of a federation which=20 > proxy (farm)=20 > > to use and what parameters to stay within. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, August 09, 2006 4:50 PM > > > To: 'Patrick Melampy'; 'Klaus Darilion' > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Congestion and Load Balancing > > > > > > I don't think there is anything particularly dynamic about what A=20 > > > knows about B, because it will be subject to contract. > > > I do not think we know enough to design congestion control=20 > > > mechanisms that work across the peering boundary. I am=20 > not aware of=20 > > > experimental work that would point towards what kinds of=20 > mechanisms=20 > > > are appropriate, and in the absence of some working=20 > examples, I fail=20 > > > to see why we should even consider it. We can limit=20 > calls per unit=20 > > > of time, and bandwidth, on a list of proxies and I think=20 > that's it. > > > > > > The design of congestion control protocols is fraught=20 > with failures=20 > > > on things that ought to have worked. The congestion control=20 > > > mechanisms we see in the PSTN are wholly unsuitable for the=20 > > > Internet. What we will need for the Internet has yet to be=20 > > > investigated. I encourage such investigation. > > > I'd be very interested in reports describing new=20 > mechanisms and how=20 > > > well they work, both on simulated and real traffic. > > > > > > But unless you can point to something that appears to=20 > work, it's out=20 > > > of bounds for this group, in my opinion. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > > Sent: Wednesday, August 09, 2006 1:30 PM > > > > To: 'Klaus Darilion' > > > > Cc: 'Brian Rosen'; speermint@ietf.org > > > > 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=20 > > > > 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=20 > exchanging this=20 > > > > 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:klaus.mailinglists@pernau.at] > > > > Sent: Wednesday, August 09, 2006 11:48 AM > > > > To: Patrick Melampy > > > > Cc: 'Brian Rosen'; speermint@ietf.org > > > > Subject: Re: [Speermint] Congestion and Load Balancing > > > > > > > > Patrick Melampy wrote: > > > > > Klaus --- What the carrier needs is four basic=20 > requirements (the > > > > receiving > > > > > or B carrier): > > > > > > > > > > 1.) To be able to receive calls > > > > > 2.) To be able to count the simultaneous calls > > > > > > > > =3D dialog-statefull proxy > > > > > > > > > 3.) To be able to count the kilobytes of bandwidth=20 > the media is > > > > consuming > > > > > > > > =3D 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=20 > > > > 3xx) > > > > > > > > > > A stateless load balancer can't provide these. > > > > > > > > IMO a load balancer is a load balancer, and beeing statefull at=20 > > > > SIP layser is different to knowing the state (load) on the SIP > > > proxies and > > > > media gateways inside your network. A LB can be SIP=20 > stateless, but=20 > > > > still knows the status of the SIP nodes in the network and may=20 > > > > distribute the calls accordingly to the SIP nodes (ok, here a=20 > > > > transaction stateful LB would be good, but a session > > > statefull LB is > > > > not required) > > > > > > > > > I believe that semi-stateless load-balancers are=20 > required. All=20 > > > > > of the technology you and Brian speak to works.=20 > However, none of=20 > > > > > 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=20 > > > > > admission > > > > control > > > > > parameters) will be important topics for this group. > > > > > > > > IMO this is inside of network B, thus out of scope for=20 > SPEERMINT. > > > > > > > > regards > > > > klaus > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > > > > Sent: Wednesday, August 09, 2006 7:59 AM > > > > > To: Brian Rosen > > > > > Cc: 'Patrick Melampy'; speermint@ietf.org > > > > > Subject: Re: [Speermint] Congestion and Load Balancing > > > > > > > > > > Some more practical LB issues. > > > > > > > > > > If the LB is used for load balancing only, there is=20 > no need to=20 > > > > > be transaction stateful - it depends on the distribution > > > logic of the LB. > > > > > If there is a random component within the LB-logic,=20 > you need a=20 > > > > > 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=20 > aware, but not=20 > > > > >> 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=20 > transaction ID=20 > > > > >> 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. =20 > You have=20 > > > > >> 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:PMelampy@acmepacket.com] > > > > >>> Sent: Saturday, August 05, 2006 4:42 PM > > > > >>> To: 'Brian Rosen' > > > > >>> Cc: speermint@ietf.org > > > > >>> Subject: RE: [Speermint] Congestion and Load Balancing > > > > >>> > > > > >>> Assuming that Domain B was determined to be the next domain=20 > > > > >>> (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=20 > that B owns. > > > > >>> This > > > > load > > > > >>> balancer would likely be stateless, and as such unable to=20 > > > > >>> 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=20 > > > > >>> 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=20 > > > > >>> 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=20 > > > > >>> per > > > > >>> second...) > > > > >>> > > > > >>> One problem we have now with B's load balancer, is that B=20 > > > > >>> 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=20 > stateful. This=20 > > > > >>> 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=20 > established=20 > > > > >>> coming > > > > from > > > > >>> A. > > > > >>> > > > > >>> Probably, A has the same issue that B has ... How=20 > many calls=20 > > > > >>> 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=20 > destined for B. > > > > >>> > > > > >>> Why is all this required? Well frankly, much of the > > > traffic will > > > > >>> have "media" based bandwidth limitations. One could=20 > consider a=20 > > > > >>> 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?=20 > Where does=20 > > > > >>> A send > > > > it? > > > > >>> Is > > > > >>> there an alternative? How can A determine if there=20 > is another=20 > > > > >>> network > > > > > (say > > > > >>> C) that can process the communication? How would A share=20 > > > > >>> 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=20 > SIP were more=20 > > > > >>> like > > > > HTTP > > > > >>> where the TCP session and the HTTP session were > > > directly connected > > > > >>> -- > > > > > with > > > > >>> COOKIES binding the physical sessions into logical=20 > application > > > > sessions, > > > > >>> then we could more readily use your suggestions. Last I=20 > > > > >>> looked, SIP transactions and dialogues are pretty nasty to > > > recognize, and > > > > >>> add retransmissions, cancels, and other nasty=20 > things that make=20 > > > > >>> 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=20 > > > > >>> 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:br@brianrosen.net] > > > > >>> Sent: Friday, August 04, 2006 2:28 PM > > > > >>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff > > > Devine'; 'Michael > > > > Hammer > > > > >>> (mhammer)'; 'Hadriel Kaplan' > > > > >>> Cc: speermint@ietf.org > > > > >>> Subject: RE: [Speermint] Congestion and Load=20 > 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:rpenno@juniper.net] > > > > >>>> Sent: Friday, August 04, 2006 2:14 PM > > > > >>>> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael=20 > > > > >>>> Hammer > > > > >>> (mhammer); > > > > >>>> Hadriel Kaplan > > > > >>>> Cc: speermint@ietf.org > > > > >>>> Subject: RE: [Speermint] Congestion and Load=20 > Balancing was Re: > > > > >>>> Secure > > > > >>> RTP > > > > >>>> Hello Brian, > > > > >>>> > > > > >>>> Are you assuming some kind of public peering or=20 > third party=20 > > > > >>>> 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=20 > > > > >>>> how the > > > > calls > > > > >>>> get distributed to _its_ proxies from peer's A=20 > proxies, right? > > > > >>>> > > > > >>>> That's why I put the load balancer between them from a=20 > > > > >>>> 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:br@brianrosen.net] > > > > >>>>> Sent: Friday, August 04, 2006 10:47 AM > > > > >>>>> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer=20 > > > > >>>>> (mhammer)'; 'Hadriel Kaplan' > > > > >>>>> Cc: speermint@ietf.org > > > > >>>>> Subject: RE: [Speermint] Congestion and Load=20 > Balancing was Re: > > > > Secure > > > > >>>> RTP > > > > >>>>> > > thread on > > > > Secure > > > > >>>>> RTP> > > > > >>>>> > > > > >>>>> I fail to see why any of this is a=20 > standardization issue: I=20 > > > > >>>>> 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=20 > that requires=20 > > > > >>>>> 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=20 > > > > >>>>> 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=20 > multiple=20 > > > > >>>>> 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=20 > at, or "near" > > > > >>>>> (in an > > > > >>>> L3 > > > > >>>>> sense) the NY and Miami IXPs and PeerB happens to have=20 > > > > >>>>> 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=20 > 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=20 > > > > >>>>> 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=20 > 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=20 > > > > >>>>> 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:PMelampy@acmepacket.com] > > > > >>>>>> Sent: Friday, August 04, 2006 12:39 PM > > > > >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer > > > (mhammer)'; > > > > >>>> 'Hadriel > > > > >>>>>> Kaplan' > > > > >>>>>> Cc: speermint@ietf.org > > > > >>>>>> 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=20 > good ones=20 > > > > >>>>>> (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=20 > > > > >>>>>> mechanisms > > > > >>>> (why > > > > >>>>> not) > > > > >>>>>> based on incoming request addresses > > > > >>>>>> 3.) We might further want to fine tune the balancer to=20 > > > > >>>>>> accommodate > > > > >>>> some > > > > >>>>>> larger customers (not exactly fair). > > > > >>>>>> > > > > >>>>>> What configurations would the load balancer=20 > need? Would the > > > > >>>> originators > > > > >>>>> of > > > > >>>>>> the requests need to understand the programmed limits of=20 > > > > >>>>>> the load balancer? > > > > >>>>>> > > > > >>>>>> NOW--- and MOST IMPORANTLY--- unlike in a HTTP load=20 > > > > >>>>>> 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=20 > 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:br@brianrosen.net] > > > > >>>>>> Sent: Friday, August 04, 2006 12:01 PM > > > > >>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer=20 > > > > >>>>>> (mhammer)'; 'Hadriel Kaplan' > > > > >>>>>> Cc: speermint@ietf.org > > > > >>>>>> 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=20 > issues with=20 > > > > >>>>>> 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=20 > engineered SIP=20 > > > > >>>>>> 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=20 > numbers just=20 > > > > >>>>>> 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=20 > stateless,=20 > > > > >>>>>> but > > > > that's > > > > >>>> not > > > > >>>>> a > > > > >>>>>> problem). > > > > >>>>>> > > > > >>>>>> Sure, you need a load balancer. Sure, you need=20 > a failover=20 > > > > >>>>>> 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=20 > > > > >>>>>> engineering to predict the traffic at the=20 > peering point. =20 > > > > >>>>>> We can engineer systems pretty straightforwardly=20 > to handle=20 > > > > >>>>>> 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=20 > > > > >>>>>> peering > > > > happens > > > > >>>> at > > > > >>>>>> multiple places around the globe, where there is no=20 > > > > >>>>>> effective > > > > limits > > > > >>>> on > > > > >>>>>> signaling bandwith (or for that matter, media > > > bandwith) to and > > > > >>>>>> from > > > > >>>> the > > > > >>>>>> peering points. We can have SIP proxies that=20 > perform the=20 > > > > >>>>>> 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:gdevine@cedarpointcom.com] > > > > >>>>>>> Sent: Friday, August 04, 2006 11:35 AM > > > > >>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer=20 > > > > >>>>>>> (mhammer); > > > > >>>> Hadriel > > > > >>>>>> Kaplan > > > > >>>>>>> Cc: speermint@ietf.org > > > > >>>>>>> Subject: RE: [Speermint] Secure RTP > > > > >>>>>>> > > > > >>>>>>> Telephone networks don't and can't work that way. They=20 > > > > >>>>>>> have > > > > >>>> overload > > > > >>>>>>> conditions and you absolutely must have a mechanism for=20 > > > > >>>>>>> dealing > > > > >>>> with > > > > >>>>>>> them. In the legacy network, you can take SS#7=20 > CICs out=20 > > > > >>>>>>> of > > > > >>>> service. > > > > >>>>>>> You can implement call gapping and call=20 > metering. We need > > > > >>>> equivalent > > > > >>>>>>> mechanisms and can likely do far better than=20 > best common=20 > > > > >>>>>>> practices > > > > >>>> in > > > > >>>>>>> the legacy network. > > > > >>>>>>> > > > > >>>>>>> Geoff > > > > >>>>>>> > > > > >>>>>>> -----Original Message----- > > > > >>>>>>> From: Brian Rosen [mailto:br@brianrosen.net] > > > > >>>>>>> Sent: Friday, August 04, 2006 11:27 AM > > > > >>>>>>> To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer=20 > > > > >>>>>>> (mhammer)'; 'Hadriel Kaplan' > > > > >>>>>>> Cc: speermint@ietf.org > > > > >>>>>>> Subject: RE: [Speermint] Secure RTP > > > > >>>>>>> > > > > >>>>>>> There is no evidence that you can't do this with the=20 > > > > >>>>>>> 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:gdevine@cedarpointcom.com] > > > > >>>>>>>> Sent: Friday, August 04, 2006 11:01 AM > > > > >>>>>>>> To: Brian Rosen; Patrick Melampy; Michael Hammer=20 > > > > >>>>>>>> (mhammer); > > > > >>>> Hadriel > > > > >>>>>>> Kaplan > > > > >>>>>>>> Cc: speermint@ietf.org > > > > >>>>>>>> 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=20 > 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=20 > > > > >>>>>>>> are > > > > >>>> finite, > > > > >>>>> not > > > > >>>>>>>> infinite and the network architecture has to take that=20 > > > > >>>>>>>> into > > > > >>>> account. > > > > >>>>>>>> Geoff > > > > >>>>>>>> > > > > >>>>>>>> -----Original Message----- > > > > >>>>>>>> From: Brian Rosen [mailto:br@brianrosen.net] > > > > >>>>>>>> Sent: Friday, August 04, 2006 10:20 AM > > > > >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)';=20 > > > > >>>>>>>> 'Hadriel > > > > >>>> Kaplan' > > > > >>>>>>>> Cc: speermint@ietf.org > > > > >>>>>>>> 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=20 > > > > >>>>>>>> that > > > > >>>> handle > > > > >>>>>>> HTTP > > > > >>>>>>>> load, and I don't see any reason we shouldn't=20 > use all of=20 > > > > >>>>>>>> those techniques to deal with SIP load. I certainly=20 > > > > >>>>>>>> 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=20 > > > > >>>>>>>> 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=20 > > > > >>>>>>>> problem > > > > >>>> (gateway > > > > >>>>>>>> selection, see TRIP), and we found it was not=20 > needed (or=20 > > > > >>>>>>>> at > > > > >>>> least > > > > >>>>> the > > > > >>>>>>>> complexity it introduced was not worth the value > > > it provided). > > > > >>>>>>>> > > > > >>>>>>>> Brian > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>>> -----Original Message----- > > > > >>>>>>>>> From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > > >>>>>>>>> Sent: Friday, August 04, 2006 9:59 AM > > > > >>>>>>>>> To: 'Brian Rosen'; 'Michael Hammer=20 > (mhammer)'; 'Hadriel > > > > >>>> Kaplan' > > > > >>>>>>>>> Cc: speermint@ietf.org > > > > >>>>>>>>> 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=20 > provisioned, and > > > > >>>> partially > > > > >>>>>>>>> discovered. The discovery aspects are the=20 > 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=20 > > > > >>>>>>>>> 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=20 > equivalent to > > > > >>>> "circuit > > > > >>>>>>>> service > > > > >>>>>>>>> state", which might be embodied as a call=20 > 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=20 > > > > >>>>>>>>> domains > > > > >>>> are > > > > >>>>>>>>> amorphous > > > > >>>>>>>>> and have very unpredictable intersection points. > > > This is why > > > > >>>> BGP > > > > >>>>> was > > > > >>>>>>>>> invented for routing IP packets. The same is true for=20 > > > > >>>>>>>>> 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=20 > protocol=20 > > > > >>>>>>>>> is > > > > >>>> required > > > > >>>>>>>> here. > > > > >>>>>>>>> In #3 -- congestion -- is dynamic and not > > > provisionable. It > > > > >>>>>>>>> is > > > > >>>>>>>> directly > > > > >>>>>>>>> related to #2, and the congestion detection and=20 > > > > >>>>>>>>> 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:br@brianrosen.net] > > > > >>>>>>>>> Sent: Friday, August 04, 2006 8:47 AM > > > > >>>>>>>>> To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan' > > > > >>>>>>>>> Cc: speermint@ietf.org > > > > >>>>>>>>> Subject: RE: [Speermint] Secure RTP > > > > >>>>>>>>> > > > > >>>>>>>>> I think you have to be careful with the "p" word. > > > > >>>>>>>>> > > > > >>>>>>>>> I don't see the purpose in standardizing=20 > mechanisms for=20 > > > > >>>>>>>>> peers > > > > >>>>> within > > > > >>>>>>> a > > > > >>>>>>>>> peering federation to discover policies that apply to=20 > > > > >>>>>>>>> each > > > > >>>> other. > > > > >>>>>>>> That is > > > > >>>>>>>>> provisioning, and there is usually not a lot=20 > 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=20 > > > > >>>>>>>>> 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=20 > B. This=20 > > > > >>>>>>>>> is not > > > > >>>> a > > > > >>>>>>>> protocol > > > > >>>>>>>>> issue, but it is what you would expect to=20 > 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,=20 > and again,=20 > > > > >>>>>>>>> we > > > > >>>> don't > > > > >>>>> need > > > > >>>>>>>>> automatic provisioning mechanisms to discover these. =20 > > > > >>>>>>>>> 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)=20 > > > > >>>>>>>>>> [mailto:mhammer@cisco.com] > > > > >>>>>>>>>> Sent: Thursday, August 03, 2006 3:13 PM > > > > >>>>>>>>>> To: Hadriel Kaplan; Brian Rosen > > > > >>>>>>>>>> Cc: speermint@ietf.org > > > > >>>>>>>>>> Subject: RE: [Speermint] Secure RTP > > > > >>>>>>>>>> > > > > >>>>>>>>>> The focus of Speermint should be centered around=20 > > > > >>>>>>>>>> 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=20 > communication=20 > > > > >>>>>>>>>> with > > > > >>>>> that > > > > >>>>>>>> peer. > > > > >>>>>>>>>> It is not about specifying X, Y, Z, or > > your favorite > > > > >>>> MUST > > > > >>>>>>>> here> > > > > >>>>>>>>>> Is is about whether the policy can be stated so one=20 > > > > >>>>>>>>>> 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 > > > > >>>>> Speermint@ietf.org > > > > >>>>> https://www1.ietf.org/mailman/listinfo/speermint > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> Speermint mailing list > > > > >> Speermint@ietf.org > > > > >> https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 15 09:13:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCyjT-0000a5-Iq; Tue, 15 Aug 2006 09:13:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCyjS-0000ZK-Lw for speermint@ietf.org; Tue, 15 Aug 2006 09:13:22 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCyjR-0001lB-C7 for speermint@ietf.org; Tue, 15 Aug 2006 09:13:22 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 15 Aug 2006 06:11:41 -0700 X-IronPort-AV: i="4.08,125,1154934000"; d="scan'208"; a="577542571:sNHT34872704" x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Congestion and Load Balancing Date: Tue, 15 Aug 2006 09:13:20 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C28051835BE@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Speermint] Congestion and Load Balancing Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAJXwqsAAAYEAA From: "Reinaldo Penno" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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:mhammer@cisco.com] > Sent: Monday, August 14, 2006 12:14 PM > To: Brian Rosen; Patrick Melampy; Klaus Darilion > Cc: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing >=20 > Brian, >=20 > 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. >=20 > 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. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, August 09, 2006 5:38 PM > > To: Michael Hammer (mhammer); 'Patrick Melampy'; 'Klaus Darilion' > > Cc: speermint@ietf.org > > 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 Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 15 10:27:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCzqN-00030A-CA; Tue, 15 Aug 2006 10:24:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCzqM-000305-ET for speermint@ietf.org; Tue, 15 Aug 2006 10:24:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCzqM-0007mP-CE for speermint@ietf.org; Tue, 15 Aug 2006 10:24:34 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCzqD-0008M3-41 for speermint@ietf.org; Tue, 15 Aug 2006 10:24:34 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 15 Aug 2006 07:22:45 -0700 X-IronPort-AV: i="4.08,127,1154934000"; d="scan'208"; a="571821301:sNHT34117148" x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [Speermint] Congestion and Load Balancing Date: Tue, 15 Aug 2006 10:24:23 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C28051835F2@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Congestion and Load Balancing Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAJXwqsAABf8PwAAFHLRAAABbT8A== From: "Reinaldo Penno" To: , "Brian Rosen" X-Spam-Score: -1.8 (-) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >From RFC3198 "$ policy (P) "Policy" can be defined from two perspectives: - A definite goal, course or method of action to guide and determine present and future decisions. "Policies" are implemented or executed within a particular context (such as policies defined within a business unit). - Policies as a set of rules to administer, manage, and control access to network resources [RFC3060]. Westerinen, et al. Informational [Page 7] RFC 3198 Terminology for Policy-Based Management November 2001 Note that these two views are not contradictory since individual rules may be defined in support of business goals. (See also "policy goal", "policy abstraction" and "policy rule".)" > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, August 15, 2006 6:50 AM > To: Reinaldo Penno; 'Michael Hammer (mhammer)'; 'Patrick Melampy'; 'Klaus > Darilion' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing >=20 > I think you walk before you run. >=20 > We start with really simple mechanisms that have the desirable > characteristic that they work for the actual problem at hand now, and then > as time evolves, the capacity issues and complexity issues will expand, > and > the solutions need to expand. >=20 > It is not at all clear to me that we need to discover policy. We may need > to discover state (like failure or congestion state), but I see policy as > relatively static. As I said before, I'm not opposed to discovering > policy > as opposed to provisioning it, but I don't think it's at all dynamic. It > changes over periods of months, not milliseconds. >=20 > I don't think we are chartered to do anything approaching SIP BGP >=20 > Brian >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Tuesday, August 15, 2006 9:10 AM > > To: Michael Hammer (mhammer); Brian Rosen; Patrick Melampy; Klaus > Darilion > > Cc: speermint@ietf.org > > 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 > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 15 12:24:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD1iA-0005eH-BL; Tue, 15 Aug 2006 12:24:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD1i9-0005e4-4z for speermint@ietf.org; Tue, 15 Aug 2006 12:24:13 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD1i5-0006WN-Pa for speermint@ietf.org; Tue, 15 Aug 2006 12:24:13 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k7FGO51x026298; Tue, 15 Aug 2006 09:24:05 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k7FGO5pO026297; Tue, 15 Aug 2006 09:24:05 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 15 Aug 2006 09:24:04 -0700 From: David Meyer To: Otmar Lendl Message-ID: <20060815162404.GA26238@1-4-5.net> References: <20060811214951.GM19113@nic.at> Mime-Version: 1.0 In-Reply-To: <20060811214951.GM19113@nic.at> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 1.1 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: speermint Subject: [Speermint] Re: More comments on draft-ietf-speermint-terminology X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2101285409==" Errors-To: speermint-bounces@ietf.org --===============2101285409== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable OK, see http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-04.txt A couple of notes: > I'd use "Call Addressing Data" for your definition of CRD. =20 I have so far resisted this. > As the term Service Provider (SP) doesn't indicate whether we're > talking about Layer3 or Layer5 services, I propose that we use >=20 > ISP: the SP which provides Layer 3 services (IP connectivity) > VSP: the SP which provides Layer 5 services (SIP service) > > That leaves us to define terms to distinguish between L3/L5 integrated > SP vs. L5 only VSPs and open vs. closed ones. >=20 > What about "IVSP" for L3/L5 Integrated VoIP Service Provider? > We could then call VSPs which are not IVSPs (the vonage model) "nIVSP" > for non-integrated VSP. >=20 > Regarding reachability via the Internet, I propose to use=20 > "open VSPs" versus "closed VSPs". I've also (so far) resisted all of this terminology. My sense is that this is way too complicated for what we want to achieve. I'd be interested in what the WG thinks... --dmm --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFE4fUkORgD1qCZ2KcRAlY0AJsGQGM7ujjBtpCPTaHU00XNMaAf/QCfQcz/ GF14hxY3NhIIFB2iizf7vR8= =v/2T -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- --===============2101285409== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============2101285409==-- From speermint-bounces@ietf.org Tue Aug 15 12:43:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD208-0002uf-8C; Tue, 15 Aug 2006 12:42:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD206-0002te-OS for speermint@ietf.org; Tue, 15 Aug 2006 12:42:46 -0400 Received: from outbound-ash.frontbridge.com ([206.16.192.249] helo=outbound1-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD202-0007Wg-D9 for speermint@ietf.org; Tue, 15 Aug 2006 12:42:46 -0400 Received: from outbound1-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-ash-R.bigfish.com (Postfix) with ESMTP id 194A911C4342 for ; Tue, 15 Aug 2006 16:42:27 +0000 (UTC) Received: from mail39-ash-R.bigfish.com (unknown [172.18.2.3]) by outbound1-ash.bigfish.com (Postfix) with ESMTP id 106B511C433D for ; Tue, 15 Aug 2006 16:42:27 +0000 (UTC) Received: from mail39-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail39-ash-R.bigfish.com (Postfix) with ESMTP id 042FD74A5F2 for ; Tue, 15 Aug 2006 16:42:27 +0000 (UTC) X-BigFish: V Received: by mail39-ash (MessageSwitch) id 1155659943675199_1362; Tue, 15 Aug 2006 16:39:03 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail39-ash.bigfish.com (Postfix) with ESMTP id 895BC744C2E for ; Tue, 15 Aug 2006 16:39:03 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k7FGd35F001393 for ; Tue, 15 Aug 2006 11:39:03 -0500 (CDT) Received: from plswg03a.ad.sprint.com (PLSWG03A.corp.sprint.com [10.214.11.49]) by mailhost.sprintspectrum.com (Switch-3.2.3/Switch-3.2.3) with ESMTP id k7FGd0iL024701 for ; Tue, 15 Aug 2006 11:39:00 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg03a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 11:39:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Congestion and Load Balancing Date: Tue, 15 Aug 2006 11:38:59 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A1302C73AAD@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Congestion and Load Balancing Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAJXwqsAAAYEAAAAbFDGA= From: "Khan, Sohel Q [CTO]" To: X-OriginalArrivalTime: 15 Aug 2006 16:39:00.0669 (UTC) FILETIME=[4FB0FED0:01C6C089] X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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.=20 -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Tuesday, August 15, 2006 8:13 AM To: speermint@ietf.org 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:mhammer@cisco.com] > Sent: Monday, August 14, 2006 12:14 PM > To: Brian Rosen; Patrick Melampy; Klaus Darilion > Cc: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing >=20 > Brian, >=20 > 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=20 > congestion path. >=20 > 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=20 > made. And I am pretty sure that the control software in switches is=20 > running code. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, August 09, 2006 5:38 PM > > To: Michael Hammer (mhammer); 'Patrick Melampy'; 'Klaus Darilion' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Congestion and Load Balancing > > > > Please don't get me started on the IETF's abandonment of its belief=20 > > in running code. > > > > While occasionally we actually just document something that exists,=20 > > we usually end up extending somewhat from something we know works. =20 > > We have pretty bad experience inventing major new functionality=20 > > ESPECIALLY IN CONGESTION CONTROL, and seeing it work. It almost=20 > > never does. > > > > So, sure, we can invent some new stuff, as long as it is some=20 > > 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=20 > > bunch of text to tweak as we gain some implementation experience,=20 > > but we know it will work. > > > > I'm not aware of any work in this area we know works we can build=20 > > from. Can you cite some? > > > > I'm not particularly opposed to having discovery mechanisms for=20 > > proxy domain names, call rates and bandwidth limits rather than=20 > > provisioning. I'm skeptical they would be used, but it's simple=20 > > enough. I am opposed to trying to say that info varies from call to > > call, but something faster than a contract negotiation does seem=20 > > practical. > > > > That's a far cry from anything we would consider to be dynamic=20 > > congestion control. > > > > Brian > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 15 14:28:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3eV-0002Lr-Hd; Tue, 15 Aug 2006 14:28:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3eU-0002LS-9j for speermint@ietf.org; Tue, 15 Aug 2006 14:28:34 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound2-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD3eR-0005Pt-Sr for speermint@ietf.org; Tue, 15 Aug 2006 14:28:34 -0400 Received: from outbound2-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-cpk-R.bigfish.com (Postfix) with ESMTP id 970164F48CD; Tue, 15 Aug 2006 18:26:44 +0000 (UTC) Received: from mail43-cpk-R.bigfish.com (unknown [192.168.21.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound2-cpk.bigfish.com (Postfix) with ESMTP id 7E0A14F75C6; Tue, 15 Aug 2006 18:26:43 +0000 (UTC) Received: from mail43-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail43-cpk-R.bigfish.com (Postfix) with ESMTP id 1B37F523E81; Tue, 15 Aug 2006 18:26:43 +0000 (UTC) X-BigFish: V Received: by mail43-cpk (MessageSwitch) id 1155666019537499_30291; Tue, 15 Aug 2006 18:20:19 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail43-cpk.bigfish.com (Postfix) with ESMTP id 59B36546CBF; Tue, 15 Aug 2006 18:20:19 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k7FIKIqd019657; Tue, 15 Aug 2006 13:20:18 -0500 (CDT) Received: from plswg01a.ad.sprint.com (PLSWG01A.corp.sprint.com [10.214.11.47]) by mailhost.sprintspectrum.com (Switch-3.2.3/Switch-3.2.3) with ESMTP id k7FIKHUj011072; Tue, 15 Aug 2006 13:20:18 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg01a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 13:20:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: More comments on draft-ietf-speermint-terminology Date: Tue, 15 Aug 2006 13:20:22 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A1302D12481@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: More comments on draft-ietf-speermint-terminology Thread-Index: AcbAh2tiGLhQj8loQnagkqPtpVb5FAAD6x8Q From: "Khan, Sohel Q [CTO]" To: "David Meyer" X-OriginalArrivalTime: 15 Aug 2006 18:20:17.0733 (UTC) FILETIME=[75E75F50:01C6C097] X-Spam-Score: 1.2 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org In Section 6.1 Federation Functionality Can subscriber database and application servers be added? A group of providers may use a set of common subscriber database and application servers. Sohel =20 -----Original Message----- From: David Meyer [mailto:dmm@1-4-5.net]=20 Sent: Tuesday, August 15, 2006 11:24 AM To: Otmar Lendl Cc: speermint Subject: [Speermint] Re: More comments on draft-ietf-speermint-terminology OK, see =09 http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-04.txt A couple of notes: > I'd use "Call Addressing Data" for your definition of CRD. =20 I have so far resisted this. > As the term Service Provider (SP) doesn't indicate whether we're=20 > talking about Layer3 or Layer5 services, I propose that we use >=20 > ISP: the SP which provides Layer 3 services (IP connectivity) > VSP: the SP which provides Layer 5 services (SIP service) > > That leaves us to define terms to distinguish between L3/L5 integrated > SP vs. L5 only VSPs and open vs. closed ones. >=20 > What about "IVSP" for L3/L5 Integrated VoIP Service Provider? > We could then call VSPs which are not IVSPs (the vonage model) "nIVSP" > for non-integrated VSP. >=20 > Regarding reachability via the Internet, I propose to use "open VSPs"=20 > versus "closed VSPs". I've also (so far) resisted all of this terminology. My sense is that this is way too complicated for what we want to achieve. I'd be interested in what the WG thinks... --dmm _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 15 14:48:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3wo-0007wN-IR; Tue, 15 Aug 2006 14:47:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3wn-0007w7-J2 for speermint@ietf.org; Tue, 15 Aug 2006 14:47:29 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=MAILSRV01.cedarpointcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD3wl-0006XL-1I for speermint@ietf.org; Tue, 15 Aug 2006 14:47:29 -0400 Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 14:47:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Congestion and Load Balancing Date: Tue, 15 Aug 2006 14:47:18 -0400 Message-ID: <402F25FC1EB2BD44831F8A4A4F6DF9421D6AD2@MAIL02.cedarpointcom.com> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C28051835BE@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Congestion and Load Balancing Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAJXwqsAAAYEAAAArFs9A= From: "Geoff Devine" To: "Reinaldo Penno" , X-OriginalArrivalTime: 15 Aug 2006 18:47:26.0041 (UTC) FILETIME=[40737490:01C6C09B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I think this is indeed a problem that needs to be solved and I agree with the middle ground approach. In my opinion, the proper approach is to define an XML-based event package to signal congestion attributes via SUBSCRIBE/NOTIFY. =20 These attributes would be: * supported connection/call rate, perhaps in units of calls per second * total number of connections/calls available * current utilization A peering point in the network could assert flow control by dynamically sending a NOTIFY lowering the call/connection rate. It could also choose to dynamically shrink the "size of the pipe" by lowering the total number of connections/calls available. This is analogous to busying out a CIC in the SS#7 ISUP world. Bear in mind that my agenda is to solve the problem of using remote media gateway resources in the federation. These are finite resources that you expect to run out at peak busy hour. You don't want to run your peering federation without congestion control since it makes the network unstable by injecting end-to-end work at peak busy hour that doesn't complete. Your media gateway controllers won't be able to keep up with the remote signaling traffic. =20 There are a number of possible architectures and topologies that could make use of this sort of mechanism. Rather than argue over which architecture or topology is best, I'd rather take the pragmatic approach and create the interface to extract the information to implement congestion control over SIP as the first step. Geoff -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Tuesday, August 15, 2006 9:13 AM To: speermint@ietf.org 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:mhammer@cisco.com] > Sent: Monday, August 14, 2006 12:14 PM > To: Brian Rosen; Patrick Melampy; Klaus Darilion > Cc: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing >=20 > Brian, >=20 > 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. >=20 > 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. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, August 09, 2006 5:38 PM > > To: Michael Hammer (mhammer); 'Patrick Melampy'; 'Klaus Darilion' > > Cc: speermint@ietf.org > > 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 Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 15 16:26:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD5UW-0003kn-9M; Tue, 15 Aug 2006 16:26:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD5UU-0003kO-P9 for speermint@ietf.org; Tue, 15 Aug 2006 16:26:22 -0400 Received: from outbound-res.frontbridge.com ([63.161.60.49] helo=outbound1-res-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD5US-0006i4-Eh for speermint@ietf.org; Tue, 15 Aug 2006 16:26:22 -0400 Received: from outbound1-res.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-res-R.bigfish.com (Postfix) with ESMTP id 99B33A89F2D; Tue, 15 Aug 2006 20:25:05 +0000 (UTC) Received: from mail58-res-R.bigfish.com (unknown [172.18.16.1]) by outbound1-res.bigfish.com (Postfix) with ESMTP id 91A51A89E1D; Tue, 15 Aug 2006 20:25:05 +0000 (UTC) Received: from mail58-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail58-res-R.bigfish.com (Postfix) with ESMTP id 85BE596A8D7; Tue, 15 Aug 2006 20:25:05 +0000 (UTC) X-BigFish: V Received: by mail58-res (MessageSwitch) id 1155667314283177_1200; Tue, 15 Aug 2006 18:41:54 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail58-res.bigfish.com (Postfix) with ESMTP id 30B0596D49D; Tue, 15 Aug 2006 18:41:54 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k7FIfrJw001676; Tue, 15 Aug 2006 13:41:53 -0500 (CDT) Received: from plswg02a.ad.sprint.com (PLSWG02A.corp.sprint.com [10.214.11.48]) by mailhost.sprintspectrum.com (Switch-3.2.3/Switch-3.2.3) with ESMTP id k7FIeRGW021714; Tue, 15 Aug 2006 13:40:27 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg02a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 13:40:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: More comments on draft-ietf-speermint-terminology Date: Tue, 15 Aug 2006 13:40:32 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A1302D12547@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: More comments on draft-ietf-speermint-terminology Thread-Index: AcbAh2tiGLhQj8loQnagkqPtpVb5FAAEhAcQ From: "Khan, Sohel Q [CTO]" To: "David Meyer" X-OriginalArrivalTime: 15 Aug 2006 18:40:27.0471 (UTC) FILETIME=[46F6BDF0:01C6C09A] X-Spam-Score: 1.2 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 In figure 1, the SPEERMINT Working group scope is defined as follows: | SPEERMINT Working Group Scope | SIP URI <--- Call Routing Data (CRD) | | | <--- Federation Detection, Policy | Lookup, and Service Location | | Hostname <--- Addressing and session establishment | | SPEERMINT Working Group Scope The CRD and Federation terms are well defined in the current draft. The other terms "policy", "service location", and "addressing and session establishment" are not well defined. May be we need three more sections to define these terms and re-arrange all the terms of the draft as above figure scope. Thanks, Sohel -----Original Message----- From: David Meyer [mailto:dmm@1-4-5.net]=20 Sent: Tuesday, August 15, 2006 11:24 AM To: Otmar Lendl Cc: speermint Subject: [Speermint] Re: More comments on draft-ietf-speermint-terminology OK, see =09 http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-04.txt A couple of notes: > I'd use "Call Addressing Data" for your definition of CRD. =20 I have so far resisted this. > As the term Service Provider (SP) doesn't indicate whether we're=20 > talking about Layer3 or Layer5 services, I propose that we use >=20 > ISP: the SP which provides Layer 3 services (IP connectivity) > VSP: the SP which provides Layer 5 services (SIP service) > > That leaves us to define terms to distinguish between L3/L5 integrated > SP vs. L5 only VSPs and open vs. closed ones. >=20 > What about "IVSP" for L3/L5 Integrated VoIP Service Provider? > We could then call VSPs which are not IVSPs (the vonage model) "nIVSP" > for non-integrated VSP. >=20 > Regarding reachability via the Internet, I propose to use "open VSPs"=20 > versus "closed VSPs". I've also (so far) resisted all of this terminology. My sense is that this is way too complicated for what we want to achieve. I'd be interested in what the WG thinks... --dmm _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 15 19:17:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD89O-0000vs-7C; Tue, 15 Aug 2006 19:16:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD88e-0000gh-S6 for speermint@ietf.org; Tue, 15 Aug 2006 19:16:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD5Q7-0005Sq-Ad for speermint@ietf.org; Tue, 15 Aug 2006 16:21:51 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GD5Bk-0007XV-9k for speermint@ietf.org; Tue, 15 Aug 2006 16:07:07 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 0C6651A395; Tue, 15 Aug 2006 22:06:47 +0200 (CEST) Date: Tue, 15 Aug 2006 22:06:47 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Re: More comments on draft-ietf-speermint-terminology Message-ID: <20060815200647.GO19113@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <20060811214951.GM19113@nic.at> <20060815162404.GA26238@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060815162404.GA26238@1-4-5.net> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: -1.6 (-) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/08/15 18:08, David Meyer wrote: > > > As the term Service Provider (SP) doesn't indicate whether we're > > talking about Layer3 or Layer5 services, I propose that we use > > > > ISP: the SP which provides Layer 3 services (IP connectivity) > > VSP: the SP which provides Layer 5 services (SIP service) > > > > That leaves us to define terms to distinguish between L3/L5 integrated > > SP vs. L5 only VSPs and open vs. closed ones. > > > > What about "IVSP" for L3/L5 Integrated VoIP Service Provider? > > We could then call VSPs which are not IVSPs (the vonage model) "nIVSP" > > for non-integrated VSP. > > > > Regarding reachability via the Internet, I propose to use > > "open VSPs" versus "closed VSPs". > > I've also (so far) resisted all of this terminology. > My sense is that this is way too complicated for what we > want to achieve. We could well do without that. I didn't quite grasp what you tried to express with the definitions of VSP vs. SP in -02. That's why I tried to clarify and describe how I'd categorize service providers. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 16 08:57:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDKxZ-0001sY-TL; Wed, 16 Aug 2006 08:57:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDKxZ-0001sT-0G for speermint@ietf.org; Wed, 16 Aug 2006 08:57:25 -0400 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDKxV-0007Jn-OR for speermint@ietf.org; Wed, 16 Aug 2006 08:57:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Aug 2006 08:56:51 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD1A6411@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FYI: Mailing List Posting Sizes / Moderator Queues Thread-Index: AcbBM3EdchhgFr/oS3OvAWtAciCsXg== From: "Livingood, Jason" To: X-OriginalArrivalTime: 16 Aug 2006 12:56:51.0624 (UTC) FILETIME=[715FE280:01C6C133] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Speermint] FYI: Mailing List Posting Sizes / Moderator Queues X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Several people replying to an exceptionally long thread may have noticed their messages not showing up on the list immediately. That is because the size of the messages has been exceeding the maximum allowed for unmoderated posts. Thus, these posts show up in a daily moderator queue for approval. =20 When replying to a thread, please reply to the sections you need and delete the rest. There is no need for messages to exceed 50KB as one of the recent threads has, when you see that 95% of the messages is just getting carried along for no reason. Thanks Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 16 09:01:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDL1S-00030E-Ow; Wed, 16 Aug 2006 09:01:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDL1Q-000302-JK for speermint@ietf.org; Wed, 16 Aug 2006 09:01:24 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDL1O-00083z-A1 for speermint@ietf.org; Wed, 16 Aug 2006 09:01:24 -0400 Received: from ([10.20.62.12]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.23299703; Wed, 16 Aug 2006 09:00:17 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 09:00:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: More comments on draft-ietf-speermint-terminology Date: Wed, 16 Aug 2006 09:00:20 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD1A6412@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: More comments on draft-ietf-speermint-terminology Thread-Index: AcbAh2tiGLhQj8loQnagkqPtpVb5FAAEhAcQACaJ6dA= From: "Livingood, Jason" To: "Khan, Sohel Q [CTO]" , "David Meyer" X-OriginalArrivalTime: 16 Aug 2006 13:00:20.0724 (UTC) FILETIME=[EE020340:01C6C133] X-Spam-Score: 1.1 (+) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Maybe I missed the earlier discussion, but I don't think a URI constitues "routing" data at all. Isn't a URI better described as "addressing" data? Then you take the addressing data to figure out where to route, by consulting other sources (IP routes, etc.). This addressing data is sometimes called location information in the ENUM WG. Once you know the location, then you figure out the route... Jason=20 > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com]=20 > Sent: Tuesday, August 15, 2006 2:41 PM > To: David Meyer > Cc: speermint > Subject: RE: [Speermint] Re: More comments on=20 > draft-ietf-speermint-terminology >=20 > =20 > In figure 1, the SPEERMINT Working group scope is defined as follows: > | SPEERMINT Working Group Scope > | > SIP URI <--- Call Routing Data (CRD) > | > | > | <--- Federation Detection, Policy > | Lookup, and Service Location > | > | > Hostname <--- Addressing and session establishment > | > | SPEERMINT Working Group Scope >=20 >=20 > The CRD and Federation terms are well defined in the current draft. > The other terms "policy", "service location", and "addressing=20 > and session establishment" are not well defined. > May be we need three more sections to define these terms and=20 > re-arrange all the terms of the draft as above figure scope. >=20 > Thanks, >=20 > Sohel >=20 > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net] > Sent: Tuesday, August 15, 2006 11:24 AM > To: Otmar Lendl > Cc: speermint > Subject: [Speermint] Re: More comments on=20 > draft-ietf-speermint-terminology >=20 > OK, see >=20 > =09 > http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-04.txt >=20 > A couple of notes: >=20 > > I'd use "Call Addressing Data" for your definition of CRD. > =20 > I have so far resisted this. >=20 > > As the term Service Provider (SP) doesn't indicate whether we're=20 > > talking about Layer3 or Layer5 services, I propose that we use > >=20 > > ISP: the SP which provides Layer 3 services (IP connectivity) > > VSP: the SP which provides Layer 5 services (SIP service) > > > > That leaves us to define terms to distinguish between L3/L5=20 > integrated >=20 > > SP vs. L5 only VSPs and open vs. closed ones. > >=20 > > What about "IVSP" for L3/L5 Integrated VoIP Service Provider? > > We could then call VSPs which are not IVSPs (the vonage=20 > model) "nIVSP" > > for non-integrated VSP. > >=20 > > Regarding reachability via the Internet, I propose to use=20 > "open VSPs"=20 > > versus "closed VSPs". >=20 > I've also (so far) resisted all of this terminology. > My sense is that this is way too complicated for what we > want to achieve. >=20 > I'd be interested in what the WG thinks... >=20 > --dmm >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 16 09:01:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDL1l-00037J-0T; Wed, 16 Aug 2006 09:01:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDL1j-000379-VF for speermint@ietf.org; Wed, 16 Aug 2006 09:01:43 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDL1i-00089l-OH for speermint@ietf.org; Wed, 16 Aug 2006 09:01:43 -0400 Received: from ([10.20.62.13]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.23403766; Wed, 16 Aug 2006 09:01:26 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 09:01:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: More comments on draft-ietf-speermint-terminology Date: Wed, 16 Aug 2006 09:01:25 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD1A6413@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: More comments on draft-ietf-speermint-terminology Thread-Index: AcbAh3/hgk2Ih5PqRpuUVw7OqGXuRAArHdWg From: "Livingood, Jason" To: "David Meyer" , "Otmar Lendl" X-OriginalArrivalTime: 16 Aug 2006 13:01:25.0484 (UTC) FILETIME=[149B9AC0:01C6C134] X-Spam-Score: 1.1 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > > That leaves us to define terms to distinguish between L3/L5=20 > integrated=20 > > SP vs. L5 only VSPs and open vs. closed ones. > >=20 > > What about "IVSP" for L3/L5 Integrated VoIP Service Provider? > > We could then call VSPs which are not IVSPs (the vonage=20 > model) "nIVSP" > > for non-integrated VSP. > >=20 > > Regarding reachability via the Internet, I propose to use=20 > "open VSPs"=20 > > versus "closed VSPs". >=20 > I've also (so far) resisted all of this terminology. > My sense is that this is way too complicated for what we > want to achieve. >=20 > I'd be interested in what the WG thinks... That seems like unnecessary splitting of hairs... And the definition of closed and open is all relative anyway. We should keep it simple... Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 16 09:36:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDLYa-0005b4-TH; Wed, 16 Aug 2006 09:35:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDLYZ-0005aG-Gy for speermint@ietf.org; Wed, 16 Aug 2006 09:35:39 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDLYY-0001lq-5e for speermint@ietf.org; Wed, 16 Aug 2006 09:35:39 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GDLYS-0001LP-ER; Wed, 16 Aug 2006 08:35:33 -0500 From: "Brian Rosen" To: "'Reinaldo Penno'" Subject: FW: [Speermint] Congestion and Load Balancing Date: Wed, 16 Aug 2006 09:35:31 -0400 Message-ID: <097001c6c138$db6d98c0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAJXwqsAABf8PwAACk4nAAMGma0AAA3fsg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, August 16, 2006 9:14 AM To: 'Reinaldo Penno'; 'Michael Hammer (mhammer)'; 'Patrick Melampy'; 'Klaus Darilion' Cc: 'speermint@ietf.org' Subject: RE: [Speermint] Congestion and Load Balancing Right at the moment, I think policy is so static it could be provisioned, but I'm not against discovery. I don't think we have any experience with "state" that could reasonably defined in a BCP (and I think that is the basic document this group is supposed to create). Specifically, any kind of SIP change, which would include an event notification package, is subject to the sip change process, and thus needs a trip through SIPPING, and probably SIP. I don't think we should go there now. Maybe, after the current overload work is completed in SIP, we can decide if that is sufficient, or needs some applicability guidance, or extension for the peering case. Brian > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, August 15, 2006 10:14 AM > To: Brian Rosen; Michael Hammer (mhammer); Patrick Melampy; Klaus Darilion > Cc: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing > > Okay, let's get our nomenclature aligned. > > Policy - changes in a period >> than state > > State - attributes about the layer 5 peering that could potentially > change from one call to the other. > > Now, you agree we should discover state and policy (although policy is > more static in nature). Although the timescales are different, should > the same method be used for both or not? > > Policy could potentially be discovered through configuration (triggered > by contract), DNS, SIP, etc. > > State on the other hand needs a mechanism that allows the update (by the > "owner") and queries (by others) quite frequently. > > Is this okay? > > Regards, > > Reinaldo > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, August 15, 2006 6:50 AM > > To: Reinaldo Penno; 'Michael Hammer (mhammer)'; 'Patrick Melampy'; > 'Klaus > > Darilion' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Congestion and Load Balancing > > > > I think you walk before you run. > > > > We start with really simple mechanisms that have the desirable > > characteristic that they work for the actual problem at hand now, and > then > > as time evolves, the capacity issues and complexity issues will > expand, > > and > > the solutions need to expand. > > > > It is not at all clear to me that we need to discover policy. We may > need > > to discover state (like failure or congestion state), but I see policy > as > > relatively static. As I said before, I'm not opposed to discovering > > policy > > as opposed to provisioning it, but I don't think it's at all dynamic. > It > > changes over periods of months, not milliseconds. > > > > I don't think we are chartered to do anything approaching SIP BGP > > > > Brian > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Sent: Tuesday, August 15, 2006 9:10 AM > > > To: Michael Hammer (mhammer); Brian Rosen; Patrick Melampy; Klaus > > Darilion > > > Cc: speermint@ietf.org > > > 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 > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 16 09:36:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDLZS-0006DY-Ae; Wed, 16 Aug 2006 09:36:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDLZR-0006BZ-Ep for speermint@ietf.org; Wed, 16 Aug 2006 09:36:33 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDLZM-0001oP-Uj for speermint@ietf.org; Wed, 16 Aug 2006 09:36:33 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GDLZH-0001P8-Eq; Wed, 16 Aug 2006 08:36:24 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" Subject: Re: [Speermint] Congestion and Load Balancing Date: Wed, 16 Aug 2006 09:36:24 -0400 Message-ID: <097101c6c138$f9acab50$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAA/o7gAAA6O7wACVZhwAALff3oAAAvtKQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I believe you can limit the total bandwidth into the peering system by contract, and you can limit the bandwidth between two peers by contract, and that is enough, for now. I don't think we have any problems building peering systems that can do that, and work satisfactorily. Yes I DO think that the media limit is the actual limit, but again, I think that is a simple bandwidth calculation, and primarily a between-two-peers number that could be governed by the peering system agreements or a bilateral agreement. I do think statistics plays a role (you "overprovision"), but it always has in telephone engineering. The difference between VoIP and TDM is the 3 or 4 order of magnitude difference in call capacity for a single signaling element, and the roughly 2-3 order of magnitude difference in engineered "media" capacity. Where in a telephone system, you have a DS0 or two to a residence, you have 500K to a meg. Where typically you have some number of OC-3s between a central office and a tandem, you have a gig. Where tandem networks are typically 155 or at best 522, you have 10G. I think it's not hard to make it possible to avoid blocking on anything except the actual destination resource (which could be a gateway). You can obviously get to enough failures where that doesn't work, and I think BUSY is a satisfactory response in that case. I recognize the issue of cascading 503s to create more problems than they solve. That is the overload work going on. Let it finish, and we'll use it. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, August 15, 2006 11:30 AM > To: Brian Rosen; Patrick Melampy; Klaus Darilion > Cc: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing > > Brain, > > Even within a federation, if you know there are hundreds of peers in > that federation, do you limit each peer to 1/100 of the signaling BW > available at your peering point, or do you monitor how many peers are > loading you with call attempts at the moment and set envelope parameters > accordingly? > > What I was looking for was the ability to throttle back inputs *before* > a signaling message, e.g. INVITE, is sent to the peering point, rather > than reacting to an overload of INVITEs. This mechanism should be a > derivative that looks at acceleration rather than velocity. An "out of > band" mechanism such as a Subscription/Notify mechanism passing policy > information informing a peer of the initial rules about permitted > traffic rate or changes to those rules could be sufficient. Call > gapping effectively does the same thing by limiting the flow of > signaling inputs for periods of time. > > Your bit about engineering probabilities sounds like a euphemistic > phrase for over-provisioning that shifts the bottleneck to being the > media path. I think there is a trade-off economically between > over-provisioning and adding a little more complex controls. > > Mike > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, August 14, 2006 5:43 PM > > To: 'Patrick Melampy'; Michael Hammer (mhammer); 'Klaus Darilion' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Congestion and Load Balancing > > > > I think you need a different work group for a different problem. > > > > I think we have been consistently talking about federations, > > and not adhoc > > routing by individual bilateral peering relationships. This > > is not a BGP > > network. > > > > I think that we will allow transit networks, but I expect them to be > > simplistic and uncommon and if the federations themselves > > don't arrange > > transit among themseleves, one or two carriers will. The > > number of cases > > where there are more than three hops between carriers will be > > small, and > > overoptimizing such cases, especially on first pass, is unwise. > > > > The probability of a transit carrier being a bottleneck is > > just not worth > > spending time on now. It's just too easy to engineer the > > probabilities low > > enough that simple mechanisms suffice. > > > > I keep imagining you think it's hard to build transit > > networks that support > > 400% of the peak busy hour bandwidth between federations with 5 nines > > reliability. I don't see it that way. Certainly, with respect to > > signaling, that is just the kind of normal capacity we create now. > > > > Media could be a different problem, but we agree we aren't > > talking about > > media. > > > > Brian > > > > > > > -----Original Message----- > > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > Sent: Monday, August 14, 2006 5:16 PM > > > To: 'Michael Hammer (mhammer)'; 'Brian Rosen'; 'Klaus Darilion' > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Congestion and Load Balancing > > > > > > Agreed -- lets just focus on signaling. > > > > > > I believe the congestion controls that are required need a > > new name, as > > > its > > > confusing everybody but me. I believe the issue (and I do not have a > > > solution) is introduced when you introduce peering. Thus > > peering will > > > create > > > the need. Let me explain.... > > > > > > Consider VoIP Domains A, B, C, D, E, F, G, and H > > > > > > Lets also assume that somehow they have exchanged > > information such that a > > > network of connectivity has been established. Let me draw it below > > > > > > > > > A---D-----E---+ > > > | | > > > B---C H > > > | | > > > F-----G---+ > > > > > > The above adjacencies and business relationships are all > > established. The > > > list of adjacencies include: > > > > > > A-D > > > D-E > > > D-C > > > B-C > > > C-F > > > F-G > > > E-H > > > G-H > > > > > > It is easy to understand that A can communicate with Domain > > H through D > > > via > > > two paths... > > > > > > 1.) A-D-E-H > > > 2.) A-D-C-F-G-H > > > > > > Domain D has to choose -- which path to take, 1 or 2. > > > > > > Obviously, the best path is out of scope for Speermint, and > > is likely to > > > be > > > based on policy local to domain D. However, Path 1 and Path > > 2 are not > > > limitless, and may experience overload conditions not > > detectable at A or > > > H. > > > For example, What if B had a large volume of traffic > > destined for E or the > > > path was diminished by equipment failures. A and H are not > > be affected, > > > but > > > one of the intermediate domains on one of the paths is. > > > > > > So at the egress of D, Domain D must decide which next hop > > to use. Where > > > will D get information that traffic to E may effect > > choosing a route to > > > take? > > > > > > I believe that one could make really complex examples that > > are indeed very > > > likely. > > > > > > One could argue that service provider peering has forced > > this problem on > > > us, > > > and if we dis-intermediate all of the domains that are not > > terminal, the > > > problem goes away. > > > > > > What we need is a way to report that Path 1 is either down > > or diminished. > > > > > > I have no idea how to make this work just yet. But I think > > we need to > > > explore that fact that disintermediation creates this > > problem, and thus > > > this > > > problem needs to be solved. > > > > > > > > > -----Original Message----- > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > Sent: Monday, August 14, 2006 3:14 PM > > > To: Brian Rosen; Patrick Melampy; Klaus Darilion > > > Cc: speermint@ietf.org > > > 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 > > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 16 09:55:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDLrL-00044X-OE; Wed, 16 Aug 2006 09:55:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDLrJ-000429-Le for speermint@ietf.org; Wed, 16 Aug 2006 09:55:01 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDLrH-0002nT-6z for speermint@ietf.org; Wed, 16 Aug 2006 09:55:01 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GDLrB-0002WP-VM; Wed, 16 Aug 2006 08:54:54 -0500 From: "Brian Rosen" To: "'Khan, Sohel Q [CTO]'" , Subject: RE: [Speermint] Congestion and Load Balancing Date: Wed, 16 Aug 2006 09:54:55 -0400 Message-ID: <097c01c6c13b$8faae250$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <858217C310A3D94182FA8AAE42860A1302C73AAD@PLSWB08C.ad.sprint.com> Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAJXwqsAAAYEAAAAbFDGAALDQlMA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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 > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Tuesday, August 15, 2006 12:39 PM > To: speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing > > > 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:rpenno@juniper.net] > Sent: Tuesday, August 15, 2006 8:13 AM > To: speermint@ietf.org > 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:mhammer@cisco.com] > > Sent: Monday, August 14, 2006 12:14 PM > > To: Brian Rosen; Patrick Melampy; Klaus Darilion > > Cc: speermint@ietf.org > > 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:br@brianrosen.net] > > > Sent: Wednesday, August 09, 2006 5:38 PM > > > To: Michael Hammer (mhammer); 'Patrick Melampy'; 'Klaus Darilion' > > > Cc: speermint@ietf.org > > > 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 > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 16 10:45:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDMda-0002tB-2z; Wed, 16 Aug 2006 10:44:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDMdY-0002qY-Iw for speermint@ietf.org; Wed, 16 Aug 2006 10:44:52 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDMdV-00059Y-8U for speermint@ietf.org; Wed, 16 Aug 2006 10:44:52 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Aug 2006 10:44:49 -0400 X-IronPort-AV: i="4.08,132,1154923200"; d="scan'208"; a="97095958:sNHT31953332" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7GEinCc019848; Wed, 16 Aug 2006 10:44:49 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7GEimdM016477; Wed, 16 Aug 2006 10:44:48 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 10:44:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Congestion and Load Balancing Date: Wed, 16 Aug 2006 10:44:49 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301CE9EE6@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Congestion and Load Balancing Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAJXwqsAAAYEAAAAbFDGAALDQlMAACLLtw From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , X-OriginalArrivalTime: 16 Aug 2006 14:44:48.0894 (UTC) FILETIME=[8620D9E0:01C6C142] DKIM-Signature: a=rsa-sha1; q=dns; l=2978; t=1155739489; x=1156603489; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Congestion=20and=20Load=20Balancing |To:=22Brian=20Rosen=22=20,=20; X=v=3Dcisco.com=3B=20h=3DD+ZIob6N7qWaKrQ323RA13TkaLI=3D; b=rBEYhQRkPqwPfZ0a42djqk4NdKvIutxqg5h6CwUL0QRlnWYCzykceviiqp5Q2KYMME9zi6zq 1BvqwLiusFNLQRxBK0ohesHwIduO8gSyqcSQKhB3tn41lEqIjw2TuzBU; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian, Do we have the same topological picture here? =20 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:br@brianrosen.net]=20 > Sent: Wednesday, August 16, 2006 9:55 AM > To: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing >=20 > I can't imagine any delay through a peering system that could=20 > add up to something an application can detect. It should be=20 > very small. If it's not, get a new peering system, something=20 > is wrong. Most peering is a SIP exchange directly between=20 > the peers (with an ENUM dip and possibly some other simple=20 > database things on the origination side). The transit time=20 > TO the peering point should swamp the actual signaling exchange. >=20 > What kind of "hot spot" could you imagine we could create in=20 > a peering system that was not due to poor engineering? Best=20 > I can do is to force an underpowered SBC to face the peering=20 > network and bottleneck on that. Don't do that. >=20 > People, I think we need to get real here. Let's start=20 > throwing around realistic numbers, and see if they work or=20 > don't. What I see here is telephone engineering numbers in=20 > an IP environment. =20 >=20 > I believe in millions of BHCA between peers, and gigabits of=20 > bandwidth. Is someone believing we are building peering=20 > systems with hundreds of millions of BHCA between a single=20 > pair of peers? Hundreds of gigabits of bandwidth don't seem=20 > to be a problem for a peering system; we can do that with a=20 > single element these days. >=20 > I can imagine we WILL get numbers in the hundreds of millions=20 > of BHCA some day. I don't think we need to worry about that now. >=20 > I can easily see how you can get beyond a single signaling=20 > element facing or within the peering fabric, but I think load=20 > balancing that is pretty straightforward, and doesn't require=20 > much standardization. I don't think you ever create hotspots=20 > in the peering. =20 >=20 > I don't believe in blocking calls before the termination=20 > resource. That may get congested, but then "Busy" is the=20 > appropriate response. =20 >=20 > Brian >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 16 11:12:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDN44-0003El-Vm; Wed, 16 Aug 2006 11:12:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDN43-0003Eg-BS for speermint@ietf.org; Wed, 16 Aug 2006 11:12:15 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDN3y-0006Ls-U2 for speermint@ietf.org; Wed, 16 Aug 2006 11:12:15 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GDN3t-00063n-16; Wed, 16 Aug 2006 10:12:05 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , Subject: RE: [Speermint] Congestion and Load Balancing Date: Wed, 16 Aug 2006 11:12:06 -0400 Message-ID: <099601c6c146$58553b10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301CE9EE6@xmb-rtp-20b.amer.cisco.com> Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAJXwqsAAAYEAAAAbFDGAALDQlMAACLLtwAACvNVA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, August 16, 2006 10:45 AM > To: Brian Rosen; speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing > > 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:br@brianrosen.net] > > Sent: Wednesday, August 16, 2006 9:55 AM > > To: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > 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 Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 16 12:03:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDNra-0005KF-An; Wed, 16 Aug 2006 12:03:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDNrZ-0005K5-J0 for speermint@ietf.org; Wed, 16 Aug 2006 12:03:25 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDNrV-0001EO-TZ for speermint@ietf.org; Wed, 16 Aug 2006 12:03:25 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Aug 2006 09:03:20 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,133,1154934000"; d="scan'208"; a="36517719:sNHT26449364" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7GG3K5b001094; Wed, 16 Aug 2006 12:03:20 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7GG3JuQ022421; Wed, 16 Aug 2006 12:03:20 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 12:03:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Congestion and Load Balancing Date: Wed, 16 Aug 2006 12:03:15 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301CE9F08@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Congestion and Load Balancing Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAJXwqsAAAYEAAAAbFDGAALDQlMAACLLtwAACvNVAAAV0+IA== From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , X-OriginalArrivalTime: 16 Aug 2006 16:03:17.0672 (UTC) FILETIME=[7CC75A80:01C6C14D] DKIM-Signature: a=rsa-sha1; q=dns; l=7481; t=1155744200; x=1156608200; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Congestion=20and=20Load=20Balancing |To:=22Brian=20Rosen=22=20,=20; X=v=3Dcisco.com=3B=20h=3DD+ZIob6N7qWaKrQ323RA13TkaLI=3D; b=Pb9IUWaXKqEdVMeSI4ddvnni27SIN+xYuBksQtHKp+a8MhQJhlcaIndIPDZt5CZIDAA+Nzkb CT+ppCjb51bvAvo45kE5xRYi4762c9ZlzYwnT42ubjiPxqz6qo7Ikqh5; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Inline.=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, August 16, 2006 11:12 AM > To: Michael Hammer (mhammer); speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing >=20 > I think peering is functionally a star: peers have some=20 > collection of elements facing the peering fabric and peering=20 > goes from one edge to the other. The "fabric" may be nothing=20 > but an IP network. It may even be the Internet. There may=20 > or may not be any active element at the hub of the star. If=20 > there is, it's a proxy server. If there isn't, it's just an=20 > IP switch or functional equivalent. OK > If the federation, by contract, limits the total number of=20 > calls towards the fabric from any one peer, and either=20 > federation contract policy or bilateral contract policy=20 > limits traffic between two specific peers, I think we can=20 > create non-blocking peering (or at least non blocking to the=20 > point where the incidence of blocking is low enough that we=20 > can ignore it and busy the call). I think that is sufficient. So, every time there is a new peer we need to renegotiate all contracts? How do we can figure out how much traffic can be exchanged between two peers statically? =20 Then, next question is what factors would cause us to change that? =20 Then, is there any reason this can not be adjusted dynamically? I am not worried about the IP fabric between the peers as that is an IP network congestion problem. My issue is "congestion" at the receiving point. Are we still addressing the same problem? > The SIP overload work is dealing with the 503 issue. I don't=20 > have anything to offer beyond that work, do you? >=20 > I am extremely suspicious of simplistic congestion control=20 > mechanisms that try to push congestion knowledge back earlier=20 > in a network. =20 Are you talking L3 or L5 network congestion here? I was thinking that we are talking about knowledge being passed from one peer to one adjacent peer, that is, only one hop away. > We have LOTS of experience that getting them=20 > right is not easy. Look at the archives on "Explicit=20 > Congestion Notification" in TCP for example. =20 Can you explain the analogy here? Does ECN address pair-wise traffic levels, or is it more concerned with cross-traffic in the fabric between the peers. There are a lot of unkowables in TCP that don't exist in this case. Also, the scale at which TCP needs to operate is much larger. > Unless you can=20 > show me a big network successfully using SUB/NOT to push=20 > congestion state backwards, then I don't believe it will=20 > work. =20 This is an argument that SUB/NOT should not be used for anything the first time. > I guarantee it won't work if it's literally just a=20 > notification to stop: that is, there is no explicit text on=20 > how you control the rate of messages, and how you control the=20 > on/off nature of the mechanism so that it has dampening. =20 > Getting such text right, and behavior right at both ends, is hard. >=20 > Brian I am not saying that it might not be hard, I just don't buy that as a reason for not trying. Imagine if you had said that at the advent of TCP (your words with a few substitutions): "If the *network*, by contract, limits the total number of=20 *packets* towards the fabric from any one peer, and either=20 *network* contract policy or bilateral contract policy=20 limits traffic between two specific peers, I think we can=20 create non-*congestion* peering (or at least non *congestion* to the=20 point where the incidence of *congestion* is low enough that we=20 can ignore it and *reject the traffic*). I think that is sufficient." TCP would not have throttling mechanisms and offered traffic would be statically limited. Mike >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Wednesday, August 16, 2006 10:45 AM > > To: Brian Rosen; speermint@ietf.org > > Subject: RE: [Speermint] Congestion and Load Balancing > >=20 > > Brian, > >=20 > > Do we have the same topological picture here? > >=20 > > Your words suggest peering is 1-1 with an SBC on each side of a=20 > > boundary, rather than an entry signaling node facing an IP network. > >=20 > > In essence the policy point is acting as a load balancer. The 503=20 > > problem occurs precisely because you may be facing an=20 > unknown N number=20 > > of federation peers and it is already too late to react=20 > when you are=20 > > being overloaded with INVITEs. An INVITE load balancer may be=20 > > overwhelmed. The idea behind the SUB/Notify mechanism is that it=20 > > would be orders of magnitude below these spigots of INVITE sources. > >=20 > > Getting real starts with asking the right questions and solving the=20 > > same problems. Thus, my first question above. We may be=20 > envisioning=20 > > different approaches to peering. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, August 16, 2006 9:55 AM > > > To: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > Subject: RE: [Speermint] Congestion and Load Balancing > > > > > > I can't imagine any delay through a peering system that=20 > could add up=20 > > > to something an application can detect. It should be=20 > very small. =20 > > > If it's not, get a new peering system, something is wrong. Most=20 > > > peering is a SIP exchange directly between the peers=20 > (with an ENUM=20 > > > dip and possibly some other simple database things on the=20 > > > origination side). The transit time TO the peering point should=20 > > > swamp the actual signaling exchange. > > > > > > What kind of "hot spot" could you imagine we could create in a=20 > > > peering system that was not due to poor engineering? =20 > Best I can do=20 > > > is to force an underpowered SBC to face the peering network and=20 > > > bottleneck on that. Don't do that. > > > > > > People, I think we need to get real here. Let's start throwing=20 > > > around realistic numbers, and see if they work or don't. =20 > What I see=20 > > > here is telephone engineering numbers in an IP environment. > > > > > > I believe in millions of BHCA between peers, and gigabits of=20 > > > bandwidth. Is someone believing we are building peering systems=20 > > > with hundreds of millions of BHCA between a single pair=20 > of peers? =20 > > > Hundreds of gigabits of bandwidth don't seem to be a=20 > problem for a=20 > > > 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=20 > > > 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=20 > signaling element=20 > > > facing or within the peering fabric, but I think load=20 > balancing that=20 > > > is pretty straightforward, and doesn't require much=20 > standardization. =20 > > > I don't think you ever create hotspots in the peering. > > > > > > I don't believe in blocking calls before the termination=20 > resource. =20 > > > That may get congested, but then "Busy" is the=20 > appropriate response. > > > > > > Brian > > > > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 16 14:34:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDQD7-00079M-3j; Wed, 16 Aug 2006 14:33:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDQD5-00076s-Gx for speermint@ietf.org; Wed, 16 Aug 2006 14:33:47 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDQD3-0000GX-1s for speermint@ietf.org; Wed, 16 Aug 2006 14:33:47 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GDQCu-0007Js-DY; Wed, 16 Aug 2006 13:33:36 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , Subject: RE: [Speermint] Congestion and Load Balancing Date: Wed, 16 Aug 2006 14:33:39 -0400 Message-ID: <09cf01c6c162$804f1520$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301CE9F08@xmb-rtp-20b.amer.cisco.com> Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAJXwqsAAAYEAAAAbFDGAALDQlMAACLLtwAACvNVAAAV0+IAAFXzlw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org In line > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, August 16, 2006 12:03 PM > To: Brian Rosen; speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing > > Inline. > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, August 16, 2006 11:12 AM > > To: Michael Hammer (mhammer); speermint@ietf.org > > Subject: RE: [Speermint] Congestion and Load Balancing > > > > 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. > > OK > > > 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. > > So, every time there is a new peer we need to renegotiate all contracts? No. Some new bilaterals MAY be needed. I can't imagine any peer LOWERING any constraints on existing peering arrangements to handle a new peer. This is just like IP peering in this regard. > > How do we can figure out how much traffic can be exchanged between two > peers statically? Are you asking how do peers determine what the actual value should be in a bi-lateral agreement? I think that is mostly determined by what the expectation is between the peers of what "normal" traffic would be, with some allowance for abnormal. I think it's accumulated experience, and I think it's very unsophisticated. It's more of a limit on the extent abnormal traffic can be dealt with (for example, are peering with the network that supports American Idol?) > Then, next question is what factors would cause us to change that? Experience > Then, is there any reason this can not be adjusted dynamically? Yes. We don't know how to do that reliably yet, and we don't really need to make it more complex -- simple mechanisms will work. > > I am not worried about the IP fabric between the peers as that is an IP > network congestion problem. My issue is "congestion" at the receiving > point. Are we still addressing the same problem? Yes, although I think "receiving point" has two meanings: 1) The ingress point for the termination peer in the peering system. I think this can be made to be large enough that we don't need anything at the origination side that responds in anything but trivial ways. 2) The actual termination point (or the proxy that directly serves it) in the termination network. This really is a busy condition, and can be reflected back to the originating UA as busy. > > > 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. > > Are you talking L3 or L5 network congestion here? L5, L3 CAN be dealt with using well understood mechanisms. > > I was thinking that we are talking about knowledge being passed from one > peer to one adjacent peer, that is, only one hop away. Yes, that is what I understood you to be worried about. I don't see that as a problem worth solving = we can build those parts of the network beefy enough that the probability of congestion is low enough to pretty much ignore. Again, I'll admit to the cascading 503, I think the SIP overload work addresses that, and we can use what they come up with for that problem. > > > We have LOTS of experience that getting them > > right is not easy. Look at the archives on "Explicit > > Congestion Notification" in TCP for example. > > Can you explain the analogy here? Does ECN address pair-wise traffic > levels, or is it more concerned with cross-traffic in the fabric between > the peers. There are a lot of unkowables in TCP that don't exist in > this case. Also, the scale at which TCP needs to operate is much > larger. ECN addresses the effect of aggregate congestion on a specific pairwise TCP connection. I think that TCP is more complex, because the number of messages per transaction in SIP is so much fewer than the number of messages in a typical TCP session. You typically don't limit how many TCP sessions can be created in the middle of the network (you do at the endpoints). However, the point is that reflecting congestion state backwards in the network, and effectively using that information to control traffic presented to a specific point in the network, regardless of the exact circumstances, has proven, many times over, to be hard problem, not yielding to simplistic solutions. > > > 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. > > This is an argument that SUB/NOT should not be used for anything the > first time. No, it's an argument that any attempt to define a congestion control mechanism that reflects congestion state backwards is hard. It's not SUB/NOT that is the problem, it is backwards flowing congestion advice. Strictly speaking, it's not the advice that is hard, it is describing when to send it, and how to react to it that is hard. > > > 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 > > I am not saying that it might not be hard, I just don't buy that as a > reason for not trying. Imagine if you had said that at the advent of > TCP (your words with a few substitutions): > > "If the *network*, by contract, limits the total number of > *packets* towards the fabric from any one peer, and either > *network* contract policy or bilateral contract policy > limits traffic between two specific peers, I think we can > create non-*congestion* peering (or at least non *congestion* to the > point where the incidence of *congestion* is low enough that we > can ignore it and *reject the traffic*). I think that is sufficient." > > TCP would not have throttling mechanisms and offered traffic would be > statically limited. Of course. Same can be said of BGP. An ENORMOUS amount of work has gone into developing the algorithms that are involved in congestion control in those protocols. They are not at all simple, and we didn't arrive at them whole cloth. I believe congestion control efforts in SIP will follow a similar path, and they will involve a bunch of simulation and/or real world testing. When we have some, then it will be time for protocol development. And, I don't see the need yet. Overengineer the peering system for now, until we have a more efficient answer. Even then, it may not be worth deploying a more complex system. A lot of the Internet relies on the realization that more bandwidth (and routing capacity) is cheaper than complex mechanisms that limit the amount of capacity you need. That's where we are right now; cheaper and easier to give you more bandwidth that to define and implement working congestion control mechanisms. Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 16 16:57:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDSRC-0008G4-Am; Wed, 16 Aug 2006 16:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDSRA-00082K-BA for speermint@ietf.org; Wed, 16 Aug 2006 16:56:28 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDSJ8-0002cK-6J for speermint@ietf.org; Wed, 16 Aug 2006 16:48:13 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Aug 2006 16:48:10 -0400 X-IronPort-AV: i="4.08,133,1154923200"; d="scan'208"; a="97166916:sNHT35046156" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7GKm9jO019106; Wed, 16 Aug 2006 16:48:09 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7GKm9dM009736; Wed, 16 Aug 2006 16:48:09 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 16:48:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Congestion and Load Balancing Date: Wed, 16 Aug 2006 16:48:08 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301D5F7F0@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Congestion and Load Balancing Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAJXwqsAAAYEAAAAbFDGAALDQlMAACLLtwAACvNVAAAV0+IAAFXzlwAAOJgZA= From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , X-OriginalArrivalTime: 16 Aug 2006 20:48:09.0382 (UTC) FILETIME=[483B5460:01C6C175] DKIM-Signature: a=rsa-sha1; q=dns; l=9999; t=1155761289; x=1156625289; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Congestion=20and=20Load=20Balancing |To:=22Brian=20Rosen=22=20,=20; X=v=3Dcisco.com=3B=20h=3DD+ZIob6N7qWaKrQ323RA13TkaLI=3D; b=S+hOUMxT5LWIbVgKiP7DRoyByk9e504IitjgGltpe18iFsAnFBw+OWkdxHTUh6V1iC/+S8MG ZXoMbKK1h4CjXgikIudA4pBaQzhyI/wdqdRGZfCSsbcHennlUo7HewbS; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian, Last questions, then I think we need to just agree to disagree. Is it possible to summarize all the bilateral static agreements of allowed traffic to be terminated at one peer into an XML document? And if all those peers agree not to exceed the traffic envelope described in that XML document, could you not agree that the receiving peer could be assured that the bulk (99%) of statistical distribution of call arrivals would be within engineered limits of the system? (And those that do exceed can be handled via INVITE rejections contemplated by SIPPING.) BTW, I see this as more analogous to the CAC for ATM or MPLS paths granted admission to the system, with committed and burst rates allowed, where the cells are the INVITEs processed by the system. More to the point, the path reservation mechanism of RSVP, where BW per path may be bumped up or down, is what you are saying is too hard to do. Products to do this exist. Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, August 16, 2006 2:34 PM > To: Michael Hammer (mhammer); speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing >=20 > In line >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Wednesday, August 16, 2006 12:03 PM > > To: Brian Rosen; speermint@ietf.org > > Subject: RE: [Speermint] Congestion and Load Balancing > >=20 > > Inline. > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, August 16, 2006 11:12 AM > > > To: Michael Hammer (mhammer); speermint@ietf.org > > > Subject: RE: [Speermint] Congestion and Load Balancing > > > > > > I think peering is functionally a star: peers have some=20 > collection=20 > > > of elements facing the peering fabric and peering goes=20 > from one edge=20 > > > to the other. The "fabric" may be nothing but an IP network. It=20 > > > may even be the Internet. There may or may not be any active=20 > > > element at the hub of the star. If there is, it's a=20 > proxy server. =20 > > > If there isn't, it's just an IP switch or functional equivalent. > >=20 > > OK > >=20 > > > If the federation, by contract, limits the total number of calls=20 > > > towards the fabric from any one peer, and either=20 > federation contract=20 > > > policy or bilateral contract policy limits traffic between two=20 > > > specific peers, I think we can create non-blocking peering (or at=20 > > > least non blocking to the point where the incidence of=20 > blocking is=20 > > > low enough that we can ignore it and busy the call). I=20 > think that=20 > > > is sufficient. > >=20 > > So, every time there is a new peer we need to renegotiate=20 > all contracts? > No. Some new bilaterals MAY be needed. I can't imagine any=20 > peer LOWERING any constraints on existing peering=20 > arrangements to handle a new peer. This is just like IP=20 > peering in this regard. >=20 > >=20 > > How do we can figure out how much traffic can be exchanged=20 > between two=20 > > peers statically? > Are you asking how do peers determine what the actual value=20 > should be in a bi-lateral agreement? I think that is mostly=20 > determined by what the expectation is between the peers of=20 > what "normal" traffic would be, with some allowance for=20 > abnormal. I think it's accumulated experience, and I think=20 > it's very unsophisticated. It's more of a limit on the=20 > extent abnormal traffic can be dealt with (for example, are=20 > peering with the network that supports American Idol?) >=20 > > Then, next question is what factors would cause us to change that? > Experience >=20 > > Then, is there any reason this can not be adjusted dynamically? > Yes. We don't know how to do that reliably yet, and we don't=20 > really need to make it more complex -- simple mechanisms will work. >=20 > >=20 > > I am not worried about the IP fabric between the peers as=20 > that is an=20 > > IP network congestion problem. My issue is "congestion" at the=20 > > receiving point. Are we still addressing the same problem? > Yes, although I think "receiving point" has two meanings: > 1) The ingress point for the termination peer in the peering=20 > system. I think this can be made to be large enough that we=20 > don't need anything at the origination side that responds in=20 > anything but trivial ways. >=20 > 2) The actual termination point (or the proxy that directly=20 > serves it) in the termination network. This really is a busy=20 > condition, and can be reflected back to the originating UA as busy. >=20 > >=20 > > > The SIP overload work is dealing with the 503 issue. I=20 > don't have=20 > > > anything to offer beyond that work, do you? > > > > > > I am extremely suspicious of simplistic congestion control=20 > > > mechanisms that try to push congestion knowledge back=20 > earlier in a=20 > > > network. > >=20 > > Are you talking L3 or L5 network congestion here? > L5, L3 CAN be dealt with using well understood mechanisms. >=20 > >=20 > > I was thinking that we are talking about knowledge being=20 > passed from=20 > > one peer to one adjacent peer, that is, only one hop away. > Yes, that is what I understood you to be worried about. I=20 > don't see that as a problem worth solving =3D we can build=20 > those parts of the network beefy enough that the probability=20 > of congestion is low enough to pretty much ignore. Again,=20 > I'll admit to the cascading 503, I think the SIP overload=20 > work addresses that, and we can use what they come up with=20 > for that problem. >=20 >=20 > >=20 > > > We have LOTS of experience that getting them right is not easy. =20 > > > Look at the archives on "Explicit Congestion Notification" in TCP=20 > > > for example. > >=20 > > Can you explain the analogy here? Does ECN address=20 > pair-wise traffic=20 > > levels, or is it more concerned with cross-traffic in the fabric=20 > > between the peers. There are a lot of unkowables in TCP that don't=20 > > exist in this case. Also, the scale at which TCP needs to=20 > operate is=20 > > much larger. > ECN addresses the effect of aggregate congestion on a=20 > specific pairwise TCP connection. I think that TCP is more=20 > complex, because the number of messages per transaction in=20 > SIP is so much fewer than the number of messages > in a typical TCP session. You typically don't limit how=20 > many TCP sessions > can be created in the middle of the network (you do at the endpoints). > However, the point is that reflecting congestion state=20 > backwards in the network, and effectively using that=20 > information to control traffic presented to a specific point=20 > in the network, regardless of the exact circumstances, has=20 > proven, many times over, to be hard problem, not yielding to=20 > simplistic solutions. =20 >=20 > >=20 > > > Unless you can > > > show me a big network successfully using SUB/NOT to push=20 > congestion=20 > > > state backwards, then I don't believe it will work. > >=20 > > This is an argument that SUB/NOT should not be used for=20 > anything the=20 > > first time. > No, it's an argument that any attempt to define a congestion=20 > control mechanism that reflects congestion state backwards is=20 > hard. It's not SUB/NOT that is the problem, it is backwards=20 > flowing congestion advice. > Strictly speaking, it's not the advice that is hard, it is=20 > describing when to send it, and how to react to it that is hard. >=20 >=20 > >=20 > > > I guarantee it won't work if it's literally just a=20 > notification to=20 > > > stop: that is, there is no explicit text on how you=20 > control the rate=20 > > > of messages, and how you control the on/off nature of the=20 > mechanism=20 > > > so that it has dampening. > > > Getting such text right, and behavior right at both ends, is hard. > > > > > > Brian > >=20 > > I am not saying that it might not be hard, I just don't buy=20 > that as a=20 > > reason for not trying. Imagine if you had said that at the=20 > advent of=20 > > TCP (your words with a few substitutions): > >=20 > > "If the *network*, by contract, limits the total number of > > *packets* towards the fabric from any one peer, and either > > *network* contract policy or bilateral contract policy=20 > limits traffic=20 > > between two specific peers, I think we can create non-*congestion*=20 > > peering (or at least non *congestion* to the point where=20 > the incidence=20 > > of *congestion* is low enough that we can ignore it and *reject the=20 > > traffic*). I think that is sufficient." > >=20 > > TCP would not have throttling mechanisms and offered=20 > traffic would be=20 > > statically limited. > Of course. Same can be said of BGP. An ENORMOUS amount of=20 > work has gone into developing the algorithms that are=20 > involved in congestion control in those protocols. They are=20 > not at all simple, and we didn't arrive at them whole cloth. =20 > I believe congestion control efforts in SIP will follow a=20 > similar path, and they will involve a bunch of simulation=20 > and/or real world testing. When we have some, then it will=20 > be time for protocol development. >=20 > And, I don't see the need yet. Overengineer the peering=20 > system for now, until we have a more efficient answer. Even=20 > then, it may not be worth deploying a more complex system. A=20 > lot of the Internet relies on the realization that more=20 > bandwidth (and routing capacity) is cheaper than complex=20 > mechanisms that limit the amount of capacity you need. =20 > That's where we are right now; cheaper and easier to give you=20 > more bandwidth that to define and implement working=20 > congestion control mechanisms. >=20 > Brian >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 16 17:19:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDSmd-0002Yr-CW; Wed, 16 Aug 2006 17:18:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDSmb-0002Yj-Mp for speermint@ietf.org; Wed, 16 Aug 2006 17:18:37 -0400 Received: from omzesmtp02.mci.com ([199.249.17.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDSmY-0006ne-C4 for speermint@ietf.org; Wed, 16 Aug 2006 17:18:37 -0400 Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0J4400B7G0HC15@firewall.mci.com> for speermint@ietf.org; Wed, 16 Aug 2006 21:17:36 +0000 (GMT) Received: from pmismtp06.wcomnet.com ([127.0.0.1]) by pmismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0J4400K430HCMN@pmismtp06.mcilink.com> for speermint@ietf.org; Wed, 16 Aug 2006 21:17:36 +0000 (GMT) Received: from XS107V7775199 ([166.50.70.191]) by pmismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0J4400IMT0HBTR@pmismtp06.mcilink.com> for speermint@ietf.org; Wed, 16 Aug 2006 21:17:36 +0000 (GMT) Date: Wed, 16 Aug 2006 16:17:35 -0500 From: Tim Dwight Subject: RE: [Speermint] Congestion and Load Balancing In-reply-to: <072C5B76F7CEAB488172C6F64B30B5E301CE9F08@xmb-rtp-20b.amer.cisco.com> To: "'Michael Hammer (mhammer)'" , 'Brian Rosen' , speermint@ietf.org Message-id: <006801c6c179$65552400$bf4632a6@mcilink.com> Organization: MCI MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAJXwqsAAAYEAAAAbFDGAALDQlMAACLLtwAACvNVAAAV0+IAAIFLQw X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: timothy.dwight@verizon.com List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Mike, > I am not worried about the IP fabric between the peers as that is an IP > network congestion problem. My issue is "congestion" at the receiving > point. Are we still addressing the same problem? I take it that your concern is not to be with congestion *in the fabric", but rather congestion in one peering partner's network. If I understand you correctly you are arguing that means ought to exist whereby the congested network can notify its peers to reduce the load they are imposing on the congested network. If that's not the gist please accept my apologies. This discussion has been hard to follow. If it is, I'd observe that: 1. the problem seems realistic (congestion happens even in "well engineered networks"). 2. solutions to this problem do exist in other domains, so not addressing it would seem a step backward 3. ideally the semantics for communicating congestion would support both selective and general overload controls. 4. selective controls need to be based on externally-meaningful information. Given that networks don't typically share topological information this probably means basing such controls on AoRs. To be scalable we'd need these to aggregate somehow (so that network A could refer to "all AoRs associated with congested device A.x" without listing them). tim _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 17 09:46:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDiCK-0003i9-Hw; Thu, 17 Aug 2006 09:46:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDiCJ-0003do-Js for speermint@ietf.org; Thu, 17 Aug 2006 09:46:11 -0400 Received: from pmesmtp01.wcom.com ([199.249.20.1] helo=pmesmtp01.mci.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDiCF-0002VS-8e for speermint@ietf.org; Thu, 17 Aug 2006 09:46:11 -0400 Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0J45002KAA85Q4@firewall.mci.com> for speermint@ietf.org; Thu, 17 Aug 2006 13:45:42 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([127.0.0.1]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0J4500B4TA85JD@pmismtp04.mcilink.com> for speermint@ietf.org; Thu, 17 Aug 2006 13:45:41 +0000 (GMT) Received: from XS107V7775199 ([166.50.70.191]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0J4500B1CA85OU@pmismtp04.mcilink.com> for speermint@ietf.org; Thu, 17 Aug 2006 13:45:41 +0000 (GMT) Date: Thu, 17 Aug 2006 08:45:41 -0500 From: Tim Dwight Subject: RE: [Speermint] Congestion and Load Balancing In-reply-to: <072C5B76F7CEAB488172C6F64B30B5E301D5F87F@xmb-rtp-20b.amer.cisco.com> To: "'Michael Hammer (mhammer)'" , 'Brian Rosen' , speermint@ietf.org Message-id: <002601c6c203$6e3204a0$bf4632a6@mcilink.com> Organization: MCI MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAJXwqsAAAYEAAAAbFDGAALDQlMAACLLtwAACvNVAAAV0+IAAIFLQwACVuYSAAAH3MIA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: timothy.dwight@verizon.com List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Good to know I wasn't completely lost :) I agree of course with respect to proactive overload controls, and the inadequacy of session-level "source quench". But I also agree with Brian's point about complexity... even seemingly simple controls can have unforseen consequences. That doesn't mean I prefer to do nothing, but I think whatever we do needs to be simple-but-provably-useful and well grounded in both theory and practice. tim > Tim, > > I think you do get what I am after. My interest was solely > in the L5 SIP traffic between domain egress and ingress > points. And I was looking for proactive versus reactive > solutions, since one you get behind the power curve on this, > one could find themselves not able to reject requests fast > enough to quench all the sources. > > Mike > > > > -----Original Message----- > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > Sent: Wednesday, August 16, 2006 5:18 PM > > To: Michael Hammer (mhammer); 'Brian Rosen'; speermint@ietf.org > > Subject: RE: [Speermint] Congestion and Load Balancing > > > > Mike, > > > > > I am not worried about the IP fabric between the peers as > > that is an > > > IP network congestion problem. My issue is "congestion" at the > > > receiving point. Are we still addressing the same problem? > > > > I take it that your concern is not to be with congestion *in the > > fabric", but rather congestion in one peering partner's > network. If I > > understand you correctly you are arguing that means ought to exist > > whereby the congested network can notify its peers to > reduce the load > > they are imposing on the congested network. > > > > If that's not the gist please accept my apologies. This discussion > > has been hard to follow. > > > > If it is, I'd observe that: > > > > 1. the problem seems realistic (congestion happens even in "well > > engineered networks"). > > > > 2. solutions to this problem do exist in other domains, so not > > addressing it would > > seem a step backward > > > > 3. ideally the semantics for communicating congestion would support > > both selective and general > > overload controls. > > > > 4. selective controls need to be based on externally-meaningful > > information. > > Given that > > networks don't typically share topological information this > > probably means basing > > such controls on AoRs. To be scalable we'd need these > to aggregate > > somehow (so that > > network A could refer to "all AoRs associated with > congested device > > A.x" > > without listing > > them). > > > > tim > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 17 10:13:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDicv-0005zo-Pa; Thu, 17 Aug 2006 10:13:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDicu-0005wI-3s for speermint@ietf.org; Thu, 17 Aug 2006 10:13:40 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDiQK-00065T-4i for speermint@ietf.org; Thu, 17 Aug 2006 10:00:41 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 17 Aug 2006 07:00:39 -0700 X-IronPort-AV: i="4.08,137,1154934000"; d="scan'208"; a="1848051364:sNHT33724304" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7HE0dAf032738; Thu, 17 Aug 2006 07:00:39 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7HE0d6W012089; Thu, 17 Aug 2006 07:00:39 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 10:00:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Congestion and Load Balancing Date: Thu, 17 Aug 2006 10:00:37 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301D5F89E@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Congestion and Load Balancing Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAJXwqsAAAYEAAAAbFDGAALDQlMAACLLtwAACvNVAAAV0+IAAIFLQwACVuYSAAAH3MIAABCZHQ From: "Michael Hammer \(mhammer\)" To: , "Brian Rosen" , X-OriginalArrivalTime: 17 Aug 2006 14:00:39.0079 (UTC) FILETIME=[8520EB70:01C6C205] DKIM-Signature: a=rsa-sha1; q=dns; l=3290; t=1155823239; x=1156687239; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Congestion=20and=20Load=20Balancing; X=v=3Dcisco.com=3B=20h=3DD+ZIob6N7qWaKrQ323RA13TkaLI=3D; b=VEQbw5xvWVOVMowUda9Vd1QG28/S7gGBjIgtu2uY4l2PiixIw76j9KurhAjgSDMjh+atMNb7 BhemELMbuw7UPjzEUcyaIr0W0lWUsQuN3jjdwUPUmy2OqaX5GYWp99t7; Authentication-Results: sj-dkim-6.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Agreed. I am looking for something as simple as possible. Mike > -----Original Message----- > From: Tim Dwight [mailto:timothy.dwight@verizon.com]=20 > Sent: Thursday, August 17, 2006 9:46 AM > To: Michael Hammer (mhammer); 'Brian Rosen'; speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing >=20 > Good to know I wasn't completely lost :) >=20 > I agree of course with respect to proactive overload=20 > controls, and the inadequacy of session-level "source=20 > quench". But I also agree with Brian's point about=20 > complexity... even seemingly simple controls can have=20 > unforseen consequences. That doesn't mean I prefer to do=20 > nothing, but I think whatever we do needs to be=20 > simple-but-provably-useful and well grounded in both theory=20 > and practice. >=20 > tim >=20 > > Tim, > >=20 > > I think you do get what I am after. My interest was solely=20 > in the L5=20 > > SIP traffic between domain egress and ingress points. And I was=20 > > looking for proactive versus reactive solutions, since one you get=20 > > behind the power curve on this, one could find themselves=20 > not able to=20 > > reject requests fast enough to quench all the sources. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > Sent: Wednesday, August 16, 2006 5:18 PM > > > To: Michael Hammer (mhammer); 'Brian Rosen'; speermint@ietf.org > > > Subject: RE: [Speermint] Congestion and Load Balancing > > >=20 > > > Mike, > > >=20 > > > > I am not worried about the IP fabric between the peers as > > > that is an > > > > IP network congestion problem. My issue is "congestion" at the=20 > > > > receiving point. Are we still addressing the same problem? > > >=20 > > > I take it that your concern is not to be with congestion *in the=20 > > > fabric", but rather congestion in one peering partner's > > network. If I > > > understand you correctly you are arguing that means ought=20 > to exist=20 > > > whereby the congested network can notify its peers to > > reduce the load > > > they are imposing on the congested network. > > >=20 > > > If that's not the gist please accept my apologies. This=20 > discussion=20 > > > has been hard to follow. > > >=20 > > > If it is, I'd observe that: > > >=20 > > > 1. the problem seems realistic (congestion happens even in "well=20 > > > engineered networks"). > > >=20 > > > 2. solutions to this problem do exist in other domains, so not=20 > > > addressing it would > > > seem a step backward > > >=20 > > > 3. ideally the semantics for communicating congestion=20 > would support=20 > > > both selective and general > > > overload controls. > > >=20 > > > 4. selective controls need to be based on externally-meaningful=20 > > > information. > > > Given that=20 > > > networks don't typically share topological information this=20 > > > probably means basing > > > such controls on AoRs. To be scalable we'd need these > > to aggregate > > > somehow (so that > > > network A could refer to "all AoRs associated with > > congested device > > > A.x" > > > without listing > > > them). > > >=20 > > > tim > > >=20 > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 17 10:17:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDifw-0007qe-PC; Thu, 17 Aug 2006 10:16:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDifv-0007nC-5U for speermint@ietf.org; Thu, 17 Aug 2006 10:16:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDhxA-0000rV-Jg for speermint@ietf.org; Thu, 17 Aug 2006 09:30:32 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDhnE-0005lQ-11 for speermint@ietf.org; Thu, 17 Aug 2006 09:20:19 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 17 Aug 2006 06:20:15 -0700 X-IronPort-AV: i="4.08,136,1154934000"; d="scan'208"; a="312058739:sNHT32681316" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7HDKFP6018856; Thu, 17 Aug 2006 06:20:15 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7HDKC6c029316; Thu, 17 Aug 2006 06:20:14 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 09:20:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Congestion and Load Balancing Date: Thu, 17 Aug 2006 09:20:13 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301D5F87F@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Congestion and Load Balancing Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAJXwqsAAAYEAAAAbFDGAALDQlMAACLLtwAACvNVAAAV0+IAAIFLQwACVuYSA= From: "Michael Hammer \(mhammer\)" To: , "Brian Rosen" , X-OriginalArrivalTime: 17 Aug 2006 13:20:14.0283 (UTC) FILETIME=[DFD669B0:01C6C1FF] DKIM-Signature: a=rsa-sha1; q=dns; l=2157; t=1155820815; x=1156684815; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Congestion=20and=20Load=20Balancing; X=v=3Dcisco.com=3B=20h=3DD+ZIob6N7qWaKrQ323RA13TkaLI=3D; b=Q7PhxMS9T4EAUfawx/49x8RcjgnY5SE5Pe726vqT8u4PF1tWy09aEEC86yL0a9OqG/pMX5uU tGZeE60PDe+ng/ZfeFTjSLn16xmxz7pNit18F34o7y799IXa0cSUy8Pl; Authentication-Results: sj-dkim-6.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.5 (--) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Tim, I think you do get what I am after. My interest was solely in the L5 SIP traffic between domain egress and ingress points. And I was looking for proactive versus reactive solutions, since one you get behind the power curve on this, one could find themselves not able to reject requests fast enough to quench all the sources. Mike > -----Original Message----- > From: Tim Dwight [mailto:timothy.dwight@verizon.com]=20 > Sent: Wednesday, August 16, 2006 5:18 PM > To: Michael Hammer (mhammer); 'Brian Rosen'; speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing >=20 > Mike, >=20 > > I am not worried about the IP fabric between the peers as=20 > that is an=20 > > IP network congestion problem. My issue is "congestion" at the=20 > > receiving point. Are we still addressing the same problem? >=20 > I take it that your concern is not to be with congestion *in=20 > the fabric", but rather congestion in one peering partner's=20 > network. If I understand you correctly you are arguing that=20 > means ought to exist whereby the congested network can notify=20 > its peers to reduce the load they are imposing on the=20 > congested network. >=20 > If that's not the gist please accept my apologies. This=20 > discussion has been hard to follow. >=20 > If it is, I'd observe that: >=20 > 1. the problem seems realistic (congestion happens even in=20 > "well engineered networks"). >=20 > 2. solutions to this problem do exist in other domains, so=20 > not addressing it would=20 > seem a step backward >=20 > 3. ideally the semantics for communicating congestion would=20 > support both selective and general > overload controls. >=20 > 4. selective controls need to be based on=20 > externally-meaningful information. > Given that=20 > networks don't typically share topological information=20 > this probably means basing > such controls on AoRs. To be scalable we'd need these to=20 > aggregate somehow (so that=20 > network A could refer to "all AoRs associated with=20 > congested device A.x" > without listing > them). >=20 > tim >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 17 10:38:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDj05-0007tV-Om; Thu, 17 Aug 2006 10:37:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDj04-0007tO-EQ for speermint@ietf.org; Thu, 17 Aug 2006 10:37:36 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDj04-0006q2-Co for speermint@ietf.org; Thu, 17 Aug 2006 10:37:36 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDizX-0007Vl-Ox for speermint@ietf.org; Thu, 17 Aug 2006 10:37:04 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GDizO-0007DV-Ai; Thu, 17 Aug 2006 09:36:54 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , , Subject: RE: [Speermint] Congestion and Load Balancing Date: Thu, 17 Aug 2006 10:36:56 -0400 Message-ID: <0c1601c6c20a$9909b6d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301D5F87F@xmb-rtp-20b.amer.cisco.com> Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAJXwqsAAAYEAAAAbFDGAALDQlMAACLLtwAACvNVAAAV0+IAAIFLQwACVuYSAAAXYikA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.5 (--) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org The following is copied from our charter: In addition, SPEERMINT considers and documents requirements for the feedback of operational conditions (e.g., congestion control) that enables the application of dynamic policy and recognizes that various mechanisms for achieving this should be studied as a potential part of any architecture. In future, as its initial work completes and the requirements become known, SPEERMINT may seek rechartering to consider various mechanism to support applying Quality of Service and/or traffic engineering mechanisms in an architecturally sound way in support of real-time Session PEERing. A charter discussion would consider how to work with with mechanisms developed by other working groups, selecting and integrating those, but as stated, first the initial milestones must be completed. And The most focused deliverables of SPEERMINT are best current practices regarding exchange of real-time sessions among VoIP and other real-time application service providers and, in particular, how such calls are routed. So, we can work on requirements, but not solutions right now. That's where I am; I understand there are some problems worth looking at. I understand there is some technology that has been applied to different problems that may be applicable. I know of some applicable work in a different work group. However, I don't think there is anything we can use in a BCP, and that's what we're doing now. I also think that mechanisms we CAN document in a BCP are sufficient now. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Thursday, August 17, 2006 9:20 AM > To: timothy.dwight@verizon.com; Brian Rosen; speermint@ietf.org > Subject: RE: [Speermint] Congestion and Load Balancing > > Tim, > > I think you do get what I am after. My interest was solely in the L5 > SIP traffic between domain egress and ingress points. And I was looking > for proactive versus reactive solutions, since one you get behind the > power curve on this, one could find themselves not able to reject > requests fast enough to quench all the sources. > > Mike > > > > -----Original Message----- > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > Sent: Wednesday, August 16, 2006 5:18 PM > > To: Michael Hammer (mhammer); 'Brian Rosen'; speermint@ietf.org > > Subject: RE: [Speermint] Congestion and Load Balancing > > > > Mike, > > > > > I am not worried about the IP fabric between the peers as > > that is an > > > IP network congestion problem. My issue is "congestion" at the > > > receiving point. Are we still addressing the same problem? > > > > I take it that your concern is not to be with congestion *in > > the fabric", but rather congestion in one peering partner's > > network. If I understand you correctly you are arguing that > > means ought to exist whereby the congested network can notify > > its peers to reduce the load they are imposing on the > > congested network. > > > > If that's not the gist please accept my apologies. This > > discussion has been hard to follow. > > > > If it is, I'd observe that: > > > > 1. the problem seems realistic (congestion happens even in > > "well engineered networks"). > > > > 2. solutions to this problem do exist in other domains, so > > not addressing it would > > seem a step backward > > > > 3. ideally the semantics for communicating congestion would > > support both selective and general > > overload controls. > > > > 4. selective controls need to be based on > > externally-meaningful information. > > Given that > > networks don't typically share topological information > > this probably means basing > > such controls on AoRs. To be scalable we'd need these to > > aggregate somehow (so that > > network A could refer to "all AoRs associated with > > congested device A.x" > > without listing > > them). > > > > tim > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 17 11:17:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDjbQ-0007ju-3Z; Thu, 17 Aug 2006 11:16:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDjbO-0007iI-VZ for speermint@ietf.org; Thu, 17 Aug 2006 11:16:10 -0400 Received: from outbound-red.frontbridge.com ([216.148.222.49] helo=outbound3-red-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDjbN-0003qB-HI for speermint@ietf.org; Thu, 17 Aug 2006 11:16:10 -0400 Received: from outbound3-red.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound3-red-R.bigfish.com (Postfix) with ESMTP id 25CD55DCB5F; Thu, 17 Aug 2006 15:16:09 +0000 (UTC) Received: from mail53-red-R.bigfish.com (unknown [172.18.12.3]) by outbound3-red.bigfish.com (Postfix) with ESMTP id 0AFB05D93C8; Thu, 17 Aug 2006 15:16:09 +0000 (UTC) Received: from mail53-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail53-red-R.bigfish.com (Postfix) with ESMTP id 0211D4A2F4F; Thu, 17 Aug 2006 15:16:09 +0000 (UTC) X-BigFish: V Received: by mail53-red (MessageSwitch) id 1155827768941985_19910; Thu, 17 Aug 2006 15:16:08 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail53-red.bigfish.com (Postfix) with ESMTP id C93B54A2A25; Thu, 17 Aug 2006 15:16:08 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k7HFG8sx027594; Thu, 17 Aug 2006 10:16:08 -0500 (CDT) Received: from pdawg05a.ad.sprint.com (PDAWG05A.corp.sprint.com [10.122.2.38]) by mailhost.sprintspectrum.com (Switch-3.2.3/Switch-3.2.3) with ESMTP id k7HFFpEs000153; Thu, 17 Aug 2006 10:15:51 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by pdawg05a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 10:15:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Congestion and Load Balancing Date: Thu, 17 Aug 2006 10:15:53 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A1302E1B418@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Congestion and Load Balancing Thread-Index: Aca7yyICmOoTtkpXT0e+22yo6tbB4QAC2F/AAAdg6tAAANkPMAAAcxMgAPb1KpAAJXwqsAAAYEAAAAbFDGAALDQlMAACLLtwAACvNVAAAV0+IAAIFLQwACVuYSAAAH3MIAADpSkw From: "Khan, Sohel Q [CTO]" To: , "Michael Hammer \(mhammer\)" , "Brian Rosen" , X-OriginalArrivalTime: 17 Aug 2006 15:15:51.0579 (UTC) FILETIME=[06C9C6B0:01C6C210] X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I agree with this. We need a proactive but simple mechanism for L5 congestion/overload control. Sohel=20 -----Original Message----- From: Tim Dwight [mailto:timothy.dwight@verizon.com]=20 Sent: Thursday, August 17, 2006 8:46 AM To: 'Michael Hammer (mhammer)'; 'Brian Rosen'; speermint@ietf.org Subject: RE: [Speermint] Congestion and Load Balancing Good to know I wasn't completely lost :) I agree of course with respect to proactive overload controls, and the inadequacy of session-level "source quench". But I also agree with Brian's point about complexity... even seemingly simple controls can have unforseen consequences. That doesn't mean I prefer to do nothing, but I think whatever we do needs to be simple-but-provably-useful and well grounded in both theory and practice. tim > Tim, >=20 > I think you do get what I am after. My interest was solely in the L5=20 > SIP traffic between domain egress and ingress points. And I was=20 > looking for proactive versus reactive solutions, since one you get=20 > behind the power curve on this, one could find themselves not able to=20 > reject requests fast enough to quench all the sources. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > Sent: Wednesday, August 16, 2006 5:18 PM > > To: Michael Hammer (mhammer); 'Brian Rosen'; speermint@ietf.org > > Subject: RE: [Speermint] Congestion and Load Balancing > >=20 > > Mike, > >=20 > > > I am not worried about the IP fabric between the peers as > > that is an > > > IP network congestion problem. My issue is "congestion" at the=20 > > > receiving point. Are we still addressing the same problem? > >=20 > > I take it that your concern is not to be with congestion *in the=20 > > fabric", but rather congestion in one peering partner's > network. If I > > understand you correctly you are arguing that means ought to exist=20 > > whereby the congested network can notify its peers to > reduce the load > > they are imposing on the congested network. > >=20 > > If that's not the gist please accept my apologies. This discussion=20 > > has been hard to follow. > >=20 > > If it is, I'd observe that: > >=20 > > 1. the problem seems realistic (congestion happens even in "well=20 > > engineered networks"). > >=20 > > 2. solutions to this problem do exist in other domains, so not=20 > > addressing it would > > seem a step backward > >=20 > > 3. ideally the semantics for communicating congestion would support=20 > > both selective and general > > overload controls. > >=20 > > 4. selective controls need to be based on externally-meaningful=20 > > information. > > Given that=20 > > networks don't typically share topological information this=20 > > probably means basing > > such controls on AoRs. To be scalable we'd need these > to aggregate > > somehow (so that > > network A could refer to "all AoRs associated with > congested device > > A.x" > > without listing > > them). > >=20 > > tim > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 18 10:16:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE58z-0007cs-KJ; Fri, 18 Aug 2006 10:16:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE58y-0007cn-SH for speermint@ietf.org; Fri, 18 Aug 2006 10:16:16 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE58x-0000TK-GI for speermint@ietf.org; Fri, 18 Aug 2006 10:16:16 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k7IEGFpF025045 for ; Fri, 18 Aug 2006 07:16:15 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k7IEGFnY025044 for speermint@ietf.org; Fri, 18 Aug 2006 07:16:15 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 18 Aug 2006 07:16:15 -0700 From: David Meyer To: speermint@ietf.org Message-ID: <20060818141614.GA25021@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Speermint] latest in speermint terminology X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0644299567==" Errors-To: speermint-bounces@ietf.org --===============0644299567== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable With all (most?) of the comments I've received (including, Otmar, s/CRD/CAD/ :-)) http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-04.txt I'll post it to the internet-drafts repository on Monday if we're close to converging. Thnx, =09 --dmm --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFE5cuuORgD1qCZ2KcRAs+fAJwLez0Z6eKt5kuqM13G1lwewXalCQCcDpWa eYeXONxEkX3Kkg7NTJ5uKL8= =XWrQ -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- --===============0644299567== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0644299567==-- From speermint-bounces@ietf.org Fri Aug 18 13:58:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE8ap-0006CU-J3; Fri, 18 Aug 2006 13:57:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE8ao-0006CP-BG for speermint@ietf.org; Fri, 18 Aug 2006 13:57:14 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE8aj-0008QE-4w for speermint@ietf.org; Fri, 18 Aug 2006 13:57:14 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Fri, 18 Aug 2006 13:57:05 -0400 id 015880DB.44E5FF72.0000571B Message-ID: <44E5FF69.60209@hxr.us> Date: Fri, 18 Aug 2006 13:56:57 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: David Meyer Subject: Re: [Speermint] latest in speermint terminology References: <20060818141614.GA25021@1-4-5.net> In-Reply-To: <20060818141614.GA25021@1-4-5.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org David Meyer wrote: > With all (most?) of the comments I've received > (including, Otmar, s/CRD/CAD/ :-)) > > http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-04.txt Regarding 4.5: 4.5. Assisted Peering In this case a federation employs a central SIP proxy (which is not itself a VSP) to bridge calls between participating networks. First, by the term "bridge", do you mean that the signaling actually passes through the proxy? If so, what about cases where the SIP proxy routes calls by issuing redirects? Also, what about that same functionality (the routing of calls between peers) using a directory style technology, such as ENUM (or maybe LDAP, though I don't know if anybody is doing that). -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 21 05:42:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF6He-00053s-ND; Mon, 21 Aug 2006 05:41:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF6Hd-00053k-9J for speermint@ietf.org; Mon, 21 Aug 2006 05:41:25 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF6Hb-00043X-VJ for speermint@ietf.org; Mon, 21 Aug 2006 05:41:25 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 1E98D1A36D; Mon, 21 Aug 2006 11:37:33 +0200 (CEST) Date: Mon, 21 Aug 2006 11:37:33 +0200 From: Otmar Lendl To: Andrew Newton Subject: Re: [Speermint] latest in speermint terminology Message-ID: <20060821093732.GP19113@nic.at> Mail-Followup-To: Otmar Lendl , Andrew Newton , David Meyer , speermint@ietf.org References: <20060818141614.GA25021@1-4-5.net> <44E5FF69.60209@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44E5FF69.60209@hxr.us> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/08/18 19:08, Andrew Newton wrote: > David Meyer wrote: > > With all (most?) of the comments I've received > > (including, Otmar, s/CRD/CAD/ :-)) > > > > http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-04.txt > > Regarding 4.5: > > 4.5. Assisted Peering > > In this case a federation employs a central SIP proxy (which is not > itself a VSP) to bridge calls between participating networks. > > First, by the term "bridge", do you mean that the signaling actually passes > through the proxy? If so, what about cases where the SIP proxy routes > calls by issuing redirects? Also, what about that same functionality (the > routing of calls between peers) using a directory style technology, such as > ENUM (or maybe LDAP, though I don't know if anybody is doing that). My intention with that term is the following context: * "direct peering" is for when the SIP elements of both networks talk directly to each other. In between are only layer 0 to 3 devices. * "transit case": there a call is passed through a L5 transit network. I thought we need a definition for a middle case: Here a fabric provider is involved in the SIP signalling (thus it's not a simple direct peering). It shouldn't matter whether it's done by redirect or forwarding SIP signalling. In these cases I'd rather avoid using the "transit" word, as the SIP proxy there is just a helper for the peering and not a fully fledged SIP Network provider who is providing transit services. ENUM (or LDAP) is a different issue: you can have someone provide ENUM services to facilitate direct peering. The term "direct peering" isn't affected by anyone providing ENUM services. Andy, do you agree with that classification? Should we change the definition of "direct peering" to include such models? Or what's your preferred definition of "assisted peering"? Would you prefer a different name for that concept? Cheers, /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 21 10:45:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFB1E-0004tQ-J3; Mon, 21 Aug 2006 10:44:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFB1D-0004nk-8k for speermint@ietf.org; Mon, 21 Aug 2006 10:44:47 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFB1B-0004o3-0d for speermint@ietf.org; Mon, 21 Aug 2006 10:44:47 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 21 Aug 2006 10:44:24 -0400 id 01588117.44E9C6C9.00003AD1 In-Reply-To: <20060821093732.GP19113@nic.at> References: <20060818141614.GA25021@1-4-5.net> <44E5FF69.60209@hxr.us> <20060821093732.GP19113@nic.at> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5B9F5451-43B7-4DBF-8D5A-26DC66DFE3BC@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Speermint] latest in speermint terminology Date: Mon, 21 Aug 2006 10:44:22 -0400 To: Otmar Lendl X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Aug 21, 2006, at 5:37 AM, Otmar Lendl wrote: > My intention with that term is the following context: > > * "direct peering" is for when the SIP elements of both networks > talk directly to each other. In between are only layer 0 to 3 > devices. > > * "transit case": there a call is passed through a L5 transit network. > > I thought we need a definition for a middle case: > > Here a fabric provider is involved in the SIP signalling (thus it's > not a simple direct peering). It shouldn't matter whether it's done > by redirect or forwarding SIP signalling. In these cases I'd rather > avoid using the "transit" word, as the SIP proxy there is just a > helper > for the peering and not a fully fledged SIP Network provider who is > providing transit services. > > ENUM (or LDAP) is a different issue: you can have someone provide > ENUM services to facilitate direct peering. The term "direct peering" > isn't affected by anyone providing ENUM services. > > Andy, do you agree with that classification? Should we change the > definition of "direct peering" to include such models? > Or what's your preferred definition of "assisted peering"? > Would you prefer a different name for that concept? There does need to be a "middle" case. I just see no difference between my SIP redirects and ENUM. In the end, my SIP servers will directly talk to your SIP servers. The entire section (Section 4) also seems to be lack an important operational distinction regarding the termination of calls. The relationship an ITSP may have with another ITSP is different than the relationship an ITSP may have with a carrier. An ITSP can only send calls to another ITSP than it knows can be terminated on that network, whereas any call can usually be terminated by a carrier. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 21 10:59:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFBEk-0000GW-07; Mon, 21 Aug 2006 10:58:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFBEi-0000By-Co for speermint@ietf.org; Mon, 21 Aug 2006 10:58:44 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFBEg-0008FF-28 for speermint@ietf.org; Mon, 21 Aug 2006 10:58:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] latest in speermint terminology Date: Mon, 21 Aug 2006 16:57:43 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C50CD@oefeg-s04.oefeg.loc> In-Reply-To: <5B9F5451-43B7-4DBF-8D5A-26DC66DFE3BC@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] latest in speermint terminology Thread-Index: AcbFMF63/knnJVacRPOPiWMysqRjJwAAVE4g From: "Stastny Richard" To: "Andrew Newton" , "Otmar Lendl" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > The > relationship an ITSP may have with another ITSP is different than the > relationship an ITSP may have with a carrier. An ITSP can only send > calls to another ITSP than it knows can be terminated on that > network, whereas any call can usually be terminated by a carrier. ? I cannot completely follow what you want to say here: A carrier and an ITSP can only terminate calls to subscribers he is providing service to. Anything else is transit. Richard _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 21 11:10:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFBPl-0003zE-Be; Mon, 21 Aug 2006 11:10:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFBPj-0003xP-6h for speermint@ietf.org; Mon, 21 Aug 2006 11:10:07 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFBPh-0001cu-RP for speermint@ietf.org; Mon, 21 Aug 2006 11:10:07 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k7LF9u4S025494; Mon, 21 Aug 2006 08:09:56 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k7LF9u8l025493; Mon, 21 Aug 2006 08:09:56 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 21 Aug 2006 08:09:56 -0700 From: David Meyer To: Stastny Richard Subject: Re: [Speermint] latest in speermint terminology Message-ID: <20060821150956.GA25439@1-4-5.net> References: <5B9F5451-43B7-4DBF-8D5A-26DC66DFE3BC@hxr.us> <32755D354E6B65498C3BD9FD496C7D463C50CD@oefeg-s04.oefeg.loc> Mime-Version: 1.0 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C50CD@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0993228404==" Errors-To: speermint-bounces@ietf.org --===============0993228404== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 21, 2006 at 04:57:43PM +0200, Stastny Richard wrote: > > The > > relationship an ITSP may have with another ITSP is different than the > > relationship an ITSP may have with a carrier. An ITSP can only send > > calls to another ITSP than it knows can be terminated on that > > network, whereas any call can usually be terminated by a carrier. >=20 > ? > I cannot completely follow what you want to say here: >=20 > A carrier and an ITSP can only terminate calls to subscribers he is > providing service to. >=20 > Anything else is transit. That, and we don't have a definition of ITSP (yet). I'm assuming that the definition of ITSP is as on http://en.wikipedia.org/wiki/ITSP. If so, we already have VSP, which is a synonym (unless someone disagrees).=20 --dmm --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFE6czEORgD1qCZ2KcRAuMIAJ0S+eNYIHDV0KQL4oYagQk9ZMMHVwCggfnC QYJnc6yk7wB+RdlVRwOTkhM= =b6KX -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- --===============0993228404== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0993228404==-- From speermint-bounces@ietf.org Mon Aug 21 12:49:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCxZ-0004J4-Kb; Mon, 21 Aug 2006 12:49:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCxY-0004Iw-Sy for speermint@ietf.org; Mon, 21 Aug 2006 12:49:08 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFCxT-0004ic-Mv for speermint@ietf.org; Mon, 21 Aug 2006 12:49:08 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Mon, 21 Aug 2006 12:48:59 -0400 id 01588117.44E9E3FB.000054FF Message-ID: <44E9E3F5.9030309@hxr.us> Date: Mon, 21 Aug 2006 12:48:53 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: David Meyer Subject: Re: [Speermint] latest in speermint terminology References: <5B9F5451-43B7-4DBF-8D5A-26DC66DFE3BC@hxr.us> <32755D354E6B65498C3BD9FD496C7D463C50CD@oefeg-s04.oefeg.loc> <20060821150956.GA25439@1-4-5.net> In-Reply-To: <20060821150956.GA25439@1-4-5.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org David Meyer wrote: > That, and we don't have a definition of ITSP (yet). I'm > assuming that the definition of ITSP is as on > http://en.wikipedia.org/wiki/ITSP. If so, we already have > VSP, which is a synonym (unless someone disagrees). No disagreement here. Perhaps the document should mention in the definition for VSP that ITSP is a common synonym. However, the document should only use VSP any place else (or vice versa... I'm not wed to either). -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 21 13:12:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFDKC-0004eJ-Oz; Mon, 21 Aug 2006 13:12:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFDKB-0004eE-86 for speermint@ietf.org; Mon, 21 Aug 2006 13:12:31 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFDKA-0001Bb-1y for speermint@ietf.org; Mon, 21 Aug 2006 13:12:31 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Mon, 21 Aug 2006 13:07:11 -0400 id 01588117.44E9E840.000057FC Message-ID: <44E9E83A.3030109@hxr.us> Date: Mon, 21 Aug 2006 13:07:06 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Speermint] latest in speermint terminology References: <32755D354E6B65498C3BD9FD496C7D463C50CD@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C50CD@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Stastny Richard wrote: >> The >> relationship an ITSP may have with another ITSP is different than the >> relationship an ITSP may have with a carrier. An ITSP can only send >> calls to another ITSP than it knows can be terminated on that >> network, whereas any call can usually be terminated by a carrier. > > ? > I cannot completely follow what you want to say here: > > A carrier and an ITSP can only terminate calls to subscribers he is > providing service to. > > Anything else is transit. Perhaps this miscommunication comes from my misuse of the word "carrier". I'm not sure what the bell-centric meaning of the word is, but in the environment I am in carriers are different than peers in that peers can only terminate some calls (i.e. those of their subscribers) while carriers can terminate any call. Looking at the definitions, this view does not have to be directly tied to Indirect Peering or Direct Peering. There certainly could be Indirect Peering that can only terminate a subset of calls (within a namespace). But then that makes me ask, what is the difference between Indirect Peering and Assisted Peering... they are both transit providers. And this all of this leaves out the case where a federation or exchange runs an ENUM directory or SIP redirect server that always results in Direct Peering. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 21 13:36:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFDhF-0005RP-9A; Mon, 21 Aug 2006 13:36:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFDhE-0005RC-73 for speermint@ietf.org; Mon, 21 Aug 2006 13:36:20 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFDhB-0004Pr-RM for speermint@ietf.org; Mon, 21 Aug 2006 13:36:20 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 5ECB43397; Mon, 21 Aug 2006 13:35:47 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 13:35:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] latest in speermint terminology Date: Mon, 21 Aug 2006 13:35:40 -0400 Message-ID: In-Reply-To: <20060821093732.GP19113@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] latest in speermint terminology Thread-Index: AcbFBk+M5bP59wjbR1eBfWmNeXkhvAAP3qxQ From: "Uzelac, Adam" To: "Otmar Lendl" , "Andrew Newton" X-OriginalArrivalTime: 21 Aug 2006 17:35:47.0304 (UTC) FILETIME=[3CAEBE80:01C6C548] X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I complete agree that we are missing another model here that encompasses the "assisted peering" notion. Do we need to create a new term for it? I don't know and lean towards "NO". Think of the call flow where the originating SP queries a SP that is NOT the terminating SP to satisfy a location request. This would be a communication in the Location Function portion of the SIP Peering Architrave ID. The sole purpose is to determine "Where and how do I route this call please?!?" That would be a relationship with a 3rd party apart from Originating/Termination SP relationship. This might be done for many reasons, but the most common today would probably be the "peering fabric" play. It's only a direct peering relationship for the sole purposes of identifying a route to the termination point. Once known, we have another direct peering relationship with the VSP that has the registered subscriber. If a direct peer is not accessible, then a transit peering path would be selected. As a side note and I know we are ahead of ourselves but I will bring it up anyways - this 3rd party peering or assisted peer is going to be a relationship that we will probably have to address with respects to CALEA-like requirements. The LEA will not be the SP of termination, but rather an "independent" (or parasitic) peering arrangement. Before I get flamed, I know it's out of scope, just mentioning. -AU -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Monday, August 21, 2006 5:38 AM To: Andrew Newton Cc: speermint@ietf.org Subject: Re: [Speermint] latest in speermint terminology On 2006/08/18 19:08, Andrew Newton wrote: > David Meyer wrote: > > With all (most?) of the comments I've received > > (including, Otmar, s/CRD/CAD/ :-)) > > > > http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-04.txt >=20 > Regarding 4.5: >=20 > 4.5. Assisted Peering >=20 > In this case a federation employs a central SIP proxy (which is not > itself a VSP) to bridge calls between participating networks. >=20 > First, by the term "bridge", do you mean that the signaling actually=20 > passes through the proxy? If so, what about cases where the SIP proxy > routes calls by issuing redirects? Also, what about that same=20 > functionality (the routing of calls between peers) using a directory=20 > style technology, such as ENUM (or maybe LDAP, though I don't know if anybody is doing that). My intention with that term is the following context: * "direct peering" is for when the SIP elements of both networks talk directly to each other. In between are only layer 0 to 3 devices. * "transit case": there a call is passed through a L5 transit network. I thought we need a definition for a middle case:=20 Here a fabric provider is involved in the SIP signalling (thus it's not a simple direct peering). It shouldn't matter whether it's done by redirect or forwarding SIP signalling. In these cases I'd rather avoid using the "transit" word, as the SIP proxy there is just a helper for the peering and not a fully fledged SIP Network provider who is providing transit services. ENUM (or LDAP) is a different issue: you can have someone provide ENUM services to facilitate direct peering. The term "direct peering" isn't affected by anyone providing ENUM services.=20 Andy, do you agree with that classification? Should we change the definition of "direct peering" to include such models?=20 Or what's your preferred definition of "assisted peering"? Would you prefer a different name for that concept? Cheers, /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 21 14:14:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFEHM-0000f8-UF; Mon, 21 Aug 2006 14:13:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFEHM-0000ew-E8 for speermint@ietf.org; Mon, 21 Aug 2006 14:13:40 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFE4i-0008NO-4O for speermint@ietf.org; Mon, 21 Aug 2006 14:00:44 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Mon, 21 Aug 2006 14:00:27 -0400 id 01588119.44E9F4BC.000062EF Message-ID: <44E9F4B5.6050708@hxr.us> Date: Mon, 21 Aug 2006 14:00:21 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Uzelac, Adam" Subject: Re: [Speermint] latest in speermint terminology References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Uzelac, Adam wrote: > > As a side note and I know we are ahead of ourselves but I will bring it > up anyways - this 3rd party peering or assisted peer is going to be a > relationship that we will probably have to address with respects to > CALEA-like requirements. The LEA will not be the SP of termination, but > rather an "independent" (or parasitic) peering arrangement. Before I get > flamed, I know it's out of scope, just mentioning. Regardless of how you see it, I think IETF working groups are forbidden from purposefully making standards work with CALEA. It isn't just a working group scope issue. http://www.wired.com/news/politics/0,1283,32455,00.html ... including a quote from Brian Rosen. Though I'm not sure which RFC it is. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 21 14:41:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFEiS-0002Qd-OI; Mon, 21 Aug 2006 14:41:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFEiR-0002QF-CJ for speermint@ietf.org; Mon, 21 Aug 2006 14:41:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFEiR-0007E8-Aa for speermint@ietf.org; Mon, 21 Aug 2006 14:41:39 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFEXQ-0007nq-C9 for speermint@ietf.org; Mon, 21 Aug 2006 14:30:21 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GFEX9-0002zs-Bg; Mon, 21 Aug 2006 13:30:02 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Uzelac, Adam'" Subject: RE: [Speermint] latest in speermint terminology Date: Mon, 21 Aug 2006 14:30:01 -0400 Message-ID: <13b001c6c54f$d4ae7890$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44E9F4B5.6050708@hxr.us> Thread-Index: AcbFTbqTfJX8H4BuQOOsJr4PMZ4/fAAAXdrg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.5 (--) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: speermint@ietf.org, 'Otmar Lendl' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org RFC2804. I was not quoted well, typical selective quoting. The point I made was that it was going to be done, to our work, and if we did it, it would be done well, and if someone else did it, it would likely be done poorly, and we'd all have to live with it anyways. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Monday, August 21, 2006 2:00 PM > To: Uzelac, Adam > Cc: speermint@ietf.org; Otmar Lendl > Subject: Re: [Speermint] latest in speermint terminology > > Uzelac, Adam wrote: > > > > As a side note and I know we are ahead of ourselves but I will bring it > > up anyways - this 3rd party peering or assisted peer is going to be a > > relationship that we will probably have to address with respects to > > CALEA-like requirements. The LEA will not be the SP of termination, but > > rather an "independent" (or parasitic) peering arrangement. Before I get > > flamed, I know it's out of scope, just mentioning. > > Regardless of how you see it, I think IETF working groups are forbidden > from > purposefully making standards work with CALEA. It isn't just a working > group scope issue. > > http://www.wired.com/news/politics/0,1283,32455,00.html ... including a > quote from Brian Rosen. > > Though I'm not sure which RFC it is. > > -andy > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 21 16:30:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFGPE-0006k9-Vy; Mon, 21 Aug 2006 16:29:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFGPD-0006hl-Gx for speermint@ietf.org; Mon, 21 Aug 2006 16:29:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFEC8-0001Jv-Nk for speermint@ietf.org; Mon, 21 Aug 2006 14:08:16 -0400 Received: from m106.maoz.com ([205.167.76.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFDV2-0006Ql-WE for speermint@ietf.org; Mon, 21 Aug 2006 13:23:46 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k7LHNhmT029080; Mon, 21 Aug 2006 10:23:43 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k7LHNhjD029079; Mon, 21 Aug 2006 10:23:43 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 21 Aug 2006 10:23:43 -0700 From: David Meyer To: Andrew Newton Subject: Re: [Speermint] latest in speermint terminology Message-ID: <20060821172343.GA29014@1-4-5.net> References: <5B9F5451-43B7-4DBF-8D5A-26DC66DFE3BC@hxr.us> <32755D354E6B65498C3BD9FD496C7D463C50CD@oefeg-s04.oefeg.loc> <20060821150956.GA25439@1-4-5.net> <44E9E3F5.9030309@hxr.us> Mime-Version: 1.0 In-Reply-To: <44E9E3F5.9030309@hxr.us> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: -2.5 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1349996702==" Errors-To: speermint-bounces@ietf.org --===============1349996702== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 21, 2006 at 12:48:53PM -0400, Andrew Newton wrote: > David Meyer wrote: > > That, and we don't have a definition of ITSP (yet). I'm > > assuming that the definition of ITSP is as on > > http://en.wikipedia.org/wiki/ITSP. If so, we already have > > VSP, which is a synonym (unless someone disagrees).=20 >=20 > No disagreement here. Perhaps the document should mention in the=20 > definition for VSP that ITSP is a common synonym. However, the document= =20 > should only use VSP any place else (or vice versa... I'm not wed to=20 > either). Alreay done... http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-04.txt --dmm --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFE6ewfORgD1qCZ2KcRAkfYAJ9YzUYzRDtBsi8EqivHMhvEK66oWACfX3Nh JhZWqkCsNLSgO1rOPgjrX28= =4GZc -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- --===============1349996702== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1349996702==-- From speermint-bounces@ietf.org Tue Aug 22 11:19:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFY1b-0000Gb-4B; Tue, 22 Aug 2006 11:18:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFY1Z-0000GV-Bn for speermint@ietf.org; Tue, 22 Aug 2006 11:18:41 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFY1X-0003aw-UV for speermint@ietf.org; Tue, 22 Aug 2006 11:18:41 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 1DE6D1A381; Tue, 22 Aug 2006 17:18:28 +0200 (CEST) Date: Tue, 22 Aug 2006 17:18:27 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] latest in speermint terminology Message-ID: <20060822151827.GQ19113@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <32755D354E6B65498C3BD9FD496C7D463C50CD@oefeg-s04.oefeg.loc> <44E9E83A.3030109@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44E9E83A.3030109@hxr.us> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/08/21 19:08, Andrew Newton wrote: > Stastny Richard wrote: > >>The > >>relationship an ITSP may have with another ITSP is different than the > >>relationship an ITSP may have with a carrier. An ITSP can only send > >>calls to another ITSP than it knows can be terminated on that > >>network, whereas any call can usually be terminated by a carrier. > > > >? > >I cannot completely follow what you want to say here: > > > >A carrier and an ITSP can only terminate calls to subscribers he is > >providing service to. > > > >Anything else is transit. > > Perhaps this miscommunication comes from my misuse of the word "carrier". > I'm not sure what the bell-centric meaning of the word is, but in the > environment I am in carriers are different than peers in that peers can > only terminate some calls (i.e. those of their subscribers) while carriers > can terminate any call. All that is an issue for the call routing logic. The actual peering interface should not change in any way just because traffic passing it is not just peering, but also transit. > Looking at the definitions, this view does not > have to be directly tied to Indirect Peering or Direct Peering. There > certainly could be Indirect Peering that can only terminate a subset of > calls (within a namespace). I think we should take a page out of the BGP playbook. There the protocol itself doesn't care whether one announces just one's own networks, that plus some customers, the default route or a full BGP table. The distinction between a transit relationship and a pure peering relationship is just one of route announcements and not one of the selection of the peering protocol. We should strive for the same. We shouldn't hardwire business decisions into the protocol design. In terms of terminology, I maintain it's beneficial to have a term between direct peering an transit. > But then that makes me ask, what is the > difference between Indirect Peering and Assisted Peering... they are both > transit providers. I think there is a point to that decision when you look at the inter-federation routing architecture: From a high level point of view, you are only interested whether two networks peer which each other or not. If VSPs X, Y, and Z are connected to the VoIP-peering point maintained by company A, then from the standpoint of routing I don't care whether calls from X to Y involve a SIP proxy operated by A. That's why the definition of "federation" does not require "direct peering", but also allows "assisted peering". /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 22 12:45:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFZN6-000694-WB; Tue, 22 Aug 2006 12:45:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFZN6-00068Y-3X for speermint@ietf.org; Tue, 22 Aug 2006 12:45:00 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFZMz-0000rD-Tn for speermint@ietf.org; Tue, 22 Aug 2006 12:45:00 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 22 Aug 2006 12:44:49 -0400 id 01588188.44EB3481.00006225 Message-ID: <44EB347C.8060902@hxr.us> Date: Tue, 22 Aug 2006 12:44:44 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Otmar Lendl , speermint@ietf.org Subject: Re: [Speermint] latest in speermint terminology References: <32755D354E6B65498C3BD9FD496C7D463C50CD@oefeg-s04.oefeg.loc> <44E9E83A.3030109@hxr.us> <20060822151827.GQ19113@nic.at> In-Reply-To: <20060822151827.GQ19113@nic.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar Lendl wrote: > > All that is an issue for the call routing logic. The actual peering > interface should not change in any way just because traffic passing > it is not just peering, but also transit. [..snip..] > We should strive for the same. We shouldn't hardwire business decisions > into the protocol design. You are cavalierly dismissing a real world consideration for an as-yet-to-be-defined specification. Additionally, the whole notion of designing for federations, as has been talked about in this working group, goes against the very principle from which you have drawn your conclusion. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 24 12:52:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIQK-0003tO-M8; Thu, 24 Aug 2006 12:51:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIQJ-0003tJ-VC for speermint@ietf.org; Thu, 24 Aug 2006 12:51:19 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGIQI-0007qs-PA for speermint@ietf.org; Thu, 24 Aug 2006 12:51:19 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 24 Aug 2006 12:51:13 -0400 id 0158835E.44EDD902.000077EC Message-ID: <44EDD8FC.3060207@hxr.us> Date: Thu, 24 Aug 2006 12:51:08 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: speermint@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Speermint] comments on draft-creighton-khandpur-speermint-srv-naptr-use-00 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I have a few comments on draft-creighton-khandpur-speermint-srv-naptr-use-00. 1) Figure 1 incorrectly describes how DNS works. In addition, wording in 3.2 "SPP2 MUST return at least three [NAPTR] records" makes the same mistake. DNS servers don't consult SIP proxies for DNS records, nor do SIP proxies return DNS records. 2) MUST "SIPS+D2T" does not apply to indirect peering. Why is this exception made? Shouldn't the advice be, "SIPS+D2T" MUST be returned in the absence of any security at a lower layer? Either way, there should be text explaining the reasoning. 3) Section 5 indicates that TTLs for SRV records should be 1 hour, apparently because they are more dynamic. There is no explanation of why they would be more dynamic. I have my suspicions, but a BCP ought to really explain the reasons behind the recommendations. The same goes for the MUST as it is applied to the weight of the SRV record. 4) There is no mention of having DNS servers returning A records with the SRV response in order to cut down on round trips. Nor is there discussion on using EDNS0 to alleviate truncation. Finally, there is no mention of DNSSEC. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 24 13:25:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIx4-0002mr-Ct; Thu, 24 Aug 2006 13:25:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIx3-0002ma-IV for speermint@ietf.org; Thu, 24 Aug 2006 13:25:09 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGItX-00054v-Mh for speermint@ietf.org; Thu, 24 Aug 2006 13:21:32 -0400 Received: from ([10.20.62.12]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.23573631; Thu, 24 Aug 2006 13:21:00 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 13:20:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] comments ondraft-creighton-khandpur-speermint-srv-naptr-use-00 Date: Thu, 24 Aug 2006 13:20:34 -0400 Message-ID: <2D78B9A368A52344B12011D476BD4A870FE5C8@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] comments ondraft-creighton-khandpur-speermint-srv-naptr-use-00 Thread-Index: AcbHnd6B0wq8tgp2SAKxl5d8A6Tu5AAA6YTA From: "Livingood, Jason" To: "Andrew Newton" , X-OriginalArrivalTime: 24 Aug 2006 17:20:35.0011 (UTC) FILETIME=[9C272130:01C6C7A1] X-Spam-Score: 1.1 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I didn't see the notice come through of the draft being online. For those who need a link, see http://www.ietf.org/internet-drafts/draft-creighton-khandpur-speermint-s rv-naptr-use-00.txt Jason=20 > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > Sent: Thursday, August 24, 2006 12:51 PM > To: speermint@ietf.org > Subject: [Speermint] comments=20 > ondraft-creighton-khandpur-speermint-srv-naptr-use-00 >=20 > I have a few comments on=20 > draft-creighton-khandpur-speermint-srv-naptr-use-00. >=20 > 1) Figure 1 incorrectly describes how DNS works. In=20 > addition, wording in > 3.2 "SPP2 MUST return at least three [NAPTR] records" makes=20 > the same mistake. DNS servers don't consult SIP proxies for=20 > DNS records, nor do SIP proxies return DNS records. >=20 > 2) MUST "SIPS+D2T" does not apply to indirect peering. Why=20 > is this exception made? Shouldn't the advice be, "SIPS+D2T"=20 > MUST be returned in the absence of any security at a lower=20 > layer? Either way, there should be text explaining the reasoning. >=20 > 3) Section 5 indicates that TTLs for SRV records should be 1=20 > hour, apparently because they are more dynamic. There is no=20 > explanation of why they would be more dynamic. I have my=20 > suspicions, but a BCP ought to really explain the reasons=20 > behind the recommendations. The same goes for the MUST as it=20 > is applied to the weight of the SRV record. >=20 > 4) There is no mention of having DNS servers returning A=20 > records with the SRV response in order to cut down on round=20 > trips. Nor is there discussion on using EDNS0 to alleviate=20 > truncation. Finally, there is no mention of DNSSEC. >=20 > -andy >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 29 15:47:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9Wj-0001yG-25; Tue, 29 Aug 2006 15:45:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9Wh-0001y0-OC for speermint@ietf.org; Tue, 29 Aug 2006 15:45:35 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI9Wf-0000J7-IB for speermint@ietf.org; Tue, 29 Aug 2006 15:45:35 -0400 Received: from ([10.20.62.12]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.23820691; Tue, 29 Aug 2006 15:43:00 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Aug 2006 15:44:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Aug 2006 15:44:15 -0400 Message-ID: <2D78B9A368A52344B12011D476BD4A8717D316@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Security Threat Vectors Thread-Index: AcbLo4JGP8IabzcOSl6gC9rz6sMqiQ== From: "Livingood, Jason" To: X-OriginalArrivalTime: 29 Aug 2006 19:44:16.0042 (UTC) FILETIME=[82C0D0A0:01C6CBA3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Speermint] Security Threat Vectors X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org We've been discussing VoIP Peering security threats and the like. I expect we will soon see a draft or two on the subject to inform discussion in the WG on this subject. As discussed previously, once we document the threats we can specify the defenses which would be implemented / recommended in an upcoming BCP. In the meantime, I was directed to this document by one of the attendees of the last SPEERMINT meeting: http://www.voipsa.org/Activities/VOIPSA_Threat_Taxonomy_0.1.pdf Regards Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 30 10:58:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIRVt-0006Mn-FH; Wed, 30 Aug 2006 10:57:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIRVr-0006Mi-K0 for speermint@ietf.org; Wed, 30 Aug 2006 10:57:55 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIRVo-0005OP-44 for speermint@ietf.org; Wed, 30 Aug 2006 10:57:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6CC44.9B860E88" Date: Wed, 30 Aug 2006 10:57:26 -0400 Message-ID: <2D78B9A368A52344B12011D476BD4A8717D47A@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Final Agenda & Other Notes: SPEERMINT Interim Meeting #1 - September 18 - 19, 2006 Thread-Index: AcbMRJs6M5ecdMEHTQqc2IpbnYsT0Q== From: "Livingood, Jason" To: X-OriginalArrivalTime: 30 Aug 2006 14:57:26.0614 (UTC) FILETIME=[9B8C3F60:01C6CC44] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Subject: [Speermint] Final Agenda & Other Notes: SPEERMINT Interim Meeting #1 - September 18 - 19, 2006 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6CC44.9B860E88 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I am attaching the latest version of the agenda, which should hopefully be the final version. =20 REMOTE: For those of you unable to attend in person, THERE WILL BE A CONFERENCE BRIDGE (Jabber room TBD): Dial +1-866-427-3611 (from overseas, you can dial +1-702-599-4015), then enter passcode 215-981-7813. IN PERSON: As of right now, these are the people who have sent an RSVP and who will be attending. If your name is NOT on this list and you plan to attend, we are not aware of this. If that is the case, please email me privately ASAP! 1 Chris Celiberti 2 Tom Creighton 3 Geoff Devine 4 Martin Dolly 5 Michael Haberler 6 Avshalom Houri 7 Alan Johnston 8 Hadrien Kaplan 9 Sohel Khan 10 Gaurav Khandpur 11 Yiu Lee 12 Otmar Lendl 13 Alex Leung 14 Gene Lew 15 Jason Livingood 16 Daryl Malas 17 Jim McEachern 18 Patrick Melampy 19 Dave Meyer 20 Jean-Francois Mule 21 Andy Newton 22 Adam O'Donnell 23 Bob Penfield 24 Reinaldo Penno 25 Jonathan Peterson 26 Penn Pfautz 27 Brian Rosen 28 Jonathan Rosenberg 29 David Schwartz 30 Richard Stastny 31 Hannes Tschofenig 32 Adam Uzelac Regards Jason ------_=_NextPart_001_01C6CC44.9B860E88 Content-Type: text/plain; name="speermint_agenda_interim_1 - v14.txt" Content-Transfer-Encoding: base64 Content-Description: speermint_agenda_interim_1 - v14.txt Content-Disposition: attachment; filename="speermint_agenda_interim_1 - v14.txt" U2Vzc2lvbiBQRUVSaW5nIGZvciBNdWx0aW1lZGlhIElOVGVyY29ubmVjdCAoc3BlZXJtaW50KQ0K DQpTUEVFUk1JTlQgSW50ZXJpbSBNZWV0aW5nICMxDQoNCkRhdGU6IFNlcHRlbWJlciAxOCAtIDE5 LCAyMDA2DQoNCkxvY2F0aW9uOiBQaGlsYWRlbHBoaWEsIFBBLCBVU0EgKENlbnRlciBDaXR5IC8g RG93bnRvd24pDQoNCk1lZXRpbmcgTG9jYXRpb246ICBUaGUgSHViIC0gQ2l0eVZpZXcgTG9jYXRp b24sIGluIHRoZSBLZXlzdG9uZSBSb29tDQoJCSAgIFVuaXRlZCBQbGF6YSBCdWlsZGluZyANCgkJ ICAgMzAgU291dGggMTd0aCBTdHJlZXQNCgkJICAgMTR0aCBGbG9vcg0KCQkgICBQaGlsYWRlbHBo aWEsIFBBIDE5MTAzDQoJCSAgIFBob25lOiAxLTg3Ny1USEVIVUItMQ0KCQkgICBEaXJlY3Rpb25z OiAgaHR0cDovL3d3dy50aGVodWIuY29tL21hcHMucGhwIA0KCQkgICBNYXA6IGh0dHA6Ly9tYXBz Lmdvb2dsZS5jb20vbWFwcz9mPXEmaGw9ZW4mcT0zMCtTKzE3dGgrU3QsKzE5MTAzJmllPVVURjgm bGw9MzkuOTUxNDQ4LC03NS4xNjgwMjgmc3BuPTAuMDA3MjM4LDAuMDIxMjg2Jm9tPTENCg0KQ29u ZmVyZW5jZSBCcmlkZ2U6IERpYWwgKzEtODY2LTQyNy0zNjExIChmcm9tIG92ZXJzZWFzLCB5b3Ug Y2FuIGRpYWwgKzEtNzAyLTU5OS00MDE1KSwgdGhlbiBlbnRlciBwYXNzY29kZSAyMTUtOTgxLTc4 MTMuDQoNCk9iamVjdGl2ZTogIFRvIGhhdmUgZGV0YWlsZWQgZGViYXRlIGFuZCBkaXNjdXNzaW9u IG9mIG9wZW4gaXNzdWVzIGZvciBjdXJyZW50IFdHIGRyYWZ0cyBhbmQgbW92ZSBhaGVhZCB3b3Jr IGl0ZW1zIG1vcmUgcXVpY2tseSB0aGFuIHdlIGNhbiBieSBoYXZpbmcgYSAyIGhvdXIgbWVldGlu ZyBldmVyeSA0IG1vbnRocyBhdCB0aGUgbWFpbiBJRVRGIG1lZXRpbmdzLiAgQWxzbywga2ljay1v ZmYgbmV3IFdHIGl0ZW1zIGluIGRldGFpbCBhbmQgbWFrZSByYXBpZCBwcm9ncmVzcyB0b3dhcmRz IGFjaGlldmluZyBXRyBtaWxlc3RvbmVzLiANCg0KTWVldGluZyBTcG9uc29yOiAgQ29tY2FzdA0K DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KDQpDSEFJUlM6CSAgICBEYXZpZCBNZXllciAgICAgIAk8ZG1tQDEtNC01 Lm5ldD4NCgkgICAgSmFzb24gTGl2aW5nb29kICAJPGphc29uX2xpdmluZ29vZEBjYWJsZS5jb21j YXN0LmNvbT4NCg0KU0VDUkVUQVJZOiAgQWxleGFuZGVyIE1heXJob2ZlciA8YWxleGFuZGVyLm1h eXJob2ZlckBuaWMuYXQ+DQoNClRFTlRBVElWRSBBR0VOREENCg0KRGF5IDEJMDgxNSAtIDE4MDAN Cg0KICAgMCAtICBSZWdpc3RyYXRpb24gJiBDb250aW5lbnRhbCBCcmVha2Zhc3QJCQkJNDUgbWlu dXRlcwkvLyAJMDgxNSAtIDA5MDANCg0KPE9WRVJWSUVXPg0KDQogICAxIC0gIFJldmlldyBvZiBB Z2VuZGEsIE1lZXRpbmcgTG9naXN0aWNzLCBhbmQgV2VsY29tZQkJMzAgbWludXRlcwkvLwkwOTAw IC0gMDkzMA0KCUdlbmVyYWwgUGhpbG9zb3BoeSAmIEZvY3VzIG9mIE1lZXRpbmcsIFdHIE9iamVj dGl2ZXMNCgkgSmFzb24gTGl2aW5nb29kICYgRGF2ZSBNZXllcg0KDQo8UFJPR1JFU1MgT0ZGSUNJ QUwgV0cgRFJBRlRTPg0KDQogICAyIC0gIERpc2N1c3MgYW5kIENsb3NlIE91dCBSZW1haW5pbmcg SXNzdWVzIChQYXJ0IDEpCQkJNjAgbWludXRlcwkvLwkwOTMwIC0gMTAzMA0KCVNQRUVSTUlOVCBU ZXJtaW5vbG9neSBEcmFmdA0KCWRyYWZ0LWlldGYtc3BlZXJtaW50LXRlcm1pbm9sb2d5LVhYDQoJ ICBEYXZlIE1leWVyDQoNCiAgIDMgLSAgQlJFQUsJCQkJCQkJCTE1IG1pbnV0ZXMgCS8vCTEwMzAg LSAxMDQ1DQoNCiAgIDQgLSAgRGlzY3VzcyBPcGVuIElzc3VlcyBhbmQgUXVlc3Rpb25zIFBvc2Vk IEJ5IEVkaXRvciAoUGFydCAxKQk2MCBtaW51dGVzCS8vCTEwNDUgLSAxMTQ1DQogICAgCU1pbmlt dW0gU2V0IG9mIFJlcXVpcmVtZW50cyBmb3IgU0lQLUJhc2VkIFZvSVAgSW50ZXJjb25uZWN0aW9u DQoJZHJhZnQtaWV0Zi1zcGVlcm1pbnQtcmVxdWlyZW1lbnRzLVhYDQoJICBKZWFuLUZyYW5jb2lz IE11bGUNCg0KICAgNSAtICBMVU5DSAkJCQkJCQkJOTAgbWludXRlcwkvLwkxMTQ1IC0gMTMxNQ0K CU9uIFlvdXIgT3duLCBJbiBMb2NhbCBBcmVhDQoNCiAgIDYgLSAgRGlzY3VzcyBPcGVuIElzc3Vl cyBhbmQgUXVlc3Rpb25zIFBvc2VkIEJ5IEVkaXRvciAoUGFydCAyKQk2MCBtaW51dGVzCS8vCTEz MTUgLSAxNDE1DQogICAgCU1pbmltdW0gU2V0IG9mIFJlcXVpcmVtZW50cyBmb3IgU0lQLUJhc2Vk IFZvSVAgSW50ZXJjb25uZWN0aW9uDQoJZHJhZnQtaWV0Zi1zcGVlcm1pbnQtcmVxdWlyZW1lbnRz LVhYDQoJICBKZWFuLUZyYW5jb2lzIE11bGUNCg0KICAgNyAtICBSZXZpZXcgYW5kIERpc2N1c3Mg TmV3IFdHIERyYWZ0IChQYXJ0IDEpDQoJTWVzc2FnZSBGbG93cyBBc3NvY2lhdGVkIHdpdGggU1BF RVJNSU5UIFJvdXRpbmcgQXJjaGl0ZWN0dXJlCTMwIG1pbnV0ZXMJLy8JMTQxNSAtIDE0NDUNCiAg ICAJZHJhZnQtaWV0Zi1zcGVlcm1pbnQtbWVzc2FnZS1mbG93cy1YWCANCgkgIFJlaW5hbGRvIFBl bm5vDQoNCiAgIDggLSAgQlJFQUsJCQkJCQkJCTE1IG1pbnV0ZXMgCS8vCTE0NDUgLSAxNTAwDQoN CiAgIDkgLSAgUmV2aWV3IGFuZCBEaXNjdXNzIE5ldyBXRyBEcmFmdCAoUGFydCAyKQ0KCU1lc3Nh Z2UgRmxvd3MgQXNzb2NpYXRlZCB3aXRoIFNQRUVSTUlOVCBSb3V0aW5nIEFyY2hpdGVjdHVyZQkz MCBtaW51dGVzCS8vCTE1MDAgLSAxNTMwDQogICAgCWRyYWZ0LWlldGYtc3BlZXJtaW50LW1lc3Nh Z2UtZmxvd3MtWFggDQoJICBSZWluYWxkbyBQZW5ubw0KDQogICAxMCAtIEV4cGVydCBCcmllZmlu ZzogVm9JUCBTZWN1cml0eSwgVHJ1c3QsIEF0dGFjayBWZWN0b3JzCQk0NSBtaW51dGVzIAkvLwkx NTMwIC0gMTYxNQ0KCUludGVuZGVkIHRvIEluZm9ybSBTZWN1cml0eSAmIFRydXN0IFJlcXVpcmVt ZW50cywgRWR1Y2F0ZSBXRw0KCSAgQWRhbSBPJ0Rvbm5lbGwgDQoNCiAgIDExIC0gIEJSRUFLCQkJ CQkJCQkxMCBtaW51dGVzIAkvLwkxNjE1IC0gMTYyNQ0KDQogICAxMiAtIFJldmlldyBhbmQgRGlz Y3VzcyBOZXcgSW5kaXZpZHVhbCBEcmFmdAkJCQkzNSBtaW51dGVzCS8vCTE2MjUgLSAxNzAwDQoJ VXNlIG9mIEROUyBTUlYgYW5kIE5BUFRSIFJlY29yZHMgZm9yIFNQRUVSTUlOVCANCglkcmFmdC1j cmVpZ2h0b24ta2hhbmRwdXItc3BlZXJtaW50LXNydi1uYXB0ci11c2UtWFgNCgkgIFRvbSBDcmVp Z2h0b24NCg0KICAgMTMgLSBDbG9zZSBNZWV0aW5nIERheSAJCQkJCQkxNSBtaW51dGVzCS8vCTE3 MDAgLSAxNzE1DQoJRGlubmVyIExvZ2lzdGljcw0KCVJldmlldyBEYXkgMiBBZ2VuZGENCgkgIEph c29uIExpdmluZ29vZA0KDQo8QUZURVIgSE9VUlM+DQoJDQoJU3BvbnNvcmVkIEdyb3VwIERpbm5l ciAJCQkJCQkJCS8vCTE4MzAgLSAyMTAwDQoJICBCdWRkYWthbiAoYXNpYW4gZnVzaW9uIG1lbnUp DQoJICAzMjUgQ2hlc3RudXQgU3RyZWV0DQoJICBQaGlsYWRlbHBoaWEsIFBBIDE5MTA2DQoJICAx LTIxNS01NzQtOTQ0MA0KCSAgaHR0cDovL3d3dy5idWRkYWthbi5jb20NCg0KRGF5IDIgCTA4MzAg LSAxNTAwDQoNCiAgIDEgLSAgQ29udGluZW50YWwgQnJlYWtmYXN0CQkJCQkJMzAgbWludXRlcyAJ Ly8JMDgzMCAtIDA5MDANCg0KICAgMiAtICBGZWRlcmF0aW9ucyBEaXNjdXNzaW9uCQkJCQkJNjAg bWludXRlcwkvLwkwOTAwIC0gMTAwMA0KCSAgTWljaGFlbCBIYWJlcmxlcg0KDQogICAzIC0gIEFy Y2hpdGVjdHVyZSBEcmFmdHMgUmV2aWV3LCBEZWJhdGUsIERpc2N1c3Npb24gKFBhcnQgMSkJCTMw IG1pbnV0ZXMJLy8JMTAwMCAtIDEwMzANCglkcmFmdC1pZXRmLXNwZWVybWludC1hcmNoaXRlY3R1 cmUtWFgNCgkgIFJlaW5hbGRvIFBlbm5vDQoNCiAgIDQgLSAgQlJFQUsJCQkJCQkJCTE1IG1pbnV0 ZXMJLy8JMTAzMCAtIDEwNDUNCg0KICAgNSAtICBBcmNoaXRlY3R1cmUgRHJhZnRzIFJldmlldywg RGViYXRlLCBEaXNjdXNzaW9uIChQYXJ0IDIpCQkzMCBtaW51dGVzCS8vCTEwNDUgLSAxMTE1DQoJ ZHJhZnQtaWV0Zi1zcGVlcm1pbnQtYXJjaGl0ZWN0dXJlLVhYDQoJICBSZWluYWxkbyBQZW5ubw0K DQogICA2IC0gCUV4cGVydCBCcmllZmluZzogVm9JUCBTZWN1cml0eSwgVHJ1c3QsIEF0dGFjayBW ZWN0b3JzICAJCTQ1IG1pbnV0ZXMgCS8vIAkxMTE1IC0gMTIwMA0KIAlJbnRlbmRlZCB0byBJbmZv cm0gU2VjdXJpdHkgJiBUcnVzdCBSZXF1aXJlbWVudHMsIEVkdWNhdGUgV0cNCiAgIAkgIEFsYW4g Sm9obnN0b24NCg0KICAgNyAtICBMVU5DSAkJCQkJCQkJOTAgbWludXRlcwkvLwkxMjAwIC0gMTMz MA0KCU9uIFlvdXIgT3duLCBJbiBMb2NhbCBBcmVhDQoNCjxGSU5BTCBSRVZJRVcgJiBDT05TRU5T VVM+DQoNCiAgIDggLSAgRmluYWwgUmV2aWV3IG9mIElzc3VlcyAmIENvbnNlbnN1cyBBZ3JlZW1l bnQJCQkxNSBtaW51dGVzCS8vCTEzMzAgLSAxMzQ1DQoJU1BFRVJNSU5UIFRlcm1pbm9sb2d5IERy YWZ0DQoJZHJhZnQtaWV0Zi1zcGVlcm1pbnQtdGVybWlub2xvZ3ktWFgNCgkgIERhdmUgTWV5ZXIN Cg0KICAgOSAtICBGaW5hbCBSZXZpZXcgb2YgSXNzdWVzICYgQ29uc2Vuc3VzIEFncmVlbWVudAkJ CTMwIG1pbnV0ZXMJLy8JMTM0NSAtIDE0MTUNCiAgICAJTWluaW11bSBTZXQgb2YgUmVxdWlyZW1l bnRzIGZvciBTSVAtQmFzZWQgVm9JUCBJbnRlcmNvbm5lY3Rpb24NCglkcmFmdC1pZXRmLXNwZWVy bWludC1yZXF1aXJlbWVudHMtWFgNCgkgIEplYW4tRnJhbmNvaXMgTXVsZQ0KDQogICAxMCAtIEZp bmFsIFJldmlldyBvZiBJc3N1ZXMgJiBDb25zZW5zdXMgQWdyZWVtZW50DQoJTWVzc2FnZSBGbG93 cyBBc3NvY2lhdGVkIHdpdGggU1BFRVJNSU5UIFJvdXRpbmcgQXJjaGl0ZWN0dXJlCTMwIG1pbnV0 ZXMJLy8JMTQxNSAtIDE0NDUNCiAgICAJZHJhZnQtaWV0Zi1zcGVlcm1pbnQtbWVzc2FnZS1mbG93 cy1YWCANCgkgIFJlaW5hbGRvIFBlbm5vDQoNCiAgIDExIC0gTWVldGluZyBDbG9zZXMJCQkJCQkJ MTUgbWludXRlcwkvLwkxNDQ1IC0gMTUwMA0KICAJUmV2aWV3IG9mIEFjdGlvbiBJdGVtcyBhbmQg UGxhbm5pbmcgZm9yIE5leHQgSUVURiBNZWV0aW5nCQ0KCSAgSmFzb24gTGl2aW5nb29kICYgRGF2 ZSBNZXllcg0KDQoNCjxNZWV0aW5nIExvY2F0aW9uIExvZ2lzdGljcz4NCglBaXJwb3J0OiBQSEws IFBoaWxhZGVscGhpYSBJbnRlcm5hdGlvbmFsIEFpcnBvcnQNCgkgIGh0dHA6Ly93d3cucGhsLm9y Zw0KDQoJVHJhbnNwb3J0YXRpb24gZnJvbSBQSEwgdG8gQ2VudGVyIENpdHk6IFIxIEFpcnBvcnQg RXhwcmVzcyBUcmFpbiAofiQ1IGFuZCAyMCBtaW5zKSBvciBUYXhpICh+JDI1KQ0KICAgICAgICAt PiBUaGUgdHJhaW4gaXMgcHJvYmFibHkgdGhlIGZhc3Rlc3Qgcm91dGUsIHVubGVzcyB5b3UgYXJl IHRyYXZlbGluZyBvdmVyIGEgd2Vla2VuZCBvciBvZmYtcGVhayB0aW1lLg0KICAgICAgICAtPiBE ZXRhaWxlZCBkaXJlY3Rpb25zIHRvIHRoZSB0cmFpbiBmcm9tIHlvdXIgdGVybWluYWwgYW5kIGZy b20gdGhlIHN0YXRpb24gdG8geW91ciBob3RlbCB3aWxsIGJlIHByb3ZpZGVkIGJlZm9yZSB0aGUg bWVldGluZy4NCiAgICAgICAgLT4gQnV5IHlvdXIgdGlja2V0IGJlZm9yZSB5b3UgYm9hcmQgdGhl IHBsYW5lIChhdXRvbWF0ZWQgbWFjaGluZXMgb24gcGxhdGZvcm0pIHRvIHNhdmUgbW9uZXkuDQoJ LT4gR2V0IHRoZSBzY2hlZHVsZSBhdCBodHRwOi8vd3d3LnNlcHRhLm9yZy9zZXJ2aWNlL3NjaGVk L3BkZnMvUjFBaXJwb3J0LnBkZg0KDQoJQ2VudHJhbCBUcmFpbiBTdGF0aW9uOiBBbXRyYWsncyAz MCBTdHJlZXQgU3RhdGlvbiAoNSAtIDEwIG1pbnMgdGF4aSB0byBtZWV0aW5nIGxvY2F0aW9uKQ0K ICAgICAgICAtPiBDb25uZWN0aW5nIHdpdGggV2FzaGluZ3RvbiwgRC5DLiwgTmV3IFlvcmssIEJv c3RvbiwgZXRjLiAgDQogICAgICAgIC0+IElmIHVzaW5nIEFtdHJhaywgQWNlbGEgaGlnaC1zcGVl ZCBzZXJ2aWNlIGlzIHJlY29tbWVuZGVkLiAgWW91IHdpbGwgbmVlZCB0byBtYWtlIGEgcmVzZXJ2 YXRpb24gZm9yIEFjZWxhIHNlcnZpY2UuDQoNCglDb252ZW50aW9uICYgVmlzaXRvcnMgQnVyZWF1 OiAgaHR0cDovL3d3dy5wY3ZiLm9yZy9hYl9waGlsL2ludGVybmF0aW9uYWwuYXNwDQoNCglDaXR5 IG9mIFBoaWxhZGVscGhpYSBWaXNpdG9yJ3MgR3VpZGU6IGh0dHA6Ly93d3cucGhpbGEuZ292L3Zp c2l0b3JzL3RyYXZlbC5odG1sDQoNCglHZW5lcmFsIFZpc2l0b3IncyBJbmZvcm1hdGlvbiBXZWJz aXRlOiBodHRwOi8vd3d3LmdvcGhpbGEuY29tDQoNCglIT1RFTFM6DQoNCgkqIFlvdSBtdXN0IGNv bnRhY3QgdGhlIGhvdGVsICpkaXJlY3RseSogdG8gdXNlIHRoZXNlIHNwZWNpYWwgcmF0ZXMuDQoN CgkqIFlvdSBtdXN0IGluZm9ybSB0aGUgaG90ZWwgdGhhdCB5b3UgYXJlIGNvbWluZyB0byBhIENv bWNhc3Qtc3BvbnNvcmVkIG1lZXRpbmcgYW5kIGFyZSByZXF1ZXN0aW5nIHRoZSBDb21jYXN0IHJh dGUuDQoNCgkqIFBsZWFzZSBjb250YWN0IE1ycy4gQWlkYSBTcGFydGEgaWYgeW91IGhhdmUgQU5Z IGRpZmZpY3VsdHkgbWFraW5nIHJlc2VydmF0aW9ucyBvciBuZWVkIHJlbGF0ZWQgYXNzaXN0YW5j ZS4gU2hlJ3MgYXQgQWlkYV9TcGFydGFAY2FibGUuY29tY2FzdC5jb20gb3IgKzEtMjE1LTk4MS03 NTAwLg0KDQoJT1BUSU9OICMxIC0gMSBCbG9jayBXYWxrIGZyb20gTWVldGluZw0KCSAgU29maXRl bCBQaGlsYWRlbHBoaWENCgkgICAgMTIwIFNvdXRoIDE3dGggU3RyZWV0DQoJICAgIGh0dHA6Ly93 d3cuc29maXRlbC5jb20vc29maXRlbC9maWNoZWhvdGVsL2diL3NvZi8yNzQxL2ZpY2hlX2hvdGVs LnNodG1sDQoJICAgIFBob25lICsxLTIxNS01NjktODMwMCANCiAgICAgICAgICAgIC0+IFNwZWNp YWwgUm9vbSBSYXRlID0gVVMkMTc1DQogICAgICAgICAgICAtPiBTcGVjaWFsIFN1aXRlIFJhdGUg PSBVUyQyMTUNCg0KCU9QVElPTiAjMiAmIDMgLSBXaXRoaW4gYSAxMCBtaW51dGUgd2Fsay4gDQoN CiAJICBDb3VydHlhcmQgYnkgTWFycmlvdHQNCiAgIAkgICAgMjEgTi4gSnVuaXBlciBTdHJlZXQg YXQgQ2l0eSBIYWxsDQogICAJICAgIGh0dHA6Ly9tYXJyaW90dC5jb20vcHJvcGVydHkvcHJvcGVy dHlQYWdlL3BobGRjDQogICAJICAgIFBob25lIDEtMjE1LTQ5Ni0zMjAwDQogICAJICAgIFJlZ3Vs YXIgcm9vbSA9ICQxMDkgcGVyIG5pZ2h0IA0KDQogCSAgTG9ld3MgSG90ZWwNCiAgIAkgICAgMTIw MCBNYXJrZXQgU3RyZWV0DQogICAJICAgIGh0dHA6Ly93d3cubG9ld3Nob3RlbHMuY29tL2hvdGVs cy9waGlsYWRlbHBoaWEvZGVmYXVsdC5hc3ANCiAgIAkgICAgUGhvbmUgMS0yMTUtNjI3LTEyMDAN CiAgIAkgICAgUmVndWxhciByb29tID0gJDEwOSBwZXIgbmlnaHQgDQoNCjwvRU5EIE9GIEFHRU5E QT4= ------_=_NextPart_001_01C6CC44.9B860E88 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint ------_=_NextPart_001_01C6CC44.9B860E88-- From speermint-bounces@ietf.org Wed Aug 30 12:21:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISog-0001Jk-Ce; Wed, 30 Aug 2006 12:21:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISof-0001Jf-8L for speermint@ietf.org; Wed, 30 Aug 2006 12:21:25 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GISob-0004A5-3m for speermint@ietf.org; Wed, 30 Aug 2006 12:21:25 -0400 Received: from localhost (localhost.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0EE84200C8E1 for ; Wed, 30 Aug 2006 18:21:46 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06378-08 for ; Wed, 30 Aug 2006 18:21:45 +0200 (CEST) Received: from venus.office (venus.office [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id E2F7220031DB for ; Wed, 30 Aug 2006 18:21:45 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6CC50.52D5D89F" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Speermint] Security Threat Vectors Date: Wed, 30 Aug 2006 18:21:17 +0200 Message-ID: <6D28EBC684A4D94096217AD2FE400873BA5B1A@venus.office> In-Reply-To: <2D78B9A368A52344B12011D476BD4A8717D316@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Security Threat Vectors Thread-Index: AcbLo4JGP8IabzcOSl6gC9rz6sMqiQAq5spQ From: "Saverio Niccolini" To: X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6CC50.52D5D89F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I have submitted yesterday a draft on VoIP Threats: https://datatracker.ietf.org/public/idindex.cgi?command=3Did_detail&id=3D= 151 18 The document should be uploaded soon (the IETF web site still says: Page not found) and it is attached here for your reference. As you can see from the acknowledgement section I already had a closer look at VOIPSA document Jason is linking and I just made minor upodate to the taxonomy part. The other parts are new. I will let the chairs have a presentation describing this draft for the interim meeting, I will try to be present remotely by Jabber at least. Please feel free to send comments on the draft. Cheers, Saverio > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Tuesday, August 29, 2006 9:44 PM > To: speermint@ietf.org > Subject: [Speermint] Security Threat Vectors >=20 > We've been discussing VoIP Peering security threats and the like. I > expect we will soon see a draft or two on the subject to inform > discussion in the WG on this subject. As discussed=20 > previously, once we > document the threats we can specify the defenses which would be > implemented / recommended in an upcoming BCP. >=20 > In the meantime, I was directed to this document by one of=20 > the attendees > of the last SPEERMINT meeting: >=20 > http://www.voipsa.org/Activities/VOIPSA_Threat_Taxonomy_0.1.pdf >=20 > Regards > Jason >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 ------_=_NextPart_001_01C6CC50.52D5D89F Content-Type: text/plain; name="draft-niccolini-speermint-voipthreats-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-niccolini-speermint-voipthreats-00.txt Content-Disposition: attachment; filename="draft-niccolini-speermint-voipthreats-00.txt" CgoKU1BFRVJNSU5UIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgUy4gTmljY29saW5pCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5FQwpJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjksIDIwMDYKRXhwaXJl czogTWFyY2ggMiwgMjAwNwoKCiAgICAgICAgICAgICAgICAgICAgICAgICBWb0lQIFNlY3VyaXR5 IFRocmVhdHMKICAgICAgICAgICAgICAgIGRyYWZ0LW5pY2NvbGluaS1zcGVlcm1pbnQtdm9pcHRo cmVhdHMtMDAKClN0YXR1cyBvZiB0aGlzIE1lbW8KCiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRl cm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueQogICBhcHBsaWNhYmxl IHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZQog ICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Ig c2hlIGJlY29tZXMKICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0 aCBTZWN0aW9uIDYgb2YgQkNQIDc5LgogICBUaGlzIGRvY3VtZW50IG1heSBub3QgYmUgbW9kaWZp ZWQsIGFuZCBkZXJpdmF0aXZlIHdvcmtzIG9mIGl0IG1heSBub3QKICAgYmUgY3JlYXRlZCwgZXhj ZXB0IHRvIHB1Ymxpc2ggaXQgYXMgYW4gUkZDIGFuZCB0byB0cmFuc2xhdGUgaXQgaW50bwogICBs YW5ndWFnZXMgb3RoZXIgdGhhbiBFbmdsaXNoLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3Jr aW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAo SUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdAogICBv dGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRl cm5ldC0KICAgRHJhZnRzLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMg dmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwg cmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUu ICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNl CiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dy ZXNzLiIKCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nl c3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuCgog ICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFj Y2Vzc2VkIGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuCgogICBUaGlzIElu dGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE1hcmNoIDIsIDIwMDcuCgpDb3B5cmlnaHQgTm90 aWNlCgogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA2KS4KCgoKCgoK CgoKCgpOaWNjb2xpbmkgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMiwgMjAwNyAgICAg ICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBWb0lQ IFRocmVhdHMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMDYKCgpBYnN0cmFjdAoKICAgVGhp cyBtZW1vIHByZXNlbnRzIHRoZSBkaWZmZXJlbnQgc2VjdXJpdHkgdGhyZWF0cyByZWxhdGVkIHRv IFZvSVAuCiAgIEZpcnN0IG9mIGFsbCBhIHRheG9ub215IGZvciB0aGUgZGlmZmVyZW50IHR5cGVz IG9mIHNlY3VyaXR5IHRocmVhdHMKICAgaXMgZGVmaW5lZC4gIEFmdGVyd2FyZHMgdGhlIGRpZmZl cmVudCBpbnN0YW5jZXMgb2YgdGhlIHRocmVhdHMgYXJlCiAgIGJyaWVmbHkgYW5hbHl6ZWQgZm9s bG93aW5nIHN1Y2ggdGF4b25vbXkuICBGaW5hbGx5IHRoZSBleGlzdGluZwogICBzZWN1cml0eSBz b2x1dGlvbnMgaW4gU0lQIGFuZCBSVFAvUlRDUCBhcmUgcHJlc2VudGVkIHRvIGRlc2NyaWJlIHRo ZQogICBjb3VudGVybWVhc3VyZXMgY3VycmVudGx5IGF2YWlsYWJsZSBmb3Igc3VjaCB0aHJlYXRz LiAgVGhlIG9iamVjdGl2ZQogICBvZiB0aGlzIGRvY3VtZW50IGlzIHRvIGlkZW50aWZ5IGFuZCBl bnVtZXJhdGUgdGhlIFZvSVAgdGhyZWF0IHZlY3RvcnMKICAgaW4gb3JkZXIgdG8gc3BlY2lmaXkg c2VjdXJpdHktcmVsYXRlZCByZXF1aXJlbWVudHMgc3BlY2lmaWMgdG8KICAgcGVlcmluZy4gIE9u Y2UgdGhlIHJlcXVpcmVtZW50cyBhcmUgaWRlbnRpZmllZCwgbWV0aG9kcyBhbmQgc29sdXRpb25z CiAgIGhvdyB0byBhY2hpZXZlIHN1Y2ggcmVxdWlyZW1lbnRzIGNhbiBiZSBzZWxlY3RlZC4KCgpU YWJsZSBvZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzCgogICAyLiAgVGF4b25vbXkgb2YgVm9J UCBTZWN1cml0eSBUaHJlYXRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgICAy LjEuICBJbnRlcmNlcHRpb24gYW5kIE1vZGlmaWNhdGlvbiBUaHJlYXRzICAuIC4gLiAuIC4gLiAu IC4gLiAuICA0CiAgICAgMi4yLiAgSW50ZXJydXB0aW9uIG9mIFNlcnZpY2UgVGhyZWF0cyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAgIDIuMy4gIEFidXNlIG9mIFNlcnZpY2UgVGhy ZWF0cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYKICAgICAyLjQuICBTb2Np YWwgVGhyZWF0cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2 CgogICAzLiAgT3ZlcnZpZXcgb2YgVm9JUCBTZWN1cml0eSBTb2x1dGlvbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDgKCiAgIDQuICBDb25jbHVzaW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMAoKICAgNS4gIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCgogICA2 LiAgQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTIKCiAgIDcuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwoKICAgQXV0aG9yJ3MgQWRkcmVzcyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0CiAgIEludGVsbGVj dHVhbCBQcm9wZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4g LiAxNQoKCgoKCgoKCgoKCgoKCgpOaWNjb2xpbmkgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWFy Y2ggMiwgMjAwNyAgICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICBWb0lQIFRocmVhdHMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMDYKCgox LiAgSW50cm9kdWN0aW9uCgogICBXaXRoIFZvSVAsIHRoZSBuZWVkIGZvciBzZWN1cml0eSBpcyBj b21wb3VuZGVkIGJlY2F1c2UgdGhlcmUgaXMgdGhlCiAgIG5lZWQgdG8gcHJvdGVjdCBib3RoIHRo ZSBjb250cm9sIHBsYW5lIGFuZCB0aGUgZGF0YSBwbGFuZS4gIEluIGEKICAgbGVnYWN5IHRlbGVw aG9uZSBzeXN0ZW0sIHNlY3VyaXR5IGlzIGEgbW9yZSB2YWxpZCBhc3N1bXB0aW9uLgogICBJbnRl cmNlcHRpbmcgY29udmVyc2F0aW9ucyByZXF1aXJlcyBlaXRoZXIgcGh5c2ljYWwgYWNjZXNzIHRv CiAgIHRlbGVwaG9uZSBsaW5lcyBvciB0byBjb21wcm9taXNlIHRoZSBQdWJsaWMgU3dpdGNoZWQg VGVsZXBob25lCiAgIE5ldHdvcmsgKFBTVE4pIG5vZGVzIG9yIHRoZSBvZmZpY2UgUHJpdmF0ZSBC cmFuY2ggZVhjaGFuZ2VzIChQQlhzKS4KICAgT25seSBwYXJ0aWN1bGFybHkgc2VjdXJpdHktc2Vu c2l0aXZlIG9yZ2FuaXphdGlvbnMgYm90aGVyIHRvIGVuY3J5cHQKICAgdm9pY2UgdHJhZmZpYyBv dmVyIHRyYWRpdGlvbmFsIHRlbGVwaG9uZSBsaW5lcy4gIEluIGNvbnRyYXN0LCB0aGUKICAgcmlz ayBvZiBzZW5kaW5nIHVuZW5jcnlwdGVkIGRhdGEgYWNyb3NzIHRoZSBJbnRlcm5ldCBpcyBtb3Jl CiAgIHNpZ25pZmljYW50IChlLmcuICBEVE1GIHRvbmVzIGNvcnJlc3BvbmRpbmcgdG8gdGhlIGNy ZWRpdCBjYXJkCiAgIG51bWJlcikuICBBbiBhZGRpdGlvbmFsIHNlY3VyaXR5IHRocmVhdCB0byBJ bnRlcm5ldCBUZWxlcGhvbnkgY29tZXMKICAgZnJvbSB0aGUgZmFjdCB0aGF0IHRoZSBzaWduYWxp bmcgaXMgc2VudCB1c2luZyB0aGUgc2FtZSBuZXR3b3JrIGFzCiAgIHRoZSBtdWx0aW1lZGlhIGRh dGE7IHRyYWRpdGlvbmFsIHRlbGVwaG9uZSBzeXN0ZW1zIGhhdmUgdGhlIHNpZ25hbGluZwogICBu ZXR3b3JrIHNlcGFyYXRlZCBmcm9tIHRoZSBkYXRhIG5ldHdvcmsuICBUaGlzIGlzIGFuIGluY3Jl YXNlZAogICBzZWN1cml0eSB0aHJlYXQgc2luY2UgYSBoYWNrZXIgY291bGQgYXR0YWNrIHRoZSBz aWduYWxpbmcgbmV0d29yayBhbmQKICAgaXRzIHNlcnZlcnMgd2l0aCBpbmNyZWFzZWQgZGFtYWdl IHBvdGVudGlhbCAoY2FsbCBoaWphY2tpbmcsIGNhbGwKICAgZHJvcCwgRG9TIGF0dGFja3MsIGV0 Yy4pLiAgVGhlcmVmb3JlIHRoZXJlIGlzIHRoZSBuZWVkIG9mCiAgIGludmVzdGlnYXRpbmcgdGhl IGRpZmZlcmVudCBzZWN1cml0eSB0aHJlYXRzIGFuZCB0byBoaWdobGlnaHQgdGhlCiAgIHNvbHV0 aW9uZCBob3cgdG8gYXZvaWQgdGhlbS4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKTmlj Y29saW5pICAgICAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDIsIDIwMDcgICAgICAgICAgICAg ICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgVm9JUCBUaHJlYXRz ICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA2CgoKMi4gIFRheG9ub215IG9mIFZvSVAgU2Vj dXJpdHkgVGhyZWF0cwoKICAgQSB0YXhvbm9teSBvZiBWb0lQIHNlY3VyaXR5IHRocmVhdHMgaGFz IGJlZW4gZGVmaW5lZCBpbiBbMV0uICBTdWNoIGEKICAgdGF4b25vbXkgaXMgYSB2ZXJ5IGNvbXBs ZXRlIG9uZSBhbmQgdGFrZXMgaW50byBhY2NvdW50IGFsc28gdGhyZWF0cwogICBub3QgY2F1c2Vk IGJ5IFZvSVAtc3BlY2lmaWMgdGVjaG5pY2FsIHJlYXNvbnMgKGUuZy4gbG9zcyBvZiBwb3dlciku CiAgIEluIHRoaXMgc2VjdGlvbiBhIHNpbWlsYXIgdGF4b25vbXkgaXMgcHJlc2VudGVkIHRyeWlu ZyB0byByZXVzZSBhcwogICBtdWNoIGFzIHBvc3NpYmxlIGZyb20gdGhlIHJlZmVyZW5jZWQgZG9j dW1lbnQgYnV0IGF2b2lkaW5nIHRvCiAgIGNsYXNzaWZ5IHRocmVhdHMgdGhhdCBjYW4gbm90IGJl IHJlY29uZHVjdGVkIHRvIHRlY2huaWNhbCByZWFzb25zLgogICBUaGUgVm9JUCBzZWN1cml0eSB0 aHJlYXRzIGNhbiBiZSBkaXZpZGVkIGludG8gZm91ciBtYWluIGFyZWFzOgoKICAgbyAgSW50ZXJj ZXB0aW9uIGFuZCBNb2RpZmljYXRpb24gVGhyZWF0czsKCiAgIG8gIEludGVycnVwdGlvbiBvZiBT ZXJ2aWNlIFRocmVhdHM7CgogICBvICBBYnVzZSBvZiBTZXJ2aWNlIFRocmVhdHM7CgogICBvICBT b2NpYWwgVGhyZWF0cy4KCjIuMS4gIEludGVyY2VwdGlvbiBhbmQgTW9kaWZpY2F0aW9uIFRocmVh dHMKCiAgIFRoZSBpbnRlcmNlcHRpb24gdGhyZWF0IHJlc3VsdHMgZnJvbSB0aGUgYWJpbGl0eSBv ZiB0aGUgYXR0YWNrZXIgb2YKICAgaW50ZXJjZXB0aW5nIHRoZSBzaWduYWxpbmcgYW5kL29yIHRo ZSBkYXRhLiAgVGhlIGludGVyY2VwdGlvbi1vbmx5CiAgIHRocmVhdCByZXN1bHRzIGluIHRoZSBh dHRhY2tlciBiZWluZyBhYmxlIHRvIHVzZSB0aGUgaW50ZXJjZXB0ZWQgZGF0YQogICBmb3IgbWFs aWNpb3VzIHNjb3BlcywgZXhhbXBsZXMgYXJlOgoKICAgbyAgY2FsbCBwYXR0ZXJuIHRyYWNraW5n IC0gdGhlIGF0dGFja2VyIHRyYWNrcyB0aGUgY2FsbCBwYXR0ZXJucyBvZgogICAgICB0aGUgdXNl cnM7CgogICBvICBudW1iZXIgaGFydmVzdGluZyAtIHRoZSBhdHRhY2tlciBoYXJ2ZXN0IG51bWJl cnMgYW5kL29yIHVzZXIKICAgICAgaWRlbnRpdGllcyBmb3IgY2FsbGluZyBzdWNoIG51bWJlcnMv aWRlbnRpdGllcyBvciBmb3IgdXNpbmcKICAgICAgc3Bvb2ZlZCBpZGVudGl0aWVzOwoKICAgbyAg Y29udmVyc2F0aW9uIHJlY29uc3RydWN0aW9uIC0gdGhlIGF0dGFja2VyIHJlY29uc3RydWN0IHRo ZQogICAgICBjb252ZXJzYXRpb24gYW5kL29yIGFkZGl0aW9uYWwgZGF0YSBkZWxpdmVyZWQgd2l0 aCBpdCAoZS5nLgogICAgICBudW1iZXJzIHRyYW5zbWl0dGVkIHdpdGggRFRNRiB0b25lcykuCgog ICBUaGUgbW9kaWZpY2F0aW9uIHRocmVhdCBzdXBwb3NlcyB0aGF0IHRoZSBhdHRhY2tlciBpcyBh YmxlIHRvIG1vZGlmeQogICB0aGUgY29udGVudCBvZiB0aGUgcGFja2V0cyBiZWluZyBpbnRlcmNl cHRlZCBhY3RpbmcgYXMgYSBtYW4gaW4gdGhlCiAgIG1pZGRsZS4gIEluIHByaW5jaXBsZSB0aGlz IHRocmVhdCBhZmZlY3QgYm90aCB0aGUgc2lnbmFsaW5nIGFuZCB0aGUKICAgZGF0YSBkZXBlbmRp bmcgb24gdGhlIGFiaWxpdHkgb2YgdGhlIGF0dGFja2VyIG9mIGludGVyY2VwdGluZyBib3RoLgog ICBUaGUgaW50ZXJjZXB0aW9uIGFuZCBtb2RpZmljYXRpb24gdGhyZWF0IHJlc3VsdHMgaW4gdGhl IGF0dGFja2VyCiAgIGJlaW5nIGFibGUgdG8gbW9kaWZ5IHRoZSBwYWNrZXRzIGZvciBtYWxpY2lv dXMgc2NvcGVzLCBleGFtcGxlcyBhcmU6CgogICBvICBjYWxsIGJsYWNrIGhvbGluZyAtIHRoZSBh dHRhY2tlciBpbnRlbnRpb25hbGx5IGRyb3BzIGVzc2VudGlhbAogICAgICBwYWNrZXRzIChlLmcu ICBJTlZJVEUpIG9mIHRoZSBWb0lQIHByb3RvY29sIHJlc3VsdGluZyB0aGUgY2FsbAogICAgICBp bml0aWF0aW9uIHRvIGZhaWw7CgoKCgoKTmljY29saW5pICAgICAgICAgICAgICAgICBFeHBpcmVz IE1hcmNoIDIsIDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgVm9JUCBUaHJlYXRzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA2 CgoKICAgbyAgY2FsbCByZXJvdXRpbmcgLSB0aGUgYXR0YWNrZXIgcmVkaXJlY3RzIHRoZSBwYWNr ZXRzIG9uIGEgZGlmZmVyZW50CiAgICAgIHBhdGggaW4gb3JkZXIgdG8gaW5jbHVkZSB1bmF1dGhv cml6ZWQgbm9kZXMgaW4gdGhlIHBhdGggb3IgdG8KICAgICAgZXhjbHVkZSBhdXRob3JpemVkIG9u ZXMgZnJvbSBpdDsKCiAgIG8gIGNvbnZlcnNhdGlvbiBhbHRlcmF0aW9uIC0gdGhlIGF0dGFja2Vy IGFsdGVycyB0aGUgcGFja2V0cyBpbiBvcmRlcgogICAgICB0byBtb2RpZnkgdGhlIGNvbnZlcnNh dGlvbiBiZXR3ZWVuIHR3byB1c2VyczsKCiAgIG8gIGNvbnZlcnNhdGlvbiBkZWdyYWRpbmcgLSB0 aGUgYXR0YWNrZXIgaW50ZW50aW9uYWxseSBkcm9wcyBhCiAgICAgIHNlbGVjdGlvbiBvZiBwYWNr ZXRzIG9yIG1vZGlmeSB0aGUgY29udGVudCBvZiB0aGVtIHdpdGggdGhlCiAgICAgIG9iamVjdGl2 ZSBvZiBkZWdyYWRpbmcgdGhlIG92ZXJhbGwgcXVhbGl0eSBvZiB0aGUgY29udmVyc2F0aW9uOwoK Mi4yLiAgSW50ZXJydXB0aW9uIG9mIFNlcnZpY2UgVGhyZWF0cwoKICAgVGhlIGludGVycnVwdGlv biBvZiBzZXJ2aWNlIGF0dGFja3MgYXJlIG1haW5seSBvcmllbnRlZCBhdAogICBjb21wcm9taXNp bmcgdGhlIGF2YWlsYWJpbGl0eSBvZiB0aGUgc2VydmljZSBvciBkZXRlcmlvcmF0aW5nIHRoZQog ICBxdWFsaXR5IGxldmVsIG9mIHN1Y2ggcmVzb3VyY2VzLiAgSW50ZXJydXB0aW9uIG9mIHNlcnZp Y2UgYXR0YWNrcyBjYW4KICAgYmUgZWl0aGVyIHNwZWNpZmljIHRvIFNJUCBwcm90b2NvbCBvciB0 byBSVFAvUlRDUCBwcm90Y29sLiAgR2VuZXJhbAogICBpbnRlcnJ1cHRpb24gb2Ygc2VydmljZSBh dHRhY2tzIG5vdCB1c2luZyBWb0lQLXNwZWNpZmljIHByb3RvY29scyBhcmUKICAgb3V0IG9mIHRo ZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiAgRXhhbXBsZXMgb2YgU0lQIHByb3RvY29sIHNwZWNp ZmljCiAgIGludGVycnVwdGlvbiBvZiBzZXJ2aWNlIGF0dGFja3MgZXhwbG9pdGluZyBTSVAtc3Bl Y2lmaWMKICAgdnVsbmVyYWJpbGl0aWVzIGFyZToKCiAgIG8gIFNJUCBtYWxmb3JtZWQgcmVxdWVz dHMgYW5kIG1lc3NhZ2VzIC0gdGhlIGF0dGFja2VyIHRyaWVzIHRvIGNhdXNlCiAgICAgIGEgY3Jh c2ggb3IgYSByZWJvb3Qgb2YgdGhlIHByb3h5L2VuZHBvaW50IGJ5IHNlbmRpbmcgU0lQIG1hbGZv cm1lZAogICAgICByZXF1ZXN0cyBhbmQgbWVzc2FnZXM7CgogICBvICBTSVAgcmVxdWVzdHMgYW5k IG1lc3NhZ2VzIGZsb29kaW5nIC0gdGhlIGF0dGFja2VyIHRyaWVzIHRvIGV4aGF1c3QKICAgICAg dGhlIHJlc291cmNlcyBvZiB0aGUgcHJveHkvZW5kcG9pbnQgYnkgc2VuZGluZyBtYW55IFNJUCBy ZXF1ZXN0cwogICAgICBhbmQgbWVzc2FnZXM7CgogICBvICBjYWxsIGhpamFja2luZyAtIHRoZSBh dHRhY2tlciB1c2VzIFNJUCBtZXNzYWdlcyAoZS5nLiAzMDEgTW92ZWQKICAgICAgVGVtcG9yYXJs eSkgaW4gb3JkZXIgdG8gaGlqYWNrIGFuIGV4aXN0aW5nIGNhbGwgdG93YXJkcyBvdGhlcgogICAg ICBwcm94eS9lbmRwb2ludCwgaXQgaXMgbmVlZGVkIHRoYXQgdGhlIGF0dGFja2VyIHJlcGxpY2F0 ZXMgdGhlCiAgICAgIHByb3BlciBTSVAgaGVhZGVyIGZvciB0aGUgaGlqYWNraW5nIHRvIGJlIHN1 Y2Nlc3NmdWwgKFRvLCBGcm9tLAogICAgICBDYWxsLUlELCBDU2VxKTsKCiAgIG8gIGNhbGwgdGVh ciBkb3duIC0gdGhlIGF0dGFja2VyIHVzZXMgU0lQIG1lc3NhZ2VzIChlLmcuICBDQU5DRUwvQllF KQogICAgICBpbiBvcmRlciB0byB0ZWFyIGRvd24gYW4gZXhpc3RpbmcgY2FsbCwgaXQgaXMgbmVl ZGVkIHRoYXQgdGhlCiAgICAgIGF0dGFja2VyIHJlcGxpY2F0ZXMgdGhlIHByb3BlciBTSVAgaGVh ZGVyIGZvciB0aGUgaGlqYWNraW5nIHRvIGJlCiAgICAgIHN1Y2Nlc3NmdWwgKFRvLCBGcm9tLCBD YWxsLUlELCBDU2VxKS4KCiAgIEV4YW1wbGVzIG9mIFJUUC9SVENQIHByb3RvY29sIHNwZWNpZmlj IGludGVycnVwdGlvbiBvZiBzZXJ2aWNlCiAgIGF0dGFja3MgZXhwbG9pdGluZyBSVFAvUlRDUC1z cGVjaWZpYyB2dWxuZXJhYmlsaXRpZXMgYXJlOgoKICAgbyAgUlRQL1JUQ1AgbWFsZm9ybWVkIG1l c3NhZ2VzIC0gdGhlIGF0dGFja2VyIHRyaWVzIHRvIGNhdXNlIGEgY3Jhc2gKICAgICAgb3IgYSBy ZWJvb3Qgb2YgdGhlIHByb3h5L2VuZHBvaW50IGJ5IHNlbmRpbmcgUlRQL1JUQ1AgbWFsZm9ybWVk CiAgICAgIG1lc3NhZ2VzOzsKCgoKCk5pY2NvbGluaSAgICAgICAgICAgICAgICAgRXhwaXJlcyBN YXJjaCAyLCAyMDA3ICAgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgIFZvSVAgVGhyZWF0cyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNgoK CiAgIG8gIFJUUC9SVENQIG1lc3NhZ2VzIGZsb29kaW5nIC0gdGhlIGF0dGFja2VyIHRyaWVzIHRv IGV4aGF1c3QgdGhlCiAgICAgIHJlc291cmNlcyBvZiB0aGUgcHJveHkvZW5kcG9pbnQgYnkgc2Vu ZGluZyBtYW55IFJUUC9SVENQCiAgICAgIG1lc3NhZ2VzOzsKCiAgIG8gIFJUUC9SVENQIHNlc3Np b24gdGVhciBkb3duIC0gdGhlIGF0dGFja2VyIHVzZXMgUlRDUCBtZXNzYWdlcyAoZS5nLgogICAg ICBCWUUpIGluIG9yZGVyIHRvIHRlYXIgZG93biBhbiBleGlzdGluZyBjYWxsIGF0IFJUUCBsYXll ciwgdGhlIFNJUAogICAgICBsYXllciB3aWxsIG5vdCBub3RpY2UgdGhhdCB0aGUgUlRQIGZsb3cg aGFzIGJlZW4gdG9ybiBkb3duIGFuZCB0aGUKICAgICAgY2FsbCB3aWxsIG5vdCByZXN1bHQgYXMg cmVsZWFzZWQ7CgogICBvICBSVFAvUlRDUCBRb1MgZGVncmFkYXRpb24gLSB0aGUgYXR0YWNrZXIg c2VuZHMgd3JvbmcgUlRDUCByZXBvcnRzCiAgICAgIGFkdmVydGlzaW5nIG1vcmUgcGFja2V0IGxv c3Mgb3IgbW9yZSBqaXR0ZXIgdGhhbiBhY3R1YWxseQogICAgICBleHBlcmltZW50ZWQgcmVzdWx0 aW5nIGluIHRoZSB1c2FnZSBvZiBhIHBvb3IgcXVhbGl0eSBjb2RlYwogICAgICBkZWdyYWRpbmcg dGhlIG92ZXJhbGwgcXVhbGl0eSBvZiB0aGUgY2FsbCBleHBlcmllbmNlLgoKICAgSW4gcHJpbmNp cGxlIHN1Y2ggYXR0YWNrcyBkb2VzIG5vdCBuZWVkIGludGVyY2VwdGlvbiBvZiBhbnkgcGFja2V0 IGluCiAgIG9yZGVyIHRvIGJlIHBlcmZvcm1lZCAoY291bGQgYmUgZG9uZSBieSBzaW1wbGUgZ3Vl c3NpbmcpIGJ1dCBzb21lIG9mCiAgIHRoZXNlIGF0dGFja3MgKGUuZy4gY2FsbCBoaWphY2tpbmcs IFJUUC9SVENQIHNlc3Npb24gdGVhciBkb3duLCBldGMuKQogICBiZW5lZml0IGZyb20gdGhlIHJl dHJpZXZhbCBvZiBjYWxsLXNwZWNpZmljIGluZm9ybWF0aW9uIGFzIGNvbWluZwogICBmcm9tIGlu dGVyY2VwdGlvbiBvZiBTSVAvUlRQL1JUQ1AgcGFja2V0cy4KCjIuMy4gIEFidXNlIG9mIFNlcnZp Y2UgVGhyZWF0cwoKICAgSW4gdGhlIGFidXNlIG9mIHNlcnZpY2UgYXR0YWNrcyBzZXJ2aWNlcyBh cmUgaW1wcm9wZXJseSB1c2VkIGZvciB0aGUKICAgc2NvcGUgb2YgY29tbWl0dGluZyBmcmF1ZCBv ciByZWR1Y2UgYmlsbGluZy4gIEV4YW1wbGVzIG9mIGFidXNlIG9mCiAgIHNlcnZpY2UgYXR0YWNr cyBhcmU6CgogICBvICBpZGVudGl0eSB0aGVmdCAtIHRoZSBhdHRhY2tlciB1c2VzIHRoZSBpZGVu dGl0eSBvZiB0aGUgb3duZXIKICAgICAgd2l0aG91dCB0aGUgY29uc2VudCBmb3IgdGhlIHNjb3Bl IG9mIG1hc2tpbmcgaGlzIHJlYWwgaWRlbnRpdHkKICAgICAgd2hlbiBjb21taXR0aW5nIGZyYXVk IChlLmcuIHdoZW4gY2FsbGluZyB0aGUgYXR0YWNrZXIgY2FuIGNoYXJnZQogICAgICB0aGUgYmls bCBvZiB0aGUgaWRlbnRpdHkgb3duZXIsIHRoZSBhdHRhY2tlciBjYW4gdXNlIHRoZSBpZGVudGl0 eQogICAgICB0byBieXBhc3MgY2FsbCBibG9ja2luZywgZXRjLik7CgogICBvICBzZXJ2aWNlIHZv bHVtZSBmcmF1ZCAtIHRoZSBhdHRhY2tlciBpbmplY3RzIGluIHRoZSBuZXR3b3JrIG1vcmUKICAg ICAgdHJhZmZpYyB0aGFuIHdoYXQgZGVjbGFyZWQgaW4gdGhlIHNlc3Npb24gcmVxdWVzdCBpbiBv cmRlciB0bwogICAgICBhdm9pZCBwYXlpbmcgZm9yIHRoZSB1c2VkIHJlc291cmNlczsKCiAgIG8g IHNlc3Npb24gcmVwbGF5IC0gdGhlIGF0dGFja2VyIHJlcGxheXMgYSBwYXN0IHNlc3Npb24gb2Yg YW5vdGhlcgogICAgICB1c2VyIGluIG9yZGVyIHRvIGhhdmUgYWNjZXNzIHRvIHRoZSBzYW1lIHJl c291cmNlcyAoZS5nLiBhIGJhbmsKICAgICAgYWNjb3VudCwgZXRjLikuCgoyLjQuICBTb2NpYWwg VGhyZWF0cwoKICAgRmFsc2UgcHJlc2VudGF0aW9uIG9mIGluZm9ybWF0aW9uIHRvZ2V0aGVyIHdp dGggdW53YW50ZWQgY29udGFjdCBhcmUKICAgdGhlIG9ubHkgc29jaWFsIHRocmVhdHMgdGhhdCBj YW4gYmUgcmVjb25kdWN0ZWQgdG8gYSB0ZWNobmljYWwKICAgYmFja2dyb3VuZCBpbiB0aGUgY2Fz ZSBvZiBWb0lQLiAgRXhhbXBsZXMgYXJlOgoKICAgbyAgZmFsc2UgcHJlc2VuYXRpb24gb2YgaWRl bnRpdHkvYXV0aG9yaXR5L3JpZ2h0cy9jb250ZW50IC0gdGhlCiAgICAgIGF0dGFja2VyIHByZXNl bnRzIGZhbHNlIG9yIG1pc2xlYWRpbmcgY3JlZGVudGlhbHMgaW4gb3JkZXIgdG8gZ2FpbgoKCgpO aWNjb2xpbmkgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMiwgMjAwNyAgICAgICAgICAg ICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBWb0lQIFRocmVh dHMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMDYKCgogICAgICBhIHNvY2lhbCBhZHZhbnRh Z2Ugb3V0IG9mIGl0OwoKICAgbyAgdW53YW50ZWQgbGF3ZnVsL3VubGF3ZnVsIGNvbnRhY3QgLSB0 aGUgYXR0YWNrZXIgY29udGFjdHMgdGhlCiAgICAgIHZpY3RpbSB3aXRoIHRoZSB1bmxhd2Z1bCBv ciBsYXdmdWwgc2NvcGVzIChlLmcuIGV4dG9ydGlvbiwKICAgICAgdGVsZW1hcmtldGluZywgZXRj LiksIHBsZWFzZSBub3RlIHRoYXQgdW53YW50ZWQgbGF3ZnVsIGNvbnRhY3QgaW4KICAgICAgdGhl IGNhc2Ugb2YgVm9JUCBpcyBhbHNvIHJlZmVycmVkIHRvIGFzIFNQYW0gb3ZlciBJbnRlcm5ldAog ICAgICBUZWxlcGhvbnkgKFNQSVQpLCBTUElUIGRpc2N1c3Npb24gaXMgZXhjbHVkZWQgYnkgdGhl IFNQRUVSTUlOVAogICAgICB3b3JraW5nIGdyb3VwIHBlciBjaGFydGVyLgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKTmljY29saW5pICAgICAgICAgICAgICAgICBF eHBpcmVzIE1hcmNoIDIsIDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgVm9JUCBUaHJlYXRzICAgICAgICAgICAgICAgICAgIEF1Z3Vz dCAyMDA2CgoKMy4gIE92ZXJ2aWV3IG9mIFZvSVAgU2VjdXJpdHkgU29sdXRpb25zCgogICBUaGlz IHNlY3Rpb24gcHJlc2VudHMgdGhlIFZvSVAgc2VjdXJpdHkgZmVhdHVyZXMgY3VycmVudGx5CiAg IHN0YW5kYXJkaXplZCBvciB1bmRlciBzdGFuZGFyZGl6YXRpb24gaW4gb3JkZXIgdG8gZ2l2ZSBh biBvdmVydmlldyBvZgogICB0aGUgYnVpbGRpbmcgYmxvY2tzIG5lZWRlZCB0byBjb3VudGVyIHRo ZSBWb0lQIFNlY3VyaXR5IHRocmVhdHMKICAgZGV0YWlsZWQgaW4gdGhpcyBkcmFmdC4gIFRoZSB0 ZWNobm9sb2d5IHRvIHNlY3VyZSBWb0lQIGNhbiBiZSBkaXZpZGVkCiAgIGluIHRocmVlIG1haW4g YXJlYXMgYXMgZm9sbG93czoKCiAgIG8gIEF1dGhlbnRpY2F0aW9uL0F1dGhvcml6YXRpb247Cgog ICBvICBFbmNyeXB0aW9uOwoKICAgbyAgSWRlbnRpdHkgbWFuYWdlbWVudC4KCiAgIEF1dGhlbnRp Y2F0aW9uIGlzIG5lZWRlZCB0byB1bmRlcnN0YW5kIHdobyB3YXMgdGhlIHNlbmRlciBvZiBhCiAg IHNwZWNpZmljIHBhY2tldC4gIEF1dGhlbnRpY2F0aW9uIGNhbiB0YWtlIHBsYWNlIGJldHdlZW4g ZGlmZmVyZW50CiAgIGVudGl0aWVzIG9yIGVuZC10by1lbmQ6CgogICBvICBmcm9tIGNsaWVudCB0 byBzZXJ2ZXIgLSBEaWdlc3QgYXV0aGVudGljYXRpb24gWzJdIG9yIG11dHVhbAogICAgICBUcmFu c3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUykgWzNdOwoKICAgbyAgZnJvbSBzZXJ2ZXIgdG8gc2Vy dmVyIC0gbXV0dWFsIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKTsKCiAgIG8gIGZyb20g c2VydmVyIHRvIGNsaWVudCAtIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKTsKCiAgIG8g IGVuZC10by1lbmQgLSBTL01JTUUgWzRdLgoKICAgQWxsIHNvbHV0aW9ucyByZXF1aXJlIHNvbWUg a2luZCBvZiB0cnVzdCByZWxhdGlvbnNoaXAgKGkuZS4gc2hhcmVkCiAgIHNlY3JldCBvciBjZXJ0 aWZpY2F0ZXMgYXV0aG9yaXRpZXMpLgoKICAgRW5jcnlwdGlvbiBpcyBuZWVkZWQgdG8gcHJvdGVj dCB0aGUgY29udGVudCBvZiB0aGUgcGFja2V0cyBmcm9tIGJlaW5nCiAgIHJlYWQgYnkgb3RoZXIg cGFydGllcyB0aGFuIHRoZSBvbmVzIHdoaWNoIGFyZSBzdXBwb3NlZCB0byBiZSB0aGUKICAgcmVj aXBpZW50IG9mIHN1Y2ggcGFja2V0cy4gIEVuY3J5cHRpb24gZm9sbG93cyB0aGUgc2FtZSBwYXJh ZGlnbSBhcwogICBhdXRoZW50aWNhdGlvbiBhbmQgY2FuIGJlIGRvbmUgZWl0aGVyIG9uIGEgaG9w LWJ5LWhvcCBvciBvbiBhIGVuZC10by0KICAgZW5kIGJhc2lzLiAgT24gYSBob3AtYnktaG9wIGJh c2lzIFRMUyBpcyB1c2VkIChUTFMgY3JlYXRlcyBhbgogICBhdXRoZW50aWNhdGVkLCBlbmNyeXB0 ZWQsIGludGVncml0eS1jaGVja2VkIGNoYW5uZWwpLiAgT24gYSBlbmQtdG8tCiAgIGVuZCBiYXNp cyBTL01JTUUgaXMgdXNlZCB0byBzaWduIGFuZCBlbmNyeXB0IHBvcnRpb25zIG9mIHRoZSBTSVAK ICAgYm9keS4gIEF0IHRoZSBtZWRpYSBsZXZlbCBhIGVuZC10by1lbmQgZW5jcnlwdGlvbiBpcyBw b3NzaWJsZSB1c2luZwogICBTUlRQIFs1XSB0byBwcm90ZWN0IFJUUC9SVENQIG1lZGlhIChhdWRp bywgdmlkZW8pLiAgQ3VycmVudGx5IHRoZXJlCiAgIGlzIGEgZGlzY3Vzc2lvbiBpbiB0aGUgSUVU RiBhYm91dCB0aGUgcmVxdWlyZW1lbnRzIGZvciBTUlRQIG1lZGlhCiAgIGtleWluZyB3aGljaCBp cyBzdGlsbCBhbiBvcGVuIGlzc3VlLiAgT3RoZXIgc29sdXRpb25zIHRoYXQgcHJvdmlkZQogICBl bmNyeXB0aW9uIGFuZCBpbnRlZ3JpdHkgYXJlIGxvd2VyIGxheWVyIG9uZXMgbGlrZSBJUHNlYyB3 aGljaCBpcwogICBkb25lIGhvcC1ieS1ob3AuCgogICBJZGVudGl0eSBtYW5hZ2VtZW1lbnQgaXMg YWxzbyBhbiBpbXBvcnRhbnQgcGllY2Ugb2Ygc2VjdXJpdHkKICAgZnJhbWV3b3JrIGluIFNJUCBb Nl0uICBUaGUgb2JqZWN0aXZlIG9mIHRoZSBpZGVudGl0eSBmcmFtZXdvcmsgaXMgdG8KICAgZ2l2 ZSB0ZWNobmljYWwgbWVhbnMgdG8gYXNzZXNzIHVzZXIgaWRlbnRpdHkgaW4gYSBzZWN1cmUgbWFu bmVyLiAgSXQKICAgcmVxdWlyZXMgc3Ryb25nIGNyeXB0b2dyYXBoaWMgYXNzZXJ0aW9ucyBidXQg aXQgcmVwcmVzZW50cyB0aGUgbW9zdAoKCgpOaWNjb2xpbmkgICAgICAgICAgICAgICAgIEV4cGly ZXMgTWFyY2ggMiwgMjAwNyAgICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICBWb0lQIFRocmVhdHMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIw MDYKCgogICBwcm9taXNpbmcgYXBwcm9hY2ggdG8gZW5hYmxlIGZ1cmh0ZXIgc2VjdXJpdHkgc29s dXRpb25zIHdoaWNoIG5lZWQKICAgdGhlIGFzc3VtcHRpb24gb2YgZGVhbGluZyB3aXRoIHN0cm9u ZyBhdXRoZW50aWNhdGVkIGlkZW50aXRpZXMuCiAgIFBsZWFlIG5vdGUgdGhhdCBvdGhlciB0ZWNo bmlxdWVzIGNvdWxkIGFsc28gYmUgdXNlZCB0byBjb3VudGVyIFZvSVAKICAgU2VjdXJpdHkgdGhy ZWF0cywgdGhlIHRlY2huaXF1ZXMgdGhhdCBjb25zdGl0dXRlIHN0YW5kLWFsb25lCiAgIHNvbHV0 aW9ucyBhbmQgdGhhdCBkbyBub3QgbmVlZCBzdGFuZGFyZGl6YXRpb24gd29yayBhcmUgbGVmdCBv dXQgdGhlCiAgIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuICBJdCBpcyBsZWZ0IG9wZW4gZm9yIGRp c2N1c3Npb24gd2hpY2ggb3RoZXIKICAgc2VjdXJpdHkgdGVjaG5pcXVlcyB0byBpbmNsdWRlIGlu IHRoaXMgc2VjdGlvbi4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgpOaWNjb2xpbmkgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMiwgMjAwNyAgICAgICAg ICAgICAgICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBWb0lQIFRo cmVhdHMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMDYKCgo0LiAgQ29uY2x1c2lvbnMKCiAg IFRoaXMgbWVtbyBwcmVzZW50ZWQgYSB0YXhvbm9teSBmb3IgdGhlIGRpZmZlcmVudCB0eXBlcyBv ZiBWb0lQCiAgIHNlY3VyaXR5IHRocmVhdHMuICBUaGUgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRo ZSB0aHJlYXRzIHdlcmUgYWxzbwogICBwcmVzZW50ZWQgd2l0aCBhIGJyaWVmIGV4cGxhbmF0aW9u LiAgRmluYWxseSB0aGUgZXhpc3Rpbmcgc2VjdXJpdHkKICAgc29sdXRpb25zIGluIFZvSVAgd2Vy ZSBwcmVzZW50ZWQgdG8gZGVzY3JpYmUgdGhlIGNvdW50ZXJtZWFzdXJlcwogICBjdXJyZW50bHkg YXZhaWxhYmxlIGZvciBzdWNoIHRocmVhdHMuICBUaGUgb2JqZWN0aXZlIG9mIHRoaXMgZG9jdW1l bnQKICAgaXMgdG8gaWRlbnRpZnkgYW5kIGVudW1lcmF0ZSB0aGUgVm9JUCB0aHJlYXQgdmVjdG9y cyBpbiBvcmRlciB0bwogICBzcGVjaWZpeSBzZWN1cml0eS1yZWxhdGVkIHJlcXVpcmVtZW50cyBz cGVjaWZpYyB0byBwZWVyaW5nLiAgT25jZSB0aGUKICAgcmVxdWlyZW1lbnRzIGFyZSBpZGVudGlm aWVkLCBtZXRob2RzIGFuZCBzb2x1dGlvbnMgaG93IHRvIGFjaGlldmUKICAgc3VjaCByZXF1aXJl bWVudHMgY2FuIGJlIHNlbGVjdGVkLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKTmljY29saW5pICAgICAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDIsIDIwMDcgICAg ICAgICAgICAgICAgW1BhZ2UgMTBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgVm9J UCBUaHJlYXRzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA2CgoKNS4gIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zCgogICBUaGlzIG1lbW8gaXMgZW50aXJlbHkgZm9jdXNlZCBvbiB0aGUgc2Vj dXJpdHkgdGhyZWF0cyBmb3IgVm9JUC4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKTmljY29saW5pICAgICAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDIs IDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgVm9JUCBUaHJlYXRzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA2CgoKNi4gIEFj a25vd2xlZGdlbWVudHMKCiAgIFRoaXMgbWVtbyB0YWtlcyBpbnNwaXJhdGlvbiBmcm9tIFZPSVBT QSBWb0lQIFNlY3VyaXR5IGFuZCBQcml2YWN5CiAgIFRocmVhdCBUYXhvbm9teS4gIFRoZSBhdXRo b3Igd291bGQgbGlrZSB0byB0aGFuayBWT0lQU0EgZm9yIGhhdmluZwogICBwcm9kdWNlZCBzdWNo IGEgY29tcHJlaGVuc2l2ZSB0YXhvbm9teSB3aGljaCBpcyB0aGUgc3RhcnRpbmcgcG9pbnQgb2YK ICAgdGhpcyBkcmFmdC4gIFRoZSBhdXRob3Igd291bGQgYWxzbyBsaWtlIHRvIHRoYW5rIEN1bGxl biBKZW5uaW5ncyBmb3IKICAgdGhlIHVzZWZ1bCBzbGlkZXMgcHJlc2VudGVkIGF0IHRoZSBWb0lQ IE1hbmFnZW1lbnQgYW5kIFNlY3VyaXR5CiAgIHdvcmtzaG9wLgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKTmljY29saW5pICAgICAgICAgICAgICAgICBFeHBpcmVz IE1hcmNoIDIsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMTJdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgVm9JUCBUaHJlYXRzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA2 CgoKNy4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFsxXSAgIlZPSVBTQSBWb0lQIFNlY3Vy aXR5IGFuZCBQcml2YWN5IFRocmVhdCBUYXhvbm9teSIsCiAgICAgICAgT2N0b2JlciAyMDA1LgoK ICAgWzJdICBSb3NlbmJlcmcsIEouLCBTY2h1bHpyaW5uZSwgSC4sIENhbWFyaWxsbywgRy4sIEpv aG5zdG9uLCBBLiwKICAgICAgICBQZXRlcnNvbiwgSi4sIFNwYXJrcywgUi4sIEhhbmRsZXksIE0u LCBhbmQgRS4gU2Nob29sZXIsICJTSVA6CiAgICAgICAgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3Rv Y29sIiwgUkZDIDMyNjEsIEp1bmUgMjAwMi4KCiAgIFszXSAgRGllcmtzLCBULiBhbmQgRS4gUmVz Y29ybGEsICJUaGUgVExTIFByb3RvY29sIFZlcnNpb24gMS4yIiwKICAgICAgICBkcmFmdC1pZXRm LXRscy1yZmM0MzQ2LWJpcy0wMS50eHQgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBKdW5lIDIwMDYuCgog ICBbNF0gIFJhbXNkZWxsLCBCLiwgIlNlY3VyZS9NdWx0aXB1cnBvc2UgSW50ZXJuZXQgTWFpbCBF eHRlbnNpb25zCiAgICAgICAgKFMvTUlNRSkgVmVyc2lvbiAzLjEgTWVzc2FnZSBTcGVjaWZpY2F0 aW9uIiwgUkZDIDM4NTEsCiAgICAgICAgSnVseSAyMDA0LgoKICAgWzVdICBCYXVnaGVyLCBNLiwg TWNHcmV3LCBELiwgTmFzbHVuZCwgTS4sIENhcnJhcmEsIEUuLCBhbmQgSy4KICAgICAgICBOb3Jy bWFuLCAiVGhlIFNlY3VyZSBSZWFsLXRpbWUgVHJhbnNwb3J0IFByb3RvY29sIChTUlRQKSIsCiAg ICAgICAgUkZDIDM3MTEsIE1hcmNoIDIwMDQuCgogICBbNl0gIFBldGVyc29uLCBKLiBhbmQgQy4g SmVubmluZ3MsICJFbmhhbmNlbWVudHMgZm9yIEF1dGhlbnRpY2F0ZWQKICAgICAgICBJZGVudGl0 eSBNYW5hZ2VtZW50IGluIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkiLAog ICAgICAgIGRyYWZ0LWlldGYtc2lwLWlkZW50aXR5LTA2LnR4dCAod29yayBpbiBwcm9ncmVzcyks IE9jdG9iZXIgMjAwNS4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCk5pY2NvbGluaSAgICAg ICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyLCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDEz XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIFZvSVAgVGhyZWF0cyAgICAgICAgICAg ICAgICAgICBBdWd1c3QgMjAwNgoKCkF1dGhvcidzIEFkZHJlc3MKCiAgIFNhdmVyaW8gTmljY29s aW5pCiAgIE5ldHdvcmsgTGFib3JhdG9yaWVzLCBORUMgRXVyb3BlIEx0ZC4KICAgS3VyZnVlcnN0 ZW4tQW5sYWdlIDM2CiAgIEhlaWRlbGJlcmcgIDY5MTE1CiAgIEdlcm1hbnkKCiAgIFBob25lOiAr NDkgKDApIDYyMjEgNDM0MiAxMTgKICAgRW1haWw6IHNhdmVyaW8ubmljY29saW5pQG5ldGxhYi5u ZWMuZGUKICAgVVJJOiAgIGh0dHA6Ly93d3cubmV0bGFiLm5lYy5kZQoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKTmljY29saW5pICAgICAgICAgICAgICAgICBFeHBpcmVz IE1hcmNoIDIsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMTRdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgVm9JUCBUaHJlYXRzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA2 CgoKRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50CgogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5l dCBTb2NpZXR5ICgyMDA2KS4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byB0aGUgcmln aHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zCiAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFu ZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzCiAgIHJldGFpbiBhbGwg dGhlaXIgcmlnaHRzLgoKICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBD T05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUwogICBPUiBJUyBT UE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJO RVQKICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQ UkVTUyBPUiBJTVBMSUVELAogICBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJS QU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFCiAgIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJ TkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVECiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hB TlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLgoKCkludGVsbGVj dHVhbCBQcm9wZXJ0eQoKICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRo ZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkKICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0 cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvCiAgIHBlcnRhaW4gdG8g dGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4K ICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVy IHN1Y2ggcmlnaHRzCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2Vz IGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcwogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQg dG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24KICAgb24gdGhlIHByb2Nl ZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQogICBm b3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMg bWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55CiAgIGFzc3VyYW5jZXMgb2YgbGlj ZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4KICAgYXR0ZW1w dCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUg dXNlIG9mCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2Vy cyBvZiB0aGlzCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYg b24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4KCiAg IFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0 dGVudGlvbiBhbnkKICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25z LCBvciBvdGhlciBwcm9wcmlldGFyeQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9n eSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQKICAgdGhpcyBzdGFuZGFyZC4gIFBs ZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdAogICBpZXRmLWlwckBp ZXRmLm9yZy4KCgpBY2tub3dsZWRnbWVudAoKICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3Ig ZnVuY3Rpb24gaXMgcHJvdmlkZWQgYnkgdGhlIElFVEYKICAgQWRtaW5pc3RyYXRpdmUgU3VwcG9y dCBBY3Rpdml0eSAoSUFTQSkuCgoKCgoKTmljY29saW5pICAgICAgICAgICAgICAgICBFeHBpcmVz IE1hcmNoIDIsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMTVdCgwKCg== ------_=_NextPart_001_01C6CC50.52D5D89F Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint ------_=_NextPart_001_01C6CC50.52D5D89F-- From speermint-bounces@ietf.org Wed Aug 30 14:09:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIUUL-0004kr-Tc; Wed, 30 Aug 2006 14:08:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIUUL-0004km-5a for speermint@ietf.org; Wed, 30 Aug 2006 14:08:33 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GIUUJ-0003fj-PJ for speermint@ietf.org; Wed, 30 Aug 2006 14:08:33 -0400 Received: (qmail invoked by alias); 30 Aug 2006 18:08:30 -0000 Received: from p54986F66.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.111.102] by mail.gmx.net (mp019) with SMTP; 30 Aug 2006 20:08:30 +0200 X-Authenticated: #29516787 Message-ID: <44F5D41B.9080603@gmx.net> Date: Wed, 30 Aug 2006 20:08:27 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: speermint@ietf.org References: <6D28EBC684A4D94096217AD2FE400873BA5B1A@venus.office> In-Reply-To: <6D28EBC684A4D94096217AD2FE400873BA5B1A@venus.office> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Speermint] Security Threats & Solutions X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi all, why is it necessary to rehash standard VoIP security threats? The mentioned/described attacks have been investigated already for a couple of years. Countermeasures have been studied, proposed and already published as RFC (or are close to get published). I hope that I am not the only person that is confused now. Ciao Hannes _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 30 15:15:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVWe-0006Y0-Mp; Wed, 30 Aug 2006 15:15:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVWe-0006Wb-3V for speermint@ietf.org; Wed, 30 Aug 2006 15:15:00 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GIVWc-0003cZ-LE for speermint@ietf.org; Wed, 30 Aug 2006 15:15:00 -0400 Received: (qmail invoked by alias); 30 Aug 2006 19:14:57 -0000 Received: from p54986F66.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.111.102] by mail.gmx.net (mp017) with SMTP; 30 Aug 2006 21:14:57 +0200 X-Authenticated: #29516787 Message-ID: <44F5E3AE.40103@gmx.net> Date: Wed, 30 Aug 2006 21:14:54 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] Security Threats & Solutions References: <072C5B76F7CEAB488172C6F64B30B5E301DDADA5@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301DDADA5@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi Mike, to me it sounds that such a document could only be written at the time when the working group is about to close (after successfully completing the charter items). Could be a nice paper (rather than an IETF document) in the spirit of: "Here is what we did and that's the impact on security." Summary: Too early todo this now. Ciao Hannes Michael Hammer (mhammer) schrieb: > I would agree we shouldn't simply rehash the previous work. But, the > Speermint work might have closed some vulnerabilities that existed > between a fully closed model and a wide-open Internet model, and it > would be useful to note those. > > Or, put another way, given the nascent state of peering, to see which > vulnerabilities can be addressed. > > Mike > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, August 30, 2006 2:08 PM >> To: speermint@ietf.org >> Subject: [Speermint] Security Threats & Solutions >> >> Hi all, >> >> why is it necessary to rehash standard VoIP security threats? >> The mentioned/described attacks have been investigated >> already for a couple of years. Countermeasures have been >> studied, proposed and already published as RFC (or are close >> to get published). >> >> I hope that I am not the only person that is confused now. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint >> > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 30 15:22:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVdN-0000sI-P1; Wed, 30 Aug 2006 15:21:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVdM-0000sD-Il for speermint@ietf.org; Wed, 30 Aug 2006 15:21:56 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GIVdL-0004PD-4J for speermint@ietf.org; Wed, 30 Aug 2006 15:21:56 -0400 Received: (qmail invoked by alias); 30 Aug 2006 19:21:54 -0000 Received: from p54986F66.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.111.102] by mail.gmx.net (mp036) with SMTP; 30 Aug 2006 21:21:54 +0200 X-Authenticated: #29516787 Message-ID: <44F5E550.2040408@gmx.net> Date: Wed, 30 Aug 2006 21:21:52 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Reinaldo Penno Subject: Re: [Speermint] Security Threats & Solutions References: <9BD5D7887235424FA97DFC223CAE3C28055DE312@proton.jnpr.net> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C28055DE312@proton.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi Reinaldo, Reinaldo Penno schrieb: > Hello, > > I was going to mention something similar. Reading about known attacks > and VoIP security nomenclature is helpful because bring people up to > speed and we all speak the same language Maybe reading one of the many books or articles would also help. but I would be interested to > understand the attacks that are _specific_ to SPEERMINT. I fully agree. Impersonating a > proxy? Malicious Reroute? DNS Hijacking attack when related to > federations? etc, I think that this is already going to far. I am not yet sure about the entire scope of the work in this group but DNS related attacks seem to be pretty relevant. These are just examples I just thought during the time > it took to write this email. > Ciao Hannes > Regards, > > Reinaldo > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, August 30, 2006 11:08 AM >> To: speermint@ietf.org >> Subject: [Speermint] Security Threats & Solutions >> >> Hi all, >> >> why is it necessary to rehash standard VoIP security threats? The >> mentioned/described attacks have been investigated already for a > couple >> of years. Countermeasures have been studied, proposed and already >> published as RFC (or are close to get published). >> >> I hope that I am not the only person that is confused now. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 30 15:54:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIW83-0006jb-GD; Wed, 30 Aug 2006 15:53:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIW82-0006jE-0f for speermint@ietf.org; Wed, 30 Aug 2006 15:53:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIV4q-0007FD-8z for speermint@ietf.org; Wed, 30 Aug 2006 14:46:16 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIUpR-0007To-0D for speermint@ietf.org; Wed, 30 Aug 2006 14:30:23 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 30 Aug 2006 11:30:20 -0700 X-IronPort-AV: i="4.08,189,1154934000"; d="scan'208"; a="315958581:sNHT32988144" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7UIUK7g022635; Wed, 30 Aug 2006 11:30:20 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7UIUJw7011969; Wed, 30 Aug 2006 11:30:20 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Aug 2006 14:30:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Security Threats & Solutions Date: Wed, 30 Aug 2006 14:30:18 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301DDADA5@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Security Threats & Solutions Thread-Index: AcbMX5smC9M47PmxS7e6v6YmVKwxsQAAlw1A From: "Michael Hammer \(mhammer\)" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 30 Aug 2006 18:30:19.0461 (UTC) FILETIME=[58C20750:01C6CC62] DKIM-Signature: a=rsa-sha1; q=dns; l=1143; t=1156962620; x=1157826620; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Security=20Threats=20&=20Solutions; X=v=3Dcisco.com=3B=20h=3DxDdhsPKjvXSgKCS4ZiJz7LAPqwo=3D; b=cftYNE3wqTfEl73EB4TE0aY2gxmQVgP3lHp1QogUcBuakyi43zD+KbVSNQSMQZzfejnv+TZS 110pSZ3DkV6xnQdPkRLcAgizuXV3fx2HLxtBu2fDXZV1XdAq4e+RIRld; Authentication-Results: sj-dkim-6.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.5 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I would agree we shouldn't simply rehash the previous work. But, the Speermint work might have closed some vulnerabilities that existed between a fully closed model and a wide-open Internet model, and it would be useful to note those. Or, put another way, given the nascent state of peering, to see which vulnerabilities can be addressed. Mike > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Wednesday, August 30, 2006 2:08 PM > To: speermint@ietf.org > Subject: [Speermint] Security Threats & Solutions >=20 > Hi all, >=20 > why is it necessary to rehash standard VoIP security threats?=20 > The mentioned/described attacks have been investigated=20 > already for a couple of years. Countermeasures have been=20 > studied, proposed and already published as RFC (or are close=20 > to get published). >=20 > I hope that I am not the only person that is confused now. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 30 17:42:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIXom-00086d-CK; Wed, 30 Aug 2006 17:41:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIXol-00086Y-6s for speermint@ietf.org; Wed, 30 Aug 2006 17:41:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIV4q-0007FD-Fg for speermint@ietf.org; Wed, 30 Aug 2006 14:46:16 -0400 Received: from borg.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIUon-0007Sy-7s for speermint@ietf.org; Wed, 30 Aug 2006 14:29:42 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 30 Aug 2006 11:27:49 -0700 X-IronPort-AV: i="4.08,189,1154934000"; d="scan'208"; a="583191025:sNHT30718324" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Security Threats & Solutions Date: Wed, 30 Aug 2006 14:29:38 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C28055DE312@proton.jnpr.net> In-Reply-To: <44F5D41B.9080603@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Security Threats & Solutions Thread-index: AcbMX3hLVQzLY6cwQDG3rVVGvqAYFwAAdwzg From: "Reinaldo Penno" To: "Hannes Tschofenig" , X-Spam-Score: -2.0 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hello, I was going to mention something similar. Reading about known attacks and VoIP security nomenclature is helpful because bring people up to speed and we all speak the same language but I would be interested to understand the attacks that are _specific_ to SPEERMINT. Impersonating a proxy? Malicious Reroute? DNS Hijacking attack when related to federations? etc, These are just examples I just thought during the time it took to write this email. Regards, Reinaldo > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, August 30, 2006 11:08 AM > To: speermint@ietf.org > Subject: [Speermint] Security Threats & Solutions >=20 > Hi all, >=20 > why is it necessary to rehash standard VoIP security threats? The > mentioned/described attacks have been investigated already for a couple > of years. Countermeasures have been studied, proposed and already > published as RFC (or are close to get published). >=20 > I hope that I am not the only person that is confused now. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Aug 30 19:21:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIZMn-0003An-4R; Wed, 30 Aug 2006 19:21:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIZMm-0003Ai-F0 for speermint@ietf.org; Wed, 30 Aug 2006 19:21:04 -0400 Received: from mail.xconnect.net ([213.187.46.35] helo=xconnect.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIZMi-00046O-2v for speermint@ietf.org; Wed, 30 Aug 2006 19:21:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Security Threat Vectors - SPIT Date: Thu, 31 Aug 2006 00:20:45 +0100 Message-ID: <062B8EE81F2EC945A577C3EFAE1DD68E1A3C8F@mail.xconnect.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Security Threat Vectors - SPIT Thread-Index: AcbLo4JGP8IabzcOSl6gC9rz6sMqiQAnMCeQ From: "Eli Katz" To: "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Here is a recent draft regarding Spam over Internet Telephony (SPIT) (submitted to Sipping WG), and happy to help work with anyone on the SPIT issues; threats, solutions or defenses. http://tools.ietf.org/wg/sipping/draft-schwartz-sipping-spit-saml-01.txt Regds Eli -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: 29 August 2006 20:44 To: speermint@ietf.org Subject: [Speermint] Security Threat Vectors We've been discussing VoIP Peering security threats and the like. I expect we will soon see a draft or two on the subject to inform discussion in the WG on this subject. As discussed previously, once we document the threats we can specify the defenses which would be implemented / recommended in an upcoming BCP. In the meantime, I was directed to this document by one of the attendees of the last SPEERMINT meeting: http://www.voipsa.org/Activities/VOIPSA_Threat_Taxonomy_0.1.pdf Regards Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 31 04:45:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIi8x-0003WX-Id; Thu, 31 Aug 2006 04:43:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIi8w-0003VQ-3n for speermint@ietf.org; Thu, 31 Aug 2006 04:43:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIi8w-0004PG-20 for speermint@ietf.org; Thu, 31 Aug 2006 04:43:22 -0400 Received: from pro22.abac.com ([66.226.64.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIi7Z-0007Ui-27 for speermint@ietf.org; Thu, 31 Aug 2006 04:41:58 -0400 Received: from jeremyb (bzq-88-152-176-97.red.bezeqint.net [88.152.176.97]) (authenticated bits=0) by pro22.abac.com (8.13.8/8.13.8) with ESMTP id k7V8ffnv054639; Thu, 31 Aug 2006 01:41:44 -0700 (PDT) (envelope-from jeremyb@digitalshtick.com) From: "Jeremy Barkan \(DigitalShtick\)" To: "'Reinaldo Penno'" , "'Hannes Tschofenig'" , Subject: RE: [Speermint] Security Threats & Solutions Date: Thu, 31 Aug 2006 11:41:21 +0200 Message-ID: <018c01c6cce1$a15862f0$6400a8c0@jeremyb> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-reply-to: <9BD5D7887235424FA97DFC223CAE3C28055DE312@proton.jnpr.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal X-Spam-Score: -2.6 (--) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org This sounds like an effort worth doing with VOIPSA. -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Wednesday, August 30, 2006 8:30 PM To: Hannes Tschofenig; speermint@ietf.org Subject: RE: [Speermint] Security Threats & Solutions Hello, I was going to mention something similar. Reading about known attacks and VoIP security nomenclature is helpful because bring people up to speed and we all speak the same language but I would be interested to understand the attacks that are _specific_ to SPEERMINT. Impersonating a proxy? Malicious Reroute? DNS Hijacking attack when related to federations? etc, These are just examples I just thought during the time it took to write this email. Regards, Reinaldo > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, August 30, 2006 11:08 AM > To: speermint@ietf.org > Subject: [Speermint] Security Threats & Solutions > > Hi all, > > why is it necessary to rehash standard VoIP security threats? The > mentioned/described attacks have been investigated already for a couple > of years. Countermeasures have been studied, proposed and already > published as RFC (or are close to get published). > > I hope that I am not the only person that is confused now. > > Ciao > Hannes > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 31 08:06:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIlHG-0000rI-Ae; Thu, 31 Aug 2006 08:04:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIlHE-0000kR-KN for speermint@ietf.org; Thu, 31 Aug 2006 08:04:08 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIlAH-0001tr-Eu for speermint@ietf.org; Thu, 31 Aug 2006 07:56:58 -0400 Received: from localhost (localhost.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6C021200C8E1; Thu, 31 Aug 2006 13:57:22 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23620-10; Thu, 31 Aug 2006 13:57:22 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 55DBE20031DB; Thu, 31 Aug 2006 13:57:22 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Speermint] Security Threats & Solutions Date: Thu, 31 Aug 2006 13:56:55 +0200 Message-ID: In-Reply-To: <018c01c6cce1$a15862f0$6400a8c0@jeremyb> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Security Threats & Solutions Thread-Index: AcbM2ZtVlVTXID0qSSy9BEjgGj7AhgAGkAsg From: "Saverio Niccolini" To: "Jeremy Barkan (DigitalShtick)" , "Reinaldo Penno" , "Hannes Tschofenig" , X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Dear all, the draft was explicitly requested by WG chairs during last IETF. I agree with you that this is a preliminar work and threats specific to peering need to be in there, please read the sentences in the draft where the objective is explicitly declared and it is inline with what you request (moreover please note that there is no such study on VoIP threats for peering out there and this need some time to be written), I just wanted to submit before the interim meeting in order to stimulate discussion since there are two slots on the topic in agenda. I am happy if you would like to input SPEERMINT specific threats that I can classify and insert into the next version of the draft before the=20 next IETF mmeting in San Diego. Cheers, Saverio > -----Original Message----- > From: Jeremy Barkan (DigitalShtick)=20 > [mailto:jeremyb@digitalshtick.com]=20 > Sent: Thursday, August 31, 2006 11:41 AM > To: 'Reinaldo Penno'; 'Hannes Tschofenig'; speermint@ietf.org > Subject: RE: [Speermint] Security Threats & Solutions >=20 > This sounds like an effort worth doing with VOIPSA. >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 > Sent: Wednesday, August 30, 2006 8:30 PM > To: Hannes Tschofenig; speermint@ietf.org > Subject: RE: [Speermint] Security Threats & Solutions >=20 > Hello, >=20 > I was going to mention something similar. Reading about known attacks > and VoIP security nomenclature is helpful because bring people up to > speed and we all speak the same language but I would be interested to > understand the attacks that are _specific_ to SPEERMINT.=20 > Impersonating a > proxy? Malicious Reroute? DNS Hijacking attack when related to > federations? etc, These are just examples I just thought=20 > during the time > it took to write this email. >=20 > Regards, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Wednesday, August 30, 2006 11:08 AM > > To: speermint@ietf.org > > Subject: [Speermint] Security Threats & Solutions > >=20 > > Hi all, > >=20 > > why is it necessary to rehash standard VoIP security threats? The > > mentioned/described attacks have been investigated already for a > couple > > of years. Countermeasures have been studied, proposed and already > > published as RFC (or are close to get published). > >=20 > > I hope that I am not the only person that is confused now. > >=20 > > Ciao > > Hannes > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 31 10:49:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GInqi-0002n8-JL; Thu, 31 Aug 2006 10:48:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GInqh-0002n3-S2 for speermint@ietf.org; Thu, 31 Aug 2006 10:48:55 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GInqg-0004KM-Fx for speermint@ietf.org; Thu, 31 Aug 2006 10:48:55 -0400 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.23891336; Thu, 31 Aug 2006 10:48:27 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 10:48:27 -0400 Received: from 70.89.32.29 ([70.89.32.29]) by PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) via Exchange Front-End Server webmail.comcast.com ([208.17.33.14]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Aug 2006 14:48:26 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 31 Aug 2006 10:48:25 -0400 Subject: Re: [Speermint] Security Threats & Solutions From: Jason Livingood To: Saverio Niccolini , "Jeremy Barkan (DigitalShtick)" , Reinaldo Penno , Hannes Tschofenig , Message-ID: Thread-Topic: [Speermint] Security Threats & Solutions Thread-Index: AcbM2ZtVlVTXID0qSSy9BEjgGj7AhgAGkAsgAAYp6JE= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 Aug 2006 14:48:27.0297 (UTC) FILETIME=[8480C110:01C6CD0C] X-Spam-Score: 1.6 (+) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Correct. I recommend anyone with questions search the archives for "security threat" or "threat vectors" to see the relevant discussion history. We have an upcoming deliverable on establishing identity & security at the domain border. In addition, we have an immediate need in the requirements draft to identify security-related requirements. Dave and I felt the best way to begin discussion was to first identify the threats, then identify requirements to address those threats. But again, this and another upcoming draft are simply starting points for discussion / to spur discussion. I think that the points raised to deal with specific threats at domain borders are fair, but sometimes you have to begin with a wide scope of examination & analysis before you can narrow that scope and get more specific... Regards Jason On 8/31/06 7:56 AM, "Saverio Niccolini" wrote: > Dear all, > > the draft was explicitly requested by WG chairs during last IETF. > I agree with you that this is a preliminar work and threats specific > to peering need to be in there, please read the sentences in the draft > where the objective is explicitly declared and it is inline with what > you request (moreover please note that there is no such study on VoIP > threats for peering out there and this need some time to be written), > I just wanted to submit before the interim meeting in order to > stimulate discussion since there are two slots on the topic > in agenda. > > I am happy if you would like to input SPEERMINT specific threats that I > can classify and insert into the next version of the draft before the > next IETF mmeting in San Diego. > > Cheers, > Saverio > >> -----Original Message----- >> From: Jeremy Barkan (DigitalShtick) >> [mailto:jeremyb@digitalshtick.com] >> Sent: Thursday, August 31, 2006 11:41 AM >> To: 'Reinaldo Penno'; 'Hannes Tschofenig'; speermint@ietf.org >> Subject: RE: [Speermint] Security Threats & Solutions >> >> This sounds like an effort worth doing with VOIPSA. >> >> -----Original Message----- >> From: Reinaldo Penno [mailto:rpenno@juniper.net] >> Sent: Wednesday, August 30, 2006 8:30 PM >> To: Hannes Tschofenig; speermint@ietf.org >> Subject: RE: [Speermint] Security Threats & Solutions >> >> Hello, >> >> I was going to mention something similar. Reading about known attacks >> and VoIP security nomenclature is helpful because bring people up to >> speed and we all speak the same language but I would be interested to >> understand the attacks that are _specific_ to SPEERMINT. >> Impersonating a >> proxy? Malicious Reroute? DNS Hijacking attack when related to >> federations? etc, These are just examples I just thought >> during the time >> it took to write this email. >> >> Regards, >> >> Reinaldo >> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Wednesday, August 30, 2006 11:08 AM >>> To: speermint@ietf.org >>> Subject: [Speermint] Security Threats & Solutions >>> >>> Hi all, >>> >>> why is it necessary to rehash standard VoIP security threats? The >>> mentioned/described attacks have been investigated already for a >> couple >>> of years. Countermeasures have been studied, proposed and already >>> published as RFC (or are close to get published). >>> >>> I hope that I am not the only person that is confused now. >>> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> Speermint mailing list >>> Speermint@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speermint >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint >> >> >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint >> > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 31 15:50:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIsYK-0000z0-9L; Thu, 31 Aug 2006 15:50:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIsY6-0000iF-L0; Thu, 31 Aug 2006 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIsY6-0001su-6k; Thu, 31 Aug 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 232E426E37; Thu, 31 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GIsY6-0007hO-0r; Thu, 31 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 31 Aug 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-04.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Terminology Author(s) : D. Meyer Filename : draft-ietf-speermint-terminology-04.txt Pages : 14 Date : 2006-8-31 This document defines the terminology that is to be used by the Session PEERing for Multimedia INTerconnect Working Group (SPEERMINT). It has as its primary objective to focus the working group during its discussions, and when writing requirements, gap analysis and other solutions oriented documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-terminology-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-terminology-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-31102426.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-terminology-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-terminology-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-31102426.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Thu Aug 31 20:40:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIx3y-00054M-KN; Thu, 31 Aug 2006 20:39:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIx3x-00054H-KH for speermint@ietf.org; Thu, 31 Aug 2006 20:39:13 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIx3w-0000gv-8x for speermint@ietf.org; Thu, 31 Aug 2006 20:39:13 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 31 Aug 2006 17:37:19 -0700 X-IronPort-AV: i="4.08,195,1154934000"; d="scan'208"; a="583713274:sNHT48574608" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Security Threats & Solutions Date: Thu, 31 Aug 2006 20:39:09 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C28055DE566@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Security Threats & Solutions Thread-index: AcbM2ZtVlVTXID0qSSy9BEjgGj7AhgAGkAsgABpwtNA= From: "Reinaldo Penno" To: "Saverio Niccolini" , "Jeremy Barkan \(DigitalShtick\)" , "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Saverio, I hope you do not think people are undermining your work. As I said, it has intrinsic value and as Jason mention it will stimulate discussion. But I would like us to start thinking about speermint attacks.=20 Now, I read your draft, and in the context of SPEERMINT I suggest the following nomenclature. Let me know if you agree. a. General SIP attacks that can also be used in the context of SPEERMINT b. General SIP attacks that cannot be used in the context of SPEERMINT but can be adapted for so. c. New attacks that peering brings about.=20 Thanks, Reinaldo > -----Original Message----- > From: Saverio Niccolini [mailto:Saverio.Niccolini@netlab.nec.de] > Sent: Thursday, August 31, 2006 4:57 AM > To: Jeremy Barkan (DigitalShtick); Reinaldo Penno; Hannes Tschofenig; > speermint@ietf.org > Subject: RE: [Speermint] Security Threats & Solutions >=20 > Dear all, >=20 > the draft was explicitly requested by WG chairs during last IETF. > I agree with you that this is a preliminar work and threats specific > to peering need to be in there, please read the sentences in the draft > where the objective is explicitly declared and it is inline with what > you request (moreover please note that there is no such study on VoIP > threats for peering out there and this need some time to be written), > I just wanted to submit before the interim meeting in order to > stimulate discussion since there are two slots on the topic > in agenda. >=20 > I am happy if you would like to input SPEERMINT specific threats that I > can classify and insert into the next version of the draft before the > next IETF mmeting in San Diego. >=20 > Cheers, > Saverio >=20 > > -----Original Message----- > > From: Jeremy Barkan (DigitalShtick) > > [mailto:jeremyb@digitalshtick.com] > > Sent: Thursday, August 31, 2006 11:41 AM > > To: 'Reinaldo Penno'; 'Hannes Tschofenig'; speermint@ietf.org > > Subject: RE: [Speermint] Security Threats & Solutions > > > > This sounds like an effort worth doing with VOIPSA. > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Wednesday, August 30, 2006 8:30 PM > > To: Hannes Tschofenig; speermint@ietf.org > > Subject: RE: [Speermint] Security Threats & Solutions > > > > Hello, > > > > I was going to mention something similar. Reading about known attacks > > and VoIP security nomenclature is helpful because bring people up to > > speed and we all speak the same language but I would be interested to > > understand the attacks that are _specific_ to SPEERMINT. > > Impersonating a > > proxy? Malicious Reroute? DNS Hijacking attack when related to > > federations? etc, These are just examples I just thought > > during the time > > it took to write this email. > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Wednesday, August 30, 2006 11:08 AM > > > To: speermint@ietf.org > > > Subject: [Speermint] Security Threats & Solutions > > > > > > Hi all, > > > > > > why is it necessary to rehash standard VoIP security threats? The > > > mentioned/described attacks have been investigated already for a > > couple > > > of years. Countermeasures have been studied, proposed and already > > > published as RFC (or are close to get published). > > > > > > I hope that I am not the only person that is confused now. > > > > > > Ciao > > > Hannes > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint
=0A=

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

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

But that was several = years =0A= ago. 

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

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

Brian

> = -----Original =0A= Message-----
> From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com]
> =0A= Sent: Thursday, August 10, 2006 1:40 PM
> To: Brian Rosen; Daryl =0A= Malas
> Cc: speermint@ietf.org
> Subject: RE: [Speermint] = Congestion =0A= and Load Balancing
>
> There used to be also a PNNI = signaling and =0A= congestion control
> specification (ATMF, April 2002); I do not = know =0A= whether anyone
> implemented it, if so, what is the =0A= experience?
>
> --- Sohel
>
> -----Original =0A= Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> = Sent: =0A= Thursday, August 10, 2006 12:31 PM
> To: Khan, Sohel Q [CTO]; = 'Daryl =0A= Malas'
> Cc: speermint@ietf.org
> Subject: RE: [Speermint] =0A= Congestion and Load Balancing
>
> Yeah, a bit; I used to = work for =0A= FORE Systems, which implemented ABR
> pretty carefully.  ABR = was =0A= never used much.
>
> It is the kind of thing I'm talking = about; the =0A= mechanism had some
> significant theoretic work behind it, and the =0A= mechanism was pretty well
> understood before the spec was = written.  =0A= Tim Dwight and others can
> probably comment more than I on that =0A= subject.
>
> I don't think the ABR mechanism is applicable = to the =0A= problem at hand.
>
> Brian
>
> > = -----Original =0A= Message-----
> > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com]
> =0A= > Sent: Thursday, August 10, 2006 1:20 PM
> > To: Brian = Rosen; Daryl =0A= Malas
> > Cc: speermint@ietf.org
> > Subject: RE: = [Speermint] =0A= Congestion and Load Balancing
> >
> >
> = >
> =0A= >
> >
> > I think in old ATM days, there were = significant =0A= research and
> > simulation studies conducted on Available Bit = Rate =0A= (ABR) flow control
> > and congestion control. I do not know = whether =0A= anyone implemented it,
> > any insight?
> >
> = > =0A= -----Original Message-----
> > From: Brian Rosen [mailto:br@brianrosen.net]
> = > Sent: =0A= Wednesday, August 09, 2006 7:28 PM
> > To: 'Daryl = Malas'
> > =0A= Cc: speermint@ietf.org
> > Subject: Re: [Speermint] Congestion = and Load =0A= Balancing
> >
> > I am aware of the congestion control =0A= (overload) work going on.  So
> > far, I'm suspicious of = it, =0A= because I don't see any experimental or
> > simulation studies = that =0A= show the effects of trying to control
> congestion in SIP.
> = > =0A= We'll see how it develops.
> >
> > I'm very suspicious = of what =0A= looks like very simple dynamic feedback
> > control on the = peering =0A= point.  We've seen this kind of thing many
> > times = before.  =0A= The Internet is very fast, and feedback loops tend to
> > = oscillate =0A= wildly really easily.  You almost always need a dampener,
> = > and =0A= sometimes something more exotic.  I'm pretty sure a = straight
> =0A= dynamic "I'm full"
> > mechanism will not be stable.  I = have no =0A= idea what kinds of filtering
> > we need, and what kind of = "frequency =0A= response" we need, but I'm pretty
>
> > sure we need = some.  =0A= I don't know if we want simple on/off ("bang-bang)
>
> > = control, =0A= or proportional control.
> > I don't even know if we understand = how you =0A= measure congestion in these
>
> > kinds of = systems.
> =0A= >
> > Please dream up a mechanism and go try it.  Let = us know =0A= how it does.
> > There are some pretty useful simulation = mechanisms for =0A= networks
> > around, simulation results rarely match real world =0A= results, but they
> > are informative.  Better if you = could try it =0A= on real networks.
> >
> > But please don't just = propose a =0A= dynamic feedback type "loop control"
> > without a good set of =0A= definitions, an understanding of what and how
> > you are = measuring, a =0A= viable control mechanism, a filter/dampener and
> > some = inkling of how =0A= well it works on real or simulated traffic.
> >
> > =0A= Brian
> >
> > > -----Original Message-----
> = > =0A= > From: Daryl Malas [mailto:daryl@level3.net]
> = > > =0A= Sent: Wednesday, August 09, 2006 6:12 PM
> > > To: Brian =0A= Rosen
> > > Cc: 'Michael Hammer (mhammer)'; 'Patrick = Melampy'; =0A= 'Klaus Darilion';
>
> > > speermint@ietf.org
> = > > =0A= Subject: RE: [Speermint] Congestion and Load Balancing
> > = >
> =0A= > > I apologize if I am restating or missing this, but I am going =0A= to
> > > jump in...so a shut up and go away is acceptable. =0A= ;-)
> > >
> > > Just to throw in my two = cents...I think =0A= there are two different
> > > issues
> >
> = > > =0A= to solve here.  First, dynamic congestion control in SIP.
> = > > =0A= Rosenberg, Hilt, and myself are working on this problem...but
> = > > =0A= definitely appreciate input.  Second, policy based = congestion
> > =0A= > control for peering.  I think this second aspect is the beast = we =0A= are
>
> > > trying to tackle in this working group. = This =0A= second aspect was going
>
> > > to be apart
> =0A= >
> > > of the policy function in the peering = architecture.  =0A= Now, how does
> > > it dynamically update the sender...I had =0A= initially recommended a
> > > subscribe mechanism where an = expiry =0A= timer will essential force the
> > > peer to re-subscribe to = gain =0A= new policy information...this could
> > > include updated = congestion =0A= information for changing the destination
> > > signaling =0A= function...or may say...go away...I can't handle any more
> > = > =0A= traffic.  Either way, this second method is in addition to the = SIP
> =0A= > > congestion/overload method...yet specific for the = peering
> =0A= environment.
> > >
> > > What do you = think?
> > =0A= >
> > > --Daryl
> > >
> > > On = Wed, =0A= 2006-08-09 at 17:37 -0400, Brian Rosen wrote:
> > > > = Please =0A= don't get me started on the IETF's abandonment of its
> > > = > =0A= belief in running code.
> > > >
> > > > = While =0A= occasionally we actually just document something that
> > > = > =0A= exists, we usually end up extending somewhat from something we
> = know =0A= works.
> > > > We have pretty bad experience inventing = major new =0A= functionality
> > > > ESPECIALLY IN CONGESTION CONTROL, = and =0A= seeing it work.  It almost
> > never does.
> > = > =0A= >
> > > > So, sure, we can invent some new stuff, as = long as =0A= it is some
> > > > likely-to-
> > > = work
> > =0A= > > extension of stuff we pretty much know works.
> > = > =0A= >
> > > > Let me cite an example.  ICE is a = pretty =0A= complex piece of
> > > > machinery,
> >
> = > =0A= > > but it's built on a base of work we KNOW will work.  ICE = may =0A= have
> > > > a bunch of text to tweak as we gain some =0A= implementation
> > > > experience, but we know it
> = > =0A= > will
> > > > work.
> > > >
> = > > =0A= > I'm not aware of any work in this area we know works we can = build
> =0A= > from.
> > > Can
> > > > you cite = some?
> =0A= > > >
> > > > I'm not particularly opposed to = having =0A= discovery mechanisms for
> > > > proxy
> > > =0A= domain
> > > > names, call rates and bandwidth limits = rather than =0A= provisioning.
> > > > I'm skeptical they would be used, = but it's =0A= simple enough.  I am
> > > > opposed to trying to = say that =0A= info varies from call to call, but
> > > > something =0A= faster
> > > than
> > > > a contract = negotiation does =0A= seem practical.
> > > >
> > > > That's a = far cry =0A= from anything we would consider to be dynamic
> > > =0A= congestion
> > > > control.
> > > = >
> > =0A= > > Brian
> > > >
> > > > > = -----Original =0A= Message-----
> > > > > From: Michael Hammer (mhammer) = [mailto:mhammer@cisco.com]
> = > > =0A= > > Sent: Wednesday, August 09, 2006 5:09 PM
> > > = > > =0A= To: Brian Rosen; Patrick Melampy; Klaus Darilion
> > > > = > Cc: =0A= speermint@ietf.org
> > > > > Subject: RE: [Speermint] =0A= Congestion and Load Balancing
> > > > >
> > = > > =0A= > So, we can't invent anything new unless it has already been
> = > =0A= invented?
> > > > >
> > > > > I = don't think =0A= I agree that only manual methods of configuring
> > > > = > =0A= peers is the only way to go.  I presume that VSPs in a
> > = > =0A= > > federation may come and go, and that traffic between peers =0A= will
> come and go.
> >
> > > > > It = seems like =0A= on some time scale slower than call setup and
> > > > = > =0A= faster
> >
> > > > > than a contract = negotiation, =0A= there ought to be a way to adjust
> > > > > parameters = of =0A= peers to reflect a balance between traffic offered
> > and = resources =0A= available.
> > > > >
> > > > > When =0A= contacted based on a DNS lookup, it doesn't seem that bad
> > = > > =0A= > to tell
> > > a
> > > > > peer which = has =0A= shown it is part of a federation which proxy
> > > > > =0A= (farm)
> >
> > > > > to use and what = parameters to =0A= stay within.
> > > > >
> > > > > =0A= Mike
> > > > >
> > > > >
> = > > =0A= >
> > > >
> > > > =0A= _______________________________________________
> > > > = Speermint =0A= mailing list
> > > > Speermint@ietf.org
> > > = > https://www1.ietf.org/mailman/listinfo/speermint
> =0A= >
> >
> > =0A= _______________________________________________
> > Speermint = mailing =0A= list
> > Speermint@ietf.org
> > https://www1.ietf.org/mailman/listinfo/speermint
>
&g= t;



_______________________________________________
Spee= rmint =0A= mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint