Subject: [DMM] comments/questions of draft-yegin-dmm-cnet-homing-00

From: Jouni Korhonen <[email-masked]>
Date: Wed, 24 Jul 2013 11:56:42 +0300

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.

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?

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. Figure 1 step 2). Have you considered other discovery
mechanisms than DNS?

- Jouni

---

From: Alper Yegin <[email-masked]>
Date: Wed, 24 Jul 2013 16:28:45 +0300

> 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.

> benefits over the legacy MIP variants? How would the CHA discovery 

We didn't consider mobile CNs. We are going after the major sources of mobile traffic, which is stemming from fixed sites.

> 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

---

From: Alper Yegin <[email-masked]>
Date: Thu, 25 Jul 2013 11:03:21 +0300

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-masked]>
> > Receiver: "Jouni Korhonen" <[email-masked]>
> > Copy: "[email-masked]" <[email-masked]>
> > Subject: Re: [DMM] comments/questions of draft-yegin-dmm-cnet-homing-00
> > 
> > 
> > _______________________________________________
> > dmm mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dmm
> 
> 
>

---

From: "Liu Min" <[email-masked]>
Date: Fri, 26 Jul 2013 01:54:13 +0800

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.

>>- 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.

>>- 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…

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.

>>- 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.

>>- " 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 u…

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.

>>- 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. 

>>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.

Min

From: Alper Yegin [mailto:[email-masked]] 
Sent: Thursday, July 25, 2013 4:03 PM
To: Min Liu
Cc: Jouni Korhonen; [email-masked]; [email-masked]
Subject: Re: [DMM] comments/questions of draft-yegin-dmm-cnet-homing-00

Hi Liu,

Alper

 

 

Hi, Alper,

 

Min Liu

---

From: Alper Yegin <[email-masked]>
Date: Fri, 26 Jul 2013 13:56:46 +0300

Hi Liu,

> 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.

> 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.

> 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 managem…

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 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". Beside…

"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".

> 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 a…

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.

> 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 f…

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.

> 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

---

From: 刘敏 <[email-masked]>
Date: Sat, 27 Jul 2013 04:09:48 +0800 (GMT+08:00)

Hi Alper,

>>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.

>>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.

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.

>>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-masked]>
Receiver: "Liu Min" <[email-masked]>
Copy: "'Jouni Korhonen'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [DMM] comments/questions of draft-yegin-dmm-cnet-homing-00

Hi Liu,

Hi Alper,

 

 

 

 

 

Your I-D says:

 

Alper

Min

Hi Liu,

 

 

Alper

 

Hi, Alper,

Min Liu