Subject: Re: [mif] mobility issues and general issues on mif

From: "Kai Ju" <[email-masked]>
Date: Sun, 18 Jan 2009 01:55:51 +0800

Hi, Hui

As you said, there are multiple way to assign the routing policy by in the
mobile access network. As viewed from the aspect of terminal, I think its a
good idea that terminal can get its routing policy from the ANDSF.

We think a default policy can be used,  when terminal can't find
corresponding policy in the routing policy from the ANDSF. The default
policy can be sent by the network.

On another hand, I am a little confused between MIF and Multihoming, would
you please help me to clarify the difference between them?

Thanks and best regards

Kai
_______________________________________________
mif mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mif

---

From: Peny Yang <[email-masked]>
Date: Mon, 19 Jan 2009 10:47:36 +0800

Hi, Kai:

> good idea that terminal can get its routing policy from the ANDSF.
[Peny] ANDSF may be one of the choices. But ANDSF just follows the
assumption of generic "one default link" IP model. So, in 3GPP, even
though ANDSF can help UE to select accesses and find the route, UE can
only choose one of the interfaces as a result.
Personally, I'm not sure if it's a good way to rely on ANDSF of 3GPP,
since it's a specific definition in one SDO.

> policy can be sent by the network.
[Peny] Could we give a chance to MN to change the policy (like user
preference) ?

> you please help me to clarify the difference between them?
[Peny] I am also not clear yet. Just give some lines as a seed for
discussion. In my personal feeling, MIF is to change the "one default
link" feature of current generic IP model. Multi-homing is to ensure
the reachability and reliability of IP network. Well, in multi-homing
MN scenarios, multi-link-multi-address is also one case. But, in this
case, MN only can choose one link as default.
Some other comments?

BRG
Peny

---

From: "Hui Deng" <[email-masked]>
Date: Mon, 19 Jan 2009 15:05:52 +0800

Hi, Peng and Kai,

See reply inline below. thanks for the discussion.
2009/1/19 Peny Yang <[email-masked]>

> since it's a specific definition in one SDO.

ANDSF in 3GPP 23.401 do cover only 3GPP network, how could ANDSF work for
23.402 for non-3GPP access still a issue, it may need some mechanism to
coordinate
between two type of access entwork.what do you think?

> case, MN only can choose one link as default.
To challenge one default link, it really takes time for mif to consider on
it, current first step in mif is to consider some straight forward way which
is simple to resolve some issues.
Regarding to multi-homing, I guess that it is more site multi-homing.
For last multi-link-multi-address mn's scenario, it will be one of MIF
scenario.

thanks

-Hui

---

From: "Kai Ju" <[email-masked]>
Date: Mon, 19 Jan 2009 19:46:55 +0800

Hi, Hui and Peny

Thanks for your comment. Please see the reply.

 [Hui]ANDSF in 3GPP 23.401 do cover only 3GPP network, how could ANDSF work
for
23.402 for non-3GPP access still a issue, it may need some mechanism to
coordinate
between two type of access entwork.what do you think?
The ANSDF solution is just a sample, because there is no one type of server
which is
defined to provide the policy in IETF until now. So let us consider it be
general, which
means it's one policy server that provides the routing policy to UE when UE
is connecting
it.

[Hui]To challenge one default link, it really takes time for mif to consider
on it, current first step in mif is to consider some straight forward way
which is simple to resolve some issues.
Agree with you, and we'll keep working on it.

2009/1/19 Hui Deng <[email-masked]>

---

From: Peny Yang <[email-masked]>
Date: Mon, 19 Jan 2009 22:10:07 +0800

> means it's one policy server that provides the routing policy to UE when UE
[Peny] Agree. 3GPP ANSDF could be a good reference when we make the
MIF solutions.

BRG
Peny

---

From: <[email-masked]>
Date: Tue, 20 Jan 2009 09:47:27 +0100

Hi all,

I've joined recently this ML and I believe discussed topics very interesting (BTW thanks to MIF promoters for bringing these issues to IETF). So, please let me jump into your discussion. 

Regarding difference between MIF and multihoming: it seems there is confusion with mobility. AFAIU, MIF is only supposed to deal with routing issue at the multi-interface MN side. The issue is to select the "best" interface for each outgoing IP flow and, in MIF context, access selection does not necessarily imply flow mobility with IP session continuity between interfaces. Nevertheless, solution should work for terminal with several active interfaces at the same time (multi-homed), or for terminal with a single interface at a time. Am I correct?
  
