Subject: Re: [mif] AMSS/Brew Multi-interface handling

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 3 May 2010 16:29:18 -0700

Hello,

Hui Deng wrote:
> Laganier, Julien <[email-masked]>:
> > Hui Deng wrote:
> >> 2010/4/14 Laganier, Julien <[email-masked]>:
> >> > Hui Deng wrote:
> >> >>
> >> >> just two clarifications AMSS/Brew DNS configuration is
> >> >> interface based other than host based?
> >> >
> >> > Quoting the text George sent:
> >> >
> >> >   AMSS allows each interface to be configured with its own set of
> >> >   DNS configuration parameters - a list of DNS servers, domain names
> >> >   etc.
> >>
> >> As you can see from the MIF discussion, even configuration could be
> >> interface based, but final DNS server selection could be host based,
> >> does AMSS/Brew works similar?
> >
> > Quoting the text George sent:
> >
> >> Interface selected to make a DNS resolution is the one to which
> >> application making the DNS query is bound.  Applications can also
> >> specify a different netpolicy as part of DNS request to select another
> >> interface for DNS resolution.  Regardless, all the DNS queries are
> >> sent only over this selected interface using the DNS configuration
> >> from the interface.
> >
> > This seems to answer your question, doesn't it?
>
> It still not clear to me, like the last sentence, it doesn't say
> application like web browser which could use multiple interfaces, 
> which interface will this application be bound to?

If the web browser has not requested connectivity via a specific netpolicy then the application is not bound to any specific interface. A separate connexion manager will be responsible to bring up or down network interfaces, an the application can use any of the interfaces that are up. The AMSS will choose the interface based on the provisioned routing policies. 

> >> >> secondly, network profile could identify only APN other than PDP
> >> >> context?
> >> >
> >> > Quoting the text George sent:
> >> >
> >> >   The network profile identifies a type of network domain
> >> >   or service within a certain network technology, such as 3GPP APN
> >> >   or Mobile IP Home Agent.  It also specifies all the mandatory
> >> >   parameters required to connect to the domain such authentication
> >> >   credentials and other optional parameters such as QoS attributes.  
> >> >   Network Profile is technology specific and set of parameters contained 
> >> >  in the profile could vary for different technologies.
> >>
> >> wifi has two type connections:connected through APN, or directed
> >> connected with Internet
> >> assume you have 3G+Wifi Connections,
> >> in your profile, it would be the same APN for 3G and Wfi, then you
> >> have to rely on access type?
> >> but access type will differentiate 3g and wifi.
> >> So who will be high priority? access type or APN(profile).
> >
> > I am not sure I follow you. Let me try to sketch what happens:
> >
> > An application specifying an APN in its network profile means that it
> > desire to connect to the PDN named by this APN.
> >
> > As a result, only interfaces connecting to that APN will be selected,
> > which rules out WiFi by itself and keeps in 3G, and any of the 3GPP
> > accesses over WiFi (such as 3GPP I-WLAN or either of the various non-
> > 3GPP accesses over S2a/b/c interfaces.)
> >
> > If the application has specified a preference for an ANY_Cellular
> > access technology (or say HSDPA) then 3G will be selected, if the
> > application has specified a preference for an ANY_Wireless access
> > technology (or say IEEE 802.11) the 3GPP I-WLAN application will be
> > selected. If the application hasn't specified anything, the default
> > access will be selected.
> >
> > Does the above clarify the situation?
>
> Could I understand that access type is more high priority than APN,
> if that is what it is designed, please kind help to clarify the text,

I do not understand what you mean by the access type being higher priority than the APN. If an application has specified connection to a given APN, then it ought to be connected to a network connecting to that APN. What else is needed?

--julien

---

From: Hui Deng <[email-masked]>
Date: Tue, 4 May 2010 22:46:51 +0800

Hello,

Inline please,

> If the web browser has not requested connectivity via a specific netpolicy then the application is not bound to any specific interface. A separate connexion manager will be responsible to bring up…
==> if you have further operation like double connextion manager,
then it may need some text to clarify it., thanks,

> I do not understand what you mean by the access type being higher priority than the APN. If an application has specified connection to a given APN, then it ought to be connected to a network connec…
==> let me try to give you more concrete example, say a web browser
could visit both WAP APN and Internet APN.
and the host has specified WLAN high priority than 3G, and browser
would like to visit a WAP website, which connection
will be used? thanks.

