Subject: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 --

From: Dave Dolson <[email-masked]>
Date: Thu, 8 Dec 2016 18:59:52 +0000

I'm just catching up on the recent drafts, so apologies if this has been covered...

1. It seems like RFC 6724 will need to be updated by dmm-ondemand-mobility.
I'm unclear on how the algorithm should be modified. Has anyone worked this out?
My sense is that Rule 4 needs to be modified to consider the new flags.
Either this document should spell out the new algorithm, or we plan for RFC6724bis.

2. Regarding the language about IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA
with legacy applications, I think it would be right to continue to support these.
PREFER_SRC_HOME could ask the network for FIXED, but automatically fall back to another address.
I think this is useful so that the application doesn't have to handle EAI_REQUIREDIPNOTSUPPORTED and try again.
(This comment goes back to point 1.)

3. I don't understand the need for IPV6_REQUIRE_NON-PERSISTENT_IP as an explicit flag.
I would think it works better to provide this behavior if neither of the other flags are set.
Literally it says, "I will not accept a FIXED or SESSION_LASTING IP". Is that useful?
It can be provided, but I don't think any app would use it. Maybe just for testing the network?

4. Consider an appendix showing source code for clients and servers with different requirements.
E.g., I believe that the setsockopt() needs to be done after socket() but before bind(), connect(), send(), sendmsg(), sendmmsg(), sendto(),etc.
(After any packets are sent is too late.)
I think it would be useful to show this recipe.

5. Are there new errors from bind(), listen() or connect(), etc.?
E.g., socket option is FIXED, but user explicitly specified a COA address to bind to?

David Dolson
Senior Software Architect, Sandvine Inc.

---

From: "Moses, Danny" <[email-masked]>
Date: Mon, 12 Dec 2016 15:50:24 +0000

Oops,

Sorry but I missed this email. Sorry.

I will review the comments and if needed, will upload another version.
Hope to complete the work by tomorrow.

Regards,
Danny

From: Dave Dolson [mailto:[email-masked]]
Sent: Thursday, December 08, 2016 21:00
To: Moses, Danny <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: WGLC for draft-ietf-dmm-ondemand-mobility-08 --

David Dolson

---------------------------------------------------------------------
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: "Moses, Danny" <[email-masked]>
Date: Wed, 14 Dec 2016 09:46:34 +0000

Hi,

I have fixed the two typos you indicated in the previous emails.
Please see my embedded reply.
I am waiting for you reply on my question below regarding the source code example comment before uploading rev 10.

Thanks for the useful comments,
Danny

DM>> This is probably true. I am adding an RFC6724 fix to my ToDo list which is quite long, so I hope someone else
Takes this work. If not, let's do this together in the future.

DM>> First, for backwards compatibility, we must support these flags and the draft does not suggest otherwise. I prefer not to mix the functionality of the legacy flags - IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA with the new flags defined in the OnDemand draft. The main reason is that the former flags are related to a MIP environment were the MN terminates the tunnel, while the OnDemand flags are related to a proxy MIP environment (PMIP or GTP - for example) were the MN is not aware of the mobility support.

DM>> Actually, this flag is one of the main motivation for this work. It enables the application to explicitly request the network not to create a tunnel for the IP session and avoid the unnecessary overhead associated with the tunnel. Opening a socket without using any of these flags means that the application does not have a preference to the type of service it receives from the network and leave the decision of choosing the type of service to either the IP stack in the MN or the network. It is important to enable the application to explicitly request a non-persistent service (and to receive an error if this service is not supported).

DM>> Your description is correct. I am wondering what is better, to add a short paragraph describing when setsockopt() should be used (as you described) or adding source code example. I prefer the text to be short and clear, and whenever we add source code examples we either end up with a long example, or limit ourselves to some obvious example that does not address all alternatives. Will adding the clarification that you pointed out be sufficient?

5. Are there new errors from bind(), listen() or connect(), etc.?
E.g., socket option is FIXED, but user explicitly specified a COA address to bind to?
DM>> We considered this, but decided not to go there since we would have to think of all the possible erroneous combination and programmer might do. We therefore, decided to clearly state that such behavior would be ignored.

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Thu, 15 Dec 2016 17:46:03 +0000

Danny,
Please see inline [DD]

