Re: [DMM] Answer on raised questions for the proposed API
Seil Jeon <seiljeon@av.it.pt> Tue, 07 April 2015 13:56 UTC
Return-Path: <seiljeon@av.it.pt>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C1E1B35D4 for <dmm@ietfa.amsl.com>; Tue, 7 Apr 2015 06:56:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.287
X-Spam-Level:
X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_w_VWClerYZ for <dmm@ietfa.amsl.com>; Tue, 7 Apr 2015 06:56:26 -0700 (PDT)
Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id D48351B35D1 for <dmm@ietf.org>; Tue, 7 Apr 2015 06:56:24 -0700 (PDT)
Received: from mail-wg0-f41.google.com (account seiljeon@av.it.pt [74.125.82.41] verified) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77447621 for dmm@ietf.org; Sun, 05 Apr 2015 19:41:17 +0100
Received: by wgyo15 with SMTP id o15so1381221wgy.2 for <dmm@ietf.org>; Sun, 05 Apr 2015 11:41:17 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.75.168 with SMTP id d8mr24828429wjw.87.1428259277144; Sun, 05 Apr 2015 11:41:17 -0700 (PDT)
Received: by 10.28.52.196 with HTTP; Sun, 5 Apr 2015 11:41:17 -0700 (PDT)
In-Reply-To: <CALhCTOFjE-nQu7nY8FMCP3Qp4=u_NeNzjZof8xKGQ=hWNUbFTg@mail.gmail.com>
References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <F0CF5715D3D1884BAC731EA1103AC28134908F15@HASMSX106.ger.corp.intel.com> <003901d06bad$75307a90$5f916fb0$@av.it.pt> <F0CF5715D3D1884BAC731EA1103AC2813490C65A@HASMSX106.ger.corp.intel.com> <001d01d06f24$f601c000$e2054000$@av.it.pt> <F0CF5715D3D1884BAC731EA1103AC2813490CB7D@HASMSX106.ger.corp.intel.com> <CALhCTOFjE-nQu7nY8FMCP3Qp4=u_NeNzjZof8xKGQ=hWNUbFTg@mail.gmail.com>
Date: Sun, 05 Apr 2015 19:41:17 +0100
Message-ID: <CALhCTOFGrGYButP7pjNP+OqJLK0_Xqv=v1JSTJ5BoHJUbU+dYg@mail.gmail.com>
From: Seil Jeon <seiljeon@av.it.pt>
To: "Moses, Danny" <danny.moses@intel.com>
Content-Type: multipart/alternative; boundary="047d7bb04bc8dc89520512fe86c5"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/tpb1pqTbJspkXKCUNHQyzQ4u-Bs>
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] Answer on raised questions for the proposed API
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Apr 2015 13:56:31 -0000
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 <seiljeon@av.it.pt> 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 <danny.moses@intel.com> > 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:seiljeon@av.it.pt] >> *Sent:* Sunday, April 05, 2015 01:16 >> *To:* Moses, Danny >> *Cc:* dmm@ietf.org >> *Subject:* RE: [DMM] Answer on raised questions for the proposed API >> >> >> >> Resent. >> >> >> >> Seil >> >> >> >> *From:* Seil Jeon [mailto:seiljeon@av.it.pt <seiljeon@av.it.pt>] >> *Sent:* Saturday, April 04, 2015 1:35 PM >> *To:* 'Moses, Danny' >> *Cc:* 'dmm@ietf.org' >> *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:danny.moses@intel.com >> <danny.moses@intel.com>] >> *Sent:* Thursday, April 02, 2015 2:16 PM >> *To:* Seil Jeon >> *Cc:* dmm@ietf.org >> *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:seiljeon@av.it.pt <seiljeon@av.it.pt>] >> *Sent:* Tuesday, March 31, 2015 15:23 >> *To:* Moses, Danny >> *Cc:* dmm@ietf.org >> *Subject:* RE: [DMM] Answer on raised questions for the proposed API >> >> >> >> Hi Danny, >> >> >> >> See the inline please. >> >> >> >> >> >> Seil Jeon >> >> >> >> >> >> *From:* Moses, Danny [mailto:danny.moses@intel.com >> <danny.moses@intel.com>] >> *Sent:* Monday, March 30, 2015 4:44 PM >> *To:* Seil Jeon >> *Cc:* dmm@ietf.org >> *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:seiljeon@av.it.pt <seiljeon@av.it.pt>] >> *Sent:* Monday, March 30, 2015 17:08 >> *To:* Moses, Danny >> *Cc:* dmm@ietf.org >> *Subject:* FW: [DMM] Answer on raised questions for the proposed API >> >> >> >> Hi Danny, >> >> >> >> Any comments? >> >> >> >> Regards, >> >> Seil Jeon >> >> >> >> >> >> *From:* dmm [mailto:dmm-bounces@ietf.org <dmm-bounces@ietf.org>] *On >> Behalf Of *Seil Jeon >> *Sent:* Thursday, March 26, 2015 8:08 PM >> *To:* dmm@ietf.org >> *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 >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> >> >
- [DMM] Answer on raised questions for the proposed… Seil Jeon
- [DMM] FW: Answer on raised questions for the prop… Seil Jeon
- Re: [DMM] Answer on raised questions for the prop… Moses, Danny
- Re: [DMM] Answer on raised questions for the prop… Seil Jeon
- Re: [DMM] Answer on raised questions for the prop… Moses, Danny
- Re: [DMM] Answer on raised questions for the prop… Moses, Danny
- Re: [DMM] Answer on raised questions for the prop… Seil Jeon
- Re: [DMM] Answer on raised questions for the prop… Seil Jeon
- Re: [DMM] Answer on raised questions for the prop… Seil Jeon
- Re: [DMM] Answer on raised questions for the prop… Seil Jeon
- Re: [DMM] Answer on raised questions for the prop… Seil Jeon
- Re: [DMM] Answer on raised questions for the prop… Seil Jeon
- Re: [DMM] Answer on raised questions for the prop… Moses, Danny
- Re: [DMM] Answer on raised questions for the prop… Seil Jeon
- [DMM] 回复： Answer on raised questions for the prop… Dapeng Liu
- Re: [DMM] 回复： Answer on raised questions for the … Moses, Danny
- [DMM] 回复： Answer on raised questions for the prop… Dapeng Liu
- Re: [DMM] 回复： Answer on raised questions for the … Moses, Danny
- [DMM] 回复： Answer on raised questions for the prop… Dapeng Liu
- Re: [DMM] 回复： Answer on raised questions for the … Seil Jeon
- [DMM] 回复： Answer on raised questions for the prop… Dapeng Liu