ietf
[Top] [All Lists]

Re: [mif] WG Review: Multiple InterFaces (mif)

2009-04-24 11:41:29
Hi, Ted,

Excuse me for late reply, thanks for the discussion.

The reason why I said before is that currently there are limtied ISP
providing ICE support for open applications, anyhow, P2P made a smart
way to reach it.

For what I know application which need ICE like IMS is normally go to
independent APN.
That could be guaranteed since it is kind of application binding APN.

Today most mobile application binding with APN(kind of interface like)
or could be on-demand select for user. I guess Marc raised similar
consideration which allow application to call such interface API, then
it can run depending on different connection's characteristic.

Please kind help to provide your text regarding this application
scenario, it will be helpful for MIF PS could include those.
I will re-read the spec which you recommend and to know the potential needs.

thanks again

-Hui


2009/4/24 Ted Hardie <hardie(_at_)qualcomm(_dot_)com>:
At 6:30 AM -0700 4/23/09, Hui Deng wrote:
For what I know at the moment service provider deployment experience,
ICE like solution has been deployed by a dedicate close network, this
is not interact with MIF space we talked here, mif are resolve general issue
with host connections, in that scenario, application is isolated.

thanks.

-Hui.

Forgive me, Hui, but it is not clear to me whether you think the application
is isolated in situations where ICE is in use, or whether it is isolated in 
the
work for which MIF might be chartered.

If your point is that not all applications have a signalling-path mechanism
for trading candidates using SDP, that is certainly true.  What is truly scary
is that this makes applications which can use ICE better off than the common
case, despite ICE's complexity.  I hope, after reading the full ICE spec and
recognizing that there are *still* cases where it does not work to establish
connectivity, you will see the scope of the problem.

Interfaces/network attachments may have different reachability characteristics
(e.g. be part of different address realms or otherwise have substantially
different access to parts of the network).  There are classes of application
which will want to make interface choices based on those characteristics.

There are many other characteristics which may play into interface choices
(do I already have a data channel on interface X, and need to acquire it on
interface y?), and I do not want to minimize those, power savings being
a big deal in my day job choices for this type of thing.  But the
applications' needs here can't be subordinate to those, or the whole point
of the link--you know, traffic across it--is lost.

Just my personal opinion, despite the mention of a day job,
                               regards,
                                       Ted


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf