Re: [rrg] Arguments in favour of Core-Edge Elimination vs. Separation?

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 26 January 2010 21:51 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26F9A28C0F9 for <rrg@core3.amsl.com>; Tue, 26 Jan 2010 13:51:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level:
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLwU91Sx77cs for <rrg@core3.amsl.com>; Tue, 26 Jan 2010 13:51:37 -0800 (PST)
Received: from mail-fx0-f214.google.com (mail-fx0-f214.google.com [209.85.220.214]) by core3.amsl.com (Postfix) with ESMTP id 2C58C28C0F5 for <rrg@irtf.org>; Tue, 26 Jan 2010 13:51:37 -0800 (PST)
Received: by fxm6 with SMTP id 6so1030784fxm.7 for <rrg@irtf.org>; Tue, 26 Jan 2010 13:51:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ZFMogAjrzafkdGTuhvy66Ldb4VQ4VWGd107tgnKZT3o=; b=A2qC2oOuEQVEPi4yeWZMXumKpAEeWZN0SaFhS8/kiNKxuT4h7EutJE9gdcZotQMdRO 8XVqgvTb+6+Pln/7D4qNuU5gj51KYKKPFGoITWj3vDeGB7NMda8A8YWcuJ2qOZheP1pk UBmfnCMhe8QOQ6gRgMBnWasBcccxgFtplqrrU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=BkV0+04Tez2+5/t1zBhLtvYzBzZAfoOo28MtKC8GZwsplUhNgWS2P5z/F71BgkhRfw UY+tGqruuva7kYcNamuSxIp+fsyIxir8XPxDKKeSIoiRw+9Vm0oez79/QvJ2p/nShe5t /alD4U/butVU1GWlVD4T4wU7KWalvvgY+Nkik=
Received: by 10.87.69.33 with SMTP id w33mr13881078fgk.29.1264542705584; Tue, 26 Jan 2010 13:51:45 -0800 (PST)
Received: from ?10.1.1.4? ([121.98.142.15]) by mx.google.com with ESMTPS id l19sm9296076fgb.25.2010.01.26.13.51.42 (version=SSLv3 cipher=RC4-MD5); Tue, 26 Jan 2010 13:51:44 -0800 (PST)
Message-ID: <4B5F63E9.7050204@gmail.com>
Date: Wed, 27 Jan 2010 10:51:37 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
References: <20100126210354.042AC6BE56A@mercury.lcs.mit.edu>
In-Reply-To: <20100126210354.042AC6BE56A@mercury.lcs.mit.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: rrg@irtf.org
Subject: Re: [rrg] Arguments in favour of Core-Edge Elimination vs. Separation?
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2010 21:51:38 -0000

Noel,

> However, if the mapping function moves closer to the servers, the cache size
> will scale more reasonably. (A hand-wavy argument that the scaling will be
> feasible is provided by noting that at the limiting case, a single server, it
> can only support a limited number of TCP connections anyway, so it perforce
> will be talking to a limited share of the network.)

I don't think that's even very hand-wavy. If a server can handle state
for N simultaneous transactions, and the extra state per transaction to
cache the mapping info is a small fraction of the total state per
transaction, surely we can pick the cache lifetime so that the cache
size also scales like N.

Also, in the context of large-scale services, "server" these days
means a rack or a room full of virtual servers, which are there
precisely to deal with scaling like N.

So it becomes necessary, not optional, to move the mapping cache
to the places where state has to scale anyway. That takes it
out of traditional networking equipment, I think.

Regards
   Brian Carpenter