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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Thu, 01 Aug 2019 06:02:31 -0700

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.

---

From: "Moses, Danny" <[email-masked]>
Date: Thu, 1 Aug 2019 17:48:45 +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:[email-masked]] 
Sent: Thursday, August 01, 2019 16:03
To: The IESG <[email-masked]>
Cc: [email-masked]; Dapeng Liu <[email-masked]>; Sri Gundavelli <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Mirja Kühlewind's No Objection on draft-ietf-dmm-ondemand-mobility-18: (with COMMENT)

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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 2 Aug 2019 09:23:05 +0200

Hi Moses,

First this was only a comment from my side and not a discuss point. So it would be good if you can double-check the wording but there is probably not more to do.

However, let me give some more background on my point. There are also mobility solutions in the transport layer. QUIC can migrate to a new IP address without opening a new connection (so basically without changing the socket); MPTCP can use multiple IP addresses and as such also dynamically open and close TCP connections, however, for the application this looks like one connection/it’s one socket. 

As you said below this is a mainly an interface question, however, I just wanted to make sure that you have in mind that mobility not always means to close a socket and open a new one.

Mirja

> On 1. Aug 2019, at 19:48, Moses, Danny <[email-masked]> wrote:
> 
> Hi Again,