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

A tao <yangjingtao@gmail.com> Tue, 11 October 2011 16:02 UTC

Return-Path: <yangjingtao@gmail.com>
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 5839B21F8EE0 for <sami@ietfa.amsl.com>; Tue, 11 Oct 2011 09:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.148
X-Spam-Level:
X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1]
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 Qf5EAmuarANe for <sami@ietfa.amsl.com>; Tue, 11 Oct 2011 09:02:00 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99B5F21F8EB3 for <sami@ietf.org>; Tue, 11 Oct 2011 09:01:53 -0700 (PDT)
Received: by vws5 with SMTP id 5so7059609vws.31 for <sami@ietf.org>; Tue, 11 Oct 2011 09:01:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N1Hj6MfrUVWeVHkq54d4rtw2xP28ni5qT9dWVeIlWpA=; b=TwRUrHV2klTpY6FU+IiYnKjxSldHa5Q16fLKXl4hCbjT59Lo3jnaOdg4pV42IvLcpc 2OJfmMavEOkdmVPif3obIk497xrDaG3RmZI36xNnsdo96jBuGYAPTdRWh9DGMCMjgxH4 wDKXjjTX+djNS0+qIBS75AF4dBTKCGuJOmX9s=
MIME-Version: 1.0
Received: by 10.52.36.41 with SMTP id n9mr19108386vdj.41.1318348911614; Tue, 11 Oct 2011 09:01:51 -0700 (PDT)
Received: by 10.52.108.100 with HTTP; Tue, 11 Oct 2011 09:01:51 -0700 (PDT)
In-Reply-To: <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> <20111011075143.GB9466@elstar.local>
Date: Wed, 12 Oct 2011 00:01:51 +0800
Message-ID: <CAB+71L1Ltu4TMTwejEzBDPuKcC+_cwF5YqV1fJc_o0t3WhW2gg@mail.gmail.com>
From: A tao <yangjingtao@gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Content-Type: multipart/alternative; boundary="20cf3079ba76911a1904af08060d"
Cc: "Yingjie Gu(yingjie)" <guyingjie@huawei.com>, "卓志强(研七 福州)" <zhuozq@ruijie.com.cn>, "sami@ietf.org" <sami@ietf.org>, "刘茗(研六 福州)" <lium@ruijie.com.cn>, 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
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 16:02:01 -0000

No doubt that a performance test results can help people to understand, to
some extent, why there are requirements and implementations to move security
functions, such as firewall/DHCP snooping/ACLs, out of Hypervisor or
servers.

If Ming can provide this results, that will be best.

We don't have the data but we also talked with DC providers, and they gave
me an example to explain why they want the firewall being executed by
network side. They deployed a VM to run Firewall functions on a x86 server.
And by test, they find the firewall consumes more than large amount of CPU
capacity which otherwise can be used to support 2-3 VMs. I don't get the
real data and the test situation, this is only a information.

2011/10/11 Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>

> 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/>
>