On Tue, Mar 5, 2019 at 2:29 AM Moses, Danny <[email protected]> wrote:
>
> 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);
> Thanks,
> Danny
>
> -----Original Message-----
> From: Tom Herbert [mailto:[email protected]]
> Sent: Monday, March 04, 2019 17:17
> To: Moses, Danny <[email protected]>
> Cc: dmm <[email protected]>
> Subject: Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt
>
> On Mon, Mar 4, 2019 at 4:25 AM Moses, Danny <[email protected]> wrote:
> >
> > 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.
> >
> 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
>
> > Regards,
> > Danny
> >
> >
> >
> >
> > -----Original Message-----
> > From: dmm [mailto:[email protected]] On Behalf Of Tom Herbert
> > Sent: Friday, February 22, 2019 22:08
> > To: dmm <[email protected]>
> > 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 protected]> 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-mobili
> > > ty
> > > -17
> > >
> > > A diff from the previous version is available at:
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-ondemand-mobility-1
> > > 7
> > >
> > >
> > > 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 protected]
> > > https://www.ietf.org/mailman/listinfo/dmm
> >
> > _______________________________________________
> > dmm mailing list
> > [email protected]
> > 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.
> >
> ---------------------------------------------------------------------
> 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
