Re: comments/questions of draft-yegin-dmm-cnet-homing-00

Hi Alper,

 

>>As long as the mobility agent stays on the most direct data-path between the MN and CN, then it does not matter where exactly it is.

>>Placing the mobility agent as close to the CN as possible increases that chance.

>>But that does not mean the CN site is the only place for the mobility agent.

>>The ISP serving the CN site is another natural place.

>>And it'd work just fine.

As I mentioned, in our I-D we just define that "Distributed Home-Proxy (DHP)  is a router near CN". In this way, DHP doesn't have to be located in CN' domain. However, we recommend to find a DHP in CN's domain because choosing DHP in other domains will not guarantee router optimization and increase the management and deployment cost of DHP.

 


>>"Compatible" term needs expanding.
>>What I mean is "we use Mobile IP as-is". We don't need to change, add, extend anything on that. In other words, we do not require any "protocol work".

I really don't understand your definition of "protocol work". You change the architecture, the operation process and the implementation of Mobile IP, but you still think you do not require any "protocol work". As I see it, what you have done is exactly expanding to Mobile IP.


>>Your I-D says:
   This standard is compliant with standard MIPv6, which means MN still
   has HoA in home domain. When MN is initiating a new connection with
   DMIPv6, it will first apply for DHoA. According to MIPv6, MN's HoA is
   permanent during in its travelling, so CN always knows its HoA.

DMIPv6 doesn't depend on HoA. We don't need to use HoA in DMIPv6. But in order to keep compliant with standard MIPv6, we assume MN will use MIPv6 to establish the connection with CN if the DHP query and DHoA allocation fail. It is only a complete consideration for exception. It is MIPv6 that assumes that MN has a HoA.
 
>>There's implementation work to be applied to MN, yes.

>>The question is: Do we need to modify Mobile IP, or do we need to design  a new protocol?

>>Our I-D says no.

>>Yours says yes.

>>That's also a difference, or a consequence of a number of differences between the two I-Ds.

In my opinion, you definitely need to modify Mobile IP. Just as I mentioned above, you change the architecture, the operation process and implementation of Mobile IP. All of these are extensions to Mobile IP. We can even call it a new protocol such as E-MIP.

 

Min




----------
Sender: "Alper Yegin" <[email protected]>
Receiver: "Liu Min" <[email protected]>
Copy: "'Jouni Korhonen'" <[email protected]>, [email protected], [email protected]
Subject: Re: [DMM] comments/questions of draft-yegin-dmm-cnet-homing-00

Hi Liu,


On Jul 25, 2013, at 8:54 PM, Liu Min wrote:


Hi Alper,
 
>>Yes it seems like we are approaching the DMM problem in the same way.
 
So we have this consensus that the main idea and approach in your I-D proposed in July 3, 2013 is the same as our I-D proposed in March 10, 2013.
 


As you know, the legacy Mobile IP approach is based on locating a HA in something called "home network".
A number of DMM contributions are proposing to add a variant to that: Locating HA in access network.
What your and our I-D are proposing is to add yet another variant: A third type of place for HA -- somewhere towards the CN.
That's all I'm saying. (not the elaborate statement you made above :-)
On the other hand exact location of HA, all the related protocol work to make that happen are all seemingly different in your and our I-D, and this is what we are discussing below.




 
>>At the technical detail level here are the essential differences between two I-Ds:
>>- The mobility agent in our case can even be outside the domain of CN.
 
In our I-D, we define that "Distributed Home-Proxy (DHP)  is a router near CN".  In this way, DHP doesn't have to be located in CN' domain. However, we do recommend to find a DHP in CN's domain because choosing DHP in other domains will not guarantee router optimization and thus violating our original intention to introduce DHP.
Choosing a mobility agent outside the domain of CN makes little sense since our purpose is to implement router optimization by moving the mobility agent close to CN.
 




As long as the mobility agent stays on the most direct data-path between the MN and CN, then it does not matter where exactly it is.
Placing the mobility agent as close to the CN as possible increases that chance.
But that does not mean the CN site is the only place for the mobility agent.
The ISP serving the CN site is another natural place.
And it'd work just fine.