Regarding ANDSF issue, I agree with preceding emails: I think access selection should rely on policy. There are a couple of selection models but the simplest is the selection managed by the terminal and based on local policies and measurement on the access link. The policies may be provided/updated by a server via out-of-band mechanism or on-demand (typically before selection) if policies include "dynamic" recommendation (e.g. access xx is overload and forbidden to application type yy). Now you can call the policy server ANDSF, or whatever you want, it is just a generic functional entity in the architecture and this entity is above all access networks. Note the access selection via policy server meet MIF requirement as well as selection in inter-access mobility situation.

Please do not hesitate to correct me if I misunderstood MIF issues.

Regards,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de Peny
> Yang
> Envoyé : lundi 19 janvier 2009 15:10
> À : Kai Ju
> Cc : [email-masked]
> Objet : Re: [mif] mobility issues and general issues on mif
> 
> Hi, Kai:
> >>> > As you said, there are multiple way to assign the routing policy by
> in
> >>> > the
> >>> > mobile access network. As viewed from the aspect of terminal, I
> think
> >>> > its a

---

From: Hui Deng <[email-masked]>
Date: Wed, 21 Jan 2009 23:23:46 +0800

---

From: <[email-masked]>
Date: Wed, 21 Jan 2009 16:38:26 +0100

Envoyé : mercredi 21 janvier 2009 16:24
À : SEITE Pierrick RD-RESA-REN
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [mif] mobility issues and general issues on mif

Hi, pierrick, 
 
[snip]
Howver I would like to raise one case, sometime, if the network congested, terminal couldn't visit policy server such as ANDSF, only network side know what happen, they may re-arrange some traffic for mobile terminal, I guess that this is been discussed in 3GPP SA2 side at the moment. 
 
[PS] you're right, I agree.

[/snip]

Regards,
Pierrick

---

From: Yungui Wang <[email-masked]>
Date: Thu, 22 Jan 2009 09:46:37 +0800

Hello Hui

One comments, whether is the IP address model to be investigated within MIF? For example, there are different types of IP address model for MIF-terminal, per IP address per IF, one IP address for multiple IF(s), etc. If considered that, mobility of application/flow over IP layer seems impliedly to be studied (e.g. in topic of IP route changing). 

B.R.
Yungui

  ----- Original Message ----- 
  From: Hui Deng 
  To: [email-masked] 
  Cc: [email-masked] 
  Sent: Wednesday, January 21, 2009 11:23 PM
  Subject: Re: [mif] mobility issues and general issues on mif

  Hi, pierrick, 

  Thanks for joining the disucssion, speaking for mobile operator is quite helpful for mif's work,
  Your experience is appreicate, see reply inline below,

  2009/1/20 <[email-masked]>

    Hi all,

  Thanks again.

    Regarding difference between MIF and multihoming: it seems there is confusion with mobility. AFAIU, MIF is only supposed to deal with routing issue at the multi-interface MN side. The issue is to select the "best" interface for each outgoing IP flow and, in MIF context, access selection does not necessarily imply flow mobility with IP session continuity between interfaces. Nevertheless, solution should work for terminal with several active interfaces at the same time (multi-homed), or for terminal with a single interface at a time. Am I correct?
  As you said here, flow mobility and IP session continuity is out of scope at the moment.
  I cann't agree with any more about your left words.

    Regarding ANDSF issue, I agree with preceding emails: I think access selection should rely on policy. There are a couple of selection models but the simplest is the selection managed by the terminal and based on local policies and measurement on the access link. The policies may be provided/updated by a server via out-of-band mechanism or on-demand (typically before selection) if policies include "dynamic" recommendation (e.g. access xx is overload and forbidden to application type yy). Now you can call the policy server ANDSF, or whatever you want, it is just a generic functional entity in the architecture and this entity is above all access networks. Note the access selection via policy server meet MIF requirement as well as selection in inter-access mobility situation.
  Most mobile terminal has implemented the policy based selection models.
  Howver I would like to raise one case, sometime, if the network congested, terminal couldn't visit policy server such as ANDSF, only network side know what happen, they may re-arrange some traffic for mobile terminal, I guess that this is been discussed in 3GPP SA2 side at the moment. 

    Please do not hesitate to correct me if I misunderstood MIF issues.
  thanks for the discussion.

  -Hui

    Regards,
    Pierrick

