Re: Answer on raised questions for the proposed API

I have been experiencing a mail posting problem on the list. It is
forwarded with a different mail account.

@Danny, Sorry if you got multiple mails.

Regards,
Seil Jeon


On Sun, Apr 5, 2015 at 7:30 PM, Seil Jeon <[email protected]> wrote:

> 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 <[email protected]>
> 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:[email protected]]
>> *Sent:* Sunday, April 05, 2015 01:16
>> *To:* Moses, Danny
>> *Cc:* [email protected]
>> *Subject:* RE: [DMM] Answer on raised questions for the proposed API
>>
>>
>>
>> Resent.
>>
>>
>>
>> Seil
>>
>>
>>
>> *From:* Seil Jeon [mailto:[email protected] <[email protected]>]
>> *Sent:* Saturday, April 04, 2015 1:35 PM
>> *To:* 'Moses, Danny'
>> *Cc:* '[email protected]'
>> *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:[email protected]
>> <[email protected]>]
>> *Sent:* Thursday, April 02, 2015 2:16 PM
>> *To:* Seil Jeon
>> *Cc:* [email protected]
>> *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:[email protected] <[email protected]>]
>> *Sent:* Tuesday, March 31, 2015 15:23
>> *To:* Moses, Danny
>> *Cc:* [email protected]
>> *Subject:* RE: [DMM] Answer on raised questions for the proposed API
>>
>>
>>
>> Hi Danny,
>>
>>
>>
>> See the inline please.
>>
>>
>>
>>
>>
>> Seil Jeon
>>
>>
>>
>>
>>
>> *From:* Moses, Danny [mailto:[email protected]
>> <[email protected]>]
>> *Sent:* Monday, March 30, 2015 4:44 PM
>> *To:* Seil Jeon
>> *Cc:* [email protected]
>> *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:[email protected] <[email protected]>]
>> *Sent:* Monday, March 30, 2015 17:08
>> *To:* Moses, Danny
>> *Cc:* [email protected]
>> *Subject:* FW: [DMM] Answer on raised questions for the proposed API
>>
>>
>>
>> Hi Danny,
>>
>>
>>
>> Any comments?
>>
>>
>>
>> Regards,
>>
>> Seil Jeon
>>
>>
>>
>>
>>
>> *From:* dmm [mailto:[email protected] <[email protected]>] *On
>> Behalf Of *Seil Jeon
>> *Sent:* Thursday, March 26, 2015 8:08 PM
>> *To:* [email protected]
>> *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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dmm
>>
>>
>

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm