Re: 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