------------------------------------------------------------------------------

---

From: Hui Deng <[email-masked]>
Date: Thu, 22 Jan 2009 14:26:04 +0800

---

From: Yungui Wang <[email-masked]>
Date: Fri, 23 Jan 2009 15:55:17 +0800

Hello Hui

Sorry for late response. In my understanding, one issue of MIF is interface selection (or named access selection). However, interface selection of a MIF-node is serving for its up-layer app/flow. When one link associated with one interface of MIF-node is down or congested, interface re-selection is needed. That's one type of mobility of app/flow between different interfaces I wanted to address. 
Maybe IP address model is related to how to do. Please forget it. 

B.R.
Yungui

  ----- Original Message ----- 
  From: Hui Deng 
  To: Yungui Wang 
  Cc: [email-masked] ; [email-masked] 
  Sent: Thursday, January 22, 2009 2:26 PM
  Subject: Re: [mif] mobility issues and general issues on mif

  Hi, Yungui,

  mif is targetting at multiple interface whatever it has how many ip address on each of them.
  I guess that you are asking more IPv6 related question.

  What I feel what ever per interface or per IP address, how it is related to mobility of application?
  we are not handling handover related issues.

  Thanks for the discussion.
  Regards,

  -Hui

  2009/1/22 Yungui Wang <[email-masked]>

    Hello Hui

    B.R.
    Yungui

      ----- Original Message ----- 
      From: Hui Deng 
      To: [email-masked] 
      Cc: [email-masked] 
      Sent: Wednesday, January 21, 2009 11:23 PM
      Subject: Re: [mif] mobility issues and general issues on mif

      Hi, pierrick, 

        Hi all,

      -Hui

        Regards,
        Pierrick

--------------------------------------------------------------------------

---

From: Hui Deng <[email-masked]>
Date: Fri, 23 Jan 2009 16:32:23 +0800

---

From: Yungui Wang <[email-masked]>
Date: Fri, 23 Jan 2009 17:29:43 +0800

Hello, Hui

Agree with your statement.  However, it (the app/flow has to be restarted when interface-handoff happens) is actually an app/flow mobility issue related to multiple interfaces.  Thus, it seems the working item MIF is the just place to resolve it.  Hope it make sense. :_)

B.R.
Yungui

  ----- Original Message ----- 
  From: Hui Deng 
  To: Yungui Wang 
  Cc: [email-masked] ; [email-masked] 
  Sent: Friday, January 23, 2009 4:32 PM
  Subject: Re: [mif] mobility issues and general issues on mif

  Hello, Yungui,

  Excuse me for misunderstanding your point, 
  reply inline below.

  2009/1/23 Yungui Wang <[email-masked]>

    Hello Hui

    Sorry for late response. In my understanding, one issue of MIF is interface selection (or named access selection). However, interface selection of a MIF-node is serving for its up-layer app/flow. 
  some mobile phone can do it, but normally, like PC application don't do it, it is up to network
  socket to choose source address, then interface is automatically selected.

    When one link associated with one interface of MIF-node is down or congested, interface re-selection is needed. That's one type of mobility of app/flow between different interfaces I wanted to address. 
  If one interface is down or congested, then application will be down as well, this socket will close as well, and you would like to move some application, then you have to restart to do it.

  -Hui

    B.R.
    Yungui

      ----- Original Message ----- 
      From: Hui Deng 
      To: Yungui Wang 
      Cc: [email-masked] ; [email-masked] 
      Sent: Thursday, January 22, 2009 2:26 PM
      Subject: Re: [mif] mobility issues and general issues on mif

      Hi, Yungui,

      -Hui

        Hello Hui

        B.R.
        Yungui

          ----- Original Message ----- 
          From: Hui Deng 

          Hi, pierrick, 

            Hi all,

          -Hui

            Regards,
            Pierrick

----------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 23 Jan 2009 13:01:54 -0500

