Subject: Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt

From: "Moses, Danny" <[email-masked]>
Date: Mon, 4 Mar 2019 12:24:32 +0000

Hi Tom,

Fair question.

I believe I mentioned that in one of my responses. The original definition was to use setsockopt() with new flags. However, some people raised the concern that this new feature changes the behavior of the function in a way that may confuse programmers and requested to use a new function (setsc()).

The issue was due to the time it takes the function to process the request. In current Socket implementation, setsockopt() is a function that returns immediately to the caller. On the other hand, this new feature may trigger an exchange of packets between the IP stack in the mobile node and the network allocating the IP prefix. This exchange takes time and the function can return only after the exchange is completed. They insisted that we maintain the current 'immediate' return behavior of setsockopt() and introduce a new function that might 'block' the calling thread until it completes.

Regards,
Danny

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Friday, February 22, 2019 22:08
To: dmm <[email-masked]>
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt

Out of curiosity, why is the new API being portrayed as a system call
(setsc) instead of a socket option (the bar for adding a socket option is much lower ).

Tom

On Fri, Feb 22, 2019 at 6:19 AM <[email-masked]> wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Distributed Mobility Management WG of the IETF.
>
>         Title           : On Demand Mobility Management
>         Authors         : Alper Yegin
>                           Danny Moses
>                           Seil Jeon
>         Filename        : draft-ietf-dmm-ondemand-mobility-17.txt
>         Pages           : 18
>         Date            : 2019-02-22
>
> Abstract:
>    Applications differ with respect to whether they need session
>    continuity and/or IP address reachability.  The network providing the
>    same type of service to any mobile host and any application running
>    on the host yields inefficiencies, as described in [RFC7333].  This
>    document defines a new concep of enabling applications to influence
>    the network's mobility services (session continuity and/or IP address
>    reachability) on a per-Socket basis, and suggests extensions to the
>    networking stack's API to accomodate this concept.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-17
> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-ondemand-mobility
> -17
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-ondemand-mobility-17
>
>
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmm
---------------------------------------------------------------------
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: Tom Herbert <[email-masked]>
Date: Mon, 4 Mar 2019 07:16:43 -0800

> The issue was due to the time it takes the function to process the request. In current Socket implementation, setsockopt() is a function that returns immediately to the caller. On the other hand, t…
Hi Danny,

It is unclear to me why address selection has to be done outside of
binding the socket. It seems like the required functionality of the
draft could be achieved by calling setsockopt to express desired
address type and then calling connect on the socket. Connect will bind
an address with the requested type and can obviously block if work
needs to be done to find an appropriate address. This simplifies the
API and addresses an ambiguity in the draft-- when setsc returns it is
unclear if the address was somehow reserved for the socket use (e.g.
this becomes pertinent if we were to add an interface to bind a unique
address to a socket).

Tom

---

From: "Moses, Danny" <[email-masked]>
Date: Tue, 5 Mar 2019 10:29:27 +0000

Can you please provide a calling sequence of your proposal?

Thanks,
Danny

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Monday, March 04, 2019 17:17
To: Moses, Danny <[email-masked]>
Cc: dmm <[email-masked]>
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt

Hi Danny,

It is unclear to me why address selection has to be done outside of binding the socket. It seems like the required functionality of the draft could be achieved by calling setsockopt to express desired address type and then calling connect on the socket. Connect will bind an address with the requested type and can obviously block if work needs to be done to find an appropriate address. This simplifies the API and addresses an ambiguity in the draft-- when setsc returns it is unclear if the address was somehow reserved for the socket use (e.g.
this becomes pertinent if we were to add an interface to bind a unique address to a socket).

Tom

---

From: Tom Herbert <[email-masked]>
Date: Tue, 5 Mar 2019 08:25:31 -0800

> Can you please provide a calling sequence of your proposal?

Something like:

s = socket(AF_INET6, SOCK_STREAM, 0) ;
setsockopt(s, IPPROTO_IP, PREFERRED_ADDRESS_TYPE,
IPV6_REQUIRE_SESSION_LASTING_IP)
if (connect(s, &serverInfo, sizeof(serverInfo)) < 0) {
   if (errno == EADDRNOTAVAIL) {
            // Didn't get address for requested type
  }
  ...
}

// To get address local address that was selected...
getsockname(s, &myaddr, &myaddrlen);

---

From: "Moses, Danny" <[email-masked]>
Date: Wed, 6 Mar 2019 11:04:43 +0000

Yes, now I see your point. Setsockopt() will trigger the exchange of packets between the mobile host and the network to allocate the desired prefix (if not already allocated), and connect() will be blocked until the prefix is allocated and the TCP handshaking is completed.

Some pros and cons that come to mind are:
Pros:
Setsockopt() is still non-blocking.
Non need to pass the address as a parameter. 
No need for defining a new function.

Conns:
It is not clear how the connect() should act if the desired address type is not allocated by the network. Should it still connect with the address available to the host or should it fail?
If it continues to connect, the application is not aware of the type of mobility service it will receive from the network.
If it should not connect, we are changing the definition of the behavior of connect(). Furthermore, applications that do not care about mobility service, will use connect() without setsockopt(). So now, connect() need to know whether or not setsockopt() was invoked for setting the desired mobility service type - also a new functionality of connect().
It will not work for UDP (were connect() is not invoked). However, this is not a strong conn, since we can define that as a default address type for UDP sockets should be 'non-persistent'. 

When the concern regarding the 'blocking' nature of setsockopt() was discussed in DMM, we provided several alternatives for resolution, and after some discussion, the one defined in the document was chosen.

Your alternative is also viable, but it is not clear to me that it is significantly better and is worth reopening the discussion once again in DMM. But, our correspondence is on the list and everyone is welcome to post an opinion.

Regards,
Danny

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Tuesday, March 05, 2019 18:26
To: Moses, Danny <[email-masked]>
Cc: dmm <[email-masked]>
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt

Something like:

> > > https://datatracker.ietf.org/doc/html/draft-ietf-dmm-ondemand-mobi
> > > li
> > > ty
> > > -17
> > >
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-ondemand-mobility
> > > -1
> > > 7
> > >
> > >
> > --------------------------------------------------------------------
> > - 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: Tom Herbert <[email-masked]>
Date: Wed, 6 Mar 2019 07:47:32 -0800

> It is not clear how the connect() should act if the desired address type is not allocated by the network. Should it still connect with the address available to the host or should it fail?

It should fail with EADDRNOTAVAIL. If the application wants to
fallback to any available address it can do that itself when the error
is returned.

> It will not work for UDP (were connect() is not invoked). However, this is not a strong conn, since we can define that as a default address type for UDP sockets should be 'non-persistent'.

bind can be called in that case for the same effect.

> Your alternative is also viable, but it is not clear to me that it is significantly better and is worth reopening the discussion once again in DMM. But, our correspondence is on the list and everyo…

Danny,

The problem is that this is API and not protocol being standardized--
it may or may not be adopted by implementations. Adding a new socket
call is a big deal. You'll need to justify that this it is necessary
and that the functionality can't be acheived with existing API. I
would suggest that you post patches for this to Linux netdev to get
feedback from the developer community.

Tom