-Hui

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 4 May 2010 08:05:01 -0700

Hi Hui,

Hui Deng wrote: 
> >> >> >   AMSS allows each interface to be configured with its own set
> >> >> >   of DNS configuration parameters - a list of DNS servers, domain
> >> >> >   names etc.
> >> >>
> >> >> As you can see from the MIF discussion, even configuration could
> >> >> be interface based, but final DNS server selection could be host
> >> >> based, does AMSS/Brew works similar?
> >> >
> >> >> specify a different netpolicy as part of DNS request to select
> >> >> another interface for DNS resolution.  Regardless, all the DNS
> >> >> queries are sent only over this selected interface using the DNS
> >> >> configuration from the interface.
> >> >
> > If the web browser has not requested connectivity via a specific
> > netpolicy then the application is not bound to any specific interface.
> > A separate connexion manager will be responsible to bring up or down
> > network interfaces, an the application can use any of the interfaces
> > that are up. The AMSS will choose the interface based on the
> > provisioned routing policies.
>

I do not know what you're referring to.

> >> >> >> secondly, network profile could identify only APN other than
> >> >> >> PDP context?
> >> >> >
> >> >> >   or service within a certain network technology, such as 3GPP
> >> >> >   APN or Mobile IP Home Agent.  It also specifies all the mandatory
> >> >> >   Network Profile is technology specific and set of parameters
> >> >> >  contained in the profile could vary for different technologies.
> >> >>
> >> >> in your profile, it would be the same APN for 3G and Wfi, then
> >> >> you have to rely on access type?
> >> > An application specifying an APN in its network profile means that
> >> > it desire to connect to the PDN named by this APN.
> >> >
> >> > As a result, only interfaces connecting to that APN will be
> >> > selected, which rules out WiFi by itself and keeps in 3G, and any of
> >> > the 3GPP accesses over WiFi (such as 3GPP I-WLAN or either of the
> >> > various non-3GPP accesses over S2a/b/c interfaces.)
> >> >
> >> > technology (or say IEEE 802.11) the 3GPP I-WLAN application will
> >> > be selected. If the application hasn't specified anything, the
> >> > default access will be selected.
> >> >
> > I do not understand what you mean by the access type being higher
> > priority than the APN. If an application has specified connection to a
> > given APN, then it ought to be connected to a network connecting to
> > that APN. What else is needed?
>

If the web browser wants to access the WAP APN it has to specify the WAP APN in the network profile of its netpolicy. Then it will be connected to that APN (WAP.)

Conversely, if the web browser wants to access the Internet APN is has to specify it in the network profile of its netpolicy, and it will then be connected to that APN (Internet.)

If the web browser doesn't specify any APN, then it will be connected as per the policy routing that was provisioned on the UE.

Now this is all a very interesting conversation and we've exchanged quite a number of emails over the last month, but coming back to my original question to Margaret: Is the text George provided going to be incorporated in the next rev. of the current practice draft?

Thank you.

--julien

---

From: Hui Deng <[email-masked]>
Date: Wed, 5 May 2010 22:35:04 +0800

Hi Julien

inline please,

> I do not know what you're referring to.
==>I read through the text which you proposed, AMSS is one kind of
mobile platform connection manager, but normally mobile OS
also has the other connection manager running over there, how could
this two CMs can coordinate each other?

> If the web browser wants to access the WAP APN it has to specify the WAP APN in the network profile of its netpolicy. Then it will be connected to that APN (WAP.)
==>Yes, it has specified WAP APN ip address there, but currently
network policy has high priority for WLAN.
will WAP browsing using WLAN connection?

> If the web browser doesn't specify any APN, then it will be connected as per the policy routing that was provisioned on the UE.
==> are you saying if there is no APN specified, then there will be
based on connection priority?

thanks

-Hui

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 5 May 2010 07:50:04 -0700

Hui,

[cutting through the long thread]

> >> > netpolicy then the application is not bound to any specific interface
> >> > A separate connexion manager will be responsible to bring up or
> >> > down network interfaces, and the application can use any of the
> >> > interfaces that are up. The AMSS will choose the interface based on the

The AMSS is not a connection manager. The text we're discussing says is the application does not request connectivity itself, then a _separate_ connection manager is responsible to bring the interfaces up and down. That connection manager can belong to the mobile OS.

[...]

