Re: [sami] A new draft on state migration use cases is submitted.

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 11 October 2011 07:52 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: sami@ietfa.amsl.com
Delivered-To: sami@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A62421F8D6E for <sami@ietfa.amsl.com>; Tue, 11 Oct 2011 00:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.699
X-Spam-Level:
X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLKQSdcgAihT for <sami@ietfa.amsl.com>; Tue, 11 Oct 2011 00:52:00 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6014421F8D36 for <sami@ietf.org>; Tue, 11 Oct 2011 00:52:00 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46EF420DEB; Tue, 11 Oct 2011 09:51:59 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gBdLPEcqA-JR; Tue, 11 Oct 2011 09:51:58 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3FA920DC2; Tue, 11 Oct 2011 09:51:57 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0C0D11B1B7B6; Tue, 11 Oct 2011 09:51:44 +0200 (CEST)
Date: Tue, 11 Oct 2011 09:51:43 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "卓志强(研七 福州)" <zhuozq@ruijie.com.cn>
Message-ID: <20111011075143.GB9466@elstar.local>
References: <CAB+71L3btz_h8Lkm9jW-WHUeS4=K-Jq-r9mmX94=NdHiepkJ-Q@mail.gmail.com> <2CE4AB2F9CD06543A3F2B0FE76661E12125C8295@fzex.ruijie.com.cn> <20111009160138.GB99820@elstar.local> <000601cc86eb$829967f0$87cc37d0$@com> <2CE4AB2F9CD06543A3F2B0FE76661E12125C85F9@fzex.ruijie.com.cn> <4A95BA014132FF49AE685FAB4B9F17F61209F3D1@dfweml506-mbx> <169529F73649BF469B4F61792955CD5C125E230D@fzex.ruijie.com.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <169529F73649BF469B4F61792955CD5C125E230D@fzex.ruijie.com.cn>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Yingjie Gu(yingjie)" <guyingjie@huawei.com>, "刘茗(研六 福州)" <lium@ruijie.com.cn>, "sami@ietf.org" <sami@ietf.org>, 'A tao' <yangjingtao@gmail.com>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [sami] A new draft on state migration use cases is submitted.
X-BeenThere: sami@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: State Migration <sami.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sami>, <mailto:sami-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sami>
List-Post: <mailto:sami@ietf.org>
List-Help: <mailto:sami-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sami>, <mailto:sami-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Oct 2011 07:52:01 -0000

On Tue, Oct 11, 2011 at 06:06:34AM +0000, 卓志强(研七 福州) wrote:
> I have the following documents to get some reference data,
> http://people.netfilter.org/kadlec/nftest.pdf
> 
> The "filtering rules" is like ACLs. As the numbers increase, the
> performance of different software have declined.

Your proposition is that moving filtering rules from the endpoint (the
hypervisor) into the network is cheaper and easier to scale. To make
any sense of the above quoted document, I would need to know what the
performance of middleboxes is going to be and I would need to know how
many hypervisors are going to be behind a middlebox. If its lets say
1:10 (one switch to ten hypervisors), then the middleboxes would need
to outperform a kernel software filter by a factor significant larger
than 10. I guess you have done this calculation so it should be easy
to provide a concrete data point.

Once the scalability trade-off is clear, one can look at the costs of
the various options (essentially more hypervisors vs. fancier switches
that peak into L4 and perhaps even beyond). I would love if problem
statement documents would go into exactly this level of detail.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>