Subject: Re: [alto] ALTO discovery in roaming scenario

From: Songhaibin <[email-masked]>
Date: Tue, 10 Jul 2012 09:25:00 +0000

Sebastian and all,

I'm late for answering your questions.

I would answer "yes" to the first two questions you raised. 

For the third question, I think the discovery document is not going to standardize the way for ALTO server discovery, it is only standardize the service tag for one discovery option using U-NAPTR. There are variable discovery methods available. So there is no one standard way. Or could you specify one standard way that every application should obey to achieve interoperability?

> If you use triangular routing it might make sense to use the
> care-of-address instead of the home address. But this may depend on many
> things, e.g., are you mostly sending data or mostly receiving data?
> So it may also be wise not to do that ...
> 

This is a good question. It should use one ALTO server when it receives data and another ALTO server while it sends data. Should one end-host be tied with only one ALTO server?

It is easy to generalize the mobile and proxy based scenarios I raised, or even generalize the whole document into only one short paragraph such like "find the resource consumer's domain name, then use the U-NAPTR method with the new defined service tag...", if we do not go to the details. 

BR,
-Haibin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sebastian Kiesel
> Sent: Sunday, July 01, 2012 2:49 AM
> To: Songhaibin
> Cc: [email-masked]
> Subject: Re: [alto] ALTO discovery in roaming scenario
> 
> Haibin, all,
> 
> On Sat, Jun 30, 2012 at 02:35:06AM +0000, Songhaibin wrote:
> > I'm very glad that you understand my proposal. If the text missed some
> > technical details of ALTO discovery in mobile IPv4 and mobile IPv6, I
> > think we can clarify them in the draft. But I cannot agree that we do
> > not need text about the right IP address selection (in mobility and
> > proxy based scenarios) in the document.
> >
> > What do other people think on this issue?
> 
> I like Michael's proposal ...
> 
> > > "In general, the ALTO server discovery should be based on the IP
> > > address that is used to communicate with other peers".
> 
> ... because it is short and generic. I think it is better to give
> general guidelines (if possible) instead of going into the details
> of various mobility mechanisms.
> 
> 
> I think Michael's proposal is perfect for all mobility, VPN and proxy
> architectures I can think of, except for one: Mobile IP with triangular
> routing.
> 
> If you use triangular routing it might make sense to use the
> care-of-address instead of the home address. But this may depend on many
> things, e.g., are you mostly sending data or mostly receiving data?
> So it may also be wise not to do that ...
> 
> 
> 
> 
> May I ask you and the other folks here three questions:
> 
> 
> 1.) Is Mobile IP with triangular routing a relevant use case?
>     (Or is there another relevant mobility mechanism for which Michael's
>     proposal does not make sense?)
> 
> 2.) Are we really sure that it is a good idea to optimize based
>     on the CoA (or deviate from Michael's proposal in some other way)?
>     E.g., are there simulation results or field trials showing
>     that much better results could be achived?
> 
> 3.) Do we really need to standardize this, in order to guarantee
>     interoperability (we could leave the decision up to the
>     implementors, as long as we are sure that letting them choose does
>     not harm interoperability)?
> 
> 
> I think adding lots of text about mobility mechanisms in general and the
> triangular routing use case in particular makes only sense if a
> significant number of people answers three times "yes".
> 
> Personally, I would answer three times with "no" ...
> 
> 
> 
> Thanks
>    Sebastian
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 10 Jul 2012 13:33:32 +0200

Haibin, 

> I would answer "yes" to the first two questions you raised. 

Well, I disagree with both, but I am willing to learn from real-world data.

> It is easy to generalize the mobile and proxy based scenarios 
> I raised, or even generalize the whole document into only one 
> short paragraph such like "find the resource consumer's 
> domain name, then use the U-NAPTR method with the new defined 
> service tag...", if we do not go to the details. 

As I mentioned before, there is a quite a number of IETF protocols providing mobility (in a somehow loose sense):