> >> >> Could I understand that access type is more high priority than
> >> >> APN, if that is what it is designed, please kind help to clarify 
> >> >> the text,
> >> >
> > If the web browser wants to access the WAP APN it has to specify the
> > WAP APN in the network profile of its netpolicy. Then it will be
> > connected to that APN (WAP.)
>

I don't know which IP address you are referring to.

If the browser has specified WAP APN, then it will only be connected to a network that corresponds to the WAP APN. If the browser has also specified that it prefers WLAN over Cellular, then a 3GPP I-WLAN session or non-3GPP access PDN connection could be used if available. I think we've discussed this already here: <http://www.ietf.org/mail-archive/web/mif/current/msg00730.html>

> > Conversely, if the web browser wants to access the Internet APN is
> > has to specify it in the network profile of its netpolicy, and it will
> > then be connected to that APN (Internet.)
> >
> > If the web browser doesn't specify any APN, then it will be connected
> > as per the policy routing that was provisioned on the UE.
>

As I said, it will be based on the policy routing provisioned on the UE.

> thanks

You are very welcome. 

However, it seems I have answered a reasonable number of your questions, while you still haven't answered the only question I've asked:

> > Now this is all a very interesting conversation and we've exchanged
> > quite a number of emails over the last month, but coming back to my
> > original question to Margaret: Is the text George provided going to be
> > incorporated in the next rev. of the current practice draft?

Would you please you or Margaret (to whom I originally asked the question) answer this?

Thank you.

--julien

---

From: Hui Deng <[email-masked]>
Date: Wed, 5 May 2010 23:21:48 +0800

Julien,

inline please,

> The AMSS is not a connection manager. The text we're discussing says is the application does not request connectivity itself, then a _separate_ connection manager is responsible to bring the interf…
==> I am getting confused here, if the AMSS is not a connection manager,
then what is AMSS, from the text proposed below
"AMSS supports a concept of “netpolicy” which allows each application
to specify the type of network connectivity desired. "
and what's the relationship between AMSS, mobile OS CM and applications?

> I don't know which IP address you are referring to.
it is wap gw ip address

> If the browser has specified WAP APN, then it will only be connected to a network that corresponds to the WAP APN. If the browser has also specified that it prefers WLAN over Cellular, then a 3GPP…
yes, IWLAN will work, here question goes to if there is no WLAN,
how it could work?

> As I said, it will be based on the policy routing provisioned on the UE.
I guess that my confusion is the policy routing here is not clear to me
and your answer continue goes to policy routing could be provisioned as it like,
Fine, it is clear for me now.

> However, it seems I have answered a reasonable number of your questions, while you still haven't answered the only question I've asked:
==> I could answer your question after the text is clear for me.
I also spent so long reasonable time to understand how it could work
through email,
and would like to avoid when the other people read the text, it is
still not clear for them.

> Would you please you or Margaret (to whom I originally asked the question) answer this?
==> I personally prefer after the text is more clear.

thanks again

-Hui

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 5 May 2010 10:24:25 -0700

Hui Deng wrote:
> > The AMSS is not a connection manager. The text we're discussing says
> > is the application does not request connectivity itself, then a
> > _separate_ connection manager is responsible to bring the interfaces up
> > and down. That connection manager can belong to the mobile OS.
>
> "AMSS supports a concept of "netpolicy" which allows each application

AMSS is a low level connectivity platform that is provided with Qualcomm chipsets, on top of which OEMs can build to provide the necessary connectivity to applications. The interaction model between AMSS, the Operating System, and the applications is not unique and depend on the design chosen by the OEM.  

Applications can invoke the AMSS directly to request connectivity according to their own netpolicies, if the mobile OS exposes applications to an AMSS API. 

The Mobile OS can let an application invoke the AMSS directly (via API as described above), or provide its own connection manager that will request connectivity to the AMSS based on applications needs. The interaction between the OS connection manager and the applications is not under the control of the AMSS and is OS dependent.

> > [...]
> >
> >> >>
> >> >> ==> let me try to give you more concrete example, say a web
> >> >> browser could visit both WAP APN and Internet APN.
> >> >> and the host has specified WLAN high priority than 3G, and
> >> >> browser would like to visit a WAP website, which connection
> >> >> will be used? thanks.
> >> >
> >> > If the web browser wants to access the WAP APN it has to specify
> >> > the WAP APN in the network profile of its netpolicy. Then it will be

AFAIK an APN is not an IP address.

