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 protected]] Sent: Thursday, August 01, 2019 16:03 To: The IESG <[email protected]> Cc: [email protected]; Dapeng Liu <[email protected]>; Sri Gundavelli <[email protected]>; [email protected]; [email protected]; [email protected] 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. _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