want to call attention to the fact that you are getting into a 
significant amount of mission creep (extending the target scope well 
beyond the problem statement.

In particular, this discussion leads to issues that would require 
changes to transport behavior, host stack structure, and routing 
structure.  All of the issues that lead to that are valid issues. 
However, they are also under investigation in other parts of the 
community (Transport area, Internet Area, and Routing Research Group.) 
Resolving those problems is going to take significant time.  Please, 
help with all of those issues.  But if you want to make progress on the 
issues called out in the problem statement draft, it would be a good 
idea to narrow the scope, not expand it.

As a final caveat, while it is tempting it is an extremely bad idea to 
try to add all of the system routing intelligence to the local node. 
Even the system does not have good visibility to many of the properties 
(actual path availability is only approximated, for example).  Using 
information the host / node already has is a very good idea.  Trying to 
get all the routing information (so as, for example, to have a better 
guess as to which interface can actually reach a given destination) 
would be a very bad idea.

To restate, there are real problems, identified in the base draft, which 
are tricky to solve.  If we want to solve them in a timely fashion, we 
need to keep to a small set of problems.

Yours,
Joel M. Halpern

Yungui Wang wrote:
> 
> Hello, Hui
>  
> Agree with your statement.  However, it (the app/flow has to be 
> restarted when interface-handoff happens) is actually an app/flow 
> mobility issue related to multiple interfaces.  Thus, it seems the 
> working item MIF is the just place to resolve it.  Hope it make sense. :_)
>  
> B.R.
> Yungui
>  
> 
>     *From:* Hui Deng <mailto:[email-masked]>
>     *To:* Yungui Wang <mailto:[email-masked]>
>     *Cc:* [email-masked]
>     <mailto:[email-masked]> ; [email-masked]
>     <mailto:[email-masked]>
>     *Sent:* Friday, January 23, 2009 4:32 PM
>     *Subject:* Re: [mif] mobility issues and general issues on mif
> 
>     Hello, Yungui,
>      
>     2009/1/23 Yungui Wang <[email-masked] <mailto:[email-masked]>>
> 
>         Hello Hui
>          
>         Sorry for late response. In my understanding, one issue of MIF
>         is interface selection (or named access selection). However,
>         interface selection of a MIF-node is serving for its up-layer
>         app/flow. 
> 
>         When one link associated with one interface of MIF-node is down
>         or congested, interface re-selection is needed. That's one type
>         of mobility of app/flow between different interfaces I wanted to
>         address.  
> 
>     If one interface is down or congested, then application will be down
>     as well, this socket will close as well, and you would like to move
>     some application, then you have to restart to do it.
>      
>             *From:* Hui Deng <mailto:[email-masked]>
>             *To:* Yungui Wang <mailto:[email-masked]>
>             *Cc:* [email-masked]
>             <mailto:[email-masked]> ; [email-masked]
>             <mailto:[email-masked]>
>             *Sent:* Thursday, January 22, 2009 2:26 PM
>             *Subject:* Re: [mif] mobility issues and general issues on mif
> 
>             Hi, Yungui,
>              
>             What I feel what ever per interface or per IP address, how
>             it is related to mobility of application?
>             2009/1/22 Yungui Wang <[email-masked]
>             <mailto:[email-masked]>>
> 
>                 Hello Hui
>                  
>                 One comments, whether is the IP address
>                 model to be investigated within MIF? For example, there
>                 are different types of IP address model for
>                 MIF-terminal, per IP address per IF, one IP address
>                 for multiple IF(s), etc. If considered that, mobility of
>                 application/flow over IP layer seems impliedly to be
>                 studied (e.g. in topic of IP route changing).
>                  
>                 B.R.
>                 Yungui
>                  
> 
>                     *From:* Hui Deng <mailto:[email-masked]>
>                     *To:* [email-masked]
>                     <mailto:[email-masked]>
>                     *Cc:* [email-masked] <mailto:[email-masked]>
>                     *Sent:* Wednesday, January 21, 2009 11:23 PM
>                     *Subject:* Re: [mif] mobility issues and general
>                     issues on mif
> 
>                     Hi, pierrick,
>                      
>                     Thanks for joining the disucssion, speaking for
>                     mobile operator is quite helpful for mif's work,
>                     2009/1/20 <[email-masked]
>                     <mailto:[email-masked]>>
> 
>                         Hi all,
> 
>                         I've joined recently this ML and I believe
>                         discussed topics very interesting (BTW thanks to
>                         MIF promoters for bringing these issues to
>                         IETF). So, please let me jump into your discussion.
> 
>                     Thanks again.
>                      
> 
> 
>                         Regarding difference between MIF and
>                         multihoming: it seems there is confusion with
>                         mobility. AFAIU, MIF is only supposed to deal
>                         with routing issue at the multi-interface MN
>                         side. The issue is to select the "best"
>                         interface for each outgoing IP flow and, in MIF
>                         context, access selection does not necessarily
>                         imply flow mobility with IP session continuity
>                         between interfaces. Nevertheless, solution
>                         should work for terminal with several active
>                         interfaces at the same time (multi-homed), or
>                         for terminal with a single interface at a time.
>                         Am I correct?
> 
>                     As you said here, flow mobility and IP session
>                     continuity is out of scope at the moment.
>                         Regarding ANDSF issue, I agree with preceding
>                         emails: I think access selection should rely on
>                         policy. There are a couple of selection models
>                         but the simplest is the selection managed by the
>                         terminal and based on local policies and
>                         measurement on the access link. The policies may
>                         be provided/updated by a server via out-of-band
>                         mechanism or on-demand (typically before
>                         selection) if policies include "dynamic"
>                         recommendation (e.g. access xx is overload and
>                         forbidden to application type yy). Now you can
>                         call the policy server ANDSF, or whatever you
>                         want, it is just a generic functional entity in
>                         the architecture and this entity is above all
>                         access networks. Note the access selection via
>                         policy server meet MIF requirement as well as
>                         selection in inter-access mobility situation.
> 
>                     Howver I would like to raise one case, sometime, if
>                     the network congested, terminal couldn't visit
>                     policy server such as ANDSF, only network side know
>                     what happen, they may re-arrange some traffic for
>                     mobile terminal, I guess that this is been discussed
>                     in 3GPP SA2 side at the moment.
>                      
> 
> 
> 
>                          > De : [email-masked]
>                         <mailto:[email-masked]>
>                         [mailto:[email-masked]
>                         <mailto:[email-masked]>] De la part de Peny
>                          > Yang
>                          > Cc : [email-masked] <mailto:[email-masked]>
>                          > > The ANSDF solution is just a sample,
>                         because there is no one type of
>                          > server
>                          > > which is
>                          > > defined to provide the policy in IETF until
>                         now. So let us consider it
>                          > be
>                          > > general, which
>                          > > means it's one policy server that provides
>                         the routing policy to UE when
>                          > UE
>                          > > is connecting
>                          > > it.
>                          > >> 2009/1/19 Peny Yang
>                         <[email-masked]
>                         <mailto:[email-masked]>>
>                          > >>>
>                          > >>> Hi, Kai:
>                          > >> ANDSF in 3GPP 23.401 do cover only 3GPP
>                         network, how could ANDSF work
>                          > for
>                          > >>> > corresponding policy in the routing
>                         policy from the ANDSF. The
>                          > default
>                          > >>> > On another hand, I am a little confused
>                         between MIF and Multihoming,
>                          > >>> > would
>                          > >> To challenge one default link, it really
>                         takes time for mif to consider
>                          > on
>                          > >> it, current first step in mif is to
>                         consider some straight forward way
>                          > which
>                          > [email-masked] <mailto:[email-masked]>
>                         [email-masked] <mailto:[email-masked]>
>                     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Kevin Chin <[email-masked]>
Date: Fri, 23 Jan 2009 17:34:49 -0800