- Proxy Mobile IP
- Mobile IPv4 (MIPv4)
- Mobile IPv6 (MIPv6)
- Hierarchical Mobile IPv6 (HMIPv6)
- NEMO
- SHIM6
- HIP
- LISP (partly)
- ...

Do you argue that we have to go into technical details for all of them? Do you plan to write that text?

Or do you argue that MIPv4 (which your suggested text apparently assumes) is the only relevant protocol that ALTO discovery has to consider in details?

Note that the current draft already has text on mobility and NAT, unlike for instance RFC 5986. I agree that in addition to NAT, proxies should be mentioned. And we should indeed highlight that
the IP address that is used for communication actually matters, in particular also in mobility scenarios.

But beyond that, I really wonder how you want to specify in detail how to deal with the wide variety of mobility and proxy solutions known in the IETF. This could end up in an endless story.

Michael

---

From: Songhaibin <[email-masked]>
Date: Wed, 11 Jul 2012 06:05:24 +0000

Michael,

> Note that the current draft already has text on mobility and NAT, unlike for
> instance RFC 5986. I agree that in addition to NAT, proxies should be mentioned.
> And we should indeed highlight that
> But beyond that, I really wonder how you want to specify in detail how to deal
> with the wide variety of mobility and proxy solutions known in the IETF. This
> could end up in an endless story.

OK. Then how about using your and Sebastian's suggested general statement about using the client's communication IP address, and highlight proxy based with one or two sentences?

I'm not convinced that we should ignore the scenarios when the above sentences cannot work. Maybe we can give guidance in the document, that there could be exceptions and using the text about triangle routing from my original email as an example. Then we do not go to every exceptions in mobility. I'm not familiar with all the mobility technologies, but some will not impact ALTO discovery such as HIP which is a 3.5 layer technology.  Does that make sense and look like a simple way to handle it in the draft?

I can help to modify the draft if we can achieve a consensus here.

BR,
-Haibin

> From: Scharf, Michael (Michael) [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2012 7:34 PM
> To: Songhaibin; Sebastian Kiesel
> Cc: [email-masked]
> Subject: RE: [alto] ALTO discovery in roaming scenario
> 
> Haibin,
> 
> Or do you argue that MIPv4 (which your suggested text apparently assumes) is
> the only relevant protocol that ALTO discovery has to consider in details?
> 
> Note that the current draft already has text on mobility and NAT, unlike for
> instance RFC 5986. I agree that in addition to NAT, proxies should be mentioned.
> And we should indeed highlight that
> But beyond that, I really wonder how you want to specify in detail how to deal
> with the wide variety of mobility and proxy solutions known in the IETF. This
> could end up in an endless story.
> 
> Michael

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 11 Jul 2012 22:01:01 +0200

Haibin,

> OK. Then how about using your and Sebastian's suggested 
> general statement about using the client's communication IP 
> address, and highlight proxy based with one or two sentences?

This looks like a reasonable idea. 

> I'm not convinced that we should ignore the scenarios when 
> the above sentences cannot work. Maybe we can give guidance 
> in the document, that there could be exceptions and using the 
> text about triangle routing from my original email as an 
> example. Then we do not go to every exceptions in mobility. 
> I'm not familiar with all the mobility technologies, but some 
> will not impact ALTO discovery such as HIP which is a 3.5 
> layer technology.  Does that make sense and look like a 
> simple way to handle it in the draft?

The draft has to be updated anyway, given the feedback in the last meeting. Certainly, triangular routing can be mentioned as an example for a specific challenge.

As a side note: AFAIK, HIP decouples the application and the IP stack, i. e., the application may not easily know what IP address is actually used by the protocol stack (there may be work-arounds, of course). I guess that this could actually be a quite significant obstacle for ALTO if an app needs the IP address to get ALTO guidance. Anyway, I think that this should be out-of-scope.

Michael