In general, I feel the specification of the programming API is incomplete, which may cause incompatibilities in different operating systems.
(I'm not concerned with the implementation specifics of communicating with the network, just the API.)

-Dave

From: Moses, Danny [mailto:[email-masked]]
Sent: Wednesday, December 14, 2016 4:47 AM
To: Dave Dolson
Cc: [email-masked]; [email-masked]
Subject: RE: WGLC for draft-ietf-dmm-ondemand-mobility-08 --

Hi,

DM>> This is probably true. I am adding an RFC6724 fix to my ToDo list which is quite long, so I hope someone else
Takes this work. If not, let's do this together in the future.
[DD] Question to the list: has anyone worked out a viable algorithm for selecting source address?

[DD] OK, but the tone of the document, including use of the word "legacy" implies deprecation. There is even wording "Legacy applications ...  will not enjoy On-Demand Mobility feature." In contrast, I think that IPV6_PREFER_SRC_HOME should provide a home address when available.

[DD] But wearing the hat of a developer, why would my application ever request this, other than for network diagnostics? If I don't care for HOME address, I would just let the stack choose... Or is there some benefit to the non-persistent address that I'm missing?

[DD] OK. Perhaps when the flags are mentioned with setsockopt(), find a place for some words like, "In practice, setsockopt() would need to be called immediately after socket creation with socket(), before bind(), listen(), connect(), sendto(), etc. that would require an address to be chosen."

5. Are there new errors from bind(), listen() or connect(), etc.?
E.g., socket option is FIXED, but user explicitly specified a COA address to bind to?
DM>> We considered this, but decided not to go there since we would have to think of all the possible erroneous combination and programmer might do. We therefore, decided to clearly state that such behavior would be ignored.
[DD] Wearing the hat of an implementor, I'm sad that the specification is ambiguous. How about saying, "When an application explicitly provides an address (e.g., to bind()), this should override any address-selection hints, and an error SHOULD NOT be raised."

David Dolson

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 19 Dec 2016 10:03:33 +0900

> E.g., socket option is FIXED, but user explicitly specified a COA address

+1. An implementer would probably choose to return EADDRNOTAVAIL if an API
requested a type of address that is not available, but the draft makes no
mention of that.

The draft also fails to mention which of the APIs will result in a request
to the network (which can block for a long period of time) and which will
not. It will be quite unexpected to app developers if system calls such as
bind() and setsockopt(), which always return immediately, can suddenly
block for whole seconds. It would also be highly unexpected if connect() on
a UDP socket took a long time since it currently returns immediately.

I don't think it's a good idea to overload these existing system calls with
new "obtain an prefix from the network" semantics. It's better to add a new
system call for that.

---

From: "Moses, Danny" <[email-masked]>
Date: Mon, 19 Dec 2016 11:15:54 +0000

OK, two is a crowd…

I am thinking of the appropriate example and will send a draft for review.

I think there might be a confusion regarding the HOME and CoA flags. Although they are also related to mobility and enable applications a selection between two types of source IP addresses, they are very different and should not be discussed in the context of OnDemand.

The HOME and CoA flags are defined to enable an application to select between a HOME address and a Care-of address. This is in the context of Mobile IP (no Proxy Mobile IP) in which the network allocates both a Home Address and a Care-of Address to the mobile host. These flags enable applications to select the type of IP session continuity in this context (where the host is one termination point of the tunnel).

The context of the OnDemand draft is PMIP (or any proxy-based architecture, like GTP). In this context, the mobile host does not have a Home Address and a Care-of-Address since the tunnel is terminated by a proxy agent. So an application cannot specify its preference regarding Home or CoA.

Danny

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Monday, December 19, 2016 03:04
To: Dave Dolson <[email-masked]>
Cc: Moses, Danny <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 --

rOn Fri, Dec 9, 2016 at 3:59 AM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:
5. Are there new errors from bind(), listen() or connect(), etc.?
E.g., socket option is FIXED, but user explicitly specified a COA address to bind to?

+1. An implementer would probably choose to return EADDRNOTAVAIL if an API requested a type of address that is not available, but the draft makes no mention of that.

The draft also fails to mention which of the APIs will result in a request to the network (which can block for a long period of time) and which will not. It will be quite unexpected to app developers if system calls such as bind() and setsockopt(), which always return immediately, can suddenly block for whole seconds. It would also be highly unexpected if connect() on a UDP socket took a long time since it currently returns immediately.

I don't think it's a good idea to overload these existing system calls with new "obtain an prefix from the network" semantics. It's better to add a new system call for that.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

---

From: Dave Dolson <[email-masked]>
Date: Tue, 20 Dec 2016 14:34:31 +0000

Danny,
Thank you for explaining. I read this draft without knowing the back story, and I did not glean the explanation below from the draft.

If you want the explanation recorded for posterity, it should be in the draft.

Having said that, it would be better, in my opinion, if this API is NOT specific to proxy-based architectures.
An application programmer is concerned with whether it needs a long-lasting address or whether an ephemeral address is acceptable.
(i.e., am I a client or a server?)

I don’t see many application programmers concerned with on-demand DMM per se.

-Dave

From: Moses, Danny [mailto:[email-masked]]
Sent: Monday, December 19, 2016 6:16 AM
To: Lorenzo Colitti; Dave Dolson
Cc: [email-masked]; [email-masked]
Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 --

OK, two is a crowd…

Danny