>
> As a final caveat, while it is tempting it is an extremely bad idea to try
> to add all of the system routing intelligence to the local node. Even the
> system does not have good visibility to many of the properties (actual path
> availability is only approximated, for example).  Using information the host
> / node already has is a very good idea.  Trying to get all the routing
> information (so as, for example, to have a better guess as to which
> interface can actually reach a given destination) would be a very bad idea.
>
Agree - Using information the host/node already has is a very good idea. The
host already has a set of tools and incentive to get it right.

> are tricky to solve.  If we want to solve them in a timely fashion, we need
> to keep to a small set of problems.
>
> Yours,
> Joel M. Halpern
>

I second this view. Let's define small set of issues to investigate.

regards,
Kevin

On Fri, Jan 23, 2009 at 10:01 AM, Joel M. Halpern <[email-masked]>wrote:

> Reading the discussion on this list, and the problem statement draft, I
> want to call attention to the fact that you are getting into a significant
> amount of mission creep (extending the target scope well beyond the problem
> statement.
>
> In particular, this discussion leads to issues that would require changes
> to transport behavior, host stack structure, and routing structure.  All of
> the issues that lead to that are valid issues. However, they are also under
> investigation in other parts of the community (Transport area, Internet
> Area, and Routing Research Group.) Resolving those problems is going to take
> significant time.  Please, help with all of those issues.  But if you want
> to make progress on the issues called out in the problem statement draft, it
> would be a good idea to narrow the scope, not expand it.
>
> As a final caveat, while it is tempting it is an extremely bad idea to try
> to add all of the system routing intelligence to the local node. Even the
> system does not have good visibility to many of the properties (actual path
> availability is only approximated, for example).  Using information the host
> / node already has is a very good idea.  Trying to get all the routing
> information (so as, for example, to have a better guess as to which
> interface can actually reach a given destination) would be a very bad idea.
>
> are tricky to solve.  If we want to solve them in a timely fashion, we need
> to keep to a small set of problems.
>
> Yours,
> Joel M. Halpern
>
> Yungui Wang wrote:
>
>>
>> Hello, Hui
>>  Agree with your statement.  However, it (the app/flow has to be restarted
>> when interface-handoff happens) is actually an app/flow mobility issue
>> related to multiple interfaces.  Thus, it seems the working item MIF is the
>> just place to resolve it.  Hope it make sense. :_)
>>  B.R.
>> Yungui
>>
>>                        mif is targetting at multiple interface whatever it
>> has how
>>            many ip address on each of them.