>>- Your I-D has a very elaborate DHP discovery, with additional protocol work, some even touching CN. Not sure why it is needed. We are simply using DNS request for that. It becomes just a matter of putting the right entry in the DNS.
 
In our I-D, we have provided several options for DHP discovery and DNS request is also used. For example, "MN query the DNS to get the DHP anycast address", "MN can use DNS to query the DHP management server address."  Actually, we assume there may exist more than one DHP in one domain. MIPv6 also assumes there may exist more than one HA in one domain.


Maybe you'd consider down-selecting them. Not only too many, but still I don't understand why a simple DNS-based lookup like we propose is not sufficient. 


 
>>- Our I-D is not modifying Mobile IP protocol at all. You seem to define new messaging for HoA discovery, and also extending BU. Again, not sure why those extensions are needed.
 
Our I-D is totally compatible with Mobile IP protocol. For DHP discovery, as we mentioned in our I-D "This procedure is similar to "dynamic home agent address discovery mechanism" in MIPv6". Besides, we provide other options for performance optimization.
 


"Compatible" term needs expanding.
What I mean is "we use Mobile IP as-is". We don't need to change, add, extend anything on that. In other words, we do not require any "protocol work".




>>- " MN decides whether the service flow needs mobility support according to the service type of the new connection request." This is not clear. In our case the determination is transparent to the upper layers. If the DNS returns an IP address for CHA, then CHA is used.
 
Router optimization is just one purpose of our I-D, besides that we also support flow management and flow handoff for high level users. Of course, users can choose not to use such functions, just as you mentioned.


I thought your I-D did one thing, and it's explained in terms of managing flows (with the CNs). Now that you are referring to two separate things: "router optimization" and "flow management and flow handoff" suggests that I'm missing one of the two things… 


Besides, coming back to my question: How does MN decide whether a service flow needs mobility support? What are the service types? How are they conveyed from the applications(?) to the IP stack. These are the questions that arise when reading that statement in your I-D.






>>- There's an assumption that MN has a HoA and CN knows that. Not sure why this is needed.
 
We don't have such an assumption. Maybe you mean this sentence in our I-D  "A notice is that, MN will use HoA to establish the connection with CN if the DHP query is failed, which means no DHP is found to  serve the current MN. Later workflow is the same as that defined in MIPv6." As you can see, it is only a complete consideration for exception.
 


Your I-D says:


   This standard is compliant with standard MIPv6, which means MN still
   has HoA in home domain. When MN is initiating a new connection with
   DMIPv6, it will first apply for DHoA. According to MIPv6, MN's HoA is
   permanent during in its travelling, so CN always knows its HoA.








>>Overall, as you can see from our I-D, we believe dynamically anchoring the IP address somewhere close to the CN can be achieved without any protocol work.
 
Actually, I really don't believe we can implement protocol optimization without doing any change to it. Actually, you definitely need to change the implementation for MN in your I-D.
 


There's implementation work to be applied to MN, yes. 
The question is: Do we need to modify Mobile IP, or do we need to design  a new protocol? 
Our I-D says no.
Yours says yes. 
That's also a difference, or a consequence of a number of differences between the two I-Ds.


Alper






 
Min
 
From: Alper Yegin [mailto:[email protected]] 
Sent: Thursday, July 25, 2013 4:03 PM
To: Min Liu
Cc: Jouni Korhonen; [email protected]; [email protected]
Subject: Re: [DMM] comments/questions of draft-yegin-dmm-cnet-homing-00
 
Hi Liu,
 
Yes it seems like we are approaching the DMM problem in the same way.
 
At the technical detail level here are the essential differences between two I-Ds:
 
- The mobility agent in our case can even be outside the domain of CN. 
 
- Your I-D has a very elaborate DHP discovery, with additional protocol work, some even touching CN. Not sure why it is needed. We are simply using DNS request for that. It becomes just a matter of putting the right entry in the DNS.
 
- Our I-D is not modifying Mobile IP protocol at all. You seem to define new messaging for HoA discovery, and also extending BU. Again, not sure why those extensions are needed.
 
