From guyingjie@huawei.com Wed Feb 29 17:16:31 2012 Return-Path: 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 9D0B821E804C for ; Wed, 29 Feb 2012 17:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.533 X-Spam-Level: X-Spam-Status: No, score=-105.533 tagged_above=-999 required=5 tests=[AWL=1.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 klk5pp85NhJO for ; Wed, 29 Feb 2012 17:16:29 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFC321E801F for ; Wed, 29 Feb 2012 17:16:23 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M06003KTM742M@szxga04-in.huawei.com> for sami@ietf.org; Thu, 01 Mar 2012 09:16:16 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0600LGFM74TN@szxga04-in.huawei.com> for sami@ietf.org; Thu, 01 Mar 2012 09:16:16 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHD75268; Thu, 01 Mar 2012 09:16:15 +0800 Received: from SZXEML432-HUB.china.huawei.com (10.72.61.60) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 01 Mar 2012 09:16:09 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.59]) by SZXEML432-HUB.china.huawei.com ([10.72.61.60]) with mapi id 14.01.0323.003; Thu, 01 Mar 2012 09:16:10 +0800 Date: Thu, 01 Mar 2012 01:16:09 +0000 From: "Yingjie Gu(yingjie)" X-Originating-IP: [10.138.41.175] To: "sami@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ECfU+NPIGk4oUuFm443H6g)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: First SAMI email in the new year, can we go further? Look forward to your opinions. Thread-index: Acz3SUkn2F6H2TiuReyy+E4fTWsLVg== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BaGI Bj8S Ciyn DAx8 Dey3 EAaZ EBrp GCue GLtW IF88 IJSN JL+X JPkj Ju0H LFYr LRr+; 1; cwBhAG0AaQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {CBF840A7-C03E-496E-AC9E-A26F668E6BB8}; ZwB1AHkAaQBuAGcAagBpAGUAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Thu, 01 Mar 2012 01:19:01 GMT; RgBpAHIAcwB0ACAAUwBBAE0ASQAgAGUAbQBhAGkAbAAgAGkAbgAgAHQAaABlACAAbgBlAHcAIAB5AGUAYQByACwAIABjAGEAbgAgAHcAZQAgAGcAbwAgAGYAdQByAHQAaABlAHIAPwAgAEwAbwBvAGsAIABmAG8AcgB3AGEAcgBkACAAdABvACAAeQBvAHUAcgAgAG8AcABpAG4AaQBvAG4AcwAuAA== x-cr-puzzleid: {CBF840A7-C03E-496E-AC9E-A26F668E6BB8} X-CFilter-Loop: Reflected Subject: [sami] First SAMI email in the new year, can we go further? Look forward to your opinions. X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 01:16:31 -0000 --Boundary_(ID_ECfU+NPIGk4oUuFm443H6g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi everyone, SAMI has been quiet for a long time since last IETF meeting. I was so busy dealing with other issues. Thank you for your continuous interest in SAMI. Hope we can continue discussion on SAMI in the mail list. According to previous discussion, one of the arguement is that we don't need State Migration if there is no VM Migration, we can, for example running active-active VMs mechanism to replace VM Migration. Whether VM Migration is a necessary mechanism is not in the scope of State Migration, we had a long discussion at the very beginning of the mail list. But since VM Migration is the precondition of State Migration problem, I would like to make some clarification. I agree that active-active VMs mechanism can support some scenarios, but not all. The problem statement draft is updated and provide two reasons. Here I cited from the draft. o Long lived connections: Some applications may establish connections with virtual machines and the connections are kept for a long time until the applications disconnect. One example is SQL, SqlConnection.Open() will always try to reuse an existing connection instead of creating a new one, and that SqlConnection.Close() will often release a connection to the connection pool instead of closing it.. The other is HTTP persistent connections, also called HTTP keep-alive, or HTTP connection reuse. The idea is to use the same TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new one for every single request/response pair. Using persistent connections is very important for improving HTTP performance. The above examples make it very clear that it's unexpectable how long the existing services will be alive, that is it's unexpectable how long the old VM need to be kept active. o Hardware failure: While there is hardware problem, it may not leave enough time for all the existing services to be finished. For example, there may be a power shortage in a particular area, and the DC providers have to move their VMs, services and data to another location in limited time. In this case, active-active mechanism may cause services disruption, if the existing services on old VMs keep running. Besides, VM migration has been a widely acknowledged technology and solutions (e.g. VMotion), so I would say we can reasonably assume VM Migration will happen and hence states need to be migrated with VM. If we get a consensus that VM Migration is a reasonable assumption, I suggest we go to detail of what we can do in IETF to resolve State Migration and how. But I look forward to your opinions. Thanks. ________________________________ Best Regards Gu Yingjie --Boundary_(ID_ECfU+NPIGk4oUuFm443H6g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi everyone,

SAMI has been q= uiet for a long time since last IETF meeting. I was so busy dealing with ot= her issues. Thank you for your continuous interest in SAMI.

Hope we can con= tinue discussion on SAMI in the mail list.

 

According to pr= evious discussion, one of the arguement is that we don’t need State M= igration if there is no VM Migration, we can, for example running active-active VMs mechanism to replace VM Migration. Whether VM Migration = is a necessary mechanism is not in the scope of State Migration, we had a l= ong discussion at the very beginning of the mail list. But since VM Migrati= on is the precondition of State Migration problem, I would like to make some clarification. I agree that a= ctive-active VMs mechanism can support some scenarios, but not all. The pro= blem statement draft is updated and provide two reasons. Here I cited from = the draft.

 

   o&= nbsp;  Long lived connections: Some applications may establish

  &nb= sp;    connections with virtual machines and the connections= are kept

  &nb= sp;    for a long time until the applications disconnect.&nb= sp; One example

  &nb= sp;    is SQL, SqlConnection.Open() will always try to reuse= an existing

  &nb= sp;    connection instead of creating a new one, and that

  &nb= sp;    SqlConnection.Close() will often release a connection= to the

  &nb= sp;    connection pool instead of closing it..  The oth= er is HTTP

  &nb= sp;    persistent connections, also called HTTP keep-alive, = or HTTP

  &nb= sp;    connection reuse.  The idea is to use the same T= CP connection to

  &nb= sp;    send and receive multiple HTTP requests/responses, as= opposed to

  &nb= sp;    opening a new one for every single request/response p= air.  Using

  &nb= sp;    persistent connections is very important for improvin= g HTTP

  &nb= sp;    performance.  The above examples make it very cl= ear that it's

  &nb= sp;    unexpectable how long the existing services will be a= live, that is

  &nb= sp;    it's unexpectable how long the old VM need to be kept= active.

 

   o&= nbsp;  Hardware failure: While there is hardware problem, it may not

  &nb= sp;    leave enough time for all the existing services to be=

  &nb= sp;    finished.  For example, there may be a power sho= rtage in a

  &nb= sp;    particular area, and the DC providers have to move th= eir VMs,

  &nb= sp;    services and data to another location in limited time= .  In this

   &n= bsp;   case, active-active mechanism may cause services disr= uption, if

  &nb= sp;    the existing services on old VMs keep running.

 

Besides, VM mig= ration has been a widely acknowledged technology and solutions (e.g. VMotio= n), so I would say we can reasonably assume VM Migration will happen and hence states need to be migrated with VM.

 

If we get a con= sensus that VM Migration is a reasonable assumption, I suggest we go to det= ail of what we can do in IETF to resolve State Migration and how.

But I look forw= ard to your opinions.

 

Thanks.

Best Regards Gu Yingjie

 

--Boundary_(ID_ECfU+NPIGk4oUuFm443H6g)--