---

From: Yungui Wang <[email-masked]>
Date: Sat, 24 Jan 2009 09:55:19 +0800

Hello

Please see inline...

  ----- Original Message ----- 
  From: Joel M. Halpern 
  To: [email-masked] 
  Sent: Saturday, January 24, 2009 2:01 AM
  Subject: Re: [mif] mobility issues and general issues on mif

  [Yungui] In this phase, I think, the mission is not very clear yet. I was just shooting out a bullet related to MIF. It can be droped/picked up if we can justify something pointless or senseful. 

  [Yungui] I just want to clarify whether MIF is concerning that issue. Nothing of solution is.  

  [Yungui] Something reasonable. However, I am trying to clarify the concrete issue whether is in the scope of MIF. Do you mean the scope has been identified (e.g. in the base ps draft) and can be closed now?

  [Yungui] Do nothing is the best news. But it (routing, etc.) should be guaranteed fine-tuned. 

  B.R.
  Yungui

  Yours,
  Joel M. Halpern

---

From: Hui Deng <[email-masked]>
Date: Mon, 26 Jan 2009 23:38:22 +0800

Hi, Yungui,

Based on current IP model (RFC 1122 strong and weak model ), without IP
mobility involvement, what the operator could do at the moment is crueily
stop and restart the service. :)

thanks for the disucssion.

-Hui

