IETF Logo Mail Archive

Re: [Sigtran] Query regarding capacity of sigtran link

David Laight <David.Laight@ACULAB.COM> Mon, 08 August 2016 12:57 UTC

Return-Path: <David.Laight@ACULAB.COM>
X-Original-To: sigtran@ietfa.amsl.com
Delivered-To: sigtran@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D7212D08F for <sigtran@ietfa.amsl.com>; Mon, 8 Aug 2016 05:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.955
X-Spam-Level:
X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgPwGcKgYcq8 for <sigtran@ietfa.amsl.com>; Mon, 8 Aug 2016 05:57:25 -0700 (PDT)
Received: from smtp-out6.electric.net (smtp-out6.electric.net [192.162.217.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D772E12B00B for <sigtran@ietf.org>; Mon, 8 Aug 2016 05:57:24 -0700 (PDT)
Received: from 1bWk7O-0000GT-Uu by out6b.electric.net with emc1-ok (Exim 4.87) (envelope-from <David.Laight@ACULAB.COM>) id 1bWk7P-0000Ic-TS; Mon, 08 Aug 2016 05:57:23 -0700
Received: by emcmailer; Mon, 08 Aug 2016 05:57:23 -0700
Received: from [213.249.233.130] (helo=AcuExch.aculab.com) by out6b.electric.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.87) (envelope-from <David.Laight@ACULAB.COM>) id 1bWk7O-0000GT-Uu; Mon, 08 Aug 2016 05:57:22 -0700
Received: from ACUEXCH.Aculab.com ([::1]) by AcuExch.aculab.com ([::1]) with mapi id 14.03.0123.003; Mon, 8 Aug 2016 13:55:31 +0100
From: David Laight <David.Laight@ACULAB.COM>
To: "'bidulock@openss7.com'" <bidulock@openss7.com>, "sigtran@ietf.org" <sigtran@ietf.org>
Thread-Topic: [Sigtran] Query regarding capacity of sigtran link
Thread-Index: AQHR8W9Vu/vutCKRo0K1yfh9ZrKb26A/BGmA
Date: Mon, 08 Aug 2016 12:55:30 +0000
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D5F50C32C@AcuExch.aculab.com>
References: <PS1PR04MB172269BA2582F52F16885623DE0E0@PS1PR04MB1722.apcprd04.prod.outlook.com> <1470651763.92914545@webmail.telesys.com> <20160808122239.GA2432@openss7.com>
In-Reply-To: <20160808122239.GA2432@openss7.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.202.99.200]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-IP: 213.249.233.130
X-Env-From: David.Laight@ACULAB.COM
X-Proto: esmtps
X-Revdns:
X-HELO: AcuExch.aculab.com
X-TLS: TLSv1:AES128-SHA:128
X-Authenticated_ID:
X-PolicySMART: 3396946, 3397078
X-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (s)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sigtran/66NEmqB6sXqzqXunupFZ_JyZlSg>
Subject: Re: [Sigtran] Query regarding capacity of sigtran link
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sigtran/>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2016 12:57:26 -0000

From: Brian F. G. Bidulock
> Sent: 08 August 2016 13:23
> Abhishek,
> 
> Abhishek Bhatt wrote:                    (Mon, 08 Aug 2016 15:52:43)
> >
> >    Can you please let me know about the maximum capacity (max traffic) of
> >    single sigtran associations (link) for both M3UA link and M2PA link.
> 
> Depends largely on how much network you have between the two points.

And how fast the systems are, and how 'slick' the application and the rest
of the protocol stack is.

The attainable throughput could quite easily be dominated by the application.

	David

v2.23.0 | Report a Bug | By Email