> > If the browser has specified WAP APN, then it will only be connected
> > to a network that corresponds to the WAP APN. If the browser has also
> > specified that it prefers WLAN over Cellular, then a 3GPP I-WLAN
> > session or non-3GPP access PDN connection could be used if available. I
> > think we've discussed this already here: <http://www.ietf.org/mail-
> ? archive/web/mif/current/msg00730.html>
>

If the application has a requirement to use WLAN, then no connectivity is provided.

If the application has a preference for WLAN, then connectivity will provided via a cellular access technology. 

> >> > has to specify it in the network profile of its netpolicy, and it
> >> > will then be connected to that APN (Internet.)
> >> >
> >> > If the web browser doesn't specify any APN, then it will be
> >> > connected as per the policy routing that was provisioned on the UE.
> >>

Good.

> >> thanks
> >
> > You are very welcome.
> >
> > However, it seems I have answered a reasonable number of your
> questions, while you still haven't answered the only question I've
> asked:
>
> through email, and would like to avoid when the other people read the
> text, it is still not clear for them.

Hopefully now it is clear to you.
 
> >> > Now this is all a very interesting conversation and we've
> >> > exchanged quite a number of emails over the last month, but coming
> >> > back to my original question to Margaret: Is the text George provided
> >> > going to be incorporated in the next rev. of the current practice draft?
> >

I personally find the text clear. If you still think the text is unclear, it would help if you were suggesting updates to the text that could remedy to that.

--julien

---

From: Hui Deng <[email-masked]>
Date: Thu, 6 May 2010 22:56:06 +0800

Inline please,

> The Mobile OS can let an application invoke the AMSS directly (via API as described above), or provide its own connection manager that will request connectivity to the AMSS based on applications ne…
==> So if mobile OS would like to reply on his own CM, this Mobile OS
have to request to AMSS,
from this descrition, I would say AMSS is more like chipsets CM. From
originally proposed text,
I don't see such detail descrition. Is above text your proposed new text?

> AFAIK an APN is not an IP address.
In mobile, if you want to use any APN, you have to configure that GW IP address.

> Hopefully now it is clear to you.
Same as above, need more clear text.

> I personally find the text clear. If you still think the text is unclear, it would help if you were suggesting updates to the text that could remedy to that.
==> like the first part text which you wrote is more informative for
AMSS, please
help to revise and update it.

thanks

-Hui

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 6 May 2010 15:54:24 -0700

Hui,

Hui Deng wrote: 
> >> ==> I am getting confused here, if the AMSS is not a connection
> >> manager, then what is AMSS, from the text proposed below
> >> "AMSS supports a concept of "netpolicy" which allows each
> >> application to specify the type of network connectivity desired. "
> > AMSS is a low level connectivity platform that is provided with
> > Qualcomm chipsets, on top of which OEMs can build to provide the
> > necessary connectivity to applications. The interaction model between
> > AMSS, the Operating System, and the applications is not unique and
> > depend on the design chosen by the OEM.
> >
> > Applications can invoke the AMSS directly to request connectivity
> > according to their own netpolicies, if the mobile OS exposes
> > applications to an AMSS API.
> >
> > The Mobile OS can let an application invoke the AMSS directly (via
> > API as described above), or provide its own connection manager that
> > will request connectivity to the AMSS based on applications needs. The
> > interaction between the OS connection manager and the applications is
> > not under the control of the AMSS and is OS dependent.
>
> have to request to AMSS, from this descrition, I would say AMSS is more 
> like chipsets CM. From originally proposed text, I don't see such detail
> descrition. Is above text your proposed new text?

Since it seems that it makes things clearer to you, the text above can complement what George originally submitted.

> >> >> > the WAP APN in the network profile of its netpolicy. Then it
> >> >> > will be connected to that APN (WAP.)
> >> >>

AFAIK in a 3GPP system the UE is not aware of the IP address of the GGSN/P-GW, so I don't understand how the browser could possibly set the IP address of the GW... But that is beyond the point that we were discussing anyway.

[...]

> >> >> > back to my original question to Margaret: Is the text George
> >> >> > provided going to be incorporated in the next rev. of the current
> >> >> > practice draft?
> >> >
> > I personally find the text clear. If you still think the text is
> > unclear, it would help if you were suggesting updates to the text that
> > could remedy to that.
>
> AMSS, please help to revise and update it.

As I said we can certainly add this text to what George originally submitted. I will let it to Margaret to incorporate appropriately both pieces of text in the next revision of the draft. 

Thank you for the discussion.

--julien