> when interface-handoff happens) is actually an app/flow mobility
> issue related to multiple interfaces.  Thus, it seems the working item
> MIF is the just place to resolve it.  Hope it make sense. :_)
>
> B.R.
> Yungui
>
>
> *From:* Hui Deng <[email-masked]>
> *To:* Yungui Wang <[email-masked]>
> *Cc:* [email-masked] ; [email-masked]
>> Sorry for late response. In my understanding, one issue of MIF is
>> interface selection (or named access selection). However, interface
>> selection of a MIF-node is serving for its up-layer app/flow.
>>
>>  When one link associated with one interface of MIF-node is down or
>> congested, interface re-selection is needed. That's one type of mobility of
>> app/flow between different interfaces I wanted to address.
>>
> If one interface is down or congested, then application will be down as
> well, this socket will close as well, and you would like to move some
> application, then you have to restart to do it.
>
>> *From:* Hui Deng <[email-masked]>
>>   *To:* Yungui Wang <[email-masked]>
>> *Cc:* [email-masked] ; [email-masked]
>>> One comments, whether is the IP address model to be investigated within
>>> MIF? For example, there are different types of IP address model for
>>> MIF-terminal, per IP address per IF, one IP address for multiple IF(s),
>>> etc. If considered that, mobility of application/flow over IP layer
>>> seems impliedly to be studied (e.g. in topic of IP route changing).
>>>
>>> B.R.
>>> Yungui
>>>
>>>
>>> *From:* Hui Deng <[email-masked]>
>>> *Cc:* [email-masked]
>>>> I've joined recently this ML and I believe discussed topics very
>>>> interesting (BTW thanks to MIF promoters for bringing these issues to IETF).
>>>> So, please let me jump into your discussion.
>>>
>>> Thanks again.
>>>
>>>
>>>>
>>>> Regarding difference between MIF and multihoming: it seems there is
>>>> confusion with mobility. AFAIU, MIF is only supposed to deal with routing
>>>> issue at the multi-interface MN side. The issue is to select the "best"
>>>> interface for each outgoing IP flow and, in MIF context, access selection
>>>> does not necessarily imply flow mobility with IP session continuity between
>>>> interfaces. Nevertheless, solution should work for terminal with several
>>>> active interfaces at the same time (multi-homed), or for terminal with a
>>>> single interface at a time. Am I correct?
>>>
>>>> Regarding ANDSF issue, I agree with preceding emails: I think access
>>>> selection should rely on policy. There are a couple of selection models but
>>>> the simplest is the selection managed by the terminal and based on local
>>>> policies and measurement on the access link. The policies may be
>>>> provided/updated by a server via out-of-band mechanism or on-demand
>>>> (typically before selection) if policies include "dynamic" recommendation
>>>> (e.g. access xx is overload and forbidden to application type yy). Now you
>>>> can call the policy server ANDSF, or whatever you want, it is just a generic
>>>> functional entity in the architecture and this entity is above all access
>>>> networks. Note the access selection via policy server meet MIF requirement
>>>> as well as selection in inter-access mobility situation.
>>>
>>> Howver I would like to raise one case, sometime, if the network
>>> congested, terminal couldn't visit policy server such as ANDSF, only network
>>> side know what happen, they may re-arrange some traffic for mobile terminal,
>>> I guess that this is been discussed in 3GPP SA2 side at the moment.
>>>
>>>
>>>>
>>>>
>>>> > > defined to provide the policy in IETF until now. So let us consider
>>>> it
>>>> > be
>>>> > > general, which
>>>> > > means it's one policy server that provides the routing policy to UE
>>>> when
>>>> > UE
>>>> > > is connecting
>>>> > > it.
>>>> > >> ANDSF in 3GPP 23.401 do cover only 3GPP network, how could ANDSF
>>>> work
>>>> > for
>>>> > >>> > On another hand, I am a little confused between MIF and
>>>> Multihoming,
>>>> > >>> > would
>>>> > >> To challenge one default link, it really takes time for mif to
>>>> consider
>>>> > on
>>>> > >> it, current first step in mif is to consider some straight forward
>>>> way
>>>> > which
>>>  ------------------------------
>>>

---

From: Hui Deng <[email-masked]>
Date: Mon, 26 Jan 2009 23:59:12 +0800

Hi, Joel,

I saw your attentions are very good advice here.
we will avoid to overlap with multipath transport and Multihoming site et
al.
To finish the timeline work is our top focus, it implies that current PS
drafts will our main target.

Regarding to your caveat, to better use information host already has will be
good idea, other than let host be a wisdom.

Thanks for your suggestions.
Regards,

-Hui

2009/1/24 Joel M. Halpern <[email-masked]>

---

From: Hui Deng <[email-masked]>
Date: Tue, 27 Jan 2009 00:01:19 +0800

Hi, Kevin,

I agree with your all here, small set of issues will be a good start.

Can you give more detail information about what host already has? such as
what kind set of tools and incentives?
thanks again.

-Hui
2009/1/24 Kevin Chin <[email-masked]>

>> try to add all of the system routing intelligence to the local node. Even
>> the system does not have good visibility to many of the properties (actual
>> path availability is only approximated, for example).  Using information the
>> host / node already has is a very good idea.  Trying to get all the routing
> Agree - Using information the host/node already has is a very good idea.
> The host already has a set of tools and incentive to get it right.
>
>
>
>>> restarted when interface-handoff happens) is actually an app/flow mobility
>>> issue related to multiple interfaces.  Thus, it seems the working item MIF
>>> is the just place to resolve it.  Hope it make sense. :_)
>>>  B.R.
>>> Yungui
>>>
>>>                        mif is targetting at multiple interface whatever
>>> it has how