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

[Mirja Kuehlewind <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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:[e-mail]] 
> Sent: Thursday, August 01, 2019 16:03
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Dapeng Liu <[e-mail]>; Sri Gundavelli <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
> 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.