- " MN decides whether the service flow needs mobility support according to the service type of the new connection request." This is not clear. In our case the determination is transparent to the upper layers. If the DNS returns an IP address for CHA, then CHA is used.



- There's an assumption that MN has a HoA and CN knows that. Not sure why this is needed.



Overall, as you can see from our I-D, we believe dynamically anchoring the IP address somewhere close to the CN can be achieved without any protocol work.



Alper


















 
 
 
 
 
 
 
On Jul 24, 2013, at 4:58 PM, 刘敏 wrote:




Hi, Alper,
We submited a draft to DMM in March (http://datatracker.ietf.org/doc/draft-liu-dmm-flows-distribution-and-handoff/?include_text=1) and made a presentation in last IETF meeting in Orlando. I think the main idea in your draft is almost the same with our I-D. In our draft, we propose a new entity named Distributed Home-Proxy (DHP) that is a router near CN, with the function for an extension of the HA, to assign Distributed Home Address (DHoA) for the MN to implement router optimization. In your draft, you propose a Corresponding Home Agent (CHA) located near CNs to allocate a HoA to the MN (Corresponding Home Address, CHoA). As I see it, the CHA is just the DHP and CHoA is the same as DHoA. Could you please explain the new contribution in your draft?
 
 
Min Liu

Institute of Computing Technology
Chinese Academy of Science


> ----------
> Sender: "Alper Yegin" <[email protected]>
> Receiver: "Jouni Korhonen" <[email protected]>
> Copy: "[email protected]" <[email protected]>
> Subject: Re: [DMM] comments/questions of draft-yegin-dmm-cnet-homing-00
> 
> 
> On Jul 24, 2013, at 11:56 AM, Jouni Korhonen wrote:
> 
> > Alper, authors,
> > 
> > In Section 3. is states:
> > 
> >  "CHA may be co-located with the CN, or located in the same site as the
> >   CN, or located in an ISP serving that site.  Not all CNs may be
> >   served by a CHA.  In case there is no CHA serving the CN, the MN and
> >   the CN may communicate using the HoA via the HA.  It is expected that
> >   CHAs would be deployed for dominant content sites on the Internet
> >   (e.g., YouTube, Facebook, Netflix, etc.)"
> > 
> > What would be the motivation or business reason for a service/content
> > provider to start offering a mobility anchoring service? High bandwidth
> > sites as listed above would need invest quite much for such a platform.
> > 
> 
> Here's our thinking:
> 
> - The direct benefit of this approach to the content provider is the reduction of transmission latency due to elimination of the triangular routes. This would enhance the their user experience.
> 
> - Considering the overall system (w/o distinguishing between the MNO and the content provider), providing anchoring/mobility near the CNet as opposed to doing it at a corner of the Internet reduces the overall cost. Given the savings, the involved parties can find a fair way to deal with it (i.e., some business deal).
> 
> On top of that, this can be provided by ISPs serving the content sites. Such ISPs can also have a business deal with the MNO for taking over the mobility management load.
> 
> 
> > I also started thinking that in general this solution (and quite many
> > other) seem to assume the CN is more or less stationary. How would the
> > CHA concept be affected if the CN is also mobile? Would it allow any
> > benefits over the legacy MIP variants? How would the CHA discovery 
> > work in this case?
> > 
> 
> We didn't consider mobile CNs. We are going after the major sources of mobile traffic, which is stemming from fixed sites.
> 
> 
> > The examples in Sections 3. and 4. show DNS as the discovery mechanism
> > for the CHA. However, there is no real description how the discovery
> > is actually carried out (except conceptual CHA domain name referred
> > in Section 3.
> 
> It's just a matter of storing cha.<yourdomain> in DNS and looking it up.
> We can add some more verbiage, if this is not clear.
> 
> > Figure 1 step 2). Have you considered other discovery
> > mechanisms than DNS?
> > 
> 
> We did some but this one seemed to be the most straightforward. 
> Any specific recommendations?
> 
> Alper
> 
> 
> 
> 
> > - Jouni
> > 
> > 
> > 
> > 
> > 
> 
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm

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