Re: [DMM] Answer on raised questions for the proposed API

[Seil Jeon <[e-mail]>]

Hi Danny,



Meeting is always good, even with you by f-to-f. But in the discussion, the
main issue is whether we will allow the default source address selection
rules defined in RFC6724 for selecting a Sustained IP address among several
ones or fundamentally block them for a specific reason raised by a DMM
need. The latter approach is not reasonable no matter how I try to think
of.it.

If an application has the specific preference of a newly obtained Sustained
IP address, it uses the proposed API.



Regards.

Seil

On Sun, Apr 5, 2015 at 12:22 PM, Moses, Danny <[e-mail]> wrote:

>  Hi Seil,
>
>
>
> By now we have been discussing this for quite some time and clearly we did
> not succeed in convincing each other.
>
> I suggest we try again when we have a chance to meet face to face.
> Meanwhile, let's listen to what other people have to say on this matter.
>
>
>
> Regards,
>
>                 /Danny
>
>
>
> *From:* Seil Jeon [mailto:[e-mail]]
> *Sent:* Sunday, April 05, 2015 01:16
> *To:* Moses, Danny
> *Cc:* [e-mail]
> *Subject:* RE: [DMM] Answer on raised questions for the proposed API
>
>
>
> Resent.
>
>
>
> Seil
>
>
>
> *From:* Seil Jeon [mailto:[e-mail] <[e-mail]>]
> *Sent:* Saturday, April 04, 2015 1:35 PM
> *To:* 'Moses, Danny'
> *Cc:* '[e-mail]'
> *Subject:* RE: [DMM] Answer on raised questions for the proposed API
>
>
>
> Hi Danny,
>
>
>
> See the inline please. I marked current replies with “>>” and previous
> replies with “>” for you to catch them easily.
>
>
>
> Regards,
>
> Seil
>
>
>
>
>
> *From:* Moses, Danny [mailto:[e-mail] <[e-mail]>]
>
> *Sent:* Thursday, April 02, 2015 2:16 PM
> *To:* Seil Jeon
> *Cc:* [e-mail]
> *Subject:* RE: [DMM] Answer on raised questions for the proposed API
>
>
>
> Hi Seil,
>
>
>
> Please see my replies (surrounded by  >>2) to yours.
>
>
>
> Regards,
>
>                 /Danny
>
>
>
> *From:* Seil Jeon [mailto:[e-mail] <[e-mail]>]
> *Sent:* Tuesday, March 31, 2015 15:23
> *To:* Moses, Danny
> *Cc:* [e-mail]
> *Subject:* RE: [DMM] Answer on raised questions for the proposed API
>
>
>
> Hi Danny,
>
>
>
> See the inline please.
>
>
>
>
>
> Seil Jeon
>
>
>
>
>
> *From:* Moses, Danny [mailto:[e-mail] <[e-mail]>]
>
> *Sent:* Monday, March 30, 2015 4:44 PM
> *To:* Seil Jeon
> *Cc:* [e-mail]
> *Subject:* RE: [DMM] Answer on raised questions for the proposed API
>
>
>
> Hi Seil,
>
>
>
> As to the potential of abuse:
>
> Yes, I see your point and you are correct. If the IP stack will not
> request a sustained IP address more than once after each movement to a new
> LAN (with a different prefix), than there will be no abuse.
>
>
>
> > Yes, it’s true. Thanks for correction.
>
>
>
> As to the second comment, please let me elaborate:
>
> One potential implementation of the IP stack in the host, can be to
> request a Nomadic IP address and a  Sustained IP address whenever
> connecting to a network, and whenever moving to a new LAN, regardless if
> there are any applications requesting any addresses. This way, whenever an
> application is launched and requests either a Nomadic or Sustained IP
> address, the stack can provide one without having to issue a request to the
> network. In this case, there is no need for this flag from the application.
>
>
>
> > Decision of which type of IP address by default will be depending on the
> IP pool management policy by operators. You case may correspond to one of
> them. What if only the Nomadic IP address is basically allocated upon a
> network attachment? That is, a lot of applications require mere Internet
> connectivity without session continuity support. So, the Sustained IP
> address will be requested on demand, and the proposed flag will be used to
> get a new Sustained IP address by expressing the explicit request by an
> application.
>
>
>
> >>2
>
> As I mentioned at the beginning of the description – it is a description
> of one alternative. I am not assuming it is the only scenario.
>
> Yes, I agree that many apps require only Nomadic IP addresses, but in this
> example, the IP stack in the host pre-allocates both Nomadic and Sustained
> IP addresses upon attachment…
>
>
>
> >> As I said, it could be, but not as general one. The proposed API is
> useful through the explicit expression for any potential scenarios.
>
>
>
> Yes, we can describe an alternative in which a Nomadic IP address is
> pre-allocated upon NW connection (and after every movement to a new LAN)
> and a Sustained (and/or Fixed) address is allocated on-demand. Even in such
> a scenario, I do not see any use for this flag – see my reply to the second
> item below…
>
> >>2
>
>
>
> >> My answer was already given in following answer in previous email.
>
>
>
> Another potential implementation of the IP stack in the host is not to
> request IP addresses in advance. In that case, it will issue a request for
> a Nomadic IP address or a Sustained IP address the first time an
> application requests one and use it for subsequent requests as long as it
> is not moving to a different LAN. Once it moves, it will again request a
> new IP address (Nomadic or Sustained – according to what is required) after
> receiving the first request from any application. In this case as well,
> there is no need for this flag.
>
>
>
> > Another application requested just Sustained IP address while the IP
> stack has already a Sustained IP address. Why should the IP stack try to
> get a new one, though the application indicated simply “Sustained IP
> address type”? You case took a step towards a solution where you want to
> draw. I don’t expect the action is generic when a Sustained IP address type
> is requested.
>
> Besides, you assumption on IP address allocation seems not valid. A mobile
> host would get an IP address whatever the allocated IP address type is when
> it attaches at a network, regardless of an application’s IP address request.
>
>
>
> >>2
>
> Looks like I did not express myself well enough (and did not fully
> understand your reply). Let me list some events that might help clarify…
>
>
>
> Initial state: Mobile node is connected to a network; no Sustained IP
> address is allocated. The IP stack sets a flag (SustainedIPAddressNeeded)
> indicating that if an application requests a Sustained IP address, it will
> have to request one from the network.
>
>
>
> Event1: An application that requires a Sustained IP address is launched.
>
> APP action: App requests a Sustained IP address from the IP stack using
> the proposed new API.
>
> IP stack action: Since SustainedIPAddressNeeded is set, request one from
> the network.
>
> Network action: Assigned a Sustained IP address to the mobile node.
>
> IP stack action: (1) Mark the new Sustained IP address as the one to be
> associated to subsequent apps; (2) Reset SustainedIPAddressNeeded;
> (3)Complete the API action and associate the marked Sustained IP address
> with that port (app)
>
>
>
> Event2: A new application that also required a Sustained IP address is
> launched
>
> App action: App requests a Sustained IP address from the IP stack using
> the proposed new API
>
> IP Stack action: Since SustainedIPAddressNeeded  is not set, complete the
> API action and associate the marked Sustained IP address with that port
> (app)
>
>
>
> Event3: The mobile node moves to a new LAN
>
> IP Stack action: Set a flag indicating that the currently available
> Sustained IP address is not optimized
>
>
>
> Event4: An application that requires a Sustained IP address is launched.
>
> APP action: App requests a Sustained IP address from the IP stack using
> the proposed new API.
>
> IP stack action: Since SustainedIPAddressNeeded is set, request one from
> the network.
>
> Network action: Assigned a Sustained IP address to the mobile node.
>
> IP stack action: (1) Mark the new Sustained IP address as the one to be
> associated to subsequent apps; (2) Reset SustainedIPAddressNeeded;
> (3)Complete the API action and associate the marked Sustained IP address
> with that port (app)
>
>
>
> Note that the behavior of the IP stack in Event4 is exactly like the one
> in Event1.
>
>
>
> *I believe that this event is the one we have different of opinions: I
> think that the default behavior of the IP stack is to request a new
> Sustained IP address since it moved to a new LAN, and you think that it
> should do so only if the application specifically requests a new Sustained
> IP address via the flag you are proposing.*
>
> >>2
>
>
>
> >> You can see my answer at the lowest “>>” in this mail.
>
>
>
> As a matter of fact, if such a flag is defined, I cannot think of an
> example where it will not be used. It seems to me that applications will
> always request a refreshed Sustained IP address (when requesting a
> Sustained IP address). If this is correct, the flag is redundant.
>
>
>
> > Some applications, e.g. email, that are not relatively restricted from
> optimal routing would consider a Sustained IP address without issuing the
> new flag. More applications based on such network characteristic can be
> thought more than expected.
>
> And such use of existing Sustained IP address is not extraordinary, since
> IP address is a resource, even in the consideration of IPv6 deployment. If
> as many as applications require new Sustained IP address, it will end up in
> a lot of network resource consumption in the mobility routers where the
> Sustained IP addresses are anchored as the terminal moves.
>
> >>2
>
> I am sorry but I disagree with the email example. I categorize it as an
> example of an application that will request a Nomadic address since it does
> not break when the mobile node moves to a new LAN and the source IP address
> is changed. It simply restarts the socket and continue with the new source
> IP address (the user will not even notice this).
>
>
>
> >> The example was given as a benefit when the existing Sustained IP
> address is used. You could get some insight from such kind of application
> not caring much the routing distance even on the Sustained IP address.
>
>
>
> I did not understand the other text regarding resource consumption. I
> thought we agreed that even of a new Sustained IP address is requested upon
> each movement to a new LAN, the effect on IP address allocation is not
> significant. Otherwise, my initial comment on applications abusing the
> network using your proposed flag, becomes valid again
>
> >>2
>
>
>
> >> No, our draft didn’t say so. Our idea is that a new Sustained IP
> address is requested upon receiving *new* flag from an application, as a
> preference for a source address selection. You need to read our draft
> classifying the categories of IP address request again.
>
>
>
> Besides, I don’t understand what is abused. Delivering its preference
> cannot be abuse. Regarding “abuse”, I see it in your default behavior
> you’re assuming here. In your scenario, a new app initiated in a new
> network will be forced to use a newly obtained Sustained IP address. You
> see that? You totally block the possibility to be considered by the default
> source address selection rules defined in RFC6724. But in our draft, in
> case the need of a newly obtained Sustained IP address is prioritized, the
> proposed *new* flag can be used by app’s request, thus it will be selected
> with priority.
>
>
>
> Can you provide a scenario in which an application will not request to
> refresh the Sustained IP address?
>
>
>
> > It was mentioned in the former comments.
>
>
>
>
>
> Regards,
>
>                 /Danny
>
> *From:* Seil Jeon [mailto:[e-mail] <[e-mail]>]
> *Sent:* Monday, March 30, 2015 17:08
> *To:* Moses, Danny
> *Cc:* [e-mail]
> *Subject:* FW: [DMM] Answer on raised questions for the proposed API
>
>
>
> Hi Danny,
>
>
>
> Any comments?
>
>
>
> Regards,
>
> Seil Jeon
>
>
>
>
>
> *From:* dmm [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *Seil Jeon
> *Sent:* Thursday, March 26, 2015 8:08 PM
> *To:* [e-mail]
> *Subject:* [DMM] Answer on raised questions for the proposed API
>
>
>
> Hi,
>
>
>
> I could attend DMM Thursday meeting via MeetEcho.
>
> I could also hear some raised comments by Danny and Someone. Here goes
> answers to the raised questions.
>
>
>
>
>
> First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW),
>
>
>
> The use of the proposed API is suggested in the SUSTAINED IP address case
> in the draft. On receiving this API with the SUSTAINED IP address type at
> the IP stack, it will try to get a new SUSTAINED IP address if there is no
> available in the currently attached access network. So, actual obtaining of
> the IP address will be tried one time while attached at a specific access
> network. Even some applications put this API after, the already obtained
> SUSTAINED IP will be used. So, no worries about abuse.
>
>
>
> Second question sounded to me like that this API is not needed because the
> host can get a new SUSTAINED IP address, right?
>
> If the question is right, I don’t understand what the question is meant,
> that is how the host can get a new SUSTAINED IP address?
>
> Based on the definition of three types of IP address, an application
> should show its requirement with an API among them. If it is the SUSTAINED
> IP address, how do we expect the IP stack will try to get a new SUSTAINED
> IP address?
>
>
>
> Besides, the propsoed API is not used alone but with the three type APIs.
>
>
>
>
>
>
>
> Regards,
>
>
>
> Seil Jeon
>
>
>
>
>
> ---------------------------------------------------------------------
> 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.
>
> ---------------------------------------------------------------------
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmm
>
>