Re: comments/questions of draft-yegin-dmm-cnet-homing-00
"Liu Min" <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Message-ID | <[email protected]> |
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. >>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. >>- 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. >>- 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 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. >>- 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 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