Re: [DMM] Mirja Kühlewind's No Objection on draft-ietf-dmm-ondemand-mobility-18: (with COMMENT)

"Moses, Danny" <danny.moses@intel.com> Thu, 01 August 2019 17:48 UTC

Return-Path: <danny.moses@intel.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0136D1201C5; Thu, 1 Aug 2019 10:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Ci3Gm6ZafLMq; Thu, 1 Aug 2019 10:48:50 -0700 (PDT)
Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (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 DBC961201B4; Thu, 1 Aug 2019 10:48:49 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2019 10:48:49 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.64,335,1559545200"; d="scan'208";a="196924063"
Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga004.fm.intel.com with ESMTP; 01 Aug 2019 10:48:49 -0700
Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 1 Aug 2019 10:48:49 -0700
Received: from hasmsx105.ger.corp.intel.com (10.184.198.19) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 1 Aug 2019 10:48:48 -0700
Received: from hasmsx106.ger.corp.intel.com ([169.254.10.57]) by HASMSX105.ger.corp.intel.com ([169.254.1.231]) with mapi id 14.03.0439.000; Thu, 1 Aug 2019 20:48:46 +0300
From: "Moses, Danny" <danny.moses@intel.com>
To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= <ietf@kuehlewind.net>
CC: "draft-ietf-dmm-ondemand-mobility@ietf.org" <draft-ietf-dmm-ondemand-mobility@ietf.org>, Dapeng Liu <max.ldp@alibaba-inc.com>, Sri Gundavelli <sgundave@cisco.com>, "dmm-chairs@ietf.org" <dmm-chairs@ietf.org>, "dmm@ietf.org" <dmm@ietf.org>, The IESG <iesg@ietf.org>, Suresh Krishnan <suresh.krishnan@gmail.com>, "Satoru Matsushima (satoru.matsushima@gmail.com)" <satoru.matsushima@gmail.com>
Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-dmm-ondemand-mobility-18:_(with_COMMENT)?=
Thread-Index: AQHVSGlqL5yDOeP5pEiILHn/DxTCZabmifyw
Date: Thu, 1 Aug 2019 17:48:45 +0000
Message-ID: <F0CF5715D3D1884BAC731EA1103AC28144312F41@HASMSX106.ger.corp.intel.com>
References: <156466455152.19187.16688460554713358200.idtracker@ietfa.amsl.com>
In-Reply-To: <156466455152.19187.16688460554713358200.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ctpclassification: CTP_NT
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNjc0ODRkODgtMzZkZi00ODY4LWJmOTYtYWM0M2IyMjFkOGE3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoicGswM2RtdFcrSWhzRGdaMUc0S25kTE9ib0l4dUR0TUxIeEw0SzQzRG5HMnZ1WUdsTlR2aU9yeGpYUlRZYnJcL2cifQ==
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
x-originating-ip: [10.184.70.10]
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/zHXZaAXvRas5_w2YKyv88LWBU3c>
Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-dmm-ondemand-mobility-18=3A_=28with_COMMENT=29?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Aug 2019 17:48:52 -0000

Hi Again,
Regarding your clarification about mobility being better served by the transport layer versus the application layer.

This work is not about trying to find a better or more efficient way to handle mobility while preserving the transport connection. It is about enabling applications to indicate whether or not they need this service, which is provided automatically and transparently in some mobile network implementations (like cellular networks).

Take, for example, the a video browser app. Since it is buffering parts of the video, it can close an existing socket and open a new one with different attributes, without any user-experience degradation. This could be useful when, as a result of a host moving to a different place that has a different (closer) instance of the video server. A switch to the new video server instance requires that the video browser is aware of the mobility event and is able to locate a different server. If the IP connection is preserved (by tunneling or any other way), the video browser will stay connected to the original server and the quality-of-experience might be affected. This is an example for a Graceful-replacement service that is more appropriate than the Session-lasting service. 

Another question you had was to whether the word 'application' is always correct. I cannot commit to 'always', but this work was designed to enable applications to convey their service needs. A transport layer cannot know the abilities of the different applications to cope with source IP address changes, only applications know that. In addition, several applications can execute concurrently, each with different needs. So the flexibility of selecting the service type should be per-application, or even, per-socket, as application may use more than one socket. 

We tried to convey both these points in the document. If you think this is not clear, please help us improve the wording.

Thanks and regards,
Danny 



-----Original Message-----
From: Mirja Kühlewind via Datatracker [mailto:noreply@ietf.org] 
Sent: Thursday, August 01, 2019 16:03
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dmm-ondemand-mobility@ietf.org; Dapeng Liu <max.ldp@alibaba-inc.com>om>; Sri Gundavelli <sgundave@cisco.com>om>; dmm-chairs@ietf.org; sgundave@cisco.com; dmm@ietf.org
Subject: Mirja Kühlewind's No Objection on draft-ietf-dmm-ondemand-mobility-18: (with COMMENT)

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dmm-ondemand-mobility-18: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my discuss. Sorry for the long delay on my side!

Here is my old  comment still:

Please also note that address mobility is actually more a transport question that an application layer question. For TCP session-lasting addresses will always be more efficient if available while an application using TCP will always need to cover the case where an TCP connection fails or is interrupted and therefore the application needs to reconnect. However, in contrast QUIC supports IP address mobility and will survive changing IP addresses. I think that should be also clarified in the draft and it should be double-check if the use of the word application is always correct or if it should be replaced sometimes with e.g. transport system or a